From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mauro Condarelli Date: Tue, 11 Feb 2020 19:05:31 +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: <5d502f6b-fa16-5d95-3842-2033493b7fd9@mclink.it> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Thanks Daniel. On 2/11/20 5:49 PM, Daniel Schwierzeck wrote: > On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli 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. >> ===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