| Age | Commit message (Collapse) | Author |
|---|
|
This makes it so that we always log the generic "system boot" event.
If boot count support has not been implemented, fake it.
BUG=chrome-os-partner:28772
BRANCH=nyan
TEST=booted on Big, ran "mosys eventlog list" and saw
"System boot" event logged with boot count == 0
Original-Change-Id: I729e28feb94546acf6173e7b67990f5b29d02fc7
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/204525
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 2598dc63ddc0d76bcdf9814cadd4c75653fd9832)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ieb4e2e36870e97d9c5f88f0190291863a65a6351
Reviewed-on: http://review.coreboot.org/8142
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Use the RTC driver interface to find the timestamp for events instead of
reading the CMOS based RTC directly on x86 or punting on ARM. This makes
timestamps available on both architectures, assuming an RTC driver is
available.
BUG=None
TEST=Built and booted on nyan_big and link and verified that the timestamps
in the event log were accurate.
BRANCH=nyan
Original-Change-Id: Id45da53bc7ddfac8dd0978e7f2a3b8bc2c7ea753
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197798
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 493b05e06dd461532c9366fb09025efb3568a975)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I4fad296ecfeff8987e4a18054661190239245f32
Reviewed-on: http://review.coreboot.org/7891
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
This cleans up a mis-merge in elog.c and puts the following
change back:
drivers/elog: Unmangle header include out of pre-proc cond
commit a3119e5835e4b8fd510d046c56a3bf2bf43a5c0d
Change-Id: Iafbbd381efdb103717022d2a3c342da376a9428f
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7838
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This reverts commit 474313d1b6556ad8b3e6750a4096b5735cbfc846.
This reverted commit was applied out of sequence and there are a number
of dependencies that need to be in place prior to adding it. Remove it
for now.
Change-Id: If80c40867098dee2feff2b9a1d824558f4d7028d
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Use the RTC driver interface to find the timestamp for events instead of
reading the CMOS based RTC directly on x86 or punting on ARM. This makes
timestamps available on both architectures, assuming an RTC driver is
available.
BUG=None
TEST=Built and booted on nyan_big and link and verified that the timestamps
in the event log were accurate.
BRANCH=nyan
Original-Change-Id: Id45da53bc7ddfac8dd0978e7f2a3b8bc2c7ea753
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197798
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 493b05e06dd461532c9366fb09025efb3568a975)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8481adde86d836b5f0b019c815bada6d232a4186
Reviewed-on: http://review.coreboot.org/7833
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This attempts to isolate/fix some x86-isms:
- Translate flash offset to memory-mapped address only on x86.
- Guard ACPI-dependent line of code
- Use a Kconfig variable for SPI bus when probing the flash rather
than assuming the bus is always on bus 0.
- Zero-out timestamp on non-x86 until we have a better abstraction.
(note: this is based off of some of Gabe's earlier work)
BUG=none
BRANCH=none
TEST=needs testing
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I887576d8bcabe374d8684aa5588f738b36170ef7
Original-Reviewed-on: https://chromium-review.googlesource.com/191203
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 1fc7a75f8c072098e017104788418aeed0705e93)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ida4b211cf21ecdde9745d4dbef6a63ffb9fbba8d
Reviewed-on: http://review.coreboot.org/7832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
This replaces a hard-coded bus number of 0 with a Kconfig variable,
CONFIG_BOOT_MEDIA_SPI_BUS. This removes an assumption made for x86
where this value is always 0 and makes it easy to add support for
other platforms where the bus number for the backing SPI flash is
more arbitrary.
BUG=none
BRANCH=none
TEST=tested on Nyan (bus=4) and Link (bus=0)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I1e878a1628af7f4ccc2f39a70b2190192767e536
Original-Reviewed-on: https://chromium-review.googlesource.com/194854
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 371c6c14d8d4b98004eebce7049a88a219682bc4)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ie105b4654e028098f2137c96e4309b8d85f096df
Reviewed-on: http://review.coreboot.org/7753
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The spi_flash_probe and and spi_setup_slave functions each took a max_hz
parameter and a spi_mode parameter which were never used.
BUG=None
TEST=Built for link, falco, rambi, nyan.
BRANCH=None
Change-Id: I3a2e0a9ab530bcc0f722f81f00e8c7bd1f6d2a22
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192046
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
[km: cherry-pick from chromium]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6174
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: Ic4905d8a6908a30602382f5846f1dc2c0dbe2431
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6068
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: I46906e6d68775edc5cfe199cfeb465db4da2691f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6072
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The elog code calculates flash offsets and their equivalent
addresses in the memory address space. However, it assumes
the detected flash size is entirely mapped into the address
space. This can lead to incorrect calculations. Add code
to allow ROM_SIZE to be less than detected flash size. The
underlying assumption is that the first ROM_SIZE bytes are
programmed into the larger device.
Change-Id: Id848f136515289b40594b7d3762e26e3e55da62f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60501
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4332
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
There was always exactly one elog descriptor declared and initialized, but its
contents were being accessed through a pointer that was passed back and forth
between functions instead of being accessed directly. This made the code more
verbose than it needed to be and harder to follow. To address this the
descriptor type was eliminated, its contents were turned into individual
global variables, and various functions were adjusted to no longer take the
descriptor as an argument.
Similarly, the code was more verbose and complicated than it needed to be
because of several wrapper functions which wrapped a single line of code which
called an underlying function with particular arguments and were only used
once. This makes it harder to tell what the code is doing because the call to
the real function you may already be familiar with is obscured behind a
new function you've never seen before. It also adds one more text to the file
as a whole while providing at best a marginal benefit. Those functions were
removed and their callers now call their contents directly.
Built and booted on Link. Ran mosys eventlog list. Cleared the event log
and ran mosys eventlog list again. Added 2000 events and ran mosys eventlog
list. Cleared the log again and ran mosys eventlog list.
Change-Id: I4f5f6b9f4f508548077b7f5a92f4322db99e01ca
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49310
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4245
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The elog driver's design was a bit more elaborate than it really needed to be
since it no longer had to keep track of multiple copies of the log in flash
and also in memory. This change streamlines it by removing unnecessary
compartmentalization of some bits of code, and some variables which tracked
the last entry added which were never used.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the event log and ran mosys eventlog list again. Cleared the log by echoing 1
into /sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list.
Change-Id: I7d4cdebf2f5b1f6bb1fc70e65eca18f71b124b18
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49309
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4244
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
elog_validate_and_fill was called in exactly one place, in
elog_init_descriptor. It didn't actually do what its name implied since the
data in the event log was already "filled" by elog_init_descriptor. Likewise
elog_init_descriptor was delegating an important part of its own job, scanning
through the list of events, to elog_validate_and_fill.
Since one function was basically just a displaced part of the other which
couldn't really stand on its own, this change merges them together.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events with
the SMI handler and ran mosys eventlog list again.
Change-Id: Ic899eeb18146d0f127d0dded207d37d63cbc716f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49308
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4243
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This function was just a wrapper around elog_init_descriptor, and all it did
was pass the current backing store location and size back in so it would be
reused. Those values, which never change, are now set in
elog_setup_descriptors, eliminating those parameters to init and eliminating
the need for _reinit_.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the log and ran mosys eventlog list again.
Change-Id: I133768aa798dfc10f32e14db95235a88666890c3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49307
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4242
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The event log driver keeps two copies of the event log in memory, one to
take the place of the historically memory mapped image of flash which is now
read and written manually, and one originally intended to be an in memory
cache of flash. Since both are now just copies in memory, there's no value in
having them both and keeping them in sync.
Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the log and ran mosys eventlog list again. Cleared the log by echoing a 1 into
/sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list again.
Change-Id: Ibed62a10c78884849726aa15ec795ab2914afc35
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49306
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4241
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The way elog_shrink currently works is that it completely clears the data in
the flash/flash descriptor and then recreates it using the part of the log
it's going to keep as stored in the memory descriptor. That scheme depends on
there being to independent copies of the log.
This change reworks elog_shrink so that it moves the data it wants to keep
within a single descriptor and then propogates it to the other and to flash
intact. This way, when one of the descriptors goes away, all we have to do is
remove the code that would update it.
Built and booted into ChromeOS on Link. Ran mosys eventlog list. Added
2000 events to the log and ran mosys eventlog list again. Echoed a 1 into
/sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list.
BRANCH=None
Change-Id: I50d77a4f00ea3c6b3e0ec8996dab1a3b31580205
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49305
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4240
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The header is at the start of the log. There's no reason to either keep a
seperate pointer to it, or to keep a copy of it in some other bit of memory.
Built and booted on Link and used 'mosys eventlog list' to list the
contents of the log. Ran
for x in $(seq 1 2000); do
cat elog.event.kernel_clean > /sys/firmware/gsmi/append_to_eventlog;
done
And ran mosys eventlog list again to verify that the log had been shrunk
correctly.
Change-Id: I2afcd52c0ce5bbb662ac56f2895cdbea28d5c2ce
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49304
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4239
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
A parrot device with a bad flash part has been seen to hang
in the elog_shrink code becuase the flash was not successfully
erased and it gets stuck in a loop trying to shrink the log
and then add an event.
Change-Id: I8bb13dbadd293f9d892f322e213c9255c8e9acb3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56405
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4186
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
If elog_clear is called before other elog functions, for instance if it's
called through an SMI immediately after the system boots, then the elog data
structures won't have been set up and the system will go off the deep end.
This change adds a call to elog_init to elog_clear to make sure things things
are always initialized before we start using them.
Before this change, this command would cause
the system to lock up if run immediately after boot:
echo 1 > /sys/firmware/gsmi/clear_eventlog
After this change, that results in the log being cleared correctly.
Change-Id: I45027f0dbfa40ca8c581954a93b14b4fedce91ed
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49303
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4144
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ib0d98e3ab5b2943c36f88765587e8963a4f49604
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3754
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Without that fix we have:
src/drivers/elog/elog.c: In function 'elog_is_header_valid':
src/drivers/elog/elog.c:213:3: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Werror=format]
Change-Id: I71b80a94c03a04eedb688ae107d92c05a878315e
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3551
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
Since there are and will be other files in nb/sb folders, we change
the general spi.h to a file name which is not easy to be duplicated.
Change-Id: I6548a81206caa608369be044747bde31e2b08d1a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/2309
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
If the event log is stored in flash that is not memory
mapped then it must use the SPI controller to read from
the flash device instead of relying on memory accesses.
In addition a new CBMEM ID is added to keep an resident
copy of the ELOG around if needed. The use of CBMEM for
this is guarded by a new CONFIG_ELOG_CBMEM config option.
This CBMEM buffer is created and filled late in the process
when the SMBIOS table is being created because CBMEM is
not functional when ELOG is first initialized.
The downside to using CBMEM is that events added via the
SMI handler at runtime are not reflected in the CBMEM copy
because I don't want to let the SMM handler write to memory
outside the TSEG region.
In reality the only time we add runtime events is at kernel
shutdown so the impact is limited.
Test:
1) Test with CONFIG_ELOG_CBMEM enabled to ensure the event
log is operational and SMBIOS points to address in CBMEM.
The test should involve at least on reboot to ensure that the
kernel is able to write events as well.
> mosys -l smbios info log | grep ^address
address | 0xacedd000
> mosys eventlog list
0 | 2012-10-10 14:02:46 | Log area cleared | 4096
1 | 2012-10-10 14:02:46 | System boot | 478
2 | 2012-10-10 14:02:46 | System Reset
3 | 2012-10-10 14:03:33 | Kernel Event | Clean Shutdown
4 | 2012-10-10 14:03:34 | System boot | 479
5 | 2012-10-10 14:03:34 | System Reset
2) Test with CONFIG_ELOG_CBMEM disabled to ensure the event
log is operational and SMBIOS points to memory mapped flash.
The test should involve at least on reboot to ensure that the
kernel is able to write events as well.
> mosys -l smbios info log | grep ^address
address | 0xffbf0000
> mosys eventlog list
0 | 2012-10-10 14:33:17 | Log area cleared | 4096
1 | 2012-10-10 14:33:18 | System boot | 480
2 | 2012-10-10 14:33:18 | System Reset
3 | 2012-10-10 14:33:35 | Kernel Event | Clean Shutdown
4 | 2012-10-10 14:33:36 | System boot | 481
5 | 2012-10-10 14:33:36 | System Reset
Change-Id: I87755d5291ce209c1e647792227c433dc966615d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1776
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Read out the post code from the previous boot and
log it if the code is not one of the expected values.
Test:
1) interrupt the boot of the system, this is easiest
with warm reset button when servo is attached
2) check the event log with mosys
65 | 2012-09-09 12:32:11 | Last post code in previous boot | 0x9d
Change-Id: Id418f4c0cf005a3e97b8c63de67cb9a09bc57384
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
Now that we have FMAP support in coreboot use it to find the
offset in flash for ELOG to use.
If coreboot has elog configured with a smaller size then use
that over the FMAP size. This is because I set aside a 16KB
region in the FMAP but we only use 4KB of it to keep the impact
to boot/resume speed to a minimum.
FMAP: Found "FMAP" version 1.0 at ffe10000.
FMAP: base = 0 size = 800000 #areas = 32
FMAP: area RW_ELOG found
FMAP: offset: 3f0000
FMAP: size: 16384 bytes
FMAP: No valid base address, using 0xff800000
ELOG: base=0x003f0000 base_ptr=0xffbf0000
ELOG: MEM @0x00190ad8 FLASH @0xffbf0000
ELOG: areas are 4096 bytes, full threshold 3072, shrink size 1024
Change-Id: I3d826812c0f259d61f41b42797c58dd179f9f1c8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1706
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
