[U-Boot] BSS footprint of FAT very high - SPL issues

[Graeme Russ]

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