Hi, I'm clearly out of my depth:
=> icache flush No arch specific invalidate_icache_all available! => dcache flush No arch specific flush_dcache_all available! => icache off => dcache off
Ooops: $ 0 : 00000000 00000000 87e806c8 00000000 $ 4 : ffffffd0 00000014 87e80518 87fce61c $ 8 : 87e7bc00 00000010 00000000 fffffffc $12 : 00000000 0000000f 00000006 00000007 $16 : ffffffd0 00000000 00000000 0000002f $20 : 87e81350 87fe8528 00000000 00000001 $24 : 00000016 87f84130 $28 : 87f882a0 87e7bba8 87e81362 87fa9524 Hi : 00000006 Lo : 000640a2 epc : 87fa1600 (text 80221600) ra : 87fa9524 (text 80229524) Status: 00000006 Cause : d0008028 (ExcCode 0a) PrId : 00019655 ### ERROR ### Please RESET the board ###
Thanks Mauro
On 1/22/20 9:16 PM, Mauro Condarelli wrote:
Hi Stefan,
On 1/21/20 1:08 PM, Stefan Roese wrote:
Hi Mauro,
On 21.01.20 12:27, Mauro Condarelli wrote:
Thanks Weijie, I made the changes You suggested. I have also seen You sent a new version of Your patches. Since mine are based on yours I *think* I should suspend sending my VoCore2 patches till Yours are fixed and integrated into master.
@Stefan Roese: is this the right course of action?
I think in the current state of Weijie's patches (v3), you can resume sending your VoCore2 support based on this latest patchset to the list. Please don't attach a patch but send it inline next time (git send-email) to enable review.
I will send next iteration as soon as I fix the reflash problem (see below). ===8<----
Side Question: Stefan wrote:
Most of this can be done by using the RAM version now (again). There is no additional RAM booting target now any more. You can use the normal U-Boot image for this now. Please note the changes TEXT_BASE here. Its now 0x80200000.
This actually seems to work right if I start from my original u-boot (1.1.3, flashed at start of SPI NOR), but it fails if I start from a flashed (at the same location) u-boot-mtmips.bin I *think* this happens because unpacking actually writes u-boot at 0x80200000 and runs it from there, so "load usb 0:1 80200000 u-boot.bin" (or equivalent) will overwrite the running u-boot and the following "go ${fileaddr}" fails: ## Starting application at 0x80200000 ... <DEAD>
No, U-Boot relocates itself to the end of RAM and runs from there. So this should work. Perhaps a cache flush is missing.
I'll give it a try on my LinkIt board as well later.
Did You manage to test this? I am currently testing loading from "paleolithic" u-boot, but I want to fix this before I finalize VoCore2 patches.
I tried to do some manual testing enabling CONFIG_CMD_CACHE, but this bombs with Weijie patches with:
LD u-boot mipsel-linux-ld.bfd: cmd/built-in.o: in function `do_icache': cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable' mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x6c): undefined reference to `icache_enable' mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x8c): undefined reference to `icache_status' make: *** [Makefile:1697: u-boot] Error 1
icache seems enabled unconditionally in arch/mips/mach-mtmips/mt7628/lowlevel_init.S::73+
I will try to add dummy functions just-to-play.
Please advise
Thanks, Stefan
Regards and Many Thanks Mauro