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@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@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 - 26:9f:0f:24:ae:39 eth0: eth@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@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.