[U-Boot-Users] Incorrect flash ids?
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) */
"listmember@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
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@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
listmember@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
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
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
participants (2)
-
Anders Larsen -
listmember＠orkun.us