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

[Daniel Schwierzeck]

On Wed, Feb 12, 2020 at 10:23 AM Mauro Condarelli <mc5686 at mclink.it> wrote:
>
> Hi Stefan,
> Hi Daniel,
>
> On 2/12/20 7:39 AM, Stefan wrote:
> > Hi Mauro,
> > Hi Daniel,
> >
> > On 11.02.20 19:05, Mauro Condarelli wrote:
> >> ===8<---
> >>
> >> What *does NOT* work is loading RAM version or, to be more precise:
> >> It works IF (and only if) you load the same code already running.
> >> I *think* this is because current Weijie code unpacks to this same
> >> location
> >> (80200000) before relocating. If you are rewriting the same code in the
> >> same location any cache inconsistencies are unimportant, otherwise
> >> Bad Things happen.
> >> I spoke with Stephan about this, but we never found a fix.
> >>
> >> ===8<---
> >
> > I also noticed that "RAM loading" the U-Boot proper does not work all
> > the time on my MT7688 targets. It seems to depend on the image size
> > and some other factors (moon phase...). ;)
> >
> > So there is very likely a bug somewhere hidden - perhaps in the
> > relocaton code. I will probably try to dig into this in sometime soon.
> > But I need a reproducable "bad" image for this. Right now, RAM loading
> > is working just fine.
> As said: In my setup RAM loading is consistently failing if I try to load
> an u-boot build consistently different from the one currently running.
> OTOH loading the same (or very similar, a rebuild is considered "the
> same") version is _always_ working for me.
>
> To rephrase: I have two setups; one based on master+weijiev3 and
> the other based on plain mtmips/testing.
> I can flash either one and it works from SPI NOR. no problems here.
> I can always RAM load successfully the same kernel as flashed.
> If I RAM load the "other" setup it always fails.
>
> I did a few tests:
> - erasing download area (mw.b 80200000 0 80000).
> - do some other loading (e.g.: the Linux kernel) between RAM load and
> "go" (attempt to clean caches, but I suspect this would only effectively
> clear D-cache, not I-cache).
> The above behavior does not change.
>
> >
> > BTW: I noticed that RAM loading does work even when loading into a
> > different address than TEXT_BASE. On the new MTMIPS targets TEXT_BASE is
> > 0x80200000 and loadind to e.g. 0x81000000 does also work.
> I do confirm this:
>   setenv autoload no; dhcp; tftpboot 81000000
> 192.168.7.101:u-boot.bin-mips.testing; go ${fileaddr}
> works as expected (loading  same-as-flashed)
>
> >
> > 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.

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.

-- 
- Daniel