[coreboot] [RFC] board_status: Add serial log to `serial_console.txt`

Paul Menzel paulepanter at users.sourceforge.net
Sun Feb 9 14:34:38 CET 2014

Am Sonntag, den 09.02.2014, 14:18 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
> On 09.02.2014 13:50, Paul Menzel wrote:

> > currently no coreboot messages are stored for boards not supporting
> > CBMEM console
> Is there any remaining? If so it's an issue to be fixed

Sorry, no idea. I thought there were some. At least not all boards have
been tested to my knowledge.

> > (or where this option is disabled (currently by default))
> Change the defaults.

It is not safe or wanted for all boards I believe. But others are more
knowledgeable to comment on that issue.

> > or no coreboot *romstage* messages are stored for boards, where the data
> > cannot be preserved (passed to ramstage).
> which boards are concerned? Which boards use ROMCC for romstage? Do they
> output anything useful in romstage? If so, can't it be compensated by
> ramstage?

In my case it is the Asus M2V-MX SE (AMD, pre-AGESA).

> > Using the serial (or USB) console all these messages can be captured
> > with no problem, so I propose to just add these captured messages into
> > the file `serial_console.txt`. Of course this file probably contains
> > also the payload and (Linux) kernel log, but I think that is fine.
> > 
> > SeaBIOS’ `readserial.py` should be used for capturing the messages as it
> > adds time stamps.
> > 
> > Scripting this is going to be hard, as the log is captured on a
> > different system. So for now I propose to add it manually.
> Having to capture serial makes setup needed for board-status more
> difficult.

Surely it will not be a requirement to capture the serial output. My
proposal is about adding it, when it is captured already and what file
name to use.

> Certainly, one needs to have a recovery method for case of
> brick

You always need that in case of a brick. What is special about serial

> but having a complete serial setup will heavily reduce board-status
> input which already isn't huge.

Again, it is not meant to be a requirement in addition to what is
currently captured.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140209/12c215f0/attachment.sig>

More information about the coreboot mailing list