[PATCH v3 00/20] Refactor the architecture parts of mt7628
sr at denx.de
Wed Feb 12 14:46:26 CET 2020
On 12.02.20 13:48, Daniel Schwierzeck wrote:
>>> Daniel, perhaps a dumb question, but is the MIPS U-Boot code position
> 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>:
> /* 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
> 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.
More information about the U-Boot