Passing boot logs to Linux?

[Dragan Simic]

On 2023-12-20 07:49, Csókás Bence wrote:
> On 2023. 12. 19. 21:33, Daniel Golle 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.
>>> 
>>> 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?
>> 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 don't think that would be a huge problem, Linux userspace can filter
> ANSI control codes if it wants to. For now, I'd like a byte-for-byte
> copy of the console, as-is, presented to Linux.

But wouldn't recording the control sequences as-is actually be pretty 
much useless?  For example, some user can spend a few minutes scrolling 
through the boot menu, which would produce a fair amount of nearly 
useless recorded data.

Moreover, if I'm not wrong, viewing or parsing such as-is data would 
actually require replaying the control sequences, to reproduce the 
actual console contents as it was recorded, which would be quite 
cumbersome.


> On 2023. 12. 20. 6:04, Dragan Simic wrote:
>> On 2023-12-20 05:45, Sean Anderson wrote:
>>> On 12/19/23 23:11, Simon Glass wrote:
>>>> On Tue, 19 Dec 2023 at 13:15, Csókás Bence <Csokas.Bence at prolan.hu>
>>>> 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.
>>>>> 
>>>>> 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?
>>>> 
>>>> Not yet, but yes I would like to see this.
>>> 
>>> I think most of the infrastructure is already here. We could use 
>>> either
>>> console recording (as mentioned above), which is more complete, or a 
>>> new
>>> LOG_DRIVER (which would have the advantage of omitting things like
>>> countdowns).
>>> 
>>> In terms of sending things to Linux, I think the natural choice would
>>> be pstore,
>>> which we already have a parser for.
>> 
>> Yes, using pstore would make sense.
>> 
>> As a note, I'm willing to work on this, if Csókás actually doesn't
>> pick it up.  I'll be so happy to see this feature reaching all kinds
>> of boards and devices.
>> 
> As I undersand (never used it before, just quickly read the kernel 
> doc),
> PStore is for Linux -> U-Boot communication. What I'm doing is the
> opposite. But the approach I envisioned is similar: make U-Boot save a
> copy of the log to a struct at a fixed memory address, then pass this
> address + the length of the log to the kernel via DT and/or 
> commandline.

Actually, pstore is primarily intended as a means to record and store 
kernel crash dumps for later investigation.  In other words, the kernel 
writes data to pstore during an oops so it can be investigated later.

One of the benefits of using pstore for record the U-Boot console 
contents, instead of using a memory region, is that no special utilities 
would be required to access the recorded console outputs.  Also, many of 
the requirements that you listed below would be already fulfilled.

> What I thought to include in the struct:
> 
> * magic cookie (it was in the 3rd party solution, and it's an easy way
> of doing some form of integrity check)
> * struct version (in case we ever change the layout)
> * U-Boot version code (maybe not necessary? It can be parsed out of the
> log as well)
> * length of the log (or it could also be passed via DT/cmdline)
> * and then the log buffer of course