You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Tim Hardisty <ti...@gmail.com> on 2025/03/24 19:12:26 UTC
Discuss NXBoot
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
Re: Discuss NXBoot
Posted by "Alan C. Assis" <ac...@gmail.com>.
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 <ti...@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 <se...@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 <ti...@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
> >>>
>
Re: Discuss NXBoot
Posted by Tim Hardisty <ti...@gmail.com>.
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 <se...@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 <ti...@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
>>>
Re: Discuss NXBoot
Posted by Sebastien Lorquet <se...@lorquet.fr>.
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 <ti...@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
>>
Re: Discuss NXBoot
Posted by TimH <Ti...@jti.uk.com.INVALID>.
Hmm, ok I was thinking it would be done after registering the frame buffer but could be as part of registration of course. Doh!
I’ll look again :-)
Regards,
Tim.
> On 27 Mar 2025, at 13:18, Alan C. Assis <ac...@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.
>
> 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 <ti...@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<ti...@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
>>>>
Re: Discuss NXBoot
Posted by Pavel Pisa <pp...@pikron.com>.
Hello Tim,
On Friday 28 of March 2025 11:22:06 Tim Hardisty wrote:
> Pavel - I have been thinking about your point regarding copying the
> (simple) nxboot_main and using it as a starting point for a more
> sophisticated application. What *I* want is probably not want *others*
> want and it could grow out of hand.
>
> Let's leave it as is...so it covers the stdout/stderr/syslog/printf
> output choices to me along with error recovery.
I think that allow to make that configurable is OK or even
welcomed for Elektroline team. The disable systlog for really
small code size makes sense.
I would suggest to replace syslog(LOG_ERR,...) and
syslog(LOG_INFO, ...) in nxboot_main.c, loader/boot.c
and loader/flash.c by nxboot_report_error and
nxboot_report_info or something similar and implement
them as functions which are implemented under some
ifdef for syslog (probably default), standard and
error output. The nxboot_report_error and nxboot_report_info
has to switch to vsyslog, vprintf, vfprintf....
Or the macro can be used directly to route to the correct
function. There would worth input form Michal Lenc
what their team prefers. But in general, make this
configurable when it does not add too much complexity
and code is OK.
On the other hand option for splash screen and boot reporter
to listen on syslog could be good option for larger systems
where more possible failures could be reported to user this
way and it is standard that drivers and kernel internal
subsystems reports failures this way.
> This discussion now only hinges on splashscreen which, from another
> branch of this discussion, I think is looking more likely a better fit
> in the kernel as part of the framebuffer registration, but will wait and
> see how that bottoms out.
Agree, general spash screen is independent but generally
usesfull option.
Best wishes,
Pavel
Pavel Pisa
phone: +420 603531357
e-mail: pisa@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
company: https://pikron.com/ PiKRON s.r.o.
Kankovskeho 1235, 182 00 Praha 8, Czech Republic
projects: https://www.openhub.net/accounts/ppisa
social: https://social.kernel.org/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
Re: Discuss NXBoot
Posted by Tim Hardisty <ti...@gmail.com>.
Pavel - I have been thinking about your point regarding copying the
(simple) nxboot_main and using it as a starting point for a more
sophisticated application. What *I* want is probably not want *others*
want and it could grow out of hand.
Let's leave it as is...so it covers the stdout/stderr/syslog/printf
output choices to me along with error recovery.
This discussion now only hinges on splashscreen which, from another
branch of this discussion, I think is looking more likely a better fit
in the kernel as part of the framebuffer registration, but will wait and
see how that bottoms out.
Thank you,
Tim.
On 27/03/2025 19:12, Tim Hardisty wrote:
> Thanks for joining in the conversation Pavel.
> I currently have my INIT_ENTRYPOINT set to the (new) fbcon
> example app, so any stdout and stderr output appear on the
> framebuffer LCD, and that then calls NXboot to load my app
> from flash etc.
>
> I want a splashscreen for, let's say, marketing/branding
> purposes so you could argue it should be in my final App
> (where it currently is) but Alan's interest in having a
> NuttX logo as a feature for newcomers means I'm happy
> to look at adding this....somewhere!
>
> The behaviour or NXboot if it isn't able to boot the final
> app straight away is another point I make. I could copy
> nxboot_main and create my own version (as you suggest) but
> that makes it non-std, hence suggesting modifying the
> current NXboot to have the option to call a user error
> task/app.
>
> On 27/03/2025 18:11, Pavel Pisa wrote:
>> 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:pisa@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<ti...@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<ti...@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
Re: Discuss NXBoot
Posted by Tim Hardisty <ti...@gmail.com>.
Thanks for joining in the conversation Pavel.
I currently have my INIT_ENTRYPOINT set to the (new) fbcon
example app, so any stdout and stderr output appear on the
framebuffer LCD, and that then calls NXboot to load my app
from flash etc.
I want a splashscreen for, let's say, marketing/branding
purposes so you could argue it should be in my final App
(where it currently is) but Alan's interest in having a
NuttX logo as a feature for newcomers means I'm happy
to look at adding this....somewhere!
The behaviour or NXboot if it isn't able to boot the final
app straight away is another point I make. I could copy
nxboot_main and create my own version (as you suggest) but
that makes it non-std, hence suggesting modifying the
current NXboot to have the option to call a user error
task/app.
On 27/03/2025 18:11, Pavel Pisa wrote:
> 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:pisa@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<ti...@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<ti...@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
Re: Discuss NXBoot
Posted by Pavel Pisa <pi...@fel.cvut.cz.INVALID>.
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: pisa@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 <ti...@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<ti...@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
Re: Discuss NXBoot
Posted by Tim Hardisty <ti...@gmail.com>.
Out of interest, I took a 800x480 png (that I currently use as a
splashscreen):
* png size: 56KiB
* C file, using LVGL image converter: 5.4MiB
Eek!
On 28/03/2025 13:06, Nathan Hartman wrote:
> Replying inline below:
>
> On Thu, Mar 27, 2025 at 5:15 PM Tim Hardisty<ti...@gmail.com>
> wrote:
>
>> 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
>
>
> I think Default "off" makes the most sense. As you pointed out elsewhere,
> systems running NuttX don't necessarily have displays. In fact, until now
> everything I use NuttX for is deeply embedded, nothing visual you can see.
> Even for systems that do come with displays, the developer might not want a
> splash screen because the graphic consumes limited flash memory, or perhaps
> because NuttX boots instantaneously so the graphic wouldn't be visible for
> long enough to justify it being there. New users should have a relatively
> easy time getting a splash screen if they want it, since it's only a
> Kconfig away.
>
>
> * If enabled, it will be displayed when the framebuffer driver is
>> registered
>> o default graphic would be NuttX logo
>
>
> Agreed, there should be a default NuttX logo in case another one isn't
> provided.
>
>
> 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.
>
>
> Agreed a C header (of hex values) is preferred.
>
> I wonder what would save flash memory--converting the image to a bitmap in
> advance, and then the splash program just copies the bitmap to framebuffer
> (more flash usage for the image, less flash usage for code to display it)
> or saving the JPEG to flash (as a C header of hex values) at the cost of a
> more complicated display code (less flash usage for the image, more flash usage
> for code to display it).
>
> I suppose one benefit of converting images to a framebuffer bitmap at build
> time: any format can be supported (jpeg, png, svg, whatever).
>
>
> * 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 ;-)
>
>
> Makes sense to me!
>
> Cheers,
> Nathan
>
Re: Discuss NXBoot
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Mar 28, 2025 at 10:13 AM Alan C. Assis <ac...@gmail.com> wrote:
> Hi Nathan,
>
> It could be just:
>
> default y if LCD_FRAMEBUFFER
>
> This way it will be "ON" for boards with LCD and Framebuffer enabled and
> "OFF" for all other boards.
That is a good combination. If there's a framebuffer there's a splash
screen by default, and developers can turn that off if they don't want it.
>
> Maybe we need to think about how to get NXlogo working for LCD_DEV too.
>
> BR,
>
> Alan
>
> On Fri, Mar 28, 2025 at 10:07 AM Nathan Hartman <ha...@gmail.com>
> wrote:
>
> > Replying inline below:
> >
> > On Thu, Mar 27, 2025 at 5:15 PM Tim Hardisty <ti...@gmail.com>
> > wrote:
> >
> > > 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
> >
> >
> >
> > I think Default "off" makes the most sense. As you pointed out elsewhere,
> > systems running NuttX don't necessarily have displays. In fact, until now
> > everything I use NuttX for is deeply embedded, nothing visual you can
> see.
> > Even for systems that do come with displays, the developer might not
> want a
> > splash screen because the graphic consumes limited flash memory, or
> perhaps
> > because NuttX boots instantaneously so the graphic wouldn't be visible
> for
> > long enough to justify it being there. New users should have a relatively
> > easy time getting a splash screen if they want it, since it's only a
> > Kconfig away.
> >
> >
> > * If enabled, it will be displayed when the framebuffer driver is
> > > registered
> > > o default graphic would be NuttX logo
> >
> >
> >
> > Agreed, there should be a default NuttX logo in case another one isn't
> > provided.
> >
> >
> > 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.
> >
> >
> >
> > Agreed a C header (of hex values) is preferred.
> >
> > I wonder what would save flash memory--converting the image to a bitmap
> in
> > advance, and then the splash program just copies the bitmap to
> framebuffer
> > (more flash usage for the image, less flash usage for code to display it)
> > or saving the JPEG to flash (as a C header of hex values) at the cost of
> a
> > more complicated display code (less flash usage for the image, more flash
> > usage
> > for code to display it).
> >
> > I suppose one benefit of converting images to a framebuffer bitmap at
> build
> > time: any format can be supported (jpeg, png, svg, whatever).
> >
> >
> > * 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 ;-)
> >
> >
> >
> > Makes sense to me!
> >
> > Cheers,
> > Nathan
> >
>
Re: Discuss NXBoot
Posted by "Alan C. Assis" <ac...@gmail.com>.
Hi Nathan,
It could be just:
default y if LCD_FRAMEBUFFER
This way it will be "ON" for boards with LCD and Framebuffer enabled and
"OFF" for all other boards.
Maybe we need to think about how to get NXlogo working for LCD_DEV too.
BR,
Alan
On Fri, Mar 28, 2025 at 10:07 AM Nathan Hartman <ha...@gmail.com>
wrote:
> Replying inline below:
>
> On Thu, Mar 27, 2025 at 5:15 PM Tim Hardisty <ti...@gmail.com>
> wrote:
>
> > 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
>
>
>
> I think Default "off" makes the most sense. As you pointed out elsewhere,
> systems running NuttX don't necessarily have displays. In fact, until now
> everything I use NuttX for is deeply embedded, nothing visual you can see.
> Even for systems that do come with displays, the developer might not want a
> splash screen because the graphic consumes limited flash memory, or perhaps
> because NuttX boots instantaneously so the graphic wouldn't be visible for
> long enough to justify it being there. New users should have a relatively
> easy time getting a splash screen if they want it, since it's only a
> Kconfig away.
>
>
> * If enabled, it will be displayed when the framebuffer driver is
> > registered
> > o default graphic would be NuttX logo
>
>
>
> Agreed, there should be a default NuttX logo in case another one isn't
> provided.
>
>
> 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.
>
>
>
> Agreed a C header (of hex values) is preferred.
>
> I wonder what would save flash memory--converting the image to a bitmap in
> advance, and then the splash program just copies the bitmap to framebuffer
> (more flash usage for the image, less flash usage for code to display it)
> or saving the JPEG to flash (as a C header of hex values) at the cost of a
> more complicated display code (less flash usage for the image, more flash
> usage
> for code to display it).
>
> I suppose one benefit of converting images to a framebuffer bitmap at build
> time: any format can be supported (jpeg, png, svg, whatever).
>
>
> * 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 ;-)
>
>
>
> Makes sense to me!
>
> Cheers,
> Nathan
>
Re: Discuss NXBoot
Posted by Nathan Hartman <ha...@gmail.com>.
Replying inline below:
On Thu, Mar 27, 2025 at 5:15 PM Tim Hardisty <ti...@gmail.com>
wrote:
> 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
I think Default "off" makes the most sense. As you pointed out elsewhere,
systems running NuttX don't necessarily have displays. In fact, until now
everything I use NuttX for is deeply embedded, nothing visual you can see.
Even for systems that do come with displays, the developer might not want a
splash screen because the graphic consumes limited flash memory, or perhaps
because NuttX boots instantaneously so the graphic wouldn't be visible for
long enough to justify it being there. New users should have a relatively
easy time getting a splash screen if they want it, since it's only a
Kconfig away.
* If enabled, it will be displayed when the framebuffer driver is
> registered
> o default graphic would be NuttX logo
Agreed, there should be a default NuttX logo in case another one isn't
provided.
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.
Agreed a C header (of hex values) is preferred.
I wonder what would save flash memory--converting the image to a bitmap in
advance, and then the splash program just copies the bitmap to framebuffer
(more flash usage for the image, less flash usage for code to display it)
or saving the JPEG to flash (as a C header of hex values) at the cost of a
more complicated display code (less flash usage for the image, more flash usage
for code to display it).
I suppose one benefit of converting images to a framebuffer bitmap at build
time: any format can be supported (jpeg, png, svg, whatever).
* 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 ;-)
Makes sense to me!
Cheers,
Nathan
Re: Discuss NXBoot
Posted by Tim Hardisty <ti...@gmail.com>.
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<ac...@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<ti...@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<ti...@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
>>>>>
Re: Discuss NXBoot
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Mar 27, 2025 at 9:18 AM Alan C. Assis <ac...@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 <ti...@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<ti...@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
> > >>
>
Re: Discuss NXBoot
Posted by "Alan C. Assis" <ac...@gmail.com>.
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 <ti...@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<ti...@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
> >>
Re: Discuss NXBoot
Posted by Tim Hardisty <ti...@gmail.com>.
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<ti...@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
>>
Re: Discuss NXBoot
Posted by "Alan C. Assis" <ac...@gmail.com>.
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 <ti...@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
>