Hi Mauro, Hi Daniel,
On 11.02.20 19:05, Mauro Condarelli wrote:
Thanks Daniel.
On 2/11/20 5:49 PM, Daniel Schwierzeck wrote:
On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli mc5686@mclink.it wrote:
===8<---- Hit any key to stop autoboot: 0 =>
ok, booting from RAM works. But what I meant with bootable is, that you can write the the u-boot-mtmips.bin to SPI flash and do a cold boot. Only then we can merge your patch.
It *does* work. The U-Boot I have flashed is essentially the same as the one built in the "master" directory, just a few days old (I changed essentially my project-specific CONFIG_EXTRA_ENV_SETTINGS).
... which reminds me of something...
... it turns out that flashing *does* work:
=> setenv autoload no; dhcp; tftpboot 85000000 192.168.7.101:u-boot-mtmips.bin; sf probe; sf update ${fileaddr} 0 ${filesize} BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 DHCP client bound to address 192.168.7.110 (2953 ms) Using eth@10110000 device TFTP from server 192.168.7.101; our IP address is 192.168.7.110 Filename 'u-boot-mtmips.bin'. Load address: 0x85000000 Loading: ################# 762.7 KiB/s done Bytes transferred = 244458 (3baea hex) device 0 offset 0x0, size 0x3baea 240362 bytes written, 4096 bytes skipped in 2.232s, speed 111952 B/s => reset resetting ...
U-Boot SPL 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100) Trying to boot from NOR
U-Boot 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)
CPU: MediaTek MT7628A ver:1 eco:2 Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz Model: VoCore2 DRAM: 128 MiB WDT: Started with servicing (60s timeout) MMC: mmc@10130000: 0 Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK Model: VoCore2 Net: Warning: eth@10110000 (eth0) using random MAC address - 8a:fb:d0:3b:d1:93 eth0: eth@10110000 Hit any key to stop autoboot: 0 =>
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.
Now that I reflashed "u-boot-mips/testing" version I can run it also "from RAM", while trying to load "master" hangs (I tried just now).
If this is considered "acceptable" (probably it has nothing to do with my vocore2 port) I can clean-up my patches and resubmit. I'm not a mips expert and I don't know how to debug this "RAM load" misbehavior, but I'm available for testing, if useful.
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.
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.
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.
===8<---
I *do* have a bootable patchset built on top of master + Nemirovsky "reconfigurable cpu clocks" + Weijie v3. Result is fully working, including net and mmc/SD.
This patchset applies cleanly to uboot-mips/testing and compile apparently without errors, but resulting u-boot.bin does not work. By "does not work" I mean it does not utter a single char on debug serial.
I tried to do a complete diff between my working tree and this non-working one and there are tons of differences, but I couldn't spot anything that might be relevant.
I am unsure on how to proceed; please advise.
maybe you have a big diff because you are not on the latest master branch. I currently have ae347120eed8204b1fdf018ddf79131964e57016. The u-boot-mips/testing is based on u-boot-mips/next and only contains Weijie's v3 patches from 14/20 to 20/20. For u-boot-mips/next I intend to create a pull request soon. The existing mtmips boards should still work without SPL support. Maybe Stefan could give it a quick test.
Maybe I messed something up in u-boot-mips/testing. There were some merge conflicts.
I don't think so. As said problem is with RAM loading.
I also have this problem (sometimes). Please see above.
Could you build a new patch queue on top of u-boot-mips/next with the remaining Weijie v3 patches and your VoCore2 patches?
I can do that if You think it's still useful, otherwise we can just use testing.
As long as all u-boot-mips changes aren't merged to mainline, your patches must work with the latest u-boot-mips/next branch. There could always be new and incompatible changes
Understood.
in mainline or in other MIPS patches which you have to figure out then.
I don't think there'll be problems. My patches are quite basic and board-only.
I plan to clean my patch expunging all project-specific stuff, rebase from the (current) tip of uboot-mips-mips/testing and resubmit (unless You tell me to do something different, of course).
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.
Thanks, Stefan