Hi Tim, Yes, these suggestions make sense!
I think for NXBoot should be nice to have the option to disable features that were used for minsh board profile: # # RTOS Features # CONFIG_DISABLE_SIGNALS=y # # Files and I/O # CONFIG_SDCLONE_DISABLE=y CONFIG_NFILE_DESCRIPTORS=0 CONFIG_NFILE_STREAMS=0 # # Device Drivers # CONFIG_DISABLE_POLL=y # # File system configuration # CONFIG_DISABLE_MOUNTPOINT=y Disabling MOUNTPOINT will disable VFS support, it was necessary to be able to use less than 16KB Flash, but disabling it we lose the option to create device files at /dev. Since the option to Disable those features was removed some time ago, I'm not sure how complex it will be to reintroduce them. BR, Alan On Mon, Mar 24, 2025 at 4:12 PM Tim Hardisty <timhardist...@gmail.com> wrote: > I am just starting to use NXboot (having migrated from Uboot, then to > MCUboot, and finally settled on NXboot) and I'm wondering whether it > would benefit from some changes and/or enhancements now I've used all > three. > > Thoughts, observations, suggestions welcomed. > > In no particular order: > > 1. Uboot offers a splashscreen - is NXboot the right place for similar, > or is it better as a core/kernel NuttX feature? > * Not everyone uses NXboot of course (probably only a few), and a > suggestion is that a nice (default) splashscreen that comes up > early gives new users a warm and fuzzy feeling. So a kernel > feature I think? > 2. NXboot uses syslog for info and error "messages". I would like to > provide some feedback to users since there can be a notable delay if > NXBoot is doing it's stuff with flash, leaving the user not knowing > what's going on: > * My first thought was to clone NXboot and add my own printf's but > that means the core app and my clone "core" will deviate over > time, and I would like to use as much "out of the box" NuttX > stuff as possible, as would others I imagine. > * But maybe the use of syslog is not necessarily right as, > strictly, NXboot is an app not kernel program? Should it have > printfs natively? > * syslog could be to file...but to access that and read it then > printf to stdout would be non-standard from within NXboot > itself, so back to me cloning it. Unless I've missed something > with syslog - in my case the console is no use as it's not > available to user, but a framebuffer display (FBCON app for > stdout and stderr) is. > 3. What if it all goes horribly wrong and neither the primary, > secondary or recovery partitions have a valid image - the main app > goes rogue, for example? > * Adding options for recovery (e.g. "insert USB memory stick now" > or use TFTP or whatever - but that's arch and board specific so > not really suited to generic enhancement of NXBoot, and needs > printf's. Uboot has loads of script-type options as well as > Kconfig driven choices, but overall Uboot is slow and clunky and > not suited - in my opinion - to embedded products. > * Or perhaps this can actually be easily done with scripts of some > sort and it is simply outside of my experience? > * But perhaps some Kconfig choices based on other NuttX features > (TFTP, DFU etc) would be OK...but which. So... > * Rather than NXBoot simply exiting - which is pointless as where > does it exit to? - or having Kconfig choices of what to do, > perhaps there could just be Kconfig option to spawn an > error-recovery task in the event of a boot fail. So the core > NXboot app allows for recovery, but the implementation of the > error task is personal choice (but could have an example). > > I'm willing to implement changes and enhancements - within reason lol - > so if there are other things it could benefit from add them to this list > and let's discuss :-) > > > TimH >
