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

[Stefan <sr@denx.de>]

Hi Mauro,

On 12.02.20 10:23, Mauro Condarelli 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?
>>
>> 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).

Could you please apply the new cmd/boot.c patch I've sent just a few
minutes ago [1] and burn this image into flash. And please test with
this image, if RAM booting of other, different images does work for you
now.

And sorry, using a different TEXT_BASE does not seem to work. Somehow
I seem to have goofed up this morning in my tests. Please use always the
correct TEXT_BASE as load address for the RAM image.

Thanks,
Stefan

[1] http://patchwork.ozlabs.org/patch/1236810/