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