[U-Boot-Users] Incorrect flash ids?

[listmember at orkun.us <listmember@orkun.us>]

Anders,

Guess what! Knowing how picky everyone can be I actually did check the 
datasheets for all these. Perhaps you should also do the same before 
accusing me of doing that first.

I still stand behind that these are incorrect as it is in the spirit of the rest 
of  XXX_ID_YYYY macros. Take a look at the file!

I notice these problems because I happen to have 28F128J3A chip on 
Cogent CSB272 board that I am porting u-boot to. I actually did manually 
issue commands using BDI2000 and verified the value for 28F128J3A as 
well.

Also another thing it is obvious that while 28F128J3 has manufacturer 
(0x89) embedded (once correct and once incorrectly) in the value the 
27F127J3A does not have any manufacturer id (or rather manufid is set 
to 0x00 incorrectly). At least these two should have matched.

Best regards,
Tolunay

On 13 Jan 2004 at 9:55, Anders Larsen wrote:

> "listmember at orkun.us" <listmember@orkun.us> schreibt:
> >Taken from include/flash.c...
> >
> >#define INTEL_ID_28F128J3   0x89189818  /*  16M = 8M x 16 x 128 */
> ...
> >#define INTEL_ID_28F320J3A  0x00160016  /*  32M = 128K x  32    */
> >#define INTEL_ID_28F640J3A  0x00170017  /*  64M = 128K x  64    */
> >#define INTEL_ID_28F128J3A  0x00180018  /* 128M = 128K x 128    */
> >
> >If I understand correctly, it seems to me that these definitions are
> >incorrect.
> 
> I think they're not.
> >
> >I think correct definitions should be as follows:
> ...
> >#define INTEL_ID_28F320J3A  0x89168916  /*  32M = 128K x  32    */
> >#define INTEL_ID_28F640J3A  0x89178917  /*  64M = 128K x  64    */
> >#define INTEL_ID_28F128J3A  0x89188918  /* 128M = 128K x 128    */
> 
> The original IDs are correct; please verify with the data-sheets of the
> chips before starting to break things!
> >
> >Please note that INTEL_ID_28F128J3 also changed (0x89189818 =>
> >0x89188918). I think 8 and 9 changed places due to a typo.
> 
> I believe you're right about it being wrong (but I don't think
> 0x89188918 is correct, either. I don't have the data-sheet of that chip
> here, however, so I can't tell what it really should be).
> 
> The reason nobody noticed 'till now is that this particular ID is never
> read from the chip - the boards that use this flash chip (cradle,
> csb226, ep7312 and innokom, never tests for the actual chip but uses a
> hard-coded ID instead).
> >
> Cheers
>  Anders