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. 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 Reviewed-on: http://review.coreboot.org/4230 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This commit is contained in:
committed by
Stefan Reinauer
parent
d5686fe23b
commit
8adf7a2c50
@ -114,6 +114,22 @@ void post_log_extra(u32 value)
|
||||
|
||||
spin_unlock(&cmos_post_lock);
|
||||
}
|
||||
|
||||
void post_log_path(struct device *dev)
|
||||
{
|
||||
if (dev) {
|
||||
/* Encode path into lower 3 bytes */
|
||||
u32 path = dev_path_encode(dev);
|
||||
/* Upper byte contains the log type */
|
||||
path |= CMOS_POST_EXTRA_DEV_PATH << 24;
|
||||
post_log_extra(path);
|
||||
}
|
||||
}
|
||||
|
||||
void post_log_clear(void)
|
||||
{
|
||||
post_log_extra(0);
|
||||
}
|
||||
#endif /* CONFIG_CMOS_POST_EXTRA */
|
||||
#endif /* !__PRE_RAM__ */
|
||||
|
||||
|
Reference in New Issue
Block a user