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