On 10.02.2014 23:47, David Hendricks wrote:
On Sun, Feb 9, 2014 at 4:50 AM, Paul Menzel <paulepanter@users.sourceforge.net mailto:paulepanter@users.sourceforge.net> 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 .
This requires user to do right manipulations. While keyboard and chair are usually fine, the space between them exhibits strong bug-inducing properties. The idea of the script is to reduce a possibility of user error creating strange reports. In this case the common erro I expect is using a stale file fom some other version. It's a particularly nasty one as at first glance in may look fine but would be almost useless to track how details changed from one submit to the next. If we let user supply files at all, it should be added to report, not replace files, and it should have some prefix to clearly indicate that user was involved in creating them. E.g. user_serial_log.txt
But in general I think I agree with Vladimir. CBMEM console should be supported and if not then that should be fixed.
-- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
On Tuesday, February 11, 2014 12:04:33 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote:
If we let user supply files at all, it should be added to report, not replace files, and it should have some prefix to clearly indicate that user was involved in creating them. E.g. user_serial_log.txt
There is a point at which the information becomes "too much". What is really relevant, in my opinion, are the following three points:
1. Is it an unmodified commit in master (AKA, not "-dirty"). 2. Does it boot? 3. What does not work, if any ?
Point 1 and 2 are answered by "cbmem -c | head". It answers point 1 with the first line of output, and point 2 by the fact that getting anything from cbmem means you've already booted your system.
Point 3 is more complicated, and it seems it is because of this point that we want to collect any and all information we can possibly get our hands on.
Other than "cbmem -c | head" and .config, a majority of people just don't care about all the pesky details. They're only useful when debugging problems some poor guy or gal is having. In that case, we can ask them for this info manually. It's not of any use in tracking down which revision + config works on _this_ board.
Alex
On 11.02.2014 01:56, mrnuke wrote:
On Tuesday, February 11, 2014 12:04:33 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote:
If we let user supply files at all, it should be added to report, not replace files, and it should have some prefix to clearly indicate that user was involved in creating them. E.g. user_serial_log.txt
There is a point at which the information becomes "too much". What is really relevant, in my opinion, are the following three points:
- Is it an unmodified commit in master (AKA, not "-dirty").
- Does it boot?
- What does not work, if any ?
Point 1 and 2 are answered by "cbmem -c | head". It answers point 1 with the first line of output, and point 2 by the fact that getting anything from cbmem means you've already booted your system.
Point 3 is more complicated, and it seems it is because of this point that we want to collect any and all information we can possibly get our hands on.
Other than "cbmem -c | head" and .config, a majority of people just don't care about all the pesky details. They're only useful when debugging problems some poor guy or gal is having. In that case, we can ask them for this info manually. It's not of any use in tracking down which revision + config works on _this_ board.
This is not the only uses of board-status. It's also useful to see if some boards have an issue which one meets in particular board. This information is important in tracking bugs down but hard to collect unless it's in the board-status.
Alex
Am Dienstag, den 11.02.2014, 00:04 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
On 10.02.2014 23:47, David Hendricks wrote:
On Sun, Feb 9, 2014 at 4:50 AM, Paul Menzel wrote:
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 .
David, thanks a lot for implementing this.
This requires user to do right manipulations. While keyboard and chair are usually fine, the space between them exhibits strong bug-inducing properties. The idea of the script is to reduce a possibility of user error creating strange reports. In this case the common error I expect is using a stale file from some other version. It's a particularly nasty one as at first glance in may look fine but would be almost useless to track how details changed from one submit to the next. If we let user supply files at all, it should be added to report, not replace files, and it should have some prefix to clearly indicate that user was involved in creating them. E.g. user_serial_log.txt
I agree with Vladimir that the file should be put there with a separate name. I am not sure about a common name though, as it could be also captured using a USB debug device or spkmodem(?).
But in general I think I agree with Vladimir. CBMEM console should be supported and if not then that should be fixed.
I also agree, but it’ll take more time and the above is a good work-around for the mean time.
Thanks,
Paul
On 19.02.2014 00:18, Paul Menzel wrote:
But in general I think I agree with Vladimir. CBMEM console should be supported and if not then that should be fixed.
I also agree, but it’ll take more time and the above is a good work-around for the mean time.
Strongly disagree workarounds are like glue: they stick around. This one is one that will stick around once implemented. It's better to avoid workarounds if sane solution is within reach. In this case you still haven't even named a single board where CBMEMC doesn't work.
I 'm with Vladimir on this one.
ron
Am Mittwoch, den 19.02.2014, 00:47 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
On 19.02.2014 00:18, Paul Menzel wrote:
But in general I think I agree with Vladimir. CBMEM console should be supported and if not then that should be fixed.
I also agree, but it’ll take more time and the above is a good work-around for the mean time.
Strongly disagree workarounds are like glue: they stick around. This one is one that will stick around once implemented. It's better to avoid workarounds if sane solution is within reach. In this case you still haven't even named a single board where CBMEMC doesn't work.
CBMEM console does not work for romstage on all AMD based boards. Ask Rudolf and Kyösti for more details, but as far as I understood them, the solution is *not* easy and not within reach at all.
Thanks,
Paul
On 19.02.2014 23:03, Paul Menzel wrote:
Am Mittwoch, den 19.02.2014, 00:47 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
On 19.02.2014 00:18, Paul Menzel wrote:
> But in general I think I agree with Vladimir. CBMEM console should be > supported and if not then that should be fixed.
I also agree, but it’ll take more time and the above is a good work-around for the mean time.
Strongly disagree workarounds are like glue: they stick around. This one is one that will stick around once implemented. It's better to avoid workarounds if sane solution is within reach. In this case you still haven't even named a single board where CBMEMC doesn't work.
CBMEM console does not work for romstage on all AMD based boards. Ask Rudolf and Kyösti for more details, but as far as I understood them, the solution is *not* easy and not within reach at all.
As I already told the info from romstage is likely of minor importance if the board boots. And if it doesn't, well no board status. If any of the info from romstage is relevant it can be printed in ramstage as well
Thanks,
Paul
Paul, your idea is a non-starter, so let's wind this conversation up, ok?
ron
On 02/20/2014 12:28 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 19.02.2014 23:03, Paul Menzel wrote:
Am Mittwoch, den 19.02.2014, 00:47 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
On 19.02.2014 00:18, Paul Menzel wrote:
>> But in general I think I agree with Vladimir. CBMEM console should be >> supported and if not then that should be fixed.
I also agree, but it’ll take more time and the above is a good work-around for the mean time.
Strongly disagree workarounds are like glue: they stick around. This one is one that will stick around once implemented. It's better to avoid workarounds if sane solution is within reach. In this case you still haven't even named a single board where CBMEMC doesn't work.
CBMEM console does not work for romstage on all AMD based boards. Ask Rudolf and Kyösti for more details, but as far as I understood them, the solution is *not* easy and not within reach at all.
As I already told the info from romstage is likely of minor importance if the board boots. And if it doesn't, well no board status. If any of the info from romstage is relevant it can be printed in ramstage as well
You do not get raminit debug output printed in ramstage.
Unfortunately, the case of incompatible DIMMs seems to be common one with recent AGESA ports so information from romstage what DIMMs have worked is actually relevant.
Kyösti
You do not get raminit debug output printed in ramstage.
Unfortunately, the case of incompatible DIMMs seems to be common one with recent AGESA ports so information from romstage what DIMMs have worked is actually relevant.
Just read this data from registers and print it.
Kyösti
Am Mittwoch, den 19.02.2014, 23:56 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
You do not get raminit debug output printed in ramstage.
Unfortunately, the case of incompatible DIMMs seems to be common one with recent AGESA ports so information from romstage what DIMMs have worked is actually relevant.
Just read this data from registers and print it.
Until this is done, such data is lost and it is not nice to ask users to rerun stuff again with such a patch. So please, could we just decide on a name for the serial/USB debug log file and be done with this? Not a lot of people are going to do this anyway.
Thanks,
Paul
On Thursday, February 20, 2014 12:11:58 AM Paul Menzel wrote:
Until this is done, such data is lost and it is not nice to ask users to rerun stuff again with such a patch. So please, could we just decide on a name for the serial/USB debug log file and be done with this? Not a lot of people are going to do this anyway.
Paul! It's been decided! It's dead! Drop it!
Alex
On 02/20/2014 12:56 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
You do not get raminit debug output printed in ramstage.
Unfortunately, the case of incompatible DIMMs seems to be common one with recent AGESA ports so information from romstage what DIMMs have worked is actually relevant.
Just read this data from registers and print it.
Neither of us has probably looked closely what details we are missing from AGESA romstages. I very much doubt it would be just static register configuration on memory controllers that could be dumped afterwards.
AMD has an amount of SMP init going on in romstage along with possibly multiple logical CPUs using CAR etc.
Kyösti
Necromancing this thread...
Sage has a patch to *optionally* use a serial console log in board_status.sh: http://review.coreboot.org/#/c/6094/
Earlier objections to such an approach seemed to stem from either: - Desire to use cbmem console instead. A fine idea, but on some platforms (especially those which use AGESA) a lot of information gets spit out to the console before cbmem is available. Re-factoring to make cbmem init happen earlier is unfeasible AFAICT.
- Avoid confusing cbmem console log and other logs. This can be easily solved by using a different filename. I personally think it's best to only upload one log (whichever is most useful) and avoid polluting the web UI with redundant files. But I could live with multiple console logs if others feel strongly.
Seeing as how only a small handful of people currently actually use this utility anyway, I'm inclined to think it's best to make the utility more useful for a major coreboot contributor get some more status reports uploaded.
Thoughts?
On Wed, Feb 19, 2014 at 3:14 PM, Kyösti Mälkki kyosti.malkki@gmail.com wrote:
On 02/20/2014 12:56 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
You do not get raminit debug output printed in ramstage.
Unfortunately, the case of incompatible DIMMs seems to be common one with recent AGESA ports so information from romstage what DIMMs have worked is actually relevant.
Just read this data from registers and print it.
Neither of us has probably looked closely what details we are missing from AGESA romstages. I very much doubt it would be just static register configuration on memory controllers that could be dumped afterwards.
AMD has an amount of SMP init going on in romstage along with possibly multiple logical CPUs using CAR etc.
-
David Hendricks -
Kyösti Mälkki -
mrnuke -
Paul Menzel -
ron minnich -
Vladimir 'φ-coder/phcoder' Serbinenko