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
