[PATCH v3 00/20] Refactor the architecture parts of mt7628

[Stefan]

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