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

[Paul Menzel]

Dear coreboot folks,

currently no coreboot messages are stored for boards not supporting
CBMEM console (or where this option is disabled (currently by default))
or no coreboot *romstage* messages are stored for boards, where the data
cannot be preserved (passed to ramstage).

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.

Thanks,

Paul

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 09.02.2014 13:50, Paul Menzel wrote:
> Dear coreboot folks,
>
> 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
> (or where this option is disabled (currently by default))

Change the defaults.
> 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?
> 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. Certainely, one needs to have a recovery method for case of
brick but having a complete serial setup will heavily reduce
board-status input which already isn't huge.
> Thanks,
>
> Paul

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

[Paul Menzel]

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
log?
> 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

[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

[Alex G.]

On 02/09/2014 07:34 AM, Paul Menzel wrote:
> Sorry, no idea. I thought there were some. At least not all boards 
> have been tested to my knowledge.

Please stop just throwing half-thoght proposals out there when you
have "no idea" (your words, not mine).

Alex

[David Hendricks]

On Sun, Feb 9, 2014 at 4:50 AM, Paul Menzel <
[e-mail]> wrote:
> Dear coreboot folks,
>
> currently no coreboot messages are stored for boards not supporting
> CBMEM console (or where this option is disabled (currently by default))
> or no coreboot *romstage* messages are stored for boards, where the data
> cannot be preserved (passed to ramstage).
>
> 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.

I don't think the script itself should be responsible for collecting serial
output. Instead, how about adding an argument to override the default
behavior of running "cbmem -c" on the target so that the user can pass in a
filename? The user will simply capture the serial output using whatever
tool they like, dump the output to a text file, and run the script with an
argument to use the file instead of calling "cbmem -c". Here is a
proof-of-concept: http://review.coreboot.org/#/c/5191 .

But in general I think I agree with Vladimir. CBMEM console should be
supported and if not then that should be fixed.