Log device path into CMOS during probe stages

One of the most common hangs during coreboot execution
is during ramstage device init steps.  Currently there
are a set of (somewhat misleading) post codes during this
phase which give some indication as to where execution
stopped, but it provides no information on what device
was actually being initialized at that point.

This uses the new CMOS "extra" log banks to store the
encoded device path of the device that is about to be
touched by coreboot.  This way if the system hangs when
talking to the device there will be some indication where
to investigate next.

BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: interrupted boot with reset button and
gathered the eventlog after several test runs:

26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset

Change-Id: I6045bd4c384358b8a4e464eb03ccad639283939c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58105
This commit is contained in:
Duncan Laurie 2013-06-10 10:34:20 -07:00 committed by ChromeBot
commit cf4fc17903
5 changed files with 41 additions and 2 deletions

View file

@ -71,8 +71,13 @@ void console_tx_flush(void);
void post_code(u8 value);
#if CONFIG_CMOS_POST_EXTRA
void post_log_extra(u32 value);
struct device;
void post_log_path(struct device *dev);
void post_log_clear(void);
#else
#define post_log_extra(x) do {} while (0)
#define post_log_path(x) do {} while (0)
#define post_log_clear() do {} while (0)
#endif
/* this function is weak and can be overridden by a mainboard function. */
void mainboard_post(u8 value);