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