Passing boot logs to Linux?

[Csókás Bence]

On 2023. 12. 19. 21:33, Daniel Golle 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.
>>
>> 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.
>
>
> Cheers
>
>
> Daniel
>

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.

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.


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


Bence