Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Haleigh Novak]

Hello,

Will the ability to change the 'Room allocated for console output in CBMEM' size still be available (and functional) for those need to view the full console output due to the addition of debugging/tracing lines?

HN

________________________________
From: coreboot  on behalf of Julius Werner via coreboot 
Sent: Monday, April 10, 2017 3:50 PM
To: Coreboot; [e-mail]
Subject: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

Hi folks,

I'm planning to make some changes to coreboot's CBMEM console with https://review.coreboot.org/#/c/18301 that should make it easier to debug problems spanning multiple reboots. I'm trying my best to avoid breaking previous behavior and keeping it compatible with older code, but there'll be some edge cases so Aaron suggested I announce it here.

The basic idea is to turn the console into a persistent ring buffer. If coreboot finds an already initialized console in memory during boot, it will just continue appending to it rather than begin writing from the start of the buffer again. This means that if you run cbmem -c, the most recent boot will always be at the bottom of the output, and you can scroll further up to see logs from the boot before that (assuming you didn't lose DRAM power or something). It may also give some runtime firmware components (like we have on ARM64) a good place to log stuff and persist crash dumps in the future.

The console buffer will fill up eventually with enough reboots, so when that happens we will start discarding the oldest lines from the log. This means the behavior if the log buffer is too small for even a single full boot will become slightly different: we'll only keep the latest lines, whereas previously we would only keep the earliest lines and a counter of dropped characters. I don't think this should be an issue though, since we normally should have enough buffer to fit a whole boot anyway (the default is currently 128KB which ought to be enough for any board).

The change may also cause some hiccups if you're using a newer version of coreboot with an older version of cbmem (or SeaBIOS or whatever else reads the console): it will not crash and it will still print the whole log, but if the log has rolled over (into "ring buffer mode") it will print lines out of order. This is unfortunately the best I can do with the way current readers are implemented. I'm of course also updating the code for cbmem so as soon as you deploy the new version it will be able to display buffers from both old and new coreboot versions correctly. (I'll send patches to align SeaBIOS and the Linux memconsole driver in the same manner as soon as the coreboot patch is approved.)

Let me know if you have any concerns about this.

RFC: Changing CBMEM console to run as a persistent ring-buffer

[Julius Werner]

> seabios doesn't read the log, instead it'll append its own messages.
> Which I expect will continue to work fine, except when it hits the end
> of the log buffer, where seabios will simply stop logging instead of
> rolling over.

Right, sorry, I confused something while writing the explanation there.
Nevertheless, the SeaBIOS code will require a small adjustment (same as the
libpayload driver in the patch I linked) to continue appending correctly
after the log has rolled over, and I'll provide that patch.
> Will the ability to change the 'Room allocated for console output in
> CBMEM' size still be available (and functional) for those need to view the
> full console output due to the addition of debugging/tracing lines?

Yes, nothing changes about where the console buffer space is allocated. You
can continue to increase the size through Kconfig. I'm just changing how it
gets used.