<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Hello, <br>
</p>
<p><br>
</p>
<p>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?<br>
</p>
<p><br>
</p>
<p>HN <br>
</p>
<div style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> coreboot <coreboot-bounces@coreboot.org> on behalf of Julius Werner via coreboot <coreboot@coreboot.org><br>
<b>Sent:</b> Monday, April 10, 2017 3:50 PM<br>
<b>To:</b> Coreboot; seabios@seabios.org<br>
<b>Subject:</b> [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi folks,
<div><br>
</div>
<div>I'm planning to make some changes to coreboot's CBMEM console with <a href="https://review.coreboot.org/#/c/18301">
https://review.coreboot.org/#/c/18301</a> 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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>Let me know if you have any concerns about this.</div>
</div>
</div>
</div>
</body>
</html>