Laczen commented on issue #19994: URL: https://github.com/apache/nuttx/issues/19994#issuecomment-5614309080
> > There is not need for a bootloader to call fetch_rom segments_lma, it is the image that needs it so it needs to be set in the NuttX source. I can incorporate the proposed change, but this will be a constant for the image in the end. There are indeed some extra changes required: there is no need for the image to call bootloader_init(), and it needs to zero the .bss. > > Hi [@Laczen](https://github.com/Laczen), correct me if I'm wrong, I assumed you are implementing the custom second stage bootloader as an application itself on `nuttx-apps`, like: > > * Custom bootloader = implementation out of the main NuttX tree, built as a Simple Boot image, so yes, `CONFIG_BOOTLOADER_OFFSET_IN_FLASH` is still a constant for all Simple Boot images, including this one; > * Your custom compatible image = implementation out of the main NuttX tree, built as `CONFIG_ESPRESSIF_CUSTOM_IMAGE`, which probably this config would need to be added to the main tree, so the code can be branched as when to call the mentioned `bootloader_init()`, `fetch_rom_segments_lma()`, etc.. Since there's no "custom image" yet, those "calls, where and when" need to be discussed. > > I think it's important we avoid mixing the "Simple Boot" concept with a custom image, although they may be using the same image format header. Hi @almir-okato thanks for the comment. I agree that this would be a espressif custom image that would need to be added in NuttX tree, and I also don't want to mix the "Simple Boot" concept. The proposal here is exactly meant to discuss the "new" image type before integrating it in the tree. Of course the correctness of the integration will need to be discussed in PR's that introduce the new type in the NuttX tree. This "new" image type is not really new, it is the esp-idf format where the startup is done from iram (including the rom mappings) instead of directly from irom. The image can be booted by the legacy esp-idf bootloader (which would setup the rom mappings twice, once in the bootloader and once in the image itself). The "new" image type would allow easier addition of newer devices as they are added with the simpleboot mechanism first. Regarding the integration in nuttx-apps: I would add 2 things in nuttx-apps: 1. The image configuration for bootloader support: that defines the basic properties of the NuttX image (the location it is compiled for and the image size), but also the support routines that defines where upgrade images should be placed and how to switch between different images, 2. The bootloader itself that would use the configuration variables defined in the nuttx-apps section. The bootloader itself could be a nuttx image, but also a bare metal application. The bootloader in nuttx-apps would not be limited to espressif devices but also target arm devices. I already have a prototype for this in https://codeberg.org/Laczen/sfboot. -- 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]
