[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