From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aneesh V <aneesh@ti.com>
Date: Fri, 29 Jul 2011 13:04:09 +0530
Subject: [U-Boot] [PATCH V6 2/5] omap-common: add nand spl support
In-Reply-To: <20110728135005.03c97ac0@schlenkerla.am.freescale.net>
References: <1311771039-31691-1-git-send-email-simonschwarzcor@gmail.com>	<1311842291-24837-1-git-send-email-simonschwarzcor@gmail.com>	<1311842291-24837-3-git-send-email-simonschwarzcor@gmail.com>	<4E316F39.30509@ti.com>
	<20110728135005.03c97ac0@schlenkerla.am.freescale.net>
Message-ID: <4E326271.7020903@ti.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Scott, Simon,

On Friday 29 July 2011 12:20 AM, Scott Wood wrote:
> On Thu, 28 Jul 2011 19:46:25 +0530
> Aneesh V<aneesh@ti.com>  wrote:
>
>> On Thursday 28 July 2011 02:08 PM, Simon Schwarz wrote:
>>> +#ifdef CONFIG_SPL_NAND_SUPPORT
>>> +static void nand_load_image(void)
>>> +{
>>> +	gpmc_init();
>>> +	nand_init();
>>> +	nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
>>> +		CONFIG_SYS_NAND_U_BOOT_SIZE,
>>> +		(uchar *)CONFIG_SYS_NAND_U_BOOT_DST);
>>
>> Guess CONFIG_SYS_NAND_U_BOOT_DST is same as CONFIG_SYS_TEXT_BASE. Why
>> define a new flag then?
>
> History from when CONFIG_SYS_TEXT_BASE was just TEXT_BASE and there was no
> separate CONFIG_SYS_TEXT_BASE_SPL.  Also, what if there's a middle step
> before the final U-Boot?  This is a define that's used across all
> platforms.
>

Perhaps he should not use any hard-coded destination. Please see below.

>>> +#ifdef CONFIG_NAND_ENV_DST
>>> +	nand_spl_load_image(CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE,
>>> +		(uchar *)CONFIG_NAND_ENV_DST);
>>> +#ifdef CONFIG_ENV_OFFSET_REDUND
>>> +	nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, CONFIG_ENV_SIZE,
>>> +		(uchar *)CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE);
>>> +#endif
>>> +#endif
>>> +	nand_deselect();
>>> +	parse_image_header((struct image_header *)CONFIG_SYS_NAND_U_BOOT_DST);
>>
>> I think you are assuming the image type and size here.
>
> This is how all the other NAND SPLs do it.  We're building both at the same
> time to create a single combination image, so it's not that bad of an
> assumption.

For OMAP, we are not building a combination image. OMAP typically
allows booting from a FAT file system in an MMC card in addition to raw
boot from eMMC/NAND. So, we have separate files for SPL/x-loader and
u-boot. The SPL file(MLO) is picked up by ROM code and u-boot is picked
up by x-loader/SPL.

The first version of my MMC SPL too was also making assumptions about
the image. But Wolfgang asked me to make it more generic.

According to this I added the necessary code to parse a mkimage header
and find the image size, load address, image type etc from the image
itself and use these while loading the image and while jumping to it.
This gives us more flexibility about the second image.

1. In raw boot the second image can be changed anytime by flashing a
new image(let's say kernel uImage) at the pre-defined location for the
second image.
2. In FAT mode just change CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME and you can
load a different image with mkimage header.

Only the jumping part needs some customization for different types of
images if parameters are passed.

I would like Simon to do it the same way for NAND. Here he is calling
parse_image_header() but only after loading the entire image. That
helps in the jumping part. But he could make the loading part also
generic.

best regards,
Aneesh