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

206 lines
7.5 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.
*/
#ifndef ELOG_H_
#define ELOG_H_
/* 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: Update event log IDs for EC events BUG=chrome-os-partner:59352 BRANCH=None TEST=Compiles successfully Change-Id: Idf2d377bf4709ea25616adfbde55f39798c0cd39 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/17393 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-11-11 22:55:56 +01: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
#define EC_EVENT_FAN_ERROR 0x12
#define EC_EVENT_THROTTLE_STOP 0x13
#define EC_EVENT_HANG_DETECT 0x14
#define EC_EVENT_HANG_REBOOT 0x15
#define EC_EVENT_PD_MCU 0x16
#define EC_EVENT_BATTERY_STATUS 0x17
#define EC_EVENT_PANIC 0x18
#define EC_EVENT_KEYBOARD_RECOVERY_HWREINIT 0x19
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
lynxpoint: Fix ELOG logging of power management events This is updated to handle LynxPoint-H and LynxPoint-LP and a new wake event is added for the power button. Boot, suspend/resume, reboot, etc on WTM2 and then check the event log to see if expected events have been added. Change-Id: I15cbc3901d81f4fd77cc04de37ff5fa048f9d3e8 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2817 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-09 02:16:37 +01:00
#define ELOG_WAKE_SOURCE_PWRBTN 0x06
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
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
Extend CMOS POST code logging to store extra data This can be used to indicate sub-state within a POST code range which can assist in debugging BIOS hangs. For example this can be used to indicate which device is about to be initialized so if the system hangs while talking to that device it can be identified. Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58104 Reviewed-on: http://review.coreboot.org/4229 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-06-10 19:21:41 +02:00
#define ELOG_TYPE_POST_EXTRA 0xa6
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
butterfly: Log EC shutdown reason in ELOG The EC saves its last "shutdown reason" for the system in EC RAM that we can read back and log on boot. The decode for the "reason" field will be added to mosys. Change-Id: I834d39122e45262ef8e7ba59201accbee5857aac Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/48323 Reviewed-by: David James <davidjames@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/4127 Tested-by: build bot (Jenkins)
2012-11-26 23:53:42 +01:00
/* EC Shutdown Reason */
#define ELOG_TYPE_EC_SHUTDOWN 0xa5
elog: Add event type for CPU thermal trip There is a status bit for this event in most intel chipsets that we can read and report. Start by adding the new event type. Change-Id: Ib06411e3b87a1d069fb469943dd445bee6c1291f Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/199370 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 386a06170ec5afb31d0fe93ace3afbaab897a598) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/7004 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-05-12 19:20:45 +02:00
/* CPU Thermal Trip */
#define ELOG_TYPE_THERM_TRIP 0xa7
elog: add sources to reflect full event type namespace usage Some events were added in other places, but coreboot's elog namespace wasn't updated. As such there's a collision with the thermtrip event. This change at least updates the elog information to reflect potential event type uage. BUG=chrome-os-partner:59395 Change-Id: Ib82e2b65ef7d34e260b7d7450174aee7537b69f6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17230 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-04 16:53:43 +01:00
/* ARM/generic versions of sleep/wake - These came from another firmware
* apparently, but not all the firmware sources were updated so that the
* elog namespace was coherent. */
#define ELOG_TYPE_SLEEP 0xa7
#define ELOG_TYPE_WAKE 0xa8
#define ELOG_TYPE_FW_WAKE 0xa9
soc/intel/common: log event when MRC cache is updated Log when the MRC cache is attempted to be updated with status of success or failure. Just one slot is supported currently which is deemed 'normal'. This is because there are more slots anticipated in the future. BUG=chrome-os-partner:59395 Change-Id: I0f81458325697aff9924cc359a4173e0d35da5da Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17231 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2016-11-04 16:07:14 +01:00
/* Memory Cache Update */
#define ELOG_TYPE_MEM_CACHE_UPDATE 0xaa
#define ELOG_MEM_CACHE_UPDATE_SLOT_NORMAL 0
mrc: Add support for separate training cache in recovery mode 1. Re-factor MRC cache driver to properly select RW_MRC_CACHE or RECOVERY_MRC_CACHE based on the boot mode. - If normal mode boot, use RW_MRC_CACHE, if available. - If recovery mode boot: - Retrain memory if RECOVERY_MRC_CACHE not present, or recovery is requested explicity with retrain memory request. - Use RECOVERY_MRC_CACHE otherwise. 2. Protect RW and RECOVERY mrc caches in recovery and non-recovery boot modes. Check if both are present under one unified region and protect that region as a whole. Else try protecting individual regions. 3. Update training data in appropriate cache: - Use RW_MRC_CACHE if normal mode. - Use RECOVERY_MRC_CACHE if present in recovery mode. Else use RW_MRC_CACHE. 4. Add proper debug logs to indicate which training data cache is used at any point. BUG=chrome-os-partner:59352 BRANCH=None TEST=Verified that correct cache is used in both normal and recovery mode on reef. Change-Id: Ie79737a1450bd1ff71543e44a5a3e16950e70fb3 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/17242 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-11-06 07:57:02 +01:00
#define ELOG_MEM_CACHE_UPDATE_SLOT_RECOVERY 1
soc/intel/common: Add save/restore for variable MRC data Piggy-back on existing MRC cache infrastructure to store variable MRC data. Only one set of data can be valid at given point of time. Currently this magically happens because region alignment is forced to 0x1000 and region itself is of the same size. This needs to be somehow programmatically enforced. Change-Id: I8a660d356ca760b8ff9907396fb9b34cb16cf1db Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/17320 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-11-08 17:30:06 +01:00
#define ELOG_MEM_CACHE_UPDATE_SLOT_VARIABLE 2
soc/intel/common: log event when MRC cache is updated Log when the MRC cache is attempted to be updated with status of success or failure. Just one slot is supported currently which is deemed 'normal'. This is because there are more slots anticipated in the future. BUG=chrome-os-partner:59395 Change-Id: I0f81458325697aff9924cc359a4173e0d35da5da Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17231 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2016-11-04 16:07:14 +01:00
#define ELOG_MEM_CACHE_UPDATE_STATUS_SUCCESS 0
#define ELOG_MEM_CACHE_UPDATE_STATUS_FAIL 1
struct elog_event_mem_cache_update {
u8 slot;
u8 status;
} __attribute__ ((packed));
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
#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);
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;
}
#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: 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);
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);
u32 boot_count_increment(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_ */