Hi, On Wed 30 Apr 2025 12:19:02 PM , Tim Hardisty wrote: > .... > 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? Yes, that is exactly what I had in mind. The first point is exactly my reasoning. It is just predefined anyway in case of NuttX as loaded image is not relocated or mapped afterwards in no way. This might change if we would target systems with MMU. They are supported in NuttX but for me it is a bit out of scope at the moment. > > 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. I caught that discussion but forgot to respond to it, honestly. I agree that for small systems syslog might be too big but I think that better solution would be to fallback to simpler syslog implementation over having switch in applications for using dual API. Consider that even debug.h uses syslog and that right now CONFIG_SYSLOG is part of Kconfig "choice" where you can select one of the SYSLOG implementations but not disable it.
> 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! That is not exactly true on NuttX from my experience. Syslog is the all and all logging in the NuttX. It is different on Linux where syslog API got replaced by journald and other monstrosities. There logging just to stderr makes sense because output is processed and indexed by user defined rules. I think that we are just going a bit on tangent. I will explain in next section. > 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 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. In the end we are talking about two different things. Let be tied it a bit to the Linux/GNU world: I think that difference here is between Linux kernel boot log and Plymouth. Syslog's destination is the "kernel boot log" while you want the output Plymouth. It doesn't matter that in our case both of them would be textual. The point is that one is used for the tracing and other for nice user experience. These two are just exclusive. In collusion 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 suggest to include just callbacks in NXBoot because someone might like to implement loader that has graphical output, other just textual and so on. > > 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. > > #ifdef CONFIG_NXBOOT_USE_EXT_ERROR_FN > #define errhdlr(err) nxboot_errhdlr(err) > #else > # define errhdlr(err) > #endif > > and > > #ifdef CONFIG_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. I think that you are not approaching callbacks correctly for the applications. The pattern you are using is common in NuttX kernel but this is applications. Although it would work it might not be the best approach for defining this fallback from user-space. My approach instead would be to take nxboot_main.c as a base for my own application. In such situation nxboot becomes just a library. With this I would introduce the appropriate API changes so your application can be implemented (such as passing pointer to the callback function to nxboot_perform_update for progress reporting). That for example requires no modification of the upstream code to introduce your fallback because you can add it in the error handling branch of your own application. At least that was our intended way to use NXBoot when we were designing it. And I agree that suggestion to have board defined fallback is outside of the scope for sure. It was just an idea. Hopefully I helped, Karel Kočí
signature.asc
Description: PGP signature
