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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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>