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

[Carl-Daniel Hailfinger]

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
>
> 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

[Patch] Add support for EN25Q series SPI flash chips

[Stefan Tauner]

On Mon, 27 Jun 2011 02:00:48 +0200
Carl-Daniel Hailfinger  wrote:
> Am 23.06.2011 01:04 schrieb David Hendricks:
> > > > 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?)

the main question regarding the evil twin was if we should rename the
old, existing EN25D16 to EN25Q16 to match the other 25Q chips. there is
only the one 25D one in flashrom and i can only find a datasheet for
another one of that series (EN25D80, id 0x3015).
so i think it makes sense to rename the D16 to Q16 and to annotate it
and the Q80 (similar problem with different block protection).
> 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?

not directly, but the D series seems to not support "Dual I/O Fast
Read" (0xBB) and "Quad I/O Fast Read" (0xEB), so theoretically we could
(try to) probe for it, but it is not 100% conclusive and i have no
idea how we could do this right now anyway. :)

another possibility would be to read the OTP data. the D versions have
less OTP memory. it is not clear what data is returned for addresses
outside the specified OTP address range though and it is also not 100%
conclusive.

i think we just should not care for now because differentiation is
not really needed yet (no support for different protected ranges
anyway).