[U-Boot-Users] Incorrect flash ids?

[U-Boot-Users] Incorrect flash ids?

[listmember at orkun.us]

Taken from include/flash.c...

#define INTEL_ID_28F128J3   0x89189818  /*  16M = 8M x 16 x 128 */
#define INTEL_ID_28F320J5   0x00140014  /*  32M = 128K x  32    */
#define INTEL_ID_28F640J5   0x00150015  /*  64M = 128K x  64    */
#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 correct definitions should be as follows:

#define INTEL_ID_28F128J3   0x89188918  /*  16M = 8M x 16 x 128 */
#define INTEL_ID_28F320J5   0x89148914  /*  32M = 128K x  32    */
#define INTEL_ID_28F640J5   0x89158915  /*  64M = 128K x  64    */
#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    */
#define INTEL_ID_28F256L18T 0x880D880D  /* 256M = 128K x 255 + 32k x 4 */

Please note that INTEL_ID_28F128J3 also changed (0x89189818 =>
0x89188918). I think 8 and 9 changed places due to a typo.

Best regards,
Tolunay

Here is the patch:

--- u-boot-1.0.0/include/flash.h        2003-08-29 17:00:48.000000000 -0500
+++ u-boot/include/flash.h      2004-01-12 18:14:33.061103106 -0600
@@ -207,12 +207,12 @@ extern int flash_real_protect(flash_info
 #define INTEL_ID_28F640C3T  0x88CC88CC /*  64M = 4M x 16 top boot sector 
     */
 #define INTEL_ID_28F640C3B  0x88CD88CD /*  64M = 4M x 16 bottom boot
sector    */

-#define INTEL_ID_28F128J3   0x89189818 /*  16M = 8M x 16 x 128 */
-#define INTEL_ID_28F320J5   0x00140014 /*  32M = 128K x  32    */
-#define INTEL_ID_28F640J5   0x00150015 /*  64M = 128K x  64    */
-#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    */
+#define INTEL_ID_28F128J3   0x89188918 /*  16M = 8M x 16 x 128 */
+#define INTEL_ID_28F320J5   0x89148914 /*  32M = 128K x  32    */
+#define INTEL_ID_28F640J5   0x89158915 /*  64M = 128K x  64    */
+#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    */
 #define INTEL_ID_28F256L18T 0x880D880D /* 256M = 128K x 255 + 32k x 4 */

 #define INTEL_ID_28F160S3   0x00D000D0 /*  16M = 512K x  32 (64kB x 32)  
     */

[U-Boot-Users] Incorrect flash ids?

[Anders Larsen]

"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

[U-Boot-Users] Incorrect flash ids?

[listmember at 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

[U-Boot-Users] Incorrect flash ids?

[Anders Larsen]

listmember at orkun.us schreibt:
>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 did, of course. And checked with the existing u-boot code, too:
It should be rather obvious that changing these IDs (which are supposed
to match the codes read back from the chips) will indeed break existing
code.

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

Looking into the data sheet of the Intel Strata chips (28FxxxJ3A, Intel
document number 290667-009) at Table 15 (Identifier Codes) you'll see
that the device codes (found at word address 0001) are
28F320J3A: 0x0016
28F640J3A: 0x0017
28F128J3A: 0x0018
No ambiguity here.

Looking into include/flash.h at the xxxx_ID_yyyy macros I fail to see
a single one with embedded manufacturer ID (apart from the (incorrect)
INTEL_ID_28F128J3).
>
>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.

Then you clearly didn't do it in the same way that the (existing)
code does it; the manufacturer code is read separately from the chip ID
(see flash_get_size() in board/eric/flash.c for a good example).
>
>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.

As already stated in my previous mail, I agree that the code for
28F128J3 (without 'A') is incorrect
(BTW, the manufacturer code is _not_ supposed to be embedded in the
xxxx_ID_yyyy codes, see above).

Cheers
 Anders

[U-Boot-Users] Incorrect flash ids?

[listmember at orkun.us]

Anders,

I guess I understand you now. I have a few things left to be clarified.

> Looking into the data sheet of the Intel Strata chips (28FxxxJ3A, Intel
> document number 290667-009) at Table 15 (Identifier Codes) you'll see
> that the device codes (found at word address 0001) are
> 28F320J3A: 0x0016
> 28F640J3A: 0x0017
> 28F128J3A: 0x0018
> No ambiguity here.

We have the same documents but apparently I was interpreting the data in
the sheet as opposed to codes in flash.h differently.

I have the the following documents:

28F320J5, 28F640J5: Document #290606-015 (Id Codes Table 14)
28F128J3, 28F640J3, 28F320J3: Document #290667-014 (Id Codes Table 5)
28F128J3A, 28F640J3A, 28F320J3A: Document #290667-009 (Id Codes Table 15)

Document 290667-014 and 290667-009 are the same in terms of ID codes. For
ID codes perspective J3 and J3A are the same.

In each of these list manufacture code is one byte (0x89) and the device
id is another byte. If, as you say, the ones that does not embed
manufacture code are the correct ones, in this case INTEL_ID_28F128J3 is
the incorrect one as it should be exactly like INTEL_ID_28F128J3A based on
the datasheets. I guess you agree on this. So, at least this discussion is
uncovering a bug one way or another...

I also looked at AMD 29LV160B and in table 9 AMD codes for this device is
documented (Publication #21358, Rev G Ammendment/+1 Feb 1999) in Table 9
as:

Byte (8-Bit) Mode: 0x49
Word (16-bit) Mode: 0x2249

However the AMD_ID_LV160B is setup as: 0x22492249

Why is it so? Shouldn't AMD_ID_LV160B be just 0x49 or 0x2249 by the same
reasoning? What is the reason for duplication of codes in the high and low
order 16-bits and if it is supposed to be like this why not 28F128J3A =>
0x00180018?

> Then you clearly didn't do it in the same way that the (existing)
> code does it; the manufacturer code is read separately from the chip ID
> (see flash_get_size() in board/eric/flash.c for a good example).

I actually started from one of the boards that had code for 2 flash chips
side by side and there is no actual detection code. The info->flash_id was
setup as:

flash_info[i].flash_id =  (INTEL_MANUFACT & FLASH_VENDMASK) |
                          (INTEL_ID_28F128J3A & FLASH_TYPEMASK);

This worked OK until I added some code for flash_real_protect from another
project which happened to use proper code FLASH_28F128J3A macro. So, I
fixed flash_init() and flash_print_info() to use FLASH_28F128J3A instead.

Apparently, probably due to misunderstanding and confusing flash_id to
xxx_ID_yyy a number of boards use wrong constants while setting up
flash_info[i]_flash_id field. For example:

cradle/flash.c
csb226/flash.c
ep7312/flash.c
innokom/flash.c
sc520_spunk/flash.c

These are not the complete list using incorrect macros but these also
appear to be the only ones that use incorrectly defined macro
INTEL_ID_28F128J3 instead of the correct J3A macro. They work because they
use the same incorrect code to check later on. I examined the code and it
seems that the change in INTEL_ID_28F128J3 should not affect any of these
since they don't use it for detection purpose at all.

I guess I just happened to base my initial code on one of these (possibly
csb226 since I am doing csb272).

I looked at actual values of these macros when I was investigating why my
flash_real_protect was not working properly. At that time, I happened to
have a look at flash.h file and I noticed INTEL_ID_28F128J3 was different
than INTEL_ID_28F128J3A and assumed the setup (which obviously includes
Manufacture code in it) was the correct one and others were wrong and
wrote my original email based on this. I did check the codes in the
datasheet seeing manufacture code 0x89 in INTEL_ID_28F128J3 made me assume
that it was the right one and the values were supposed to be combination
of Manufacture codes and Device Id for Intel devices. I guess it is clear
now why I made the claim initially.

> (BTW, the manufacturer code is _not_ supposed to be embedded in the
> xxxx_ID_yyyy codes, see above).

That was my mistake as there is no documentation on how these should be I
assumed the wrong one was correct.

> Cheers
>  Anders

[U-Boot-Users] Incorrect flash ids?

[listmember at orkun.us]

> Anders,
>

> Why is it so? Shouldn't AMD_ID_LV160B be just 0x49 or 0x2249 by the same
> reasoning? What is the reason for duplication of codes in the high and low
> order 16-bits and if it is supposed to be like this why not 28F128J3A =>
> 0x00180018?

Actually, it is 0x00180018. So, the question is why duplicate the id in
the high and low order 16 bits?

The only problem seems to be INTEL_ID_28F128J3 which should be the same as
INTEL_ID_28F128J3A per datasheet.

Regards,
Tolunay

[U-Boot-Users] Incorrect flash ids?

[Rune Torgersen]

Because these flashes are 16bit wide and there are usually two of them
(one for high order 16bits and one for the low order 16 bits)

> 
> Actually, it is 0x00180018. So, the question is why duplicate 
> the id in the high and low order 16 bits?
>