Recent changes in EC/Vboot/U-boot have completely broken
the logging of developer and recovery modes.
Recovery mode may not be in VBNV, so if that is zero and
yet we are in recovery mode then assume it is there because
the button/key was pressed.
Since there may not be any actual developer mode switch
we look if option rom is loaded and the system is not
in recovery mode and consider that as developer mode.
Change-Id: I70104877b24de477217e1ff5b3a019aef22343ec
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1346
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This will log if the ME is disabled or has an error.
1) disable ME via EC console: gpioset PCH_HDA_SDO 1
2) boot the device
3) read eventlog with "mosys eventlog list"
71 | 2012-07-13 10:10:55 | Management Engine | Disabled
Change-Id: I9f6ee452d2aea76e6a5ea2cd50a50ff36245692a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1345
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The linux kernel contains an SMI driver that was written by
me (Duncan) and upstreamed a couple years ago called GSMI.
This driver will format a parameter buffer and pass pointers
to this parameter buffer to the SMI handler. It uses this to
generate events for kernel shutdown reasons: Clean, Panic, Oops,
etc.
This function expects to be passed pointers into the SMM state
save area that correspond to the prameter buffer and the return
code, which are typically EAX and EBX.
The format of the parameter buffer is defined in the kernel
driver so we implement the same interface here in order to be
compatible.
GSMI_CMD_HANDSHAKE: this is an early call that it does to try
and detect what kind of BIOS is running.
GSMI_CMD_SET_EVENT_LOG: this contains a parameter buffer that
has event type and data. The kernel-specific events are
translated here and raw events are passed through as well which
allows any run-time event to be added for testing.
GSMI_CMD_CLEAR_EVENT_LOG: this command clears the event log.
First the gsmi driver must be enabled in the kernel with
CONFIG_GOOGLE_GSMI and then events can be added via sysfs
and events are automatically generated for various kernel
shutdown reasons.
These can be seen in the event log as the 'Kernel Event' type:
169 | 2012-06-23 15:03:04 | Kernl Event | Clean Shutdown
181 | 2012-06-23 16:26:32 | Kernl Event | Oops
181 | 2012-06-23 16:26:32 | Kernl Event | Panic
Change-Id: Ic0a3916401f0d9811e4aa8b2c560657dccc920c1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1316
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This maintains a 32bit monotonically increasing boot counter
that is stored in CMOS and logged on every non-S3 boot when
the event log is initialized.
In CMOS the count is prefixed with a 16bit signature and
appended with a 16bit checksum.
This counter is incremented in sandybridge early_init which is
called by romstage. It is incremented early in order notice
when reboots happen after memory init.
The counter is then logged when ELOG is initialized and will
store the boot count as part of a 'System boot; event.
Reboot a few times and look for 'System boot' events in the
event log and check that they are increasing. Also verify
that the counter does NOT increase when resuming from S3.
171 | 2012-06-23 16:02:55 | System boot | 285
176 | 2012-06-23 16:26:00 | System boot | 286
182 | 2012-06-23 16:27:04 | System boot | 287
189 | 2012-06-23 16:31:10 | System boot | 288
Change-Id: I23faeafcf155edfd10aa6882598b3883575f8a33
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1315
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This standared SMBIOS 0able describes the location and format
of the event log to the OS and applications. In this case the
pointer is a 32bit physical address pointer to the log in
memory mapped flash.
Look for SMBIOS type15 entry with 'dmidecode -t 15'
Handle 0x0004, DMI type 15, 23 bytes
System Event Log
Area Length: 4095 bytes
Header Start Offset: 0x0000
Header Length: 8 bytes
Data Start Offset: 0x0008
Access Method: Memory-mapped physical 32-bit address
Access Address: 0xFFB6F000
Status: Valid, Not Full
Change Token: 0x00000000
Header Format: OEM-specific
Supported Log Type Descriptors: 0
Change-Id: I1e7729e604000f197e26e69991a2867e869197a6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1314
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is based around the SMBIOS event log specification but
expanded with OEM event types to support more specific and
relevant system events.
It requires flash storage and a minimum 4K block (or flash block
size) that should be allocated in the FMAP.
A copy of the event log is maintained in memory for convenience
and speed and the in-memory copy is written to flash at specific
points.
The log is automatically shunk when it reaches a configurable
full threshold in order to not get stuck with a full log that
needs OS help to clear.
ELOG implements the specification published here:
http://code.google.com/p/firmware-event-log/wiki/FirmwareEventLogDesign
And is similar to what we use in other firmware at Google.
This implementation does not support double-buffered flash
regions. This is done because speed is valued over the log
reliability and it keeps the code simpler for the first version.
This is a large commit and by itself it just provides a new
driver that is made available to coreboot. Without additional
patches it is not very useful, but the end result is an event
log that will contain entries like this:
171 | 2012-06-23 16:02:55 | System boot | 285
172 | 2012-06-23 16:02:55 | EC Event | Power Button
173 | 2012-06-23 16:02:55 | SUS Power Fail
174 | 2012-06-23 16:02:55 | System Reset
175 | 2012-06-23 16:02:55 | ACPI Wake | S5
Change-Id: I985524c67f525c8a268eccbd856c1a4c2a426889
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1311
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Duncan Laurie