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 >>>
