[U-Boot] [PATCH] ARM DaVinci: Adding CONFIG options for NAND ALE and CLE

[David Brownell]

On Tuesday 28 April 2009, s-paulraj at ti.com wrote:
> The CLE and ALE for DaVinci DM644x is not the same as DM646x. This patch
> adds 2 CONFIG_ options to the config.h header files to all the DM6446 based
> boards. These values are then used by the driver.

I had been thinking that the davinci_nand driver should
probably change to let board_nand_init() really become a
board-specific function...

It would call a driver routine to init the callback functions
and set up private data so that for example the 2GByte NAND
could be properly treated as a single device with two chips,
instead of two separate devices.  (As Linux does; I'm just
assuming that mechanism works right in U-Boot.)

Other private data could include CLE/ALE masks, if needed.
I may well have missed something, but I thought that the
ROM on all chips used the same mask values when booting
from NAND flash... but that non-boot chips might end up
using different values, if they wanted.  (Burst memory
access would work better if toggling low address bits
didn't affect ALE/CLE, etc.)


Alternatively ... how about just letting those values be
defined in the headers if the boot-from-NAND defaults
shouldn't be used?

That is, the u-boot davinci_nand.c code could

	#ifndef CONFIG_SYS_DAVINCI_NAND_CLE
	... #define it to the default 0x10 ...
	#endif

I think the convention for these things (toplevel README) is
that since they're hardware-specific, CONFIG_SYS_* is the
prefix not CONFIG_* for those symbols.


Related: MASK_ALE should not be 0x0a by default, but 0x08;
right?  That's what newer docs say; I think the old stuff
was just a bug.  In Linux, 0x08 works just fine.

And for that matter, include/asm-arm/arch-davinci/nand_defs.h
is starting to look almost un-necessary after those cleanup
patches I sent.  :)


> This has been tested on the 
> DM644x, DM355, DM357 and DM365. Support for the latter 3 will be
> added soon. 

I'm glad to see TI's latest U-Boot work becoming public...

However, this won't apply on top of the cleanup patches I just
sent, which remove the NAND_CE0{ALE,CLE,DATA} symbols in favor
of the relevant nand_chip pointer.  As you know, that change
is important for support of the EVM boards which include the
socketed 2 GByte NAND chips, with multiple chip select lines.

- Dave