Re: [flashrom] [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).