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 <acas...@gmail.com> wrote: > > Hi Tim, > > Yes, maybe it could be an option inside your fbcon app. > > My initial thought was that having a nxlogo inside the kernel (like Linux) > could make it available for all boards that register a framebuffer. > > But since using your fbcon with the NSH terminal on LCD, the users will see > the NuttX Logo in similar way was Linux users do. > > BR, > > Alan > >> On Thu, Mar 27, 2025 at 9:38 AM Tim Hardisty <timhardist...@gmail.com> >> wrote: >> >> I am still unsure about where a framebuffer splashscreen best "lives". >> >> * If a framebuffer device is used for a given board, this would be >> registered in a board bringup file. Or, at least, that's what my >> board does. So a splashscreen could be done there - but is then not >> a "generic" thing that any new user would see to get that warm and >> fuzzy feeling that their first foray into the NuttX world was a >> success...unless someone want's to go and add it to every single >> board bringup in the repo that uses a framebuffer video driver? >> * NXboot initially seemed logical to me, only in as much as it mimics >> what U-boot does, but NXboot is, again, not something most use and >> is not part of basic defconfigs for many, if any, boards? And NXboot >> only hangs around for a short while unless there are issues . >> * (newly added) FBCON still might be a good place as it is a good (I >> hope!) starter example app for those using framebuffer video - it >> allows NSH to work in its most basic form). Documentation could be >> added to point people in the direction of this (where?). >> * Leave it as a user app thing (where I have it now, via LVGL in my >> "main" custom app. >> >> On balance, I'm thinking FBCON. >> >> Also:i f we wanted to do something "fancy" on multi-cpu architectures, >> what are the relevant system calls to get the number of cores? >> >>> On 24/03/2025 19:38, Alan C. Assis wrote: >>> Hi Tim, >>> >>> Yes, these suggestions make sense! >>> >>> I think for NXBoot should be nice to have the option to disable features >>> that were used for minsh board profile: >>> >>> # >>> # RTOS Features >>> # >>> CONFIG_DISABLE_SIGNALS=y >>> >>> # >>> # Files and I/O >>> # >>> CONFIG_SDCLONE_DISABLE=y >>> CONFIG_NFILE_DESCRIPTORS=0 >>> CONFIG_NFILE_STREAMS=0 >>> >>> # >>> # Device Drivers >>> # >>> CONFIG_DISABLE_POLL=y >>> >>> # >>> # File system configuration >>> # >>> CONFIG_DISABLE_MOUNTPOINT=y >>> >>> Disabling MOUNTPOINT will disable VFS support, it was necessary to be >> able >>> to use less than 16KB Flash, but disabling it we lose the option to >> create >>> device files at /dev. >>> >>> Since the option to Disable those features was removed some time ago, I'm >>> not sure how complex it will be to reintroduce them. >>> >>> BR, >>> >>> Alan >>> >>> On Mon, Mar 24, 2025 at 4:12 PM Tim Hardisty<timhardist...@gmail.com> >>> wrote: >>> >>>> I am just starting to use NXboot (having migrated from Uboot, then to >>>> MCUboot, and finally settled on NXboot) and I'm wondering whether it >>>> would benefit from some changes and/or enhancements now I've used all >>>> three. >>>> >>>> Thoughts, observations, suggestions welcomed. >>>> >>>> In no particular order: >>>> >>>> 1. Uboot offers a splashscreen - is NXboot the right place for >> similar, >>>> or is it better as a core/kernel NuttX feature? >>>> * Not everyone uses NXboot of course (probably only a few), and a >>>> suggestion is that a nice (default) splashscreen that comes up >>>> early gives new users a warm and fuzzy feeling. So a kernel >>>> feature I think? >>>> 2. NXboot uses syslog for info and error "messages". I would like to >>>> provide some feedback to users since there can be a notable delay >> if >>>> NXBoot is doing it's stuff with flash, leaving the user not knowing >>>> what's going on: >>>> * My first thought was to clone NXboot and add my own printf's >> but >>>> that means the core app and my clone "core" will deviate over >>>> time, and I would like to use as much "out of the box" NuttX >>>> stuff as possible, as would others I imagine. >>>> * But maybe the use of syslog is not necessarily right as, >>>> strictly, NXboot is an app not kernel program? Should it have >>>> printfs natively? >>>> * syslog could be to file...but to access that and read it then >>>> printf to stdout would be non-standard from within NXboot >>>> itself, so back to me cloning it. Unless I've missed something >>>> with syslog - in my case the console is no use as it's not >>>> available to user, but a framebuffer display (FBCON app for >>>> stdout and stderr) is. >>>> 3. What if it all goes horribly wrong and neither the primary, >>>> secondary or recovery partitions have a valid image - the main app >>>> goes rogue, for example? >>>> * Adding options for recovery (e.g. "insert USB memory stick now" >>>> or use TFTP or whatever - but that's arch and board specific so >>>> not really suited to generic enhancement of NXBoot, and needs >>>> printf's. Uboot has loads of script-type options as well as >>>> Kconfig driven choices, but overall Uboot is slow and clunky >> and >>>> not suited - in my opinion - to embedded products. >>>> * Or perhaps this can actually be easily done with scripts of >> some >>>> sort and it is simply outside of my experience? >>>> * But perhaps some Kconfig choices based on other NuttX features >>>> (TFTP, DFU etc) would be OK...but which. So... >>>> * Rather than NXBoot simply exiting - which is pointless as where >>>> does it exit to? - or having Kconfig choices of what to do, >>>> perhaps there could just be Kconfig option to spawn an >>>> error-recovery task in the event of a boot fail. So the core >>>> NXboot app allows for recovery, but the implementation of the >>>> error task is personal choice (but could have an example). >>>> >>>> I'm willing to implement changes and enhancements - within reason lol - >>>> so if there are other things it could benefit from add them to this list >>>> and let's discuss :-) >>>> >>>> >>>> TimH >>>>
