Dear bin4ry,
On 08/28/2013 03:30 PM, bin4ry wrote:
I want to extend the u-boot SPL code with some fuzzy extractor logic by adding code into `{u-boot_sources}/arch/arm/cpu/armv7/omap-common/hwinit-common.c`. U-boot shall be used on a PandaBoard ES (omap4460 SoC).
Thus, first I successfully implemented the code on my x86 pc and I am porting it to the ARM-based PandaBoard. The complete code can be found here (as a side note the "main" function is s_init()):
However, I am expecting dozens of unexptected effects, which results in either stopping during the execution of the code, stopping u-boot after reading u-boot.img or not sending output (and thus not booting) at all.
For example, I want to call two functions (`computeSyndrome`, `decodeErrors`) inside a `for`-loop, which is part of another function `golayDecode`.
For my first problem please ignore the code below the multiline comment starting with `/* >>>> These lines of code below totally break u-boot`. Also only the function `computeSyndrome` in conjunction with the calling function `golayDecode` is important.
The issue: If comment out both functions `computeSyndrome` and `decodeErrors` everything works fine and the OS (Android) is booting. However, if `computeSyndrome` is not commented out and thus gets processed, u-boot stucks after displaying `reading u-boot.img`. The funny thing about it: even if I replace `computeSyndrome` with a bogus function which does not but iterating a values or displaying stuff, u-boot stucks as well.
Furthermore, if I remove the multiline comment furhter below to also include the residual code, u-boot doesn't display ony character. *
I am a beginner regarding microprocessor programming but I can not figure out a possible error in these 12 lines of the computeSyndrome function or the general behaviour of u-boot at all. **
Does anyone have a clue what I am missing?
<snip code>
I'll not dive in your code but just a few comments. 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 ;).
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?).
It would be the easiest solution if you could move your code to another place. Maybe inject it in board_init_f? If not you'll need to setup CRT by initializing BSS correctly for your needs _and_ verify you'll not blow up your minimal stack there. That could be a quite expensive task. Verifying the stack usage is advised in any case, see doc/README.SPL how to do so.
Best regards
Andreas Bießmann