On Tuesday 28 April 2009, s-paulraj@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