Passing boot logs to Linux?

[Dragan Simic]

On 2023-12-20 08:52, Csókás Bence wrote:
> On 2023. 12. 20. 8:09, Dragan Simic wrote:
>> On 2023-12-20 07:49, Csókás Bence wrote:
>>> On 2023. 12. 19. 21:33, Daniel Golle wrote:
>>>> 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.
> 
> It *is* useless, but most of the times the user won't be scrolling at
> all anyways, that's why I don't think these few extra bytes would be a
> problem.

Quite frankly, when it comes to computing in general, taking the "ah, it 
probably won't happen" approach isn't the best thing to do.  We should 
aim toward covering properly even the edge cases, if you agree.

> And no, you don't need anything to "process" ANSI codes, you can just
> `cat` them and your terminal will parse it anyways.

In that case, you'd probably see only the end results of the control 
sequences, which makes logging them as-is quite pointless.  To see what 
actually happened on the U-Boot console, you'd need to execute the 
control sequences step by step and watch the results.

>>> 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
> 
> That's what I read as well. Is there support for U-boot to write and
> Linux to read PStores?

No and yes, but U-Boot can already read pstore.  Please see 
doc/usage/cmd/pstore.rst for the U-Boot part, and 
Documentation/admin-guide/pstore-blk.rst for the Linux kernel part.

Another benefit of using pstore would be no permanently wasted RAM for 
the recorded console contents.  Also, having the data recorded to a 
storage device also goes along with providing permanent records.