Hi, On Wed 30 Apr 2025 10:28:56 AM , Tim Hardisty wrote: > OK...here's my thinking this morning - from my point of view/my use > case/but hopefully universally applicable: > > 1. I realise there is no need for the bootloader process, in kernel > space, to know the details of the image version. > 2. NXboot always calls <board_boot_image> so won't change that in any > way, but there was none for my arch. > 3. I wrote one, and in keeping with Uboot and SAMA5D2 eval boards, I > wrote this to copy and run to SDRAM. My board would support XIP but > I haven't explored that so, for now, I stuck with the tried-and > tested and added this functionality to board_boot_image - without > the image size it can only copy the entire slot which has a slight > performance penalty. Makes sense. > 4. MCUboot - for example - does the copy to RAM itself so, as has been > suggested, it would be good if NXboot gains this too. It will need > the destination RAM address for this which could: > * either be via a Kconfig manually entered value used directly by > NXboot, or > * saved in the header, which would mean a change to the header > struct, and to the image creation script. We have included a way to have extended headers included in the image. The original idea was to include cryptographic signature in there (it is part of the image and thus we don't have to care about size of the key used for signing). The same extension could be used to store RAM address. Or we could just add this fixed size field to the existing header. I am just not sure if image is the correct location for this. Considering U-Boot there you can have FIT image that specifies where every part should land but NXBoot image is single part and thus I would rather compare it with older way U-Boot booted system and there the load address was deduced by U-Boot script itself. I think that unless we have some compound image (that I am not sure we need for NXBoot at the moment) I would just keep it as compile time constant. The identifier in the header is intended as a unique value identifying compatibility and in case of loading to the RAM it might contain 32bits of address and by requiring this identifier to match the consistency of the bootloader and image expected address would be ensured. > 5. One issue I have with NXboot is lack of printf-type error/info > messages as well as progress during copy processes which can be > lengthy (a minute or more). There is also a desire to not rely on syslog > * I will address this by Kconfig-selected addition of > "nxboot_print_info" and "nxboot_print_err" functions that > dprintf to stdout and stderr as appropriate I think that this system already exists and is the syslog. You can configure syslog in NuttX to print output to the stderr. By passing it through syslog we provide ability to manage messages in system defined way contrary to the plain printf. Consider that syslog can be logged and thus even accessed from later booted image. Printf won't do that for you. I think that current logging should stay mostly as is on syslog to allow logs collecting, but I think that we should add some sort of hackable progress reporting that could be in default directed to the stderr/stdout. We discussed this with Michal and I think that adding callback to the `nxboot_perform_update` might be the appropriate solution. The default nxboot_main.c could just print dots for example to signal running operation. The more advanced or board specific reporting could be implemented in custom nxboot main (meaning having own entry point and own nxboot main in downstream project). > 6. If the boot fails completely - I accept that NXboot is designed to > be very robust, but things do happen! - I will add a simple > nxboot_print_err message, but the addition of an external error > handler function may still be appropriate, easy to add, with no > overhead if not wanted. I mat use it simply to flash board-specific > LEDs, or initiate a recovery process, or something. I don't have anything against this. The question is what would be the form of this integration. I don't think that fallback itself should be part of the nxboot as it will be inevitably board specific and thus it might be rather some board specific logic called over boardctl again. It might make sense to have ability to jump to some dedicated recovery routine even in the standard system (not just for the bootloader) such as when init script fails in NSH. > > I will investigate the options relating to 4 above today - I prefer the > idea of this address being in the header, and added by the loader > functions, using a Kconfig board-specific setting. Need to make sure it > is backwards compatible though. > > On 29/04/2025 22:17, Tim Hardisty wrote: > > 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>
signature.asc
Description: PGP signature
