From mboxrd@z Thu Jan 1 00:00:00 1970 From: listmember at orkun.us Date: Tue, 13 Jan 2004 12:47:50 -0600 (CST) Subject: [U-Boot-Users] Incorrect flash ids? In-Reply-To: References: <14406.216.110.51.8.1073953444.squirrel@www.orkun.us><40036300.21469.1F117239@localhost> Message-ID: <19617.216.110.51.8.1074019670.squirrel@www.orkun.us> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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