On Friday, February 11, 2011 11:51:24 pm Albert ARIBAUD wrote: > Le 12/02/2011 08:14, Aaron Williams a écrit : > > On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote: > >> Le 12/02/2011 07:42, Aaron Williams a écrit : > >>> I've placed the results of the scan below. > >>> > >>> The problem is that in 8-bit mode the code that scans the CFI does not > >>> follow the specification. > >>> > >>> In the specification to read the CFI data you write 0x98 to address > >>> 0xAA, not address 0x55 as you do in 16-bit mode. flash_offset_cfi is > >>> set to 0x55 which in this case is wrong and won't work. When it tries > >>> 16-bit mode then it writes to address 0xAA which causes it to work. > >> > >> Let us see the specs, then. The specs I have (admittedly not necessarily > >> the latest: I use JESD 68.01, september 1999) state the following: > >> > >> "Nonvolatile memory devices are assumed to power up in a read-only > >> state. Independent of that assumption, the Query structure contents must > >> be able to be read at the specific address locations following a single > >> system write cycle where: 1) a 98h Query command code is written to 55h > >> address location within the device’s address space (in maximum device > >> buswidth), and 2) the device is in any valid read state, such as “Read > >> Array” or “Read ID Data”. > >> > >> I read "55h address location within the device’s address space (in > >> maximum device buswidth" as implying that 0x55 is the only address to > >> use but is in device bus terms, and that may mean different CPU > >> addresses for different devices types: for x8 devices, one should access > >> the byte address 0x55 because the device bus is in bytes, whereas for > >> x8/x16 and x16 devices, one should access byte address 0xAA because it > >> translates to x16 device bus address 0x55 -- regardless of actual x8 or > >> x16 mode. > >> > >> Are we in sync here? > > > > This is wrong. The address is actually 0xAA in x8 mode and 0x55 in x16 > > mode according to the data sheet. > > Yes, but the 0xAA address is a byte address and the 0x55 address is a > word address, translating to byte address 0xAA as well. > > On the JESD 68.01 spec, page number 3 (that's PDF page 9), the byte > location for a pure x8 device is 0x55, and 0xAA for a x16 device, both > in x16 or x8 mode (the difference is that byte mode will expect a byte > write of 0x98 where x16 mode will expect a word write of 0x0098). > > This is in sync with my Macronix MX29LV400CB/CT spec. > > >> Now it's been a long time since I last looked at my ED Mini V2 Flash, > >> but I should be able to dig it up and do a test within one or two hours. > >> > >>> -Aaron > >> > >>> Here's the results of the scan: > >> Yes, that's what U-boot *CFI code* does, but I'd like to see what very > >> basic writes and reads give without any detection logic involved. > >> > >> Amicalement, > > > > When I use the addresses and data shown in the datasheet, everything > > responds as it should using mw.b and md.b. > > > > Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 > > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa > > Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 > > Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 > > Octeon ebb6300(ram)# md.b 0x1f400000 1 > > 1f400000: 01 . > > Octeon ebb6300(ram)# md.b 0x1f400002 1 > > 1f400002: 7e ~ > > Octeon ebb6300(ram)# md.b 0x1f400004 1 > > 1f400004: 00 . > > > > Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 > > Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 > > Octeon ebb6300(ram)# md.b 0x1f400020 > > 1f400020: 51 Q > > Octeon ebb6300(ram)# md.b 0x1f400022 > > 1f400022: 52 R > > Octeon ebb6300(ram)# md.b 0x1f400024 > > 1f400024: 59 Y > > Octeon ebb6300(ram)# md.b 0x1f400026 > > 1f400026: 02 . > > Octeon ebb6300(ram)# md.b 0x1f400028 > > 1f400028: 00 . > > > > -Aaron > > The CFI query is normal for a x16 device: byte address 0xAA is word > address 0x55, which is what is expected from a x16 device in x8 mode as > in x16 mode. > > Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode? > > Amicalement, You mean like this?
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 Octeon ebb6300(ram)# md.b 0x1f400000 0 Octeon ebb6300(ram)# md.b 0x1f400000 1 1f400000: 01 . Octeon ebb6300(ram)# md.b 0x1f400002 1 1f400002: 7e ~ Octeon ebb6300(ram)# md.b 0x1f400004 1 1f400004: 00 . Octeon ebb6300(ram)# md.b 0x1f400005 1 1f400005: 00 . Octeon ebb6300(ram)# md.b 0x1f400006 1 1f400006: 1a . Octeon ebb6300(ram)# md.b 0x1f400008 1 1f400008: 00 . Octeon ebb6300(ram)# md.b 0x1f40000a 1 1f40000a: 00 . Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 1f400020: 51 Q Octeon ebb6300(ram)# md.b 0x1f400022 1f400022: 52 R Octeon ebb6300(ram)# md.b 0x1f400024 1f400024: 59 Y Octeon ebb6300(ram)# md.b 0x1f400026 1f400026: 02 . Octeon ebb6300(ram)# md.b 0x1f400028 1f400028: 00 . -Aaron _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot