[U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
Aaron Williams
Aaron.Williams at caviumnetworks.com
Sat Feb 12 08:14:42 CET 2011
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.
>
> 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
More information about the U-Boot
mailing list