[U-Boot] Unexpected effects/problems porting code to u-boot SPL

[Andreas Bießmann]

Dear 0xbin4ry,

please keep the list in cc.

On 28.08.13 19:17, 0xbin4ry wrote:
> Am 28.08.13 16:58, schrieb Andreas Bießmann:
>> In s_init you do
>> _not_ have a full CRT! The BSS is not initialized there and writing data
>> in BSS will likely corrupt code, at least in the 'normal' u-boot mode
>> before relocation. In the SPL case for omap it's a bit different (BSS
>> lays in SDRAM which will be initialized at end of s_init .. and I dunno
>> if it is zeroed out correctly as required by full CRT ;).
>
> Ah  ok. Thanks for clarification. I did not know about the partial CRT.
>
>> Another issue could be that you have only a small, temporary stack
>> there. I feel the s_init() is just the wrong place to call your code.
>> AFAIR was a discussion regarding s_init and correct placement in the
>> call chain. This would maybe solve the two mentioned problems but will
>> also move your code to another place (maybe after some decission you'll
>> feed with your code's output?).
>
> The reason why I put my code at such an early place is because I want to
> extract the "untouched" first ~30 kByte of the on-chip ram (Starting at
> 0x040300000).

ouch, 30kB? How big is the SRAM of omap4? How big is your code and how
many stack space is reserved? Are these 30kB part of your SPL binary?

> This is a rather simple algorithm which already works
> flawlessly. I could store the data in an array and pass it to the more
> complex algorithm, which I could put into board_init_f, you suggested.
> Do you know a "best practice" to pass such a data structure between both
> functions?

You'll need to wait until sdram_init() is run, then you can use the
SDRAM and place your stuff there. If the BLOB is part of your SPL, why
don't just use the symbols later on?

> However, the code must still be part oft the SPL and must be executed
> before the actual u-boot.img gets loaded. But I guess board_init_f is
> still part of the SPL (I did not work with this function, yet and
> currently do not have the code at hand)?

Yes it is part of SPL an it's used to run board specific stuff. The _f
indicates that it is run 'in place' before relocation. This is an
leftover from NOR flash days where the very first code is run form NOR
in place. The _r part will run later, but this is omitted in SPL case.

Best regards

Andreas Bießmann