From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Schwarz Date: Tue, 06 Dec 2011 18:53:47 +0100 Subject: [U-Boot] [PATCH V7 5/5] omap-common: fixes BSS overwriting problem In-Reply-To: <4EDE4E54.7060602@denx.de> 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> Message-ID: <4EDE56AB.3070504@gmail.com> List-Id: 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 06:18 PM, Stefano Babic wrote: > On 31/10/2011 17:23, Simon Schwarz wrote: >> From: Simon Schwarz >> >> spl_nand overwrote BSS section because it reads a whole block everytime. Now >> loads the block to spare area and just copy the needed junk to destination. >> Whole block read is necessary for ecc check! >> >> Signed-off-by: Simon Schwarz >> --- > >> @@ -71,7 +71,8 @@ void spl_nand_load_image(void) >> CONFIG_SYS_NAND_PAGE_SIZE, (void *)header); >> spl_parse_image_header(header); >> nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS, >> - spl_image.size, (void *)spl_image.load_addr); >> + spl_image.size, >> + (void *)spl_image.load_addr - sizeof(header)); > ^--- > > > Do you mean maybe sizeof(*header) ? > > However, spl_image.load_addr was already decremented in > spl_parse_image_header() and correctly set to 64 byte before the load > address. Do we really need it ? > > 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 ? > > 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. Regards Simon