[U-Boot] [PATCH v2 6/7] am335x_evm: Add support for the NOR module on the memory cape

[Tom Rini]

On Thu, May 16, 2013 at 04:32:58PM +0200, Peter Korsgaard wrote:
> >>>>> "Tom" == Tom Rini <trini at ti.com> writes:
> 
>  Tom> From: Steve Kipisz <s-kipisz2 at ti.com>
>  Tom> This patch adds support for the NOR module that attaches
>  Tom> to the memory cape for a Beaglebone board. This does not
>  Tom> add booting support; only support so that you can boot from
>  Tom> SD/MMC and see the NOR module so that it can be programmed.
[snip]
>  Tom> @@ -77,9 +77,15 @@ void gpmc_init(void)
>  
>  Tom>  	/* global settings */
>  Tom>  	writel(0x00000008, &gpmc_cfg->sysconfig);
>  Tom> +#ifdef CONFIG_NOR
>  Tom> +	writel(0x00000000, &gpmc_cfg->irqstatus);
>  Tom> +	writel(0x00000000, &gpmc_cfg->irqenable);
>  Tom> +	writel(0x00000A00, &gpmc_cfg->config);
>  Tom> +#else
>  Tom>  	writel(0x00000100, &gpmc_cfg->irqstatus);
>  Tom>  	writel(0x00000100, &gpmc_cfg->irqenable);
>  Tom>  	writel(0x00000012, &gpmc_cfg->config);
>  Tom> +#endif
> 
> This looks to me as an indication that irqstatus/irqenable/config should
> really be arguments of gpmc_init().

Perhaps.  I've still got an open poke about what's going on, exactly
here.

[snip]
>  Tom> +/* NOR chip on NOR module for Beaglebone */
>  Tom> +#define STNOR_GPMC_CONFIG1	0x00001200
>  Tom> +#define STNOR_GPMC_CONFIG2	0x00101000
>  Tom> +#define STNOR_GPMC_CONFIG3	0x00030301
>  Tom> +#define STNOR_GPMC_CONFIG4	0x10041004
>  Tom> +#define STNOR_GPMC_CONFIG5	0x000C1010
>  Tom> +#define STNOR_GPMC_CONFIG6	0x08070280
>  Tom> +#define STNOR_GPMC_CONFIG7	0x00000F48
> 
> Why are these not in board/ti/am335x/board.{c,h} if they are beaglebone
> specific?

The timings would be valid to anyone using the same NOR on a custom
chip.  I'll re-word the comment.

>  Tom> +#ifdef CONFIG_NOR
>  Tom> +	/* Reconfigure CS0 for NOR instead of NAND. */
>  Tom> +	enable_gpmc_cs_config(gpmc_nor, &gpmc_cfg->cs[0],
>  Tom> +			      CONFIG_SYS_FLASH_BASE, GPMC_SIZE_16M);
>  Tom> +#endif
>  Tom> +
> 
> Perhaps the nand handling should just get moved out of gpmc_init() (or
> the _cs_config args should be passed to gpmc_init() ).

I looked at this, on the scale of redoing omap3 too (where we have a lot
of existing examples).  The split we've got now works and it's harmless
to re-configure CS0 in the case where the defaults don't work.  I think
this would lead us to an abstraction that leads to a lot of board files
duplicating the same code.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130516/19ab589d/attachment.pgp>