Thanks Daniel.
On 2/11/20 5:49 PM, Daniel Schwierzeck wrote:
> On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli <mc5...@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.
>> ===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.
> 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.
Best Regards (and pardon me for the noise, please)
Mauro Condarelli
