Hello Lars, On Saturday 13 of September 2025 10:16:14 Lars Kruse wrote: > 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 :)
Nice to hear that the code looks usesfull. > 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/7c69d7c68087aa29f349728ed2aea28b3f >d36fa7/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. What comes to my mind is that the binary image which is intended to be run has to be relocated, linked to the address which account that the image header will be added before actual code placed into memory at place to be executed. See boards/arm/samv7/common/scripts/flash.ld.template https://github.com/apache/nuttx/blob/778f3fa39c9f92504bcb0b208edf5b37dc90a076/boards/arm/samv7/common/scripts/flash.ld.template#L33 #ifdef CONFIG_SAMV7_FORMAT_MCUBOOT # define MCUBOOT_HEADER_SIZE CONFIG_SAMV7_MCUBOOT_HEADER_SIZE # ifdef CONFIG_BOARDCTL_BOOT_IMAGE # define FLASH_OFFSET 0 # define FLASH_IMG_SIZE CONFIG_SAMV7_OTA_PRIMARY_SLOT_OFFSET # else # define FLASH_OFFSET (CONFIG_SAMV7_OTA_PRIMARY_SLOT_OFFSET + MCUBOOT_HEADER_SIZE) # define FLASH_IMG_SIZE (CONFIG_SAMV7_OTA_SLOT_SIZE - MCUBOOT_HEADER_SIZE) # endif #else # define FLASH_OFFSET 0 # define FLASH_IMG_SIZE CONFIG_ARCH_CHIP_SAMV7_MEM_FLASH #endif I expect that you take bootable binary which is intended to be placed at PRIMARY_SLOT_OFFSET or some other address directly and execute it. It can run as long as all jumps are relative and data accesses position independent. I.e. position independent code PIC but it is not typical for embedded systems and would cause other problems. If it is case then code can run up to some point where absolute address is computed, accessed andthen fails. Another problem of Cortex-M0 and probably even M0+ is that it has fixed start address for the vector table if I remember well. All M3, M4, M33 has it defined in register. So there has to be some jump table at Flash start/pointing to bootloader but if it should be redirected to the application in PRIMARY_SLOT then there has to be some jump to jump table in RAM. If the code is not run from PRIMARY_SLOT directly in Flash then there could be more options how to copy code at right place. But if both NXboot and application are intended to be run from the RAM memory, then it is necessary to ensure that NXboot does not overwrite itself when copying application. Reserve whole space for boot-switcher updater for whole system run. So there are option how to copy image at some free RAM addres and then provide some small assembly to blob compiled trampoline which moves image to local position even overwriting NXboot code i RAM. So may it be some of my ideas/hinst could help. Best wishes, Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa company: https://pikron.com/ PiKRON s.r.o. Kankovskeho 1235, 182 00 Praha 8, Czech Republic projects: https://www.openhub.net/accounts/ppisa social: https://social.kernel.org/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
