On Tue 29 Apr 2025 08:45:11 PM , Tim Hardisty wrote: > > The structures are available in the apps space but not kernel space, > unless you include a convoluted path to get from the board directory > (out-of-tree in my case). I have been trying to include to my board > stuff as I thought that's were it would belong, consistent with other > image boot, arch-specific functions. The file is not in the usual > apps/include directory: it is a sub-directory of the nxboot app > directory, so I was think to split it so not everything in the current > nxboot.h needs to be available to the kernel space, just the minimum. > But still needs a "../.." type header inclusion which is not nice. And you can't do the copy to the RAM from user-space? It least I would implement it in such a way that user-space would copy it to some location (defined either by build configuration or by kernel at runtime) and then used boardctl to switch to the RAM. Or am I missing what are you actually doing? > > Karel emailed me (direct, not to list: perhaps just a mistake) saying: > > if you are trying to implement image loading to RAM by bootloader I > would suggest you to think about adding this mode possibly to the NXBoot > itself. > Our use case (me and Michal Lenc) is to boot image from program flash and > perform update over external storage (such as SPI NOR); thus loading to RAM is > not provided at the moment. But if implemented correctly it could make sense > to > have loading to RAM as well. > > My use case is similar but different: I have a partitioned NOR-flash > that has the 3x NXboot slots. An update would usually be via the "user > app" to get the new image into a specific "slot" partition...but I am > also looking at the worst case, of when an upgrade goes horribly wrong > and the user needs to recover somehow. I am also in the process of > developing an option for NXboot to call an external handler in this > situation to allow prompts to the user to insert USB sticks or whatever. > I will do this as an "example app" to demonstrate the principle. This sound pretty much like our use case with addition of recovery step that we don't have as we consider in such breakage usage of JTAG and such to be a valid recovery step.
I am not sure if you are not trying to fortify something that is already designed with failure in mind (while I am not saying that we didn't miss something). The question is what could go so horribly wrong. Commonly that would be failure of NOR during the update process where simple system reset would not recover it. I am not sure if such recoverable failure is even possible. In NXBoot design we took care to ensure that update process is resilient against reboots. Thus we copy image but still keep it at NOR until the verification step where we do some erases to prevent rollback-update cycle after unexpected reboot. Thus we are always able to recover the copy process. There is a case where image in the program flash gets corrupted and we don't support recovery from NOR at that moment but consider that if program flash is corrupted (not by copy operation, that is protected by checksum, but by itself) the same can and will happen with bootloader and thus in such a case you must expect that you don't even have bootloader (unless it is stored on the different storage, such as bootloader in internal flash and system image on external that is executable as well). If you have time, could you write up on the platform and requirements you have so we are not discussing only just concepts? > > If I was to add "load to RAM" to NXboot that would probably be a > good/better thing. But I don't know how generic that could be, across > many many architectures. I'll have to ponder that - took me a while to > get the right assembly code for my arch (SAMA5D2). I may need to think > laterally here! > > On 29/04/2025 20:24, Michal Lenc wrote: > > Hi Tim, > > > > If I remember correctly, these structures are public now, you should > > be able to include <nxboot.h> from your application. > > > > Best regards, > > > > Michal > > > > On 4/29/25 19:48, Tim Hardisty wrote: > >> I am adding enhancements to my custom image booting software (that > >> copies the image from flash to internal SDRAM). > >> > >> As part of that I would like, via PR, to expose /struct > >> nxboot_img_header/ and it's associated /struct nxboot_hdr_version/ > >> and /struct nxboot_img_version/ via a public header file > >> (apps/include/nxboot/nxboot.h). > >> > >> It will allow me to get the actual image size for copying rather than > >> the entire "slot" size, as well as to be able to extract the image > >> version information for use by my app. > >> > >> Can anyone see any problems with this? > >>
signature.asc
Description: PGP signature
