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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot