I believe I am over-thinking this and genuinely appreciate your input. I will sleep on this and think again tomorrow. Thanks!
> On 29 Apr 2025, at 21:23, Karel Kočí <cyn...@email.cz> wrote: > > 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>
