Hi,
I don't know the RP processors, nor the Arm V6M, but does it run by
copying the image to RAM and running from RAM like my board does
(SAMA5D27 which is Arm7A)?
If so I will share my experience of getting board_boot_image to work for
that processor as it may help.
Regards,
Tim.
Hello,
I am currently trying to implement a firmware upgrade for my rp2040-based board.
I picked nxboot for this purpose and managed to get *almost* everything done.
By the way: receiving a firmware upgrade via `netcat -l 10000 | dd of=/dev/mtd`
in the NuttX shell is simply beautiful :)
The only missing piece in the chain of things is the current lack of an
implementation of "board_boot_image" for rp2040.
I looked at the other existing implementations of this function for other
architectures and followed their content and style.
The result is here:
https://github.com/sumpfralle/nuttx/blob/7c69d7c68087aa29f349728ed2aea28b3fd36fa7/boards/arm/rp2040/common/src/rp2040_boot_image.c
I am eager to prepare a pull request as soon as I managed to launch my target
firmware once…
The problem is:
- The final action in the function (jumping to the reset function
of the target firmware) succeeds. At least gdb shows me, that the function
"start" [1] in the target context is reached.
- But the jump to "__start" [2] ends in a fault state:
[rp2040.core0] clearing lockup after double fault
Attached you find screenhots of the gdb session right before jumping to
"__start"
and right after. Sorry for the pixels - I am not aware of a text-based
screenshot
tool.
I am not well-versed with the raw details of arm processors (I rather enjoy the
beauty of NuttX posix interface). Thus, I have problems to analyze this failure
now. And I was really staring way too long at this problem…
Just for the context - there are some things, that I managed to get to work in
this area:
- I was able to (re)start the "bootloader" image with the above code.
(by manipulating the reset jump address at the end of "board_boot_image")
Thus, the procedure seems to work. But maybe some remains of the bootloader
context are still active when switching to the target firmware.
- I compared the content of the uploaded image with the locally built image.
They are identical. The upload itself worked.
Do you have any ideas, what could trigger the above fault?
Or maybe you have hints, how I could debug it?
Thank you for your time!
Cheers,
Lars
[1]
https://github.com/apache/nuttx/blob/master/arch/arm/src/armv6-m/arm_vectors.c#L67
[2]
https://github.com/apache/nuttx/blob/master/arch/arm/src/rp2040/rp2040_start.c#L84
