Hi Nathan,
Thanks for your thoughts. It has made me think more logically (I hope)
about why and when you might want a splashscreen.
I'm currently thinking that it is only a pretty "hello world" that
allows branding. With that in mind:
* Embedded devices, using NuttX, may not have an LCD of course
* Whether to display a splashscreen is a decision only the product
design team (team of 1 in my case lol) can make
o Likewise: how long it's displayed for
* NXboot should only be there for a brief time -as you say - so not
really a place for a "wow, look at what you've just powered up"
pretty-pretty graphic
o If things go wrong during the bootloader process, a splashscreen
is irrelevant: that's where my error recovery suggestion comes in.
* NXboot - as I understand it and currently use it - boots an image
which is a complete standalone NuttX kernel and startup app: nsh to
get you going; a custom app, most likely, in the RW.
So:
* I think a splashscreen in the kernel *does* make sense.
* It should be enabled/disabled via Kconfig. But what default?
o Default "on" - would be good for new users
o Default "off" - doesn't change anything for current users
* If enabled, it will be displayed when the framebuffer driver is
registered
o default graphic would be NuttX logo
o custom logo can be supported via Kconfig choice
+ I favour a "c" or header file created using an online tool,
rather than messing around with converting jpegs on the fly.
* Timeout. Hmmm...
o "none" could mean display it and forget about it until something
comes along to reinit/overwrite. Onus on the developer.
o "auto" could mean display until NuttX is done loading. Is there
a signal or anything we could use to check this?
o a non-zero value "n" could mean keep it there for "n" seconds
regardless - and delay finishing NuttX load until that timeout
expires or NuttX is ready (whichever is longer). Also needs a
signal or something so we know when NuttX is ready.
* With the above implemented:
o the NXboot app could build it's minimal kernel with no
splashscreen enabled
o the "main" app could build it with a splashscreen enabled (if
wanted)
WDYT ;-)
On 27/03/2025 18:43, Nathan Hartman wrote:
On Thu, Mar 27, 2025 at 9:18 AM Alan C. Assis<acas...@gmail.com> 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.
If nxlogo is in the kernel, that means nxboot can use it also?
Normally nxboot should be instantaneous as far as user can tell. Only in
case of firmware upgrade, firmware missing, etc, nxboot will be running for
some time. So I think nxboot should not display the logo unless it's going
to be visible for at least 0.5 seconds. If nxboot starts, finds firmware,
and then branches to firmware, and if that entire process takes < 0.5
seconds, maybe nxboot should only blank the display.
WDYT?
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
