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

[Daniel Schwierzeck <daniel.schwierzeck@gmail.com>]

On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli <mc5686@mclink.it> wrote:
>
> Sorry Daniel,
> I seem unable to pass the message through.
>
> I have, in front of me two, very similar directories:
>
> u-boot.master:
> built from master + Weijie.v3 patches + my vocore2 patch.
>
> u-boot-mips:
> built from u-boot-mips/testing + my vocore2 patch.
>
> I was very careful not to change anything after patching.
>
> In both directories I do:
>
> make ARCH=mips CROSS_COMPILE=mipsel-linux- distclean
> make ARCH=mips CROSS_COMPILE=mipsel-linux- vocore2_defconfig
> make ARCH=mips CROSS_COMPILE=mipsel-linux-
>
> Both produce similarly-sized u-boot-mtmips.bin (Flash version)
> and u-boot.bin (RAM version).
>
> On my target I do:
>
> setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin; go
> ${fileaddr}
>
> In the case of the "master dir I get:
>
> => setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin;
> go ${fileaddr}
> BOOTP broadcast 1
> DHCP client bound to address 192.168.7.135 (115 ms)
> Using eth at 10110000 device
> TFTP from server 192.168.7.101; our IP address is 192.168.7.135
> Filename 'u-boot.bin'.
> Load address: 0x80200000
> Loading: ####################################
>      1.1 MiB/s
> done
> Bytes transferred = 527090 (80af2 hex)
> ## Starting application at 0x80200000 ...
>
>
> U-Boot 2020.01-00648-gc46834052a-dirty (Feb 11 2020 - 09:30:52 +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 - 26:9f:0f:24:ae:39
> eth0: eth at 10110000
> 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.

>
> If I do the same with product of "mips" dir I get:
>
> => setenv autoload no; dhcp; tftpboot 80200000 192.168.7.101:u-boot.bin;
> go ${fileaddr}
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> BOOTP broadcast 4
> DHCP client bound to address 192.168.7.112 (3136 ms)
> Using eth at 10110000 device
> TFTP from server 192.168.7.101; our IP address is 192.168.7.112
> Filename 'u-boot.bin'.
> Load address: 0x80200000
> Loading: ####################################
>      1 MiB/s
> done
> Bytes transferred = 527390 (80c1e hex)
> ## Starting application at 0x80200000 ...
> <*DEAD*>
>
> I am trying to understand where difference lies... and failing, to date :(
>
> I already sent "my vocore2 patch" (Note: that is a "git rebase -i"
> squashing the three commits in one, no change) earlier today;
> if You think it might be useful I can send also the complete
> "git format-patch" from a known u-boot master commit from
> where I branched off
> (currently 8b9cc858e0239823b051a9324431d511baf2b998)
>
> My "git log --oneline" on "master" is:
> c46834052a (HEAD -> weijie.v3.vocore.net, syno0/weijie.v3.vocore.net)
> Move back environment to SPI NOR. Changes to environment default settings.
> 7dbd7fc8bc Added network setup.
> 375435c35e (syno0/weijie.v3.vocore, weijie.v3.vocore) Add support for
> SoM "VoCore2".
> f4fa7f499e (syno0/weijie.v3, weijie.v3) mips: mtmips: add support for
> mt7628-rfb
> 724463aa9e mips: mtmips: enable SPL for all boards
> 1fe4eda6c3 mips: mtmips: add SPL support
> 5ea8181206 spl: nor: add lzma decompression support for legacy image
> 173aa9cb6c tools: binman: add etype file for u-boot-lzma-img
> 789a9085d3 Makefile: add support to generate LZMA compressed u-boot image
> e4721a8b98 lib: enable lzma decompression support for SPL build
> b769d64488 mips: add an option to enable u_boot_list section for SPL
> loaders in u-boot-spl.lds
> c704313c7e mips: enable support for appending dtb to spl binary
> 8801d2b226 dts: mtmips: add alternative pinmux node for uart2
> 4cda40c3ea mips: mtmips: rewrite lowlevel codes of mt7628
> 13299d7651 mips: add a option to support not reserving malloc space on
> initial stack
> eb8a3689b0 mips: add a mtmips-specific field to architecture-specific
> global data
> f5fda08bed configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all
> mtmips boards
> e95f8beabe mips: mtmips: make use of sysreset-resetctrl for mt7628 soc
> 58246e0175 sysreset: add reset controller based reboot driver
> b6a20ebced mips: start.S: avoid overwriting outside gd when clearing
> global data in stack
> c2359e8947 mips: add an option to support initialize SRAM for initial stack
> a6eecdd28e mips: mtmips: add predefined i-cache/d-cache size and linesize
> b096b2e05f mips: add support to restore exception vector base before
> booting linux
> 2e5b1c00fd MIPS: allow override of get_tbclk()
> 8b9cc858e0 mx7ulp: Move SoC base address to a common file
> ...
>
> while in the "mips" directory I have:
> cd23ee2179 (HEAD -> VoCore2) Move back environment to SPI NOR. Changes
> to environment default settings.
> ddc07fb968 Added network setup.
> 9eabc0c0bb Add support for SoM "VoCore2".
> b3d1d5d05b (origin/testing, testing, master) mips: mtmips: add support
> for mt7628-rfb
>
> As said: there must be some difference, somewhere,
> but it's not evident (to me) where it is and how to find it.
>
> Thanks in Advance for any advice
> Best Regards
> Mauro
>
> On 2/11/20 2:54 PM, Daniel Schwierzeck wrote:
> > On Tue, Feb 11, 2020 at 11:58 AM Mauro Condarelli <mc5686@mclink.it> wrote:
> >> Thanks Daniel.
> >>
> >> On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:
> >>> Hi Mauro,
> >>>
> >>> Am 10.02.20 um 21:20 schrieb Mauro Condarelli:
> >>>> FYI
> >>>> I've been using this patchset for over a week without any adverse effect.
> >>>> It allowed me to port to VoCore2 board.
> >>>> Should I add a "Tested-by" flag?
> >>>> If so: how should I do it?
> >>>>
> >>>> Regards
> >>>> Mauro Codarelli
> >>>>
> >>> sorry that I could respond to your questions earlier. I've pushed the
> >>> complete patch set from Weijie to:
> >>>
> >>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
> >> I tried to use this repo/branch, but something is wrong (or I goofed badly).
> >>> Maybe this helps you with development. If you have a bootable patch set
> >>> (you can do MMC later) for your VoCore2 board, please submit a regular
> >>> patch series based on that branch so that we can review again.
> >> 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.
Could you build a new patch queue on top of u-boot-mips/next with the remaining
Weijie v3 patches and your VoCore2 patches?

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
in mainline or in other MIPS patches which you have to figure out then.

-- 
- Daniel