Thanks Karel.
See below, inline.
On 30/04/2025 11:06, Karel Kočí wrote:
4. MCUboot - for example - does the copy to RAM itself so, as has been
suggested, it would be good if NXboot gains this too. It will need
the destination RAM address for this which could:
* either be via a Kconfig manually entered value used directly by
NXboot, or
* saved in the header, which would mean a change to the header
struct, and to the image creation script.
We have included a way to have extended headers included in the image. The
original idea was to include cryptographic signature in there (it is part of the
image and thus we don't have to care about size of the key used for signing).
The same extension could be used to store RAM address. Or we could just add this
fixed size field to the existing header.
I am just not sure if image is the correct location for this. Considering U-Boot
there you can have FIT image that specifies where every part should land but
NXBoot image is single part and thus I would rather compare it with older way
U-Boot booted system and there the load address was deduced by U-Boot script
itself. I think that unless we have some compound image (that I am not sure we
need for NXBoot at the moment) I would just keep it as compile time constant.
The identifier in the header is intended as a unique value identifying
compatibility and in case of loading to the RAM it might contain 32bits of
address and by requiring this identifier to match the consistency of the
bootloader and image expected address would be ensured.
I already have a board .ld file with a relevant Kconfig setting (along
the lines of CONFIG_BOARDNAME_RAM_START) that is used:
1. to denote the sdram start to the loader (but it is usually hard
coded so no big deal to lose this)
2. In my bootloader function for the copy to ram function, so a
candidate if we add the ram load to NXboot
If I add a RAM_COPY choice and RAM_LOAD_ADDRESS to NXboot's Kconfig
would that work? Did I understand you right?
5. One issue I have with NXboot is lack of printf-type error/info
messages as well as progress during copy processes which can be
lengthy (a minute or more). There is also a desire to not rely on syslog
* I will address this by Kconfig-selected addition of
"nxboot_print_info" and "nxboot_print_err" functions that
dprintf to stdout and stderr as appropriate
I think that this system already exists and is the syslog. You can configure
syslog in NuttX to print output to the stderr. By passing it through syslog we
provide ability to manage messages in system defined way contrary to the plain
printf. Consider that syslog can be logged and thus even accessed from later
booted image. Printf won't do that for you. I think that current logging should
stay mostly as is on syslog to allow logs collecting, but I think that we should
add some sort of hackable progress reporting that could be in default directed
to the stderr/stdout. We discussed this with Michal and I think that adding
callback to the `nxboot_perform_update` might be the appropriate solution. The
default nxboot_main.c could just print dots for example to signal running
operation. The more advanced or board specific reporting could be implemented in
custom nxboot main (meaning having own entry point and own nxboot main in
downstream project).
I agree we keep syslog, but three things:
1. There was an earlier discussion which requested that NXboot
shouldn't be dependent on syslog (to keep the size down). If
disabled, and it is the only output method, there is no feedback to
a user.
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!
3. syslog messages may be prepended by [INFO] etc. and filtered by
LOG_LEVEL. I use syslog already in my app with those two features -
but it gets messy if you simply want user-friendly messages on (for
example, and in my case) an LCD. Simple printf/fprintf is just
fine...in addition to syslog if syslog is enabled.
I like your idea of a callback for the dots, and that would use my
suggested "nxboot_print_info" function I think for the dots?
6. If the boot fails completely - I accept that NXboot is designed to
be very robust, but things do happen! - I will add a simple
nxboot_print_err message, but the addition of an external error
handler function may still be appropriate, easy to add, with no
overhead if not wanted. I mat use it simply to flash board-specific
LEDs, or initiate a recovery process, or something.
I don't have anything against this. The question is what would be the form of
this integration. I don't think that fallback itself should be part of the
nxboot as it will be inevitably board specific and thus it might be rather some
board specific logic called over boardctl again. It might make sense to have
ability to jump to some dedicated recovery routine even in the standard system
(not just for the bootloader) such as when init script fails in NSH.
I have added the following to tryout my idea for custom error handling,
and added calls to the error handler just in the two places at the end
of nxboot_main that there are possible ERROR returns.
#ifdefCONFIG_NXBOOT_USE_EXT_ERROR_FN
#defineerrhdlr(err) nxboot_errhdlr(err)
#else
# defineerrhdlr(err)
#endif
and
#ifdefCONFIG_NXBOOT_USE_EXT_ERROR_FN
extern void nxboot_errhdlr(int err);
#endif
I then have an error function simply as one my own out-of-tree custom
apps. Fail in the case of, for example, NSH init script fails, fall
outside of the PR intended here I think, unless now is the time to
embrace this idea and I'll leave it for now as its not a critical thing
for me at the moment?
Otherwise, if it seems OK for now, I can add an example app to
NuttX-apps to act as a template if others want to do this too.
