GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/src/include/elog.h

81 lines
2.7 KiB
C
Raw Normal View History

src/include: Use SPDX for GPL-2.0-only files Done with sed and God Lines. Only done for C-like code for now. Change-Id: I2fa3bad88bb5b068baa1cfc6bbcddaabb09da1c5 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40053 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2020-04-02 23:48:27 +02:00
/* SPDX-License-Identifier: GPL-2.0-only */
ELOG: Add support for flash based event log 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>
2012-06-24 01:08:47 +02:00
#ifndef ELOG_H_
#define ELOG_H_
Move ELOG defines/struct to commonib/bsd/elog.h Move ELOG defines and structs from include/elog.h to include/comonlib/bsd/elog.h. This is needed because the will be used from util/ (in a future commit). It also replaces uNN types with uintNN_t types, for the reason described above. BUG=b:172210863 Signed-off-by: Ricardo Quesada <ricardoq@google.com> Change-Id: I4f307f599a311810df2367b7c888f650cff1214a Reviewed-on: https://review.coreboot.org/c/coreboot/+/56405 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2021-07-17 01:44:58 +02:00
#include <commonlib/bsd/elog.h>
src/include: Add missing includes Change-Id: I746ea7805bae553a146130994d8174aa2e189610 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/43368 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
2020-07-12 09:03:22 +02:00
#include <stdint.h>
coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX) This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-06 01:53:33 +01:00
#if CONFIG(ELOG)
elog: Do not attempt to init SPI This severs a dependency the eventlog code has on initializing chipset/SoC SPI controller. Currently elog_init() calls spi_init() as a catch-all. This worked for x86 since the SPI controller is only used for one thing on existing platforms. As we add eventlogging support to non-x86 platforms we need to consider the more generalized case where the assumptions about how SPI works on x86 are no longer valid. BUG=none BRANCH=none Signed-off-by: David Hendricks <dhendrix@chromium.org> TEST=built and booted on Link, Beltino and Rambi. See below for "mosys eventlog list" output on Link showing boot and suspend/resume events (including lid close/open) added successfully. localhost ~ # mosys eventlog list 0 | 2014-04-14 13:52:44 | Log area cleared | 4096 1 | 2014-04-14 13:52:44 | System boot | 50 2 | 2014-04-14 13:52:44 | EC Event | Power Button 3 | 2014-04-14 13:52:44 | SUS Power Fail 4 | 2014-04-14 13:52:44 | System Reset 5 | 2014-04-14 13:52:44 | ACPI Wake | S5 6 | 2014-04-14 13:53:25 | ACPI Enter | S3 7 | 2014-04-14 13:53:35 | ACPI Wake | S3 8 | 2014-04-14 13:53:35 | Wake Source | RTC Alarm | 0 9 | 2014-04-14 13:53:49 | ACPI Enter | S3 10 | 2014-04-14 13:54:00 | EC Event | Lid Open 11 | 2014-04-14 13:54:00 | ACPI Wake | S3 12 | 2014-04-14 13:54:00 | Wake Source | GPIO | 15 Original-Change-Id: I26e25c0a856f7b8db5ab6b8e7e1acae291d2eadc Original-Reviewed-on: https://chromium-review.googlesource.com/194526 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Commit-Queue: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 2971d20b6ebdd9803b05ccbbaeefe1bde1a21af4) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Ia5f2913fd8e4fee6e741e6d1e39d32bb86525cb3 Reviewed-on: http://review.coreboot.org/7831 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-04-14 01:45:31 +02:00
/* Eventlog backing storage must be initialized before calling elog_init(). */
ELOG: Add support for flash based event log 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>
2012-06-24 01:08:47 +02:00
extern int elog_init(void);
extern int elog_clear(void);
drivers/elog: provide return status for all operations Instead of relying on global state to determine if an error occurred provide the ability to know if an add or shrink operation is successful. Now the call chains report the error back up the stack and out to the callers. BUG=chrome-os-partner:55932 Change-Id: Id4ed4d93e331f1bf16e038df69ef067446d00102 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16104 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-08-06 17:02:37 +02:00
/* Event addition functions return < 0 on failure and 0 on success. */
extern int elog_add_event_raw(u8 event_type, void *data, u8 data_size);
extern int elog_add_event(u8 event_type);
extern int elog_add_event_byte(u8 event_type, u8 data);
extern int elog_add_event_word(u8 event_type, u16 data);
extern int elog_add_event_dword(u8 event_type, u32 data);
extern int elog_add_event_wake(u8 source, u32 instance);
ELOG: Add support for generating SMBIOS type15 table 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>
2012-06-24 01:13:42 +02:00
extern int elog_smbios_write_type15(unsigned long *current, int handle);
drivers/elog/elog.c: Create extended event For debug reasons, sometimes you not only want to log an event, but also some extra information that would help debugging. Create an extended event reporting event type with a dword complement, and define extended events for failing to enter S3 due to pending wake event (one for pm1 and one for gpe0). BUG=b:111100312 TEST=Add a fake pending wake event, build and boot grunt, see the event in eventlog.txt. Change-Id: I3e8df0953db09197d6d8145b0fc1e583379deaa5 Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-on: https://review.coreboot.org/28246 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2018-08-20 22:51:30 +02:00
extern int elog_add_extended_event(u8 type, u32 complement);
nyan*: Add an empty elog functions for the !CONFIG_ELOG case Provide elog stub functions so eventlog support can be omitted without littering code with "#if CONFIG_ELOG". This makes it so coreboot can be built without eventlog support for these platforms for debugging purposes. BUG=none BRANCH=none TEST=compiled for Nyan and Rambi with CONFIG_ELOG unset Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Ibf56d29a09234068773378f99ad9bffd5480dc9c Original-Reviewed-on: https://chromium-review.googlesource.com/198647 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Tom Warren <twarren@nvidia.com> Original-Commit-Queue: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 8e83dd460647972c4f46c19f8dc3d3ad7baeb550) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I3c0803ceb7a1c06da717416c42b6b7730c029ed0 Reviewed-on: http://review.coreboot.org/7901 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2014-05-09 05:04:02 +02:00
#else
/* Stubs to help avoid littering sources with #if CONFIG_ELOG */
static inline int elog_init(void) { return -1; }
static inline int elog_clear(void) { return -1; }
elog: fix default elog_add_event_raw() declaration When CONFIG_ELOG isn't used default empty inline functions are provided, however the elog_add_event_raw() had the wrong type signature. Fix that. BUG=chrome-os-partner:59395 Change-Id: Iaee68440bbafc1e91c88a7b03e283fc3e72de0a3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17232 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-04 17:17:54 +01:00
static inline int elog_add_event_raw(u8 event_type, void *data,
u8 data_size) { return 0; }
drivers/elog: provide return status for all operations Instead of relying on global state to determine if an error occurred provide the ability to know if an add or shrink operation is successful. Now the call chains report the error back up the stack and out to the callers. BUG=chrome-os-partner:55932 Change-Id: Id4ed4d93e331f1bf16e038df69ef067446d00102 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16104 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-08-06 17:02:37 +02:00
static inline int elog_add_event(u8 event_type) { return 0; }
static inline int elog_add_event_byte(u8 event_type, u8 data) { return 0; }
static inline int elog_add_event_word(u8 event_type, u16 data) { return 0; }
static inline int elog_add_event_dword(u8 event_type, u32 data) { return 0; }
static inline int elog_add_event_wake(u8 source, u32 instance) { return 0; }
nyan*: Add an empty elog functions for the !CONFIG_ELOG case Provide elog stub functions so eventlog support can be omitted without littering code with "#if CONFIG_ELOG". This makes it so coreboot can be built without eventlog support for these platforms for debugging purposes. BUG=none BRANCH=none TEST=compiled for Nyan and Rambi with CONFIG_ELOG unset Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Ibf56d29a09234068773378f99ad9bffd5480dc9c Original-Reviewed-on: https://chromium-review.googlesource.com/198647 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Tom Warren <twarren@nvidia.com> Original-Commit-Queue: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 8e83dd460647972c4f46c19f8dc3d3ad7baeb550) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I3c0803ceb7a1c06da717416c42b6b7730c029ed0 Reviewed-on: http://review.coreboot.org/7901 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2014-05-09 05:04:02 +02:00
static inline int elog_smbios_write_type15(unsigned long *current,
int handle) {
return 0;
}
drivers/elog/elog.c: Create extended event For debug reasons, sometimes you not only want to log an event, but also some extra information that would help debugging. Create an extended event reporting event type with a dword complement, and define extended events for failing to enter S3 due to pending wake event (one for pm1 and one for gpe0). BUG=b:111100312 TEST=Add a fake pending wake event, build and boot grunt, see the event in eventlog.txt. Change-Id: I3e8df0953db09197d6d8145b0fc1e583379deaa5 Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com> Reviewed-on: https://review.coreboot.org/28246 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2018-08-20 22:51:30 +02:00
static inline int elog_add_extended_event(u8 type, u32 complement) { return 0; }
nyan*: Add an empty elog functions for the !CONFIG_ELOG case Provide elog stub functions so eventlog support can be omitted without littering code with "#if CONFIG_ELOG". This makes it so coreboot can be built without eventlog support for these platforms for debugging purposes. BUG=none BRANCH=none TEST=compiled for Nyan and Rambi with CONFIG_ELOG unset Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Ibf56d29a09234068773378f99ad9bffd5480dc9c Original-Reviewed-on: https://chromium-review.googlesource.com/198647 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Tom Warren <twarren@nvidia.com> Original-Commit-Queue: David Hendricks <dhendrix@chromium.org> Original-Tested-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 8e83dd460647972c4f46c19f8dc3d3ad7baeb550) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I3c0803ceb7a1c06da717416c42b6b7730c029ed0 Reviewed-on: http://review.coreboot.org/7901 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2014-05-09 05:04:02 +02:00
#endif
ELOG: Add support for flash based event log 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>
2012-06-24 01:08:47 +02:00
ELOG: Introduce elog_gsmi variants This avoids a lot of if (CONFIG(ELOG_GSMI)) boilerplate. Change-Id: I87d25c820daedeb33b3b474a6632a89ea80b0867 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36647 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-11-06 10:04:27 +01:00
#if CONFIG(ELOG_GSMI)
#define elog_gsmi_add_event elog_add_event
#define elog_gsmi_add_event_byte elog_add_event_byte
#define elog_gsmi_add_event_word elog_add_event_word
#else
static inline int elog_gsmi_add_event(u8 event_type) { return 0; }
static inline int elog_gsmi_add_event_byte(u8 event_type, u8 data) { return 0; }
static inline int elog_gsmi_add_event_word(u8 event_type, u16 data) { return 0; }
#endif
ELOG: Add support for SMM and kernel GSMI driver 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-06-24 01:48:38 +02:00
extern u32 gsmi_exec(u8 command, u32 *param);
coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX) This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-06 01:53:33 +01:00
#if CONFIG(ELOG_BOOT_COUNT)
ELOG: Add support for a monotonic boot counter in CMOS 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-06-24 01:37:45 +02:00
u32 boot_count_read(void);
elog: Allow calling boot_count_read() without CONFIG_ELOG_BOOT_COUNT Have boot_count_read() just return 0 if CONFIG_ELOG_BOOT_COUNT is not enabled. BUG=b:79865267 TEST=firmware_EventLog Change-Id: I70f16226371324dea37b3f36f85c2037e324ef31 Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Reviewed-on: https://review.coreboot.org/26526 Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-25 02:00:45 +02:00
#else
static inline u32 boot_count_read(void)
{
return 0;
}
#endif
ELOG: Add support for a monotonic boot counter in CMOS 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-06-24 01:37:45 +02:00
u32 boot_count_increment(void);
drivers/elog: Add elog_boot_notify() Change-Id: I898188d31fcfd153eb95d0a7324fa9fd85316e3c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35373 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2019-09-11 16:12:26 +02:00
static inline void elog_boot_notify(int s3_resume)
{
if (CONFIG(ELOG_BOOT_COUNT) && !s3_resume)
boot_count_increment();
}
elog: Support logging S0ix sleep/wake info in elog 1. Add support for new GSMI commands to log S0ix entry/exit information in elog. 2. In case of resume, provide callbacks to allow platform and mainboard to log any wake source information. BUG=b:67874513 Change-Id: I593e8a9e31cad720ac1f77aab447a0dbdbe9a28b Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/22079 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-10-15 03:12:25 +02:00
/*
* Callback from GSMI handler to allow platform to log any wake source
* information.
*/
void elog_gsmi_cb_platform_log_wake_source(void);
/*
* Callback from GSMI handler to allow mainboard to log any wake source
* information.
*/
void elog_gsmi_cb_mainboard_log_wake_source(void);
ELOG: Add support for flash based event log 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>
2012-06-24 01:08:47 +02:00
#endif /* ELOG_H_ */