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 <dan...@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
