[flashrom] [Patch] Add support for EN25Q series SPI flash chips

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Mon Jun 27 02:00:48 CEST 2011


Am 23.06.2011 01:04 schrieb David Hendricks:
> I'm still not sure what the best course of action is for dealing with the
> D16 versus Q16 evil twin scenario. Let's see if Carl-Daniel has further
> comments.
>
> Signed-off-by: David Hendricks <dhendrix at google.com>
>
> As we discussed on IRC, this particular chip supports "Serial Flash
> Discoverable Parameters" (SFDP). I tried to add support using the values
> listed in Table 9 of their datasheet, and left a TODO to update the probe
> routine later on.
>   

Ah yes, SFDP. Stefan has implemented a patch to support that in the
meantime.



> On Wed, Jun 22, 2011 at 9:15 AM, Stefan Tauner wrote:
>> somewhere below...
>> +#define EON_EN25QH16           0x7015
>
> Done. I rearranged the EN25Q* #defines a bit so they're in alphabetical
> order with respect to the other EN25* chips.
>
>
>   
>>> Index: flashchips.c
>>> ===================================================================
>>> --- flashchips.c      (revision 1285)
>>> +++ flashchips.c      (working copy)
>>> @@ -2807,6 +2807,8 @@
>>>       },
>>>
>>>       {
>>> +             /* Note: EN25Q16 is an evil twin which shares the model ID
>>> +                but has different write protection capabilities */
>>>               .vendor         = "Eon",
>>>               .name           = "EN25D16",
>>>       
>> change according to the macro name chosen (if applicable see above)
>>     
> The EN25D16 was there first... I'm not sure if we should change it. I
> imagine the D16 is out of production, but I assume *somebody* is using it.
>
> WWCDD? (What Would Carl-Daniel Do?)
>   

Evil twins... I have a patch for that: 
http://patchwork.coreboot.org/patch/1861/

The rules are simple:
If two chips are identical from a flashrom POV (same command set and
write/erase characteristics), combine them into one entry. If those
chips differ, give them two entries and mark them as evil twins.
Differing write protection is a corner case... we don't really have a
good write protection handling in flashrom (yet), and until one of the
four suggested/implemented designs is chosen, this is difficult to
handle. Is there a way to probe for the write protection capabilities?

Side note: Probing could be a bit more intelligent for the case of
almost-identical chips. It could calculate the greatest common command
set and offer to use that merging result. Other tricks are possible as well.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the flashrom mailing list