From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Schwierzeck Date: Tue, 11 Feb 2020 17:49:46 +0100 Subject: [PATCH v3 00/20] Refactor the architecture parts of mt7628 In-Reply-To: References: <1579594674-6665-1-git-send-email-weijie.gao@mediatek.com> <85741485-0d75-dd5c-78a0-34c1eda6c8c4@mclink.it> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli 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 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