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

[Mauro Condarelli]

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?
>
> Mauro, please try loading into a different address on your non-working
> setup and report back if RAM loading works in this case.
Attempt to load, even at different address, the "other" u-boot fails:
  setenv autoload no; dhcp; tftpboot 81000000
192.168.7.101:u-boot.bin-weijie.v3.vocore2; go ${fileaddr}
hangs after "## Starting application at 0x81000000 ..." (I currently have
in SPI NOR the u-boot-mtmips.bin-mips.testing built together
u-boot.bin-mips.testing).

>> ===8<---
>> I don't think so.
>> As said problem is with RAM loading.
>
> I also have this problem (sometimes). Please see above.
>
>> ===8<---
>> For the Ram-lading problem I do not currently plan any
>> action, but I'm available.
>
> A test with a different load address would be interesting.
Done (see above).
Tell me if You want me to rebuild with a different TEXT_BASE
and test that.

>
> Thanks,
> Stefan
Regards
Mauro