From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Fri, 11 Feb 2011 11:58:20 +0530 Subject: [U-Boot] BSS footprint of FAT very high - SPL issues In-Reply-To: <4D4CF506.5090902@free.fr> References: <4D4798E2.3050500@ti.com> <20110201075521.60484B187@gemini.denx.de> <4D47C1C9.1020002@ti.com> <20110201100312.241C1B187@gemini.denx.de> <4D495966.4010009@ti.com> <4D495E02.4080509@free.fr> <4D4963D6.3020505@ti.com> <4D4974DC.9010103@free.fr> <4D4A85C2.7070807@ti.com> <4D4CF506.5090902@free.fr> Message-ID: <4D54D704.3060508@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Wolfgang, Albert, On Saturday 05 February 2011 12:28 PM, Albert ARIBAUD wrote: > Hi Aneesh, > > Le 03/02/2011 11:38, Aneesh V a ?crit : > >> On second thoughts I would like to keep the entire bss in SDRAM. With >> MMC and FAT support, the SPL is already nearing the IRAM budget in >> OMAP3. It helps to save some space by moving out bss to SDRAM. >> >> If needed, I can fix up the start.S by defining something like >> _end_of_data. But is that really needed. I do not see any SPL that >> needs relocation and SDRAM bss at the same time. > > "Patches Welcome" :) -- with added thanks for patching all start.S / > u-boot.lds in the ARM arch consistently. I see __u_boot_cmd_end as the end of the image to be relocated in all the scripts. Shall I use this label for this purpose. This will work for now and save me from touching all those linker scripts. However, there is a small possibility of this leading to the same problem as with __bss_start in future. I don't think that should be a big concern. Do you agree? Best regards, Aneesh