summaryrefslogtreecommitdiff
path: root/src/drivers/elog/Makefile.inc
AgeCommit message (Collapse)Author
2012-07-26ELOG: Add support for SMM and kernel GSMI driverDuncan Laurie
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>
2012-07-25ELOG: Add support for a monotonic boot counter in CMOSDuncan Laurie
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>
2012-07-24ELOG: Add support for flash based event logDuncan Laurie
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>