From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aneesh V Date: Wed, 02 Feb 2011 18:47:26 +0530 Subject: [U-Boot] BSS footprint of FAT very high - SPL issues In-Reply-To: <20110201100312.241C1B187@gemini.denx.de> References: <4D4798E2.3050500@ti.com> <20110201075521.60484B187@gemini.denx.de> <4D47C1C9.1020002@ti.com> <20110201100312.241C1B187@gemini.denx.de> Message-ID: <4D495966.4010009@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 Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4D47C1C9.1020002@ti.com> you wrote: >> >>> Why would that be necessary? Just put the BSS segment in SDRAM, and >>> everything is fine, isn't it? >> >> SDRAM is initialized by the SPL. So, bss can not be initialized and >> used until SDRAM initialization is complete. I would prefer to have > > Yes, this is normal. > >> rest of the bss in internal RAM so that it's available as soon as we >> enter C code. > > Well, you probably have to decide if you want an easy solution with > the restictions of the internal RAM size, or a somewhat more complex > solution with much more powerful resources. I tried putting bss in SDRAM and it works for me. I just had to put a couple of variables explicitly in .data section. However, there is one minor issue that I would like to report. Making .bss disjoint from the rest of the image may break the relocation code in start.S. Currently the assumption is that '__bss_start' indicates the end of .data and hence the image. That will not be the case when .text and .data are in IRAM and .bss in SDRAM. I am not affected because our SPL doesn't need relocation. Best regards, Aneesh