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

[Albert ARIBAUD]

Le 02/02/2011 15:01, Aneesh V a écrit :
> 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.
>
>
>>
>>> 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.
>>
>> That's a good remark -- formally, the relocation code should go from
>> start of text to end of data, not to start of BSS.
>>
>> And that's one more reason for me to want bss stay with text and data
>> (and your two variables above should stay uninitialized) and external
>> RAM get its own memory declaration in the linker file. :)
>>
>
> I can try that too. Just one small question.
> You want to have the source file changes for putting the buffers in
> .ram section only for SPL, right?
> We could have done this globally(for both u-boot and SPL) and merge .ram
> with .bss for u-boot. But that would require changes to all linker scripts.

Correct: the BSS size issue only hits SPL, and only in your case -- 
U-Boot as such does not have strict BSS size issues. So yes, the change 
should affect only the board's SPL linker file if it exists, but if not, 
then the generic SPL linker file should be ok, because the change will 
only have an effect for boards where the code actually maps data to the 
DRAM section.

> Best regards,
> Aneesh

Amicalement,
-- 
Albert.