[U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try

[Albert ARIBAUD <albert.aribaud@free.fr>]

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,
-- 
Albert.