Hello Tim and Alan,
I think that splash screen should be separate component/
application in the NuttX Apps.
In the fact, for bigger system and more complex boot
process you can use NSH and script calling some
spash application which can setup frame buffer
and then register listener to the system log
and then it can call nxboot as separate application,
or even in background so you can keep some animation
going.
For Flash space reduced boot solution you can
set INIT_ENTRYPOINT to start some splash screen
application and it can have in its configuration
option what to do next. On a bigger systems it should
be exec to "nxboot_loader" on really small it can
be through direct call of nxboot_loader_main().
Or you can copy nxboot_main.c logic to more
sophisticated application which can provide
more logic what to do in the case of some failures,
which icon to show etc etc. Actual body of the NXboot
is in the other files and nxboot_main.c is in the
fact only a wrapper around
nxboot_perform_update(true)
info.path = CONFIG_NXBOOT_PRIMARY_SLOT_PATH;
info.header_size = CONFIG_NXBOOT_HEADER_SIZE;
return boardctl(BOARDIOC_BOOT_IMAGE, (uintptr_t)&info);
Best wishes,
Pavel
Pavel Pisa
e-mail: p...@cmp.felk.cvut.cz
Department of Control Engineering FEE CVUT
Karlovo namesti 13, 121 35, Prague 2
university: http://control.fel.cvut.cz/
personal: http://cmp.felk.cvut.cz/~pisa
social: https://social.kernel.org/ppisa
projects: https://www.openhub.net/accounts/ppisa
CAN related:http://canbus.pages.fel.cvut.cz/
RISC-V education: https://comparch.edu.cvut.cz/
Open Technologies Research Education and Exchange Services
https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
On Thursday 27 of March 2025 14:15:47 Alan C. Assis wrote:
> Hi Tim,
>
> Yes, maybe it could be an option inside your fbcon app.
>
> My initial thought was that having a nxlogo inside the kernel (like Linux)
> could make it available for all boards that register a framebuffer.
>
> But since using your fbcon with the NSH terminal on LCD, the users will see
> the NuttX Logo in similar way was Linux users do.
>
> BR,
>
> Alan
>
> On Thu, Mar 27, 2025 at 9:38 AM Tim Hardisty <timhardist...@gmail.com>
>
> wrote:
> > I am still unsure about where a framebuffer splashscreen best "lives".
> >
> > * If a framebuffer device is used for a given board, this would be
> > registered in a board bringup file. Or, at least, that's what my
> > board does. So a splashscreen could be done there - but is then not
> > a "generic" thing that any new user would see to get that warm and
> > fuzzy feeling that their first foray into the NuttX world was a
> > success...unless someone want's to go and add it to every single
> > board bringup in the repo that uses a framebuffer video driver?
> > * NXboot initially seemed logical to me, only in as much as it mimics
> > what U-boot does, but NXboot is, again, not something most use and
> > is not part of basic defconfigs for many, if any, boards? And NXboot
> > only hangs around for a short while unless there are issues .
> > * (newly added) FBCON still might be a good place as it is a good (I
> > hope!) starter example app for those using framebuffer video - it
> > allows NSH to work in its most basic form). Documentation could be
> > added to point people in the direction of this (where?).
> > * Leave it as a user app thing (where I have it now, via LVGL in my
> > "main" custom app.
> >
> > On balance, I'm thinking FBCON.
> >
> > Also:i f we wanted to do something "fancy" on multi-cpu architectures,
> > what are the relevant system calls to get the number of cores?
> >
> > On 24/03/2025 19: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
