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
