Hi, On 03.01.24 13:44, Heinrich Schuchardt wrote: > 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
Yes, that's what I would suggest as well. For reference, barebox supports pstore with ramoops backend to share its dmesg buffer with Linux. You can take a look there for pointers. The code may not directly portable to U-Boot though barebox implements pstore as a file system. The problem of interactive console I/O filling up the log is resolved by having only logged output (pr_info, dev_info and friends) output to pstore and plain printf only prints to enabled serial consoles. Cheers, Ahmad > > 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 >> > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
