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

[Albert ARIBAUD]

Le 12/02/2011 01:15, Aaron Williams a écrit :
> I think I found  the problem. The cfi code does not work properly in x8 mode.
>
> In x8 mode, according to the datasheet, the addresses should be doubled for
> all of the commands. Additionally, according to my correspondence with
> Spansion, there needs to be at least a 500ns delay after a reset command.
>
> The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT when
> it is actually 8-bits. Currently things just happen to work because the bus is
> being incorrectly detected as 16-bits,
>
> The 16-bit bus detection, however, breaks in x8 mode when it issues the
> commands for the manufacturer ID.
>
> In this case, the following takes place:
>
> In cmdset_amd_read_jedec_ids
> fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit
> flash_write16: Wrote 0xf0f0 to address 1f400000
> funlock writing 0xaa to address 0xaaa
> fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit
> flash_write16: Wrote 0xaaaa to address 1f401554
> funlock writing 0xaa to address 0x555
> fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit
> flash_write16: Wrote 0x5555 to address 1f400aaa
> fwc addr 1f401554 cmd 90 9090 16bit x 8 bit
> flash_write16: Wrote 0x9090 to address 1f401554
> flash_read8: Read 0x0 from address 1f400001
> flash_read8: Read 0x3f from address 1f400003
>
> This does not work.
>
> If the proper sequence is written, then it works fine.
>
> The proper sequence, according to the datasheet, is to do the following:
>
> write 0xf0 to address 0x0000
> write 0xaa to address 0xaaa
> write 0x55 to address 0x555
> write 0x90 to address 0xaaa
> read address 0 (returns 1 as expected)
> read address 2 (returns 0x7e as expected)
> ...
>
> So the cfi code is broken in the x8 case.

Hmm... It would be surprising that the x8 CFI code be broken -- not 
impossible, mind you -- because it was intensively used with a variety 
of chips, and thus extensively checked for brokenness.

What *might* be at stake is the result of the width detection, because 
many reputedly CFI compliant Flash devices are actually not compliant, 
especially among the dual-width, x8/x16, ones. On my ED Mini V2, there 
is a Macronix x8/x16 part which presents its CFI QRY response as a pure 
x16 even though it is a x8/x16, thus tricking the width detection 
mechanism into taking the wrong decision; I had to resort to using the 
LEGACY feature of manually defining the widths.

Did you check the Flash part against the CFI specs, including the QRY 
location and layout?

Can you boot into a RAM-baed u-boot and use its memory write and read 
commands (m[wd].[lwb]) to test the main CFI sequences of your Flash device?

Amicalement,
-- 
Albert.