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