Passing boot logs to Linux?

[Dragan Simic]

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 <daniel at 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;
>> }