[PATCH v3 00/20] Refactor the architecture parts of mt7628

[Stefan]

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 at 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 at 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 at 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 at 10110000 (eth0) using random MAC address - 8a:fb:d0:3b:d1:93
> eth0: eth at 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