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

[Aneesh V]

Hello Albert,

On Wednesday 02 February 2011 08:44 PM, Albert ARIBAUD wrote:
[snip ..]

>>>> 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.

On second thoughts I would like to keep the entire bss in SDRAM. With
MMC and FAT support, the SPL is already nearing the IRAM budget in
OMAP3. It helps to save some space by moving out bss to SDRAM.

If needed, I can fix up the start.S by defining something like
_end_of_data. But is that really needed. I do not see any SPL that
needs relocation and SDRAM bss at the same time.

Best regards,
Aneesh