On 30/04/2025 16:36, Karel Kočí wrote:
On Wed 30 Apr 2025 03:45:36 PM , Tim Hardisty wrote:
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
<snip>...configure system itself to send syslog output to the
system console with option CONFIG_SYSLOG_CONSOLE.
I think my arch, with an "early" available UART that gets used as
console is thwarting my attempts to get syslog to stdout or stderr.
I would suggest you to go through the syslog
related configurations such as CONFIG_SYSLOG_DEVPATH
I have, many many times lol and have tried everything I can think of for
the SYSLOG_DEVPATH to make this stdout, but no luck so far...I am still
trying!
(`Device Drivers/System Logging`). NuttX has really significant amount of syslog
consumers (channels) and you can even register new ones
(CONFIG_SYSLOG_REGISTER).
Yes, I may end up having to register a syslog channel from my nxboot
board_bringup stuff. I am on this now. My problem not yours lol.
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?
Are you sure that you disabled it really? As far as I can see it can't be
disabled in Kconfig. It might be forced somehow but it is "choice" in Kconfig
and I live in believe that it requires that exactly one option in choice would
be selected.
There is a Kconfig option to Disable System Logging. Maybe it's new as I
am working with master. I just trusted it! Disabling FILE streaming
saves another 1.5k though.
Size is not my concern, but have been bearing it in mind with the work here.
I have just implemented a very simple callback that is only called from
<copy_partition> right now...
...does this suggest the callback function should have a "reason code"
perhaps?
I think that you have a correct idea in the sense that some additional info in
the callback should be provided. The exact location and content should probably
be collaboration with Michal. I am not sure what are all the possible
significant time consuming operations in the code. I think that callback should
be right in front of all of the long operations and in case of data copy
operation (the callback you now have) it should signal also progress for sure.
You should not probably add any strings for that callback to the library.
Instead use enums and ints or even floats and document them. That provides easy
way to even localize the user facing boot process side. It would be way harder
if you would have to compare strings.
Agreed and, indeed, what I was thinking. I like enums :-)
I now have RAM loading from NXboot working, so I will work more on the
callback and look to submit a draft PR and give you, Michel, and of
course others the opportunity to review and suggest changes.
