Hi Tim, there is already an open issue about it: https://github.com/apache/nuttx/issues/11390
Please take a look at that discussion, POSIX SIGNALS are still required for PSE51, but for NXBoot it could be disabled as well. BR, Alan On Tue, Mar 25, 2025 at 6:47 AM Tim Hardisty <timhardist...@gmail.com> wrote: > I think I’ll leave that for someone with more experience… and time! This > could be raised as a specific issue on GitHub if someone could take the > time to do that and capture the details? > > I can do quick win fixes as they benefit me and hopefully others too :-) > > Regards, > > Tim. > > > On 25 Mar 2025, at 08:16, Sebastien Lorquet <sebast...@lorquet.fr> > wrote: > > > > Hello, > > > > I agree that for compacity, reintroducing the possibility to disable the > VFS entirely would be quite interesting. > > > > That is a large challenge! > > > > Sebastien > > > > > >> On 24/03/2025 20:38, Alan C. Assis wrote: > >> 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 > >>> >
