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. And no, you don't need anything to "process" ANSI codes, you can just `cat` them and your terminal will parse it anyways. >> 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? Bence
