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

164 lines
5.6 KiB
C
Raw Normal View History

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
/*
* This file is part of the coreboot project.
*
* Copyright (C) 2012 The ChromiumOS Authors. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
*/
#ifndef ELOG_H_
#define ELOG_H_
#if CONFIG_ELOG
/* SMI command code for GSMI event logging */
#define ELOG_GSMI_APM_CNT 0xEF
#define MAX_EVENT_SIZE 0x7F
/* End of log */
#define ELOG_TYPE_EOL 0xFF
/*
* Standard SMBIOS event log types below 0x80
*/
#define ELOG_TYPE_UNDEFINED_EVENT 0x00
#define ELOG_TYPE_SINGLE_BIT_ECC_MEM_ERR 0x01
#define ELOG_TYPE_MULTI_BIT_ECC_MEM_ERR 0x02
#define ELOG_TYPE_MEM_PARITY_ERR 0x03
#define ELOG_TYPE_BUS_TIMEOUT 0x04
#define ELOG_TYPE_IO_CHECK 0x05
#define ELOG_TYPE_SW_NMI 0x06
#define ELOG_TYPE_POST_MEM_RESIZE 0x07
#define ELOG_TYPE_POST_ERR 0x08
#define ELOG_TYPE_PCI_PERR 0x09
#define ELOG_TYPE_PCI_SERR 0x0A
#define ELOG_TYPE_CPU_FAIL 0x0B
#define ELOG_TYPE_EISA_TIMEOUT 0x0C
#define ELOG_TYPE_CORRECTABLE_MEMLOG_DIS 0x0D
#define ELOG_TYPE_LOG_DISABLED 0x0E
#define ELOG_TYPE_UNDEFINED_EVENT2 0x0F
#define ELOG_TYPE_SYS_LIMIT_EXCEED 0x10
#define ELOG_TYPE_ASYNC_HW_TIMER_EXPIRED 0x11
#define ELOG_TYPE_SYS_CONFIG_INFO 0x12
#define ELOG_TYPE_HDD_INFO 0x13
#define ELOG_TYPE_SYS_RECONFIG 0x14
#define ELOG_TYPE_CPU_ERROR 0x15
#define ELOG_TYPE_LOG_CLEAR 0x16
#define ELOG_TYPE_BOOT 0x17
/*
* Extended defined OEM event types start at 0x80
*/
/* OS/kernel events */
#define ELOG_TYPE_OS_EVENT 0x81
/* Last event from coreboot */
#define ELOG_TYPE_OS_BOOT 0x90
/* Embedded controller event */
#define ELOG_TYPE_EC_EVENT 0x91
ELOG: Add EC events to elog header These events were initially for Chrome EC but they can be applied to any EC. Change-Id: I0eba9dbe8bde506e7f9ce18c7793399d40e6ab3b Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/1746 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-09-10 19:03:46 +02:00
#define EC_EVENT_LID_CLOSED 0x01
#define EC_EVENT_LID_OPEN 0x02
#define EC_EVENT_POWER_BUTTON 0x03
#define EC_EVENT_AC_CONNECTED 0x04
#define EC_EVENT_AC_DISCONNECTED 0x05
#define EC_EVENT_BATTERY_LOW 0x06
#define EC_EVENT_BATTERY_CRITICAL 0x07
#define EC_EVENT_BATTERY 0x08
#define EC_EVENT_THERMAL_THRESHOLD 0x09
#define EC_EVENT_THERMAL_OVERLOAD 0x0a
#define EC_EVENT_THERMAL 0x0b
#define EC_EVENT_USB_CHARGER 0x0c
#define EC_EVENT_KEY_PRESSED 0x0d
#define EC_EVENT_INTERFACE_READY 0x0e
#define EC_EVENT_KEYBOARD_RECOVERY 0x0f
#define EC_EVENT_THERMAL_SHUTDOWN 0x10
#define EC_EVENT_BATTERY_SHUTDOWN 0x11
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
/* Power */
#define ELOG_TYPE_POWER_FAIL 0x92
#define ELOG_TYPE_SUS_POWER_FAIL 0x93
#define ELOG_TYPE_PWROK_FAIL 0x94
#define ELOG_TYPE_SYS_PWROK_FAIL 0x95
#define ELOG_TYPE_POWER_ON 0x96
#define ELOG_TYPE_POWER_BUTTON 0x97
#define ELOG_TYPE_POWER_BUTTON_OVERRIDE 0x98
/* Reset */
#define ELOG_TYPE_RESET_BUTTON 0x99
#define ELOG_TYPE_SYSTEM_RESET 0x9a
#define ELOG_TYPE_RTC_RESET 0x9b
#define ELOG_TYPE_TCO_RESET 0x9c
/* Sleep/Wake */
#define ELOG_TYPE_ACPI_ENTER 0x9d
#define ELOG_TYPE_ACPI_WAKE 0x9e
#define ELOG_TYPE_WAKE_SOURCE 0x9f
#define ELOG_WAKE_SOURCE_PCIE 0x00
#define ELOG_WAKE_SOURCE_PME 0x01
#define ELOG_WAKE_SOURCE_PME_INTERNAL 0x02
#define ELOG_WAKE_SOURCE_RTC 0x03
#define ELOG_WAKE_SOURCE_GPIO 0x04
#define ELOG_WAKE_SOURCE_SMBUS 0x05
struct elog_event_data_wake {
u8 source;
u32 instance;
} __attribute__ ((packed));
/* Chrome OS related events */
#define ELOG_TYPE_CROS_DEVELOPER_MODE 0xa0
#define ELOG_TYPE_CROS_RECOVERY_MODE 0xa1
ELOG: Fix reporting of developer/recovery modes 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>
2012-07-16 21:47:45 +02:00
#define ELOG_CROS_RECOVERY_MODE_BUTTON 0x02
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
Log event for abnormal management engine status 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>
2012-07-13 19:11:54 +02:00
/* Management Engine Events */
#define ELOG_TYPE_MANAGEMENT_ENGINE 0xa2
elog: add extended management engine event We are seeing ME disabled and ME error events on some devices and this extended info can help with debug. Also fix a potential issue where if the log does manage to get completely full it will never try to shrink it because the only call to shrink the log happens after a successful event write. Add a check at elog init time to shrink the log size. Change-Id: Ib81dc231f6a004b341900374e6c07962cc292031 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/1739 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-09-01 23:00:23 +02:00
#define ELOG_TYPE_MANAGEMENT_ENGINE_EXT 0xa4
struct elog_event_data_me_extended {
u8 current_working_state;
u8 operation_state;
u8 operation_mode;
u8 error_code;
u8 progress_code;
u8 current_pmevent;
u8 current_state;
} __attribute__ ((packed));
Log event for abnormal management engine status 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>
2012-07-13 19:11:54 +02:00
EC: Prepare to read and log last post code from previous boot (elog portion, support in EC code pending) - Use a new EC command to read the last post code from the previous boot - If the post code is not well-known final boot or resume code then log it Change-Id: Id6249e9a182243eb87c777edd56f48de72125e77 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/1703 Reviewed-by: Marc Jones <marcj303@gmail.com> Tested-by: build bot (Jenkins)
2012-08-13 18:40:02 +02:00
/* Last post code from previous boot */
#define ELOG_TYPE_LAST_POST_CODE 0xa3
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);
extern void elog_add_event_raw(u8 event_type, void *data, u8 data_size);
extern void elog_add_event(u8 event_type);
extern void elog_add_event_byte(u8 event_type, u8 data);
extern void elog_add_event_word(u8 event_type, u16 data);
extern void elog_add_event_dword(u8 event_type, u32 data);
extern void 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);
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: 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
#if CONFIG_ELOG_GSMI
extern u32 gsmi_exec(u8 command, u32 *param);
#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
#if CONFIG_ELOG_BOOT_COUNT
u32 boot_count_read(void);
u32 boot_count_increment(void);
#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
#endif /* !CONFIG_ELOG */
#endif /* ELOG_H_ */