On Wed, Nov 18, 2009 at 12:58 AM, <hvaib...@ti.com> wrote:
> From: Vaibhav Hiremath <hvaib...@ti.com>
>
> User can now choose between NAND and ONENAND support in omap3_evm.h
>
> Signed-off-by: Vaibhav Hiremath <hvaib...@ti.com>
> ---
> include/configs/omap3_evm.h | 27 ++++++++++++++++++++++++++-
> 1 files changed, 26 insertions(+), 1 deletions(-)
>
> diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> index a5514ae..3434306 100644
> --- a/include/configs/omap3_evm.h
> +++ b/include/configs/omap3_evm.h
> @@ -110,7 +110,8 @@
>
> #define CONFIG_CMD_I2C /* I2C serial bus support */
> #define CONFIG_CMD_MMC /* MMC support */
> -#define CONFIG_CMD_ONENAND /* ONENAND support */
> +/*#define CONFIG_CMD_ONENAND*/ /* ONENAND support */
do you wish to use #undef instead of commented code? also adding a
comment on top saying this is an option might help..
This patch opens up a chain for me: how do we have the same build of
u-boot boot accross nand, onenand, mmc type devices?
current u-boot looks constrainted in that respect.
> +#define CONFIG_CMD_NAND /* NAND support */
> #define CONFIG_CMD_DHCP
> #define CONFIG_CMD_PING
>
> @@ -141,6 +142,7 @@
> /* to access */
> /* nand at CS0 */
>
> +
> #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of */
> /* NAND devices */
> #define CONFIG_SYS_64BIT_VSPRINTF /* needed for nand_util.c */
> @@ -268,7 +270,13 @@
> #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE
> #define CONFIG_SYS_ONENAND_BASE ONENAND_MAP
>
> +#if defined(CONFIG_CMD_NAND)
> +#define CONFIG_NAND_OMAP_GPMC
> +#define GPMC_NAND_ECC_LP_x16_LAYOUT 1
> +#define CONFIG_ENV_IS_IN_NAND 1
> +#elif defined(CONFIG_CMD_ONENAND)
> #define CONFIG_ENV_IS_IN_ONENAND 1
> +#endif
what if a user decided to enable NAND and ONENAND?
> #define ONENAND_ENV_OFFSET 0x260000 /* environment starts here */
> #define SMNAND_ENV_OFFSET 0x260000 /* environment starts here */
>
> @@ -300,6 +308,23 @@ extern unsigned int boot_flash_sec;
> extern unsigned int boot_flash_type;
> #endif
>
> +
> +#define WRITE_NAND_COMMAND(d, adr)\
> + writel(d, &nand_cs_base->nand_cmd)
writel? i thought u had 16 bit nand device.
> +#define WRITE_NAND_ADDRESS(d, adr)\
> + writel(d, &nand_cs_base->nand_adr)
> +#define WRITE_NAND(d, adr) writew(d, &nand_cs_base->nand_dat)
> +#define READ_NAND(adr) readl(&nand_cs_base->nand_dat)
readl?? should'nt you be using readw?
Why these functions? does'nt mtd layer handle this? look at beagle ->
it does not use that..
> +
> +/* Other NAND Access APIs */
> +#define NAND_WP_OFF() do {readl(&gpmc_cfg_base->config) |= GPMC_CONFIG_WP; }
> \
> + while (0)
> +#define NAND_WP_ON() do {readl(&gpmc_cfg_base->config) &= ~GPMC_CONFIG_WP; }
> \
> + while (0)
> +#define NAND_DISABLE_CE(nand)
> +#define NAND_ENABLE_CE(nand)
> +#define NAND_WAIT_READY(nand) udelay(10)
> +
are these really needed?
> /*----------------------------------------------------------------------------
> * SMSC9115 Ethernet from SMSC9118 family
> *----------------------------------------------------------------------------
> --
> 1.6.2.4
>
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
