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

Aneesh V aneesh at ti.com
Thu Feb 3 08:01:21 CET 2011


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.

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.

Best regards,
Aneesh


More information about the U-Boot mailing list