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