Passing boot logs to Linux?

[Heinrich Schuchardt]

On 03.01.24 11:11, Csókás Bence wrote:
> Hi,
>
> 2023. 12. 31. 0:54 keltezéssel, Heinrich Schuchardt írta:
>> 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:
>>>>
>>>> Hi Bence,
>>>>
>>>> On Tue, Dec 19, 2023 at 08:08:48PM +0000, Csókás Bence wrote:
>>>>> Hi!
>>>>>
>>>>> 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.
>>
>> A driver writing log messages to a file could be created in U-Boot.
>
> I am aware, however, this is not what we want to do right now. We want
> to pass the logs to the booted up OS on the *same* machine.
>
>>>>> 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.
>
> Of course. But it should be trivial to add a driver to Linux and other
> FOSS OSes to support reading these records from memory.

Please, have a look at Linux'

Documentation/admin-guide/ramoops.rst
Documentation/devicetree/bindings/reserved-memory/ramoops.yaml

If U-Boot had a log driver writing to the ramoops buffer we would not
need any change in Linux.

The current U-Boot drivers are

common/log_syslog.c
common/log_console.c

Best regards

Heinrich

>
>> 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
>
> According to page 16, records can be of the following types:
> * error, recovered
> * previous error
> * simulated error
>
> There is no type that is an operational condition (even though you can
> append informational sections to an error record). So what we could do
> is mark everything as "recovered", but that is misleading, booting is
> not an "error condition".
>
>  > *
> https://uefi.org/sites/default/files/resources/Spike%20Yuan-%20Server%20RAS%20and%20UEFI%20CPER_final.pdf
>
> This looks like some promo material, not very useful from an
> implementation standpoint. Plus, this talks about Intel-based cloud
> computing/HPC, not exactly the embedded systems we are targeting.
>
>> Boot errors can be reported via the ACPI BERT table. But that won't help
>> you in OpenWRT which uses device-trees.
>
> Exactly. I would avoid depending on ACPI/UEFI. Having a simple in-memory
> struct can be supported on all platforms, even without ACPI, UEFI,
> writable filesystem, even DT is not needed if you can pass the base
> pointer to the OS via other means (ie. command line).
>
>> Best regards
>>
>> Heinrich
>
> Bence
>