Hi,
[This whole description is not qspi specific but qspi happens to be my boot source. It should be the same when booting from mmc or nand.]
On my socfgpa gen5 board, I was a little surprised that a soft reboot did not start the SPL from qspi after updating it from a running Linux (via swupdate writing to qspi).
When debugging this, I found that this is because SPL and U-Boot set the magic value 0xae9efebc to the sysmgr_regs->romcodegrp_warmramgrp_enable register, which tells the boot ROM that it can jump to SPL in OnChip RAM on next warm reboot.
Now this is a problem for me specifically because I want to run the SPL stored in qspi after updating it. I don't know if I'm the only one wanting to do that, but I could implement this for my own board by just resetting the magic value in the warmramgrp_enable register.
What surprised me more is that the boot ROM provides the ability to check the CRC of SPL, but it doesn't check the CRC since the related registers tellt it to not do that (to enable this, SPL would have to write its length + CRC to sysmgr registers). I would have suspected this bad design since maybe we were rebooted by the watchdog because some driver wrote bad data somewhere, so it might well be the SPL in OnChip RAM is not intact any more.
Now should we: a) calculate and set a CRC for SPL's text / rodata segments (what about initialized rwdata?) or b) set the warmramgrp_enable register to always load SPL from boot source or c) make it configurable?
Writing the code for any of the 3 choices is easy, so I wanted to get an opinion first before sending a patch. Personally, I'd favour always loading SPL from boot source, but the comment (in misc_gen5.c arch_early_init_r()) suggests I'd break ancient kernels with that (I assume the problem is the problem I have with 4.9: Linux sets qspi into 4-byte mode and the boot rom can then not load SPL since it uses 3-byte mode without switching mode in the qspi chip).
Any thoughts?
Simon