Hi there!
currently it is not possible to build single working OMAP3 binary which
enables more than one of these:
CONFIG_NOR
CONFIG_NAND
CONFIG_CMD_ONENAND
first problem lies in gpmc_init which configures CS[0] to one flash type
determined at compile time. Another is that identify_nand_chip hang when
trying to indentify chip which is not present. The same issue is with
OneNAND mtd driver. And finally omap_gpmc:board_nand_init() searches
for NAND specific configuration in gpmc config1 register - but that value
is forced earlier from gpmc_init, making test completely pointless.
Most of these issues are fixed with patches sent as reply to this message,
but:
As we might want to use single binary also to boot from MMC or other
sources, we cannot use boot_device to get a glue about used flash type.
Also U-Boot should not count on being loaded by its own SPL. So, to make
things easier to begin with, do we all agree that omap_gpmc:board_nand_init
as well as its OneNAND counterpart should expect gpmc config1 register
properly set and fail if something unexpected is found? That basically
means if we should rely on CS0 config provided by first stage loader or
try to rediscover flash devices (this problem does not exist when flash
itself is boot source)
Thank you for your attention,
ladis
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
