From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Thu, 03 Feb 2011 21:05:09 +1100 Subject: [U-Boot] BSS footprint of FAT very high - SPL issues In-Reply-To: <4D4A52C1.9000604@ti.com> 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> <4D4A52C1.9000604@ti.com> Message-ID: <4D4A7DD5.7040805@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 03/02/11 18:01, Aneesh V wrote: > Hello Graeme, > > On Thursday 03 February 2011 02:31 AM, Graeme Russ wrote: > [snip ..] >>> Yes. These are variables that otherwise would go to BSS. I do this >>> because I need them before SDRAM initialization. One of this is the gd >>> structure. I allocate gd structure in .data that is in IRAM. >>> Why I need gd before SDRAM? Because I try to initialize serial console >>> as early as possible and this code has some reference to gd. >>> >> >> Which is a perfectly normal scenario and the way things have always been. >> There should have been no need to shuffle gd around because of console >> initialisation. >> >> And as I understand it, gd itself does not get statically 'allocated' in >> the u-boot image per-se (i.e. not in .data and not in .bss) - Only the >> pointer to it is allocated. In most arches, this pointer is itself not >> in .data or .bss but rather in a fixed reserved register. In the new x86 >> (final patches coming soon), the pointer is allocated in .data with a >> preset initialised value pointing into Cache-As-RAM (i.e. IRAM). Prior to >> relocation, the gd pointer variable points to somewhere in IRAM / CAR and >> after relocation, gd gets copied into the heap and the gd pointer adjusted >> to point to the new permanent copy. > > Please note that SPL starts executing from IRAM and not > FLASH (copied there by ROM code). So we have .data available > immediately. Actually we do not need gd except to reuse some code from > u-boot that uses it. Declaring gd as a static variable was just a > convenience decision. Ah, silly me - I missed the fact this was SPL. Makes more sense now :) > > If I were to allocate it separately I would have to allocate it in the > same IRAM and I may end up reserving more space than needed to allow > for future expansion. IRAM space is at a premium. So, declaring it as a > static variable helps in allocating only as much space as is needed. > Makes sense Regards, Graeme