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 am happy what I have (pending further test, of course!), but I want this integrated in upstream master, if possible, so I'm prepared to rebase my patches after Weijie ones are in.
Any comment welcome.
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.
Note that if I load the same version flashed it works ok (presumably because I'm overwriting with the same content, so no harm done). How can I load in RAM end test a new version once I flash new-style u-boot? I am thinking about relinking at a different address, but I'm unsure.
See above.
Thanks, Stefan