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

290 lines
10 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_
#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
elog: Update for EC Device Events Replace the unused "thermal overload" event with the new "device event" and define the first few device events that are supported by the Chromium EC. BUG=b:30624430 TEST=build for google/* mainboards Change-Id: I1f3aeedb87c2aad29a0a67b5c50c29a6961fb45f Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/20427 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2017-06-30 08:53:48 +02:00
#define EC_EVENT_DEVICE_EVENT 0x0a
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_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
elog: Add all EC event codes Add the missing EC event codes in elog.h and correct the event code value for RECOVERY_HWREINIT. Change-Id: If9fb319cce1e4acce4b3d7c3a39365986856a9b4 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/18693 Tested-by: build bot (Jenkins) Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-03-09 01:04:16 +01:00
#define EC_EVENT_KEYBOARD_FASTBOOT 0x19
#define EC_EVENT_RTC 0x1a
#define EC_EVENT_MKBP 0x1b
#define EC_EVENT_USB_MUX 0x1c
#define EC_EVENT_MODE_CHANGE 0x1d
#define EC_EVENT_KEYBOARD_RECOVERY_HWREINIT 0x1e
#define EC_EVENT_EXTENDED 0x1f
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
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
/*
* Deep Sx wake variant is provided below - 0xad
* Sleep/"wake pending" event log provided below - 0xb1 - 0x01/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
#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 more wake sources Add wake sources for PME events generated by different devices. BUG=b:37088992 Change-Id: I25098f489f401148171c235cb341f6e7bb2b635b Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/19923 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-05-25 09:13:01 +02:00
#define ELOG_WAKE_SOURCE_PME_HDA 0x07
#define ELOG_WAKE_SOURCE_PME_GBE 0x08
#define ELOG_WAKE_SOURCE_PME_EMMC 0x09
#define ELOG_WAKE_SOURCE_PME_SDCARD 0x0a
#define ELOG_WAKE_SOURCE_PME_PCIE1 0x0b
#define ELOG_WAKE_SOURCE_PME_PCIE2 0x0c
#define ELOG_WAKE_SOURCE_PME_PCIE3 0x0d
#define ELOG_WAKE_SOURCE_PME_PCIE4 0x0e
#define ELOG_WAKE_SOURCE_PME_PCIE5 0x0f
#define ELOG_WAKE_SOURCE_PME_PCIE6 0x10
#define ELOG_WAKE_SOURCE_PME_PCIE7 0x11
#define ELOG_WAKE_SOURCE_PME_PCIE8 0x12
#define ELOG_WAKE_SOURCE_PME_PCIE9 0x13
#define ELOG_WAKE_SOURCE_PME_PCIE10 0x14
#define ELOG_WAKE_SOURCE_PME_PCIE11 0x15
#define ELOG_WAKE_SOURCE_PME_PCIE12 0x16
#define ELOG_WAKE_SOURCE_PME_SATA 0x17
#define ELOG_WAKE_SOURCE_PME_CSE 0x18
#define ELOG_WAKE_SOURCE_PME_CSE2 0x19
#define ELOG_WAKE_SOURCE_PME_CSE3 0x1a
#define ELOG_WAKE_SOURCE_PME_XHCI 0x1b
#define ELOG_WAKE_SOURCE_PME_XDCI 0x1c
elog: Add more detailed wake source events for USB2.0/3.0 port wake BUG=b:37088992 Change-Id: If0b495234d6e498d5c64ba4dd186440cd7a1c5c6 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/20121 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-06-09 00:46:42 +02:00
#define ELOG_WAKE_SOURCE_PME_XHCI_USB_2 0x1d
#define ELOG_WAKE_SOURCE_PME_XHCI_USB_3 0x1e
driver/intel/wifi: Update wifi wake source in elog In S3 resume, wifi is one of the wake sources. If elog is enabled in config, then log wifi wakes in elog. BUG=b:36992859 TEST= Build for Soraka. Do WoWlan during S3. Verify elog having update on wake due to Wifi. Change-Id: I7d42c5c81e0a3f7a3f94c3f6b7d2ebdf029d1aff Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com> Reviewed-on: https://review.coreboot.org/20455 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-07-03 18:27:11 +02:00
#define ELOG_WAKE_SOURCE_PME_WIFI 0x1f
cr50: check if the new image needs to be enabled and act on it The AP sends the Cr50 a request to enable the new firmware image. If the new Cr50 image was found and enabled, the AP expects the Cr50 to reset the device in 1 second. While waiting for the Cr50 to reset, the AP logs a newly defined event and optionally shuts down the system. By default the x86 systems power off as shutting those systems down is not board specific. BRANCH=gru,reef BUG=b:35580805 TEST=built a reef image, observed that in case cr50 image is updated, after the next reboot the AP stops booting before loading depthcharge, reports upcoming reset and waits for it. Once the system is booted after that, the new event can be found in the log: localhost ~ # mosys eventlog list ... 7 | 2017-03-23 18:42:12 | Chrome OS Developer Mode 8 | 2017-03-23 18:42:13 | Unknown | 0xac 9 | 2017-03-23 18:42:21 | System boot | 46 ... Change-Id: I45fd6058c03f32ff8edccd56ca2aa5359d9b21b1 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/18946 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2017-03-23 00:16:34 +01:00
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;
Rename __attribute__((packed)) --> __packed Also unify __attribute__ ((..)) to __attribute__((..)) and handle ((__packed__)) like ((packed)) Change-Id: Ie60a51c3fa92b5009724a5b7c2932e361bf3490c Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/15921 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-07-13 02:20:27 +02:00
} __packed;
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
/* 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;
Rename __attribute__((packed)) --> __packed Also unify __attribute__ ((..)) to __attribute__((..)) and handle ((__packed__)) like ((packed)) Change-Id: Ie60a51c3fa92b5009724a5b7c2932e361bf3490c Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/15921 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-07-13 02:20:27 +02:00
} __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 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;
Rename __attribute__((packed)) --> __packed Also unify __attribute__ ((..)) to __attribute__((..)) and handle ((__packed__)) like ((packed)) Change-Id: Ie60a51c3fa92b5009724a5b7c2932e361bf3490c Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/15921 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-07-13 02:20:27 +02:00
} __packed;
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
elog: Fix duplicate event type The current elog implementation has two event types defined for 0xa7, apparently the result of divergent coreboot trees on chromium where some events were added to ARM systems but not upstreamed until later. Fix this by moving ELOG_TYPE_THERM_TRIP to be 0xab, since the current elog parsing code in chromium is using ELOG_TYPE_SLEEP for 0xa7. BUG=b:35977516 TEST=check for proper "CPU Thermal Trip" event when investigating a device that is unexpectedly powering down. Change-Id: Idfa9b2322527803097f4f19f7930ccbdf2eccf35 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/18579 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-03-05 23:35:57 +01:00
/* CPU Thermal Trip */
#define ELOG_TYPE_THERM_TRIP 0xab
cr50: check if the new image needs to be enabled and act on it The AP sends the Cr50 a request to enable the new firmware image. If the new Cr50 image was found and enabled, the AP expects the Cr50 to reset the device in 1 second. While waiting for the Cr50 to reset, the AP logs a newly defined event and optionally shuts down the system. By default the x86 systems power off as shutting those systems down is not board specific. BRANCH=gru,reef BUG=b:35580805 TEST=built a reef image, observed that in case cr50 image is updated, after the next reboot the AP stops booting before loading depthcharge, reports upcoming reset and waits for it. Once the system is booted after that, the new event can be found in the log: localhost ~ # mosys eventlog list ... 7 | 2017-03-23 18:42:12 | Chrome OS Developer Mode 8 | 2017-03-23 18:42:13 | Unknown | 0xac 9 | 2017-03-23 18:42:21 | System boot | 46 ... Change-Id: I45fd6058c03f32ff8edccd56ca2aa5359d9b21b1 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/18946 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2017-03-23 00:16:34 +01:00
/* Cr50 */
#define ELOG_TYPE_CR50_UPDATE 0xac
elog: Add a new elog type for deep Sx variant This is useful for debugging based on eventlog to identify if platform entered normal or deep Sx. BUG=b:38436041 Change-Id: Ic7d8e5b8aafc07aed385fe3c4831ab7d29e1f890 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/19797 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-05-19 19:50:02 +02:00
/* Deep Sx wake variant */
#define ELOG_TYPE_ACPI_DEEP_WAKE 0xad
elog: Update for EC Device Events Replace the unused "thermal overload" event with the new "device event" and define the first few device events that are supported by the Chromium EC. BUG=b:30624430 TEST=build for google/* mainboards Change-Id: I1f3aeedb87c2aad29a0a67b5c50c29a6961fb45f Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/20427 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2017-06-30 08:53:48 +02:00
/* EC Device Event */
#define ELOG_TYPE_EC_DEVICE_EVENT 0xae
#define ELOG_EC_DEVICE_EVENT_TRACKPAD 0x01
#define ELOG_EC_DEVICE_EVENT_DSP 0x02
#define ELOG_EC_DEVICE_EVENT_WIFI 0x03
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
/* S0ix sleep/wake */
#define ELOG_TYPE_S0IX_ENTER 0xaf
#define ELOG_TYPE_S0IX_EXIT 0xb0
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
/* Extended events */
#define ELOG_TYPE_EXTENDED_EVENT 0xb1
#define ELOG_SLEEP_PENDING_PM1_WAKE 0x01
#define ELOG_SLEEP_PENDING_GPE0_WAKE 0x02
coreboot: check Cr50 PM mode on normal boot Under some scenarios the key ladder on the Cr50 can get disabled. If this state is detected, trigger a reboot of the Cr50 to restore full TPM functionality. BUG=b:121463033 BRANCH=none TEST=Built coreboot on sarien and grunt platforms. TEST=Ran 'gsctool -a -m disable' and reboot. Verified coreboot sends VENDOR_CC_IMMEDIATE_RESET command to Cr50 and that the Cr50 resets and then the platform boots normally. TEST=Performed Cr50 rollback to 0.0.22 which does not support the VENDOR_CC_TPM_MODE command, confirmed that platform boots normally and the coreboot log captures the unsupported command. Tested-by: Keith Short <keithshort@chromium.org> Change-Id: I70e012efaf1079d43890e909bc6b5015bef6835a Signed-off-by: Keith Short <keithshort@chromium.org> Reviewed-on: https://review.coreboot.org/c/31260 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-02-06 00:15:10 +01:00
/* Cr50 reset to enable TPM */
#define ELOG_TYPE_CR50_NEED_RESET 0xb2
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
struct elog_event_extended_event {
u8 event_type;
u32 event_complement;
} __packed;
src/include: add IS_ENABLED() around Kconfig symbol references Change-Id: I2fbe6376a1cf98d328464556917638a5679641d2 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/20354 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2017-06-24 22:13:53 +02:00
#if IS_ENABLED(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: 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: 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
#if IS_ENABLED(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);
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_ */