On Tuesday 28 April 2009, s-paul...@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
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
