See inline.
On 30/04/2025 14:26, Karel Kočí wrote:
Hi,
On Wed 30 Apr 2025 12:19:02 PM , Tim Hardisty wrote:
5. One issue I have with NXboot is lack of printf-type error/info
messages
I think that this system already exists and is the syslog.
I cannot find anywhere to configure NuttX syslog to send output to
stdout or stderr...I am sure it is my inexperience but not being able to
do is in part what drove me to discuss this change. My arch/board has a
default UART as the console output and that is what syslog stubbornly
uses unless I add log to file (which I do have in my main app). I just
want some friendly messages to my LCD! So see below.
1. There was an earlier discussion which requested that NXboot shouldn't be
dependent on syslog (to keep the size down).
I caught that discussion but forgot to respond to it, honestly.
I just built my nxboot binary with and without syslog enabled - there's
about 300 bytes difference so the size argument seems misjudged?
2. Syslog output is generally not seen by the user anyway - and I want to give
the user comfort that things are OK (info type messages)- or not (error
type messages!
I think that this is the primary point. You are attempting to provide user with
nice presentation with cleanup up information while I am more concerned about
traceability. <snip>
In conclusion that is why I suggested that syslog should stay but that we should
also add callbacks to the NXBoot loader allowing info about boot process to be
displayed in the user defined way.
I have just implemented a very simple callback that is only called from
<copy_partition> right now, as that is what takes forever for me. It
just handles the "." using my in-progress "nxboot_report_info". To make
it sensible, I also added string constants in the calls to
<validate_image> to allow printing of "what" was being validated
(primary/secondary/recovery/etc). But that means changes throughout the
code which is not necessarily a good plan.
If we want to call the function wherever it is appropriate, not just for
<copy_partition>, it really does need more information - the
what/why/where the callback is being invoked.
So...does this suggest the callback function should have a "reason code"
perhaps? Allowing the default callback function in nxboot_main -
dprintf, essentially - to produce meaningful default feedback messages
based on the reason code, and only when enabled, that can readily be
unbolted and replaced by a custom out-of-tree derivative of nxboot_main
using nxboot as a library as you suggest?
Have I "got it"?
...the addition of an external error
handler function may still be appropriate
My approach instead would be to take nxboot_main.c as
a base for my own application.
This has also been suggested by others so I now accept it graciously. I
don't need it right now and will revisit it in the way proposed if it
does ever become necessary.
Hopefully I helped,
Karel Kočí
I genuinely appreciate you taking the time to dialogue with me on this,
I really do, and it has helped a lot :-)
