Hi Daniel, On 12.02.20 13:48, Daniel Schwierzeck wrote:
<snip>
Daniel, perhaps a dumb question, but is the MIPS U-Boot code position independant?from your tests I can only conclude that RAM loading doesn't work at all. If you see it "working" than you simply junp to the old copy which the SPL created. A MIPS U-Boot is always built with position-dependant code. To make the U-Boot binary relocatable, we use the tools/mips-relocs.c which was ported from Linux. During linking we let gcc emit relocation entries which are post-processed by the mips-relocs tool. The output is then inserted into u-boot.bin in section ".data.reloc". Those reloc entries are then used by the MIPS relocation code to patch all symbols with the relative offset to the new text address. If you build for example the Gardena Smart Gateway and disassemble the u-boot binary (which becomes the SPL payload), the very first instruction is this: 80200000 <_start>: #endif .endm ENTRY(_start) /* U-Boot entry point */ b reset 80200000: 1000013f b 80200500 <reset> mtc0 zero, CP0_COUNT # clear cp0 count for most accurate boot timing 80200004: 40804800 mtc0 zero,c0_count So if you load u-boot.bin to a different address than 0x80200000 and jump to it, the first instruction is a jump back to address 0x80200500. If the old SPL copy of u-boot.bin is still there, you'll see a "working" RAM boot.
Thanks for this analysis. This is exactly what happened in my test this morning.
Actually Mauro already did the right thing with erasing the load area at 0x80200000 before downloading a new binary. A stable approach to a RAM boot binary (which I use in my out-of-tree boards) would be to use a KSEG1 text address e.g. 0xa0200000 and explicitely switch the CPU to non-caching mode (this is normally skipped with CONFIG_SKIP_LOWLEVEL_INIT in the SPL payload). This approach always worked for me for booting via UART or EJTAG without getting messed up by cache effects. So either we officially drop RAM boot support for mtmips platform (respectively don't use the u-boot.bin intended for SPL payload as RAM boot binary) or we keep the special RAM boot configs.
I assume that you are also okay with the cache flush approach? I'll send v2 of this patch pretty soon if nobody objects. Thanks, Stefan
