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

Vladimir 'φ-coder/phcoder' Serbinenko phcoder at gmail.com
Sun Feb 9 14:47:31 CET 2014

On 09.02.2014 14:34, Paul Menzel wrote:
> 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.
board-status is all about testing. When we see incomplete
coreboot_console.txt it means there is a bug to be fixed, not workarounded.
>>> (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.
I don't see any problem with enabling cbmemc by default on all boards.
>>> 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).
What is the info we need from it? ROMCC boards usually don't output much.
>>> Using the serial (or USB)
Your argument with USB console is completele broken as EHCI debug is not
supported on ROMCC boards at all.
>>> 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.
And who will care about it then?
>> 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
> log?
I use debricking setup perhaps every 20 flashes on a supported board.
Not every time.
>> 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.
> Thanks,
> Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 274 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140209/66637b32/attachment.sig>

More information about the coreboot mailing list