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

[Graeme Russ]

On Thu, Feb 3, 2011 at 1:01 AM, Aneesh V <aneesh at ti.com> wrote:
> Hi Albert,
>
> On Wednesday 02 February 2011 07:07 PM, Albert ARIBAUD wrote:
>> Hi Aneesh,
>>
>> Le 02/02/2011 14:17, Aneesh V a écrit :
>>> Hello Wolfgang, Albert,
>>>
>>> On Tuesday 01 February 2011 03:33 PM, Wolfgang Denk wrote:
>>>> Dear Aneesh V,
>>>>
>>>> In message<4D47C1C9.1020002 at 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.
>>
>> You mean data that would have ended in BSS but that you moved to .data?
>> Why?
>
> 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.

Regards,

Graeme