Laczen commented on PR #18373: URL: https://github.com/apache/nuttx/pull/18373#issuecomment-3882838947
> > @aviralgarg05 have you tried building nxboot/mcuboot/miniboot from nuttx-apps using the provided board_boot_image? miniboot might be the simplest for the first tests. > > Validated with `nuttx-apps` boot paths and `board_boot_image` enabled: > > * `BOOT_MINIBOOT`: build pass > * `BOOT_NXBOOT` + `NXBOOT_BOOTLOADER`: build pass > * `BOOT_MCUBOOT` + `MCUBOOT_BOOTLOADER`: build pass > > I first hit local host-tool gaps (`imgtool`, `esptool`) and reran successfully after installing them in the build environment. That the build pass is good, however it is not a test of `board_boot_image`, to test this it is needed to build a mcuboot format image, write it to `OTA...`. Build a miniboot image in simpleboot format (this is bootable by the rom bootloader) and write the miniboot image to 0x1000 (for esp32). Then restart and the mcuboot format image should start. Regarding image formats: * mcuboot and simpleboot images are location fixed images (meaning that they have to be placed at a specific location to be bootable). This is done to avoid having to map rom segments, or more correctly "delegate" the rom mapping to the image itself. This is achieved by "including" the image offset inside a part of the image that is loaded from flash to iram/dram. So in this case there is no need to map rom segments. * legacy idf images are not lcation fixed. They require the ram to be loaded, but also the rom mappings to be done by the bootloader. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
