From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Date: Wed, 12 Feb 2020 13:25:28 +0100 Subject: [PATCH v3 00/20] Refactor the architecture parts of mt7628 In-Reply-To: <92731912-74f9-e635-5fea-8c9455fcf002@mclink.it> References: <1579594674-6665-1-git-send-email-weijie.gao@mediatek.com> <85741485-0d75-dd5c-78a0-34c1eda6c8c4@mclink.it> <5d502f6b-fa16-5d95-3842-2033493b7fd9@mclink.it> <92731912-74f9-e635-5fea-8c9455fcf002@mclink.it> Message-ID: <10d5647f-ef1a-71ef-dc93-7fac5039f1b0@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.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/