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/
