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

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
participants (1)
-
Andreas Bießmann