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
