From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Tue, 6 Dec 2011 13:42:45 -0600
Subject: [U-Boot] [PATCH V7 5/5] omap-common: fixes BSS overwriting
	problem
In-Reply-To: <4EDE56AB.3070504@gmail.com>
References: <1317284033-16188-1-git-send-email-simonschwarzcor@gmail.com>
	<1320078187-28423-1-git-send-email-simonschwarzcor@gmail.com>
	<1320078187-28423-6-git-send-email-simonschwarzcor@gmail.com>
	<4EDE4E54.7060602@denx.de> <4EDE56AB.3070504@gmail.com>
Message-ID: <4EDE7035.5070901@freescale.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

On 12/06/2011 11:53 AM, Simon Schwarz wrote:
> On 12/06/2011 06:18 PM, Stefano Babic wrote:
>> I found the readon of the kernel corrupt image. We are setting a very
>> hard address in /nand_spl_simple.c:
>>
>> ecc_calc = (u_char *)(CONFIG_SYS_SDRAM_BASE + 0x10000);
>>
>> Because the image for a TI SOC is loaded at 0x80008000, we have a
>> conflict and the image is corrupted where the ECC is computed.
>>
>> It is not a really good idea to fix in this way where to compute the
>> ECC. Should be not better to put it in the CONFIG_SYS_INIT_RAM_ADDR
>> area ?

There's a patch to fix this (with some minor changes requested):
http://patchwork.ozlabs.org/patch/128018/

>> Best regards,
>> Stefano Babic
>>
> 
> Hmm. This is from the former nand_spl.
> 
> Why not use malloc for this? Thanks to changes in the FAT driver we now
> have it in the SPL.
> 
> I don't see a reason to have this in SRAM when SDRAM is available.

nand_spl_simple.c is used by some very small SPL targets -- 4K or so.
malloc doesn't fit.

-Scott