On 2023-12-31 00:54, Heinrich Schuchardt wrote:
On 12/20/23 05:11, Simon Glass wrote:
+Heinrich Schuchardt
On Tue, 19 Dec 2023 at 13:33, Daniel Golle <dan...@makrotopia.org>
wrote:
On Tue, Dec 19, 2023 at 08:08:48PM +0000, Csókás Bence wrote:
Is passing the U-Boot boot log to Linux supported yet? We are
working
with a third-party solution, which works, but is a bit hacky, so I
was
wondering if an official solution has been merged yet.
U-Boot supports writing log messages to an rsyslog server via broadcast
to UDP port 514 (CONFIG_LOG_SYSLOG=y).
The device name can be set via environment variable log_hostname.
If you have a log server for your devices in the same network segment,
you can consolidate all your logs there.
Sure, that's also an option for one's development environment, but
unfortunately not for various standalone embedded devices in the field.
A driver writing log messages to a file could be created in U-Boot.
Please read our earlier discussion about why writing to persistent
storage is desired and why it isn't. Basically, we need to support both
persistent storage and RAM backends.
I saw that there was an option CONFIG_CONSOLE_RECORD that saves
everything to a membuff, but I don't know if that can be exported to
Linux yet. And if not in the tree yet, would such a patch be
welcome?
It is not enough to export a memory buffer. There must be support in
the
operating system to read it.
Linux supports the common platform error record (CPER) format defined
in
the UEFI specification. See
*
https://www.dmtf.org/sites/default/files/PMCI_CPEREvent_Proposal_v3.pdf
*
https://uefi.org/sites/default/files/resources/Spike%20Yuan-%20Server%20RAS%20and%20UEFI%20CPER_final.pdf
Boot errors can be reported via the ACPI BERT table. But that won't
help
you in OpenWRT which uses device-trees.
This is interesting and presents another option to be implemented at
some point. Just as some devices and platforms want to use UEFI, some
simply don't, and having more options available is always good.
To me this sounds very useful and definitely something we'd like to
have in OpenWrt. So I'd volunteer to review and test your patches
once
they are ready.
What comes to mind is that CONFIG_CONSOLE_RECORD also captures ANSI
sequences during menu or count-down before boot, so we'd have to
either
introduce a dedicated log_printf() call and use that when ever we
want
the output to also become part of the log buffer or we could somehow
filter the recorded console, eliminating all terminal control
sequences.
I have been asking for this for a while. We need some sort of inline
function to enable ANSI output. Perhaps something like this?
#if CONFIG_IS_ENABLED(ANSI)
bool use_ansi(void);
#else
static inline bool use_ansi(void) { return false; }
#endif
bool use_ansi(void)
{
return gd->flags & GD_FLG_ANSI;
}
