| Age | Commit message (Collapse) | Author |
|---|
|
On x86 platforms, google_chromeec_early_init() is used to put the EC
into RO mode when there's a recovery request. This is to avoid training
memory multiple times when the recovery request is through an EC host
event while the EC is running RW code. Under that condition the EC will
be reset (along with the rest of the system) when the kernel verification
happens. This leads to an execessively long recovery path because of the
double reboot performing full memory training each time.
By putting this logic into the verstage program this reduces the
bootblock size on the skylake boards. Additionally, this provides the
the correct logic for all future boards since it's not tied to FSP
nor the mainboard itself. Lastly, this double memory training protection
works only for platforms which verify starting from bootblock. The
platforms which don't start verifying until after romstage need to
have their own calls (such as haswell and baytrail).
Change-Id: Ia8385dfc136b09fb20bd3519f3cc621e540b11a5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16318
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The SPI drivers for the various chipsets are not consistent in
their handling of when they are accessible. Coupled with the
unknown ordering of boot_device_init() being called this can
lead to unexpected behavior (probing failures or hangs). Instead
move the act of initializing the SPI flash boot device to when
the various infrastructure requires its usage when it calls
boot_device_rw(). Those platforms utilizing the RW boot device
would need to ensure their SPI drivers are functional and
ready when the call happens.
This further removes any other systems failing to boot as
reported in https://ticket.coreboot.org/issues/67.
BUG=chrome-os-partner:56151
Change-Id: Ib3bddf5e26bf5322f3dd20345eeef6bee40f0f66
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16300
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
It's necessary to call spi_init() prior to calling spi_flash_probe()
such that the SPI drivers can do any work required prior to performing
SPI transactions. It could be argued that the drivers should handle
such situations, however the SPI API implementations seem to assume the
callers ensured spi_init() was called before any SPI transactions.
This fixes systems that failed to boot introduced by [1]. Issue tracked
in https://ticket.coreboot.org/issues/67.
[1] I2aa75f88409309e3f9b9bd79b52d27c0061139c8
https://review.coreboot.org/16200
BUG=chrome-os-partner:56151
Change-Id: I2d8d5ac685833521f1efe212b07a4b61ba0d9bc3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16297
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
Add SMBIOS memory GUID and functions to retrieve HOB.
BUG=chrome-os-partner:55505
TEST='dmidecode -t 17' and 'mosys -k memory spd print all'
Change-Id: Ie7e2239bb691c748d9fd852c3dc8cdc05243b164
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-on: https://review.coreboot.org/16245
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Instead of assuming SPI backing use a region_device to
abstract away the underlying storage mechanism.
BUG=chrome-os-partner:55932
Change-Id: I6b0f5a7e9bea8833fb1bca87e02abefab63acec3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16204
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
On many x86 platforms the boot device is SPI which is memory
mapped. However, in order to write to the boot device one needs
to use the SPI api. Therefore, provide a common implementation
of boot_device_rw() which has no mmap() functionality. It only
reads, writes, and erases. This will be used in the existing
infrastructure but in a SPI agnostic way.
Two options are added:
1. BOOT_DEVICE_SPI_FLASH_RW_NOMMAP
2. BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY
The former is auto-selected when COMMON_CBFS_SPI_WRAPPER is not
selected. The latter can be used to include the implementation
in the early stages such as bootblock, verstage, and romstage.
BUG=chrome-os-partner:56151
Change-Id: I2aa75f88409309e3f9b9bd79b52d27c0061139c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16200
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
It shouldn't matter if COMMON_CBFS_SPI_WRAPPER is selected to
include the SPI flash support in all stages. Therefore, include
the SPI flash support files in all the stages. While there include
the same set of files for all stages. They were out of sync for
some reason.
BUG=chrome-os-partner:56151
Change-Id: I933335104203315cbbcf965185a7c176974e6356
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16198
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The spi_flash_probe() routine was setting a global varible
unconditonally regardless if the probe was for the boot device
or even if the boot devcie was flash. Moreover, there's no need
to report the SPI information if the boot device isn't even SPI.
Lastly, it's possible that the boot device is a SPI flash, but
the platform may never probe (selecting SPI_FLASH) for the
actual device connected. In that situation don't fill anything
in as no correct information is known.
BUG=chrome-os-partner:56151
Change-Id: Ib0eba601df4d77bede313c358c92b0536355bbd0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16197
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Provide the RW boot device operations for the common cbfs
SPI wrapper. The RW region_device is the same as the read-only
one. As noted in the boot_device_rw() introduction patch the
mmap() support should not be used in conjuction with writing
as that results in incoherent operations. That's fine as the
current mmap() support is only used in the cbfs layer which
does not support writing, i.e. no cbfs regions would be
written to with any previous or outstanding mmap() calls.
BUG=chrome-os-partner:56151
Change-Id: I7cc7309a68ad23b30208ac961b1999a79626b307
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16199
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Indicate to the build system that a platform provides support
for a writable boot device. The following will provide the
necessary support:
COMMON_CBFS_SPI_WRAPPER users
soc/intel/apollolake
soc/intel/baytrail
soc/intel/braswell
soc/intel/broadwell
soc/intel/skylake
The SPI_FLASH option is auto-selected if the platform provides
write supoprt for the boot device and SPI flash is the boot
device.
Other platforms may provide similar support, but they do that
in a device specific manner such as selecting SPI_FLASH
explicitly. This provides clearance against build failures
where chipsets don't provide SPI API implementations even
though the platform may use a SPI flash to boot.
BUG=chrome-os-partner:56151
Change-Id: If78160f231c8312a313f9b9753607d044345d274
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16211
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The common boot device spi implementation is very much
specific to SPI flash. As such it should be moved into
that subdirectory. It's still a high-level option but
it correctly depends on BOOT_DEVICE_SPI_FLASH. Additionally
that allows the auto-selection of SPI_FLASH by a platform
selecting COMMON_CBFS_SPI_WRAPPER which allows for culling
of SPI_FLASH selections everywhere.
BUG=chrome-os-partner:56151
Change-Id: Ia2ccfdc9e1a4348cd91b381f9712d8853b7d2a79
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16212
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
BUG=chrome-os-partner:56151
Change-Id: I06f138078c47a1e4b4b3edbdbf662f171e11c9d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16228
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fixed "intierface" typo.
Change-Id: I65f0156ee059a8bed96c900ca3da3a06f45901e8
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-on: https://review.coreboot.org/16252
Tested-by: build bot (Jenkins)
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
|
|
Provide a default value of 0 in drivers/spi as there weren't
default values aside from specific mainboards and arch/x86.
Remove any default 0 values while noting to keep the option's
default to 0.
BUG=chrome-os-partner:56151
Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16192
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Almost all boards and chipsets within the codebase assume or
use SPI flash as the boot device. Therefore, provide an option
for the boards/chipsets which don't currently support SPI flash
as the boot device. The default is to assume SPI flash is the
boot device unless otherwise instructed. This falls in line
with the current assumptions, but it also allows one to
differentiate a platform desiring SPI flash support while it not
being the actual boot device.
One thing to note is that while google/daisy does boot with SPI
flash part no SPI API interfaces were ever implemented. Therefore,
mark that board as not having a SPI boot device.
BUG=chrome-os-partner:56151
Change-Id: Id4e0b4ec5e440e41421fbb6d0ca2be4185b62a6e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16191
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This reverts commit a83bbf58541cf41ea7a97dedbc8c02dffa59e86d.
This was submitted out of order.
Change-Id: Ic5a28faf94c1f1901a72e46343722eb4224c5086
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16226
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
All flash drivers are automatically included in the build unless
COMMON_CBFS_SPI_WRAPPER was selected. However, there are cases
where these drivers are unnecessary such as certain intel platforms
where spi controller uses hardware sequencing without any ability
to manually probe the device. Therefore, provide an option that the
SoC can set the default value for. The COMMON_CBFS_SPI_WRAPPER
option is still honored by not including all drivers when that
is selected.
BUG=chrome-os-partner:56151
Change-Id: Ie9aa447da450f7c8717545f05cff800139a9e2dd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16187
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
BUG=chrome-os-partner:56151
Change-Id: Ibdd7c8754f9bf560a878136b1f55238e2c2549d3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16193
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Provide more informative messages when CONFIG_ELOG_DEBUG is enabled
as well as more informative error messages in the case of
elog_scan_flash() failing. In the sync path the in-memory buffer is
dumped in before the contents are read back from the non-volatile
backing store and dumped again if the subsequent parsing fails.
BUG=chrome-os-partner:55932
Change-Id: I716adfb246ef6fbefc0de89cd94b3c1310468896
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16184
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Don't verify HOB list pointer or HOBs when FSP returns a reset request.
BRANCH=none
BUG=chrome-os-partner:56159
TEST=Build and run on Galileo Gen2.
Change-Id: I6382f5ff92092623955806ebff340608c4ee156a
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16162
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It cooperates better with the file sorting heuristic.
Change-Id: I1c071243720352970dd2c4c2afed12451f91dcaa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16141
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add fsp_write_line function which may be called by FSP to output debug
serial data to the console.
TEST=Build and run on Galileo Gen2
Change-Id: If7bfcea1af82209dcdc5a9f9f2d9334842c1595e
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add fsp_write_line function which may be called by FSP to output debug
serial data to the console.
TEST=Build and run on Galileo Gen2
Change-Id: Ib01aef448798e47ac613b38eb20bf25537b9221f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16128
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Commit 0d9cd92e (chromeos: Clean up elog handling) removed the
individual elog_init() calls from mainboards that did them and automated
adding certain events through the boot state machine. Unfortunately,
the new code would sometimes not log any specific event at all, and
thereby also never call elog_init() (through elog_add_event()) which
adds the "System boot" event.
We can assume that any board that configures the eventlog at all
actually wants to use it, so let's just add another call to elog_init()
to the boot state machine so we can ensure it gets called at least once.
BRANCH=None
BUG=chrome-os-partner:56001
TEST=Booted Kevin, confirmed that eventlog code runs again.
Change-Id: Ibe7bfc94b3e3d11ba881399a39f9915991c89d8c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16118
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
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>
|
|
Don't conditionally compile parts of the code. The unused pieces
get culled by the linker, and the #if's just clutter things up.
BUG=chrome-os-partner:55932
Change-Id: Ic18b2deb0cfef7167c05f0a641eae2f4cdc848ee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16102
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
There were checks against global variables trying to determine
failing cases of elog_find_flash(). Instead move the checks
into elog_find_flash() and return value indicating failure.
A minimum 4KiB check was added to ensure the eventlog is at
least that size which makes the heuristic checks cleaner.
BUG=chrome-os-partner:55932
Change-Id: I4d9d13148555e05d4f217a10f995831a0e437fc3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16101
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
There were 3 variables indicating the state of the event log
region. However, there's no need to keep track of those
individually. The only thing required is to know is if
elog_scan_flash() failed. There's no other tracking required
beyond that.
BUG=chrome-os-partner:55932
Change-Id: I88ad32091d3c37966a2ac6272f8ad95bcc8c4270
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16100
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
There were multiple paths where writes and erases of the flash
were being done. Instead provide a single place for synchronizing
the non-volatile storage from the mirrored event log. This
synchronization point resides as the very last thing done when
adding an event to the log. The shrinking check happens before
committing the event to non-volatile storage so there's no need
to attempt a shrink in elog_init() because any previous events
committed already honored the full threshold.
BUG=chrome-os-partner:55932
Change-Id: Iaec9480eb3116fdc2f823c25d028a4cfb65a6eaf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16099
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Instead of treating offsets relative to after the header make
the offsets relative to the in-memory mirror buffer. This
simplifies the logic in that all offsets are treated the same.
It also allows one to remove a global variable.
BUG=chrome-os-partner:55932
Change-Id: I42491e05755d414562b02b6f9ae47f5c357d2f8a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16098
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
A region_device can be used to represent the in-memory mirror
of the event log. The region_device infrastructure has builtin
bounds checking so there's no need to duplicate that. In addition,
it allows for removing much of the math juggling for the buffer
size, etc.
BUG=chrome-os-partner:55932
Change-Id: Ic7fe9466019640b449257c5905ed919ac522bb58
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16097
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
There's only 2 users of checking if the event buffer is cleared
to the EOL value. Each were passing pointers of the in-memory
mirror while also doing calculations for the size to check. Since
the in-memory mirror is one big buffer the only thing required
to know is the offset to start checking from. The check is always
done through the end of the buffer.
BUG=chrome-os-partner:55932
Change-Id: Icd4a7edc74407d6578fc93e9eb533abd3aa17277
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16096
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Instead of taking pointers and back-calculating the
proper offset perform writes in terms of the offsets
within the elog region in flash.
BUG=chrome-os-partner:55932
Change-Id: I5fd65423f5a6e03825c788bc36417f509b58f64d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16095
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
|
|
The elog_flash_erase() was only called to erase the entire
elog region in flash. Therefore, drop the parameters and
perform the full erase.
BUG=chrome-os-partner:55932
Change-Id: I6590347ae60d407bc0df141e9196eb70532f8585
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16094
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
There was a check against the next event offset against
the shrink size in elog_shrink(). However, all calls
to elog_shrink() were conditionalized on the next
event offset exceeding the full threshold. The shrink
size is set to the minimum of the full threshold and
a percentage of the elog region size. Therefore, it's
impossible for the next event offset to be less than
the shrink size because full threshold is always greater
than or equal to the shrink size.
BUG=chrome-os-partner:55932
Change-Id: Ie6ff106f1c53c15aa36a82223a235a7ac97fd8c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16093
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
For the elog shrink case we log the number of bytes shrunk
from the event log. However, when clearing the log the
size recorded was the entire region size including the header
as well as the event region space. To be more consistent
mark the clearing event with the number of bytes actually
cleared out (excluding the header size).
BUG=chrome-os-partner:55932
Change-Id: I7c33da97bd29a90bfe975b1c6f148f181016f13f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16092
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
get_rom_size() is no longer used. Remove it.
BUG=chrome-os-partner:55932
Change-Id: Id9fa8f67b67ee355243a5c763cfafa0ce76e9b2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16088
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The -b FSP_LOC argument to cbfstool is only valid for the COREBOOT
CBFS. Don't pass that value for all other CBFS regions.
Change-Id: Ib5321e7a7dbee8d26eb558933c8ce3fea50b11fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14641
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
If EC_GOOGLE_CHROMEEC is enabled, ensure that the EC is in correct mode
before running memory init. This saves additional memory training
required in recovery path because of reboot later in ramstage.
BUG=chrome-os-partner:54245
Change-Id: Ic71c054afdcd0001cea95563fe513783b56f3e60
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/16034
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Although we have already support for the flash chip N25Q128 there is a
similar type available which has the same geometry and opcodes but
unfortunately a slightly different device type ID. While the already
supported N25Q128 has the ID 0xbb18 this one has the ID 0xba18.
To make both types available in the flash support table, use N25Q128A as
the flash name. This name can be found in the datasheet which can be
found here:
https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_128mb_3v_65nm.pdf
TEST=Booted and verified that MRC cache could be written
Change-Id: I02a47692efb23a9a06a289c367488abd256b8e0c
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/16061
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add the Kconfig value to point to the checklist data files.
TEST=Build and run on Galileo Gen2
Change-Id: I3737b46162214fad139382193de944ec5d175645
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16039
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The TPM version string has become much longer recently, and the
TPM_FW_VER register available on VID 1ae0 devices supports reading in
arbitrary size quantities.
Let's read 50 bytes at a time to reduce the SPI register read wrapper
overhead, and increase the length limit to 300 bytes to accommodate
longer version strings.
TEST=verified on the Kevin device:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: RO_A: 0.0.1/84e2dde7 RO_B:* 0.0.2/13eda43f RW_A:* cr50_v1.1.5005-444ddb7 RW_B: cr50_v1.1.5005-5aac83c
cr50_v1.1.5005-444ddb7 private-cr51:v0.0.66-bd9a0fe tpm2:v0.0.259-8f3d735 cryptoc:v0.0.4-5319e83 2016-07-31 10:58:05 vbendeb@kvasha
Change-Id: Ifaf28c1a9a3990372a9cec108c098edbe50d3243
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/16000
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Choose appropriate debug levels for the various messages in the FSP
driver. Change:
* BIOS_DEBUG --> BIOS_SPEW: Normal FSP driver output level, allows
builder to disable FSP driver output by selecting
CONFIG_DEFAULT_CONSOLE_LOGLEVEL_7
* BIOS_ERROR --> BIOS_CRIT: These errors will prevent coreboot and the
payload from successfully booting
TEST=Build and run on Galileo Gen2
Change-Id: Ic3352de2022e16482bf47fc953aedeef8f0c2880
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16003
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Remove unused function declaration.
TEST=Build and run on Galileo Gen2
Change-Id: Id971829c19c2535c975a68c44fb3697f60d0b4ad
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16022
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add a Kconfig value to enable display of FSP header. Move the display
code into a separate module to remove it entirely from the final image.
TEST=Build and run on Galileo Gen2
Change-Id: I7047a9e58e6a6481c8453dbfebfbfe69dc8823d8
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16002
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Other SOC platforms need to handle the FspNotify calls in the same way
as Apollo Lake. Migrate the FspNotify calls into the FSP 2.0 driver.
Provide a platform callback to handle anything else that needs to be
done after the FspNotify call.
Display the MTRRs before the first call to fsp_notify.
TEST=Build and run on Galileo Gen2
Change-Id: I1ff327d77516d4ea212740c16c2514c2908758a2
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15855
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Move all FSP error handling into the FSP 2.0 driver. This removes the
need to implement error handling within the SOC code.
TEST=Build and run on Galileo Gen2
Change-Id: I4d548b4c90d369d3857c24f50f93e7db7e9d3028
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15853
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Verify that FSP is properly returning:
* HOB list pointer
* FSP_BOOTLOADER_TOLUM_HOB
* FSP_RESERVED_MEMORY_RESOURCE_HOB
TEST=Build and run on Galileo Gen2
Change-Id: I23005d10f7f3ccf06a2e29dab5fa11c7ed79f187
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15850
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add support to display the HOBs returned by FSP:
* Add Kconfig value to enable HOB display
* Move hob_header, hob_resource and uuid_name structures into util.h
* Move hob_type enum into util.h
* Remove static from the debug utility functions
* Add fsp_ prefix to the debug utility functions
* Declare the debug utility functions in debug.h
* Add HOB type name table
* Add more GUID values
* Add new GUID name table for additional GUIDs
* Add routine to convert EDK-II GUID into a name
* Add SOC specific routine to handle unknown GUID types
* Add routine to convert HOB type into a name
* Add SOC specific routine to handle unknown HOB types
* Add routine to display the hobs
TEST=Build and run on Galileo Gen2
Change-Id: I10606d752859fff0f4f08a5ac03ab129b2c96d1f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15851
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add UPD display support:
* Add a Kconfig value to enable UPD value display
* Add a routine to display a UPD value
* Add a call before MemoryInit to display the UPD parameters
* Add a routine to display the architectural parameters for MemoryInit
* Add a weak routine to display the other UPD parameters for MemoryInit
* Add a call before SiliconInit to display the UPD parameters
* Add a weak routine to display the UPD parameters for SiliconInit
TEST=Build and run on Galileo Gen2.
Change-Id: I35fb8410c0bccf217b32af4b8bbe5ad6671f81f6
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15847
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Display the MTRR values in the following locations:
* Before the call to FspMemoryInit to document coreboot settings
* After the call to FspMemoryInit
* Before the call to FspSiliconInit
* After the call to FspSiliconInit
* After the call to FspNotify
* Before the call to FspNotify added in patch 15855
TEST=Build and run on Galileo Gen2
Change-Id: I8942ef4ca4677501a5c38abaff1c3489eebea53c
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15849
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
If ELOG_BOOT_COUNT is enabled and the boot is not s3 resume, then
increment boot count.
BUG=chrome-os-partner:55473
Change-Id: Ib3e77180bd640ec0424978e73034d7c99cdcba95
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15948
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
|
|
Disable the chatty FSP behavior for normal builds. Use a Kconfig value
to enable the display of the FSP call entry points, the call parameters
and the returned status for MemoryInit, SiliconInit and FspNotify. The
debug code is placed into drivers/intel/fsp2_0/debug.c.
TEST=Build and run on Galileo Gen2
Change-Id: Iacae66f72bc5b4ba1469f53fcce4669726234441
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15989
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
(val & 4) == 1 is always false. Since val & 4 is either zero or
non-zero, just drop the second test (for "== 1").
Validated against the data sheet that this is really the right register,
bit and value.
Change-Id: I627df9a9b4fddfff486689e405f52a3b54135eef
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1241864
Reviewed-on: https://review.coreboot.org/16009
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
These non-ascii & unprintable characters aren't needed.
Change-Id: I129f729f66d6a692de729d76971f7deb7a19c254
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15977
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I7930d5cded290f2605d0c92a9c465a3f0c1291a2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15974
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Change-Id: I720469ea1df75544f5b1e0cab718502d8a9cf197
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15983
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This removes the newlines from all files found by the new
int-015-final-newlines script.
Change-Id: I65b6d5b403fe3fa30b7ac11958cc0f9880704ed7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15975
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Keep this enabled by default as most x86 platforms could have PCI-e
slots equipped with one of these Intel WiFi adapters.
The Kconfig entries under google boards had no function previously,
the variable was never referenced.
Change-Id: I728ce3fd83d51d4e5e32b848a2079c5fcee29349
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15931
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Update the copyright dates in the FSP 2.0 files.
Add a copyright to Kconfig.
TEST=Build and run on Galileo Gen2
Change-Id: I0ad0c5650bde0e31d01a04bcc7d22a19273fe29b
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15852
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
FSP temp ram init was getting called earlier from ROMCC bootblock.
Now with C entry boot block, it is needed to locate FSP header and
call FspTempRamInit.
Hence add fsp 1_1 driver code to locate FSP Temp ram and execute.
BUG=chrome-os-partner:55357
BRANCH=none
TEST=Built kunimitsu and ensure FSP Temp Ram Init return success
Change-Id: If40b267777a8dc5c473d1115b19b98609ff3fd74
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/15787
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
These files are required by storm and gale boards for enabling elog
support in ramstage.
BUG=chrome-os-partner:55639
Change-Id: I2bbfee2acf2bfe2f896a8619b1276dcea1b87f16
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15893
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
With VBOOT_VERIFY_FIRMWARE separated from CHROMEOS, move recovery and
developer mode check functions to vboot. Thus, get rid of the
BOOTMODE_STRAPS option which controlled these functions under src/lib.
BUG=chrome-os-partner:55639
Change-Id: Ia2571026ce8976856add01095cc6be415d2be22e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15868
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
If the system is in recovery, store the newly generated MRC data using a
dummy version which is not legit. This ensures that on next normal boot,
new MRC data will be generated and stored.
BUG=chrome-os-partner:55699
Change-Id: Ib13e8c978dc1b4fc8817fab16d0e606f210f2586
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15828
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Quark does not support the rdmsr and wrmsr instructions. In this case
use a SOC specific routine to support the setting of the MTRRs. Migrate
the code from FSP 1.1 to be x86 CPU common.
Since all rdmsr/wrmsr accesses are being converted, fix the build
failure for quark in lib/reg_script.c. Move the soc_msr_x routines and
their depencies from romstage/mtrr.c to reg_access.c.
TEST=Build and run on Galileo Gen2
Change-Id: Ibc68e696d8066fbe2322f446d8c983d3f86052ea
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15839
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Convert the FSP 2.0 UPD headers from typedef to struct:
* FSP_UPD_HEADER
* FSPM_ARCH_UPD
TEST=Build and run on Galileo Gen2
Change-Id: Iab241ea07c955e95ff988a4a30103d2a112179b6
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15856
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The removal of ELOG_FLASH_BASE and ELOG_FLASH_SIZE resulted
in the FMAP region for the eventlog to be honored. However,
certain systems seem to have a large eventlog region that
wasn't being used in practice. Because of the malloc() in the
eventlog init sequence a large allocation was now being requested
that can exhaust the heap. Put back the 4KiB capacity until
the resource usage is fixed.
BUG=chrome-os-partner:55593
Change-Id: Ib54b396b48e5be80f737fc3feb0d58348c0d2844
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15835
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Separate NO_XIP_EARLY_STAGES from loading FSP-M into cache-as-RAM.
Quark executes romstage directly from the SPI flash part (in-place),
but loads FSP-M into ESRAM. This split occurs because ESRAM is too
small to hold everything while debugging.
Platforms executing FSP-M directly from the SPI flash need to select
FSP_M_XIP.
TEST=Build and run on Galileo Gen2.
Change-Id: Ib5313ae96dcec101510e82438b1889d315569696
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15848
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Build the UART drivers for the postcar stage.
TEST=Build and run on Galileo Gen2
Change-Id: I8bf51135ab7e62fa4bc3e8d45583f2feac56942f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15843
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Now that FMAP is a first class citizen in coreboot
there's no reason to have alternate locations for ELOG.
If one wants eventlog support they need to specify the
ELOG entry in the FMAP. The one side effect is that
the code was previously limiting the size to 4KiB
because the default ELOG_AREA_SIZE was 4KiB. However,
that's no longer the case as the FMAP region size is
honored.
Change-Id: I4ce5f15032387155d2f56f0de61f2d85271ba606
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15814
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
FSP 2.0 spec only defines 2 reset request (COLD, WARM) exit codes. The
rest 6 codes are platform-specific and may vary. Modify helper function
so that only basic resets are handled and let SoC deal with the rest.
Change-Id: Ib2f446e0449301407b135933a2088bcffc3ac32a
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15730
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
The FSPS component can request resets. Handle those
generically.
BUG=chrome-os-partner:52679
Change-Id: I41c2da543420102d864e3c5e039fed13632225b4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15748
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The FSPM component can request resets. Properly handle those.
BUG=chrome-os-partner:52679
Change-Id: If21245443761cb993e86c0e383c8bca87f460a85
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15747
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Ensure that the stack provided to FSPM doesn't overlap the current
program which is loading the FSPM component. If there is a conflict
that's an error since it could cause the current program to crash.
BUG=chrome-os-partner:52679
Change-Id: Ifff465266e5bb3cb3cf9b616d322a46199f802c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15746
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
If the system is in recovery mode force a full retrain.
BUG=chrome-os-partner:52679
Change-Id: I4e87685600880d815fe3198b820a10aa269baf37
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15745
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Utilizing the FSP revision while saving the memory training data is
important because it means when the FSP is updated the memory training
is redone. The previous implementation was just using '0' as a revision.
Because of that behavior a retrain would not have been done on an FSP
upgrade.
BUG=chrome-os-partner:52679
Change-Id: I1430bd78c770a840d2deff2476f47150c02cf27d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15744
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Remove the now unused fsp_load_binary() function.
BUG=chrome-os-partner:52679
Change-Id: I5667eb71689a69a9e05f7be05cb0c7e7795a55d3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15743
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The FSPS component loading was just loading to any memory address
listed in the header. That could be anywhere in the address space
including ramstage itself -- let alone corrupting the OS memory on
S3 resume. Remedy this by loading and relocating FSPS into cbmem.
The UEFI 2.4 header files include path are selected to provide the
types necessary for FSP relocation.
BUG=chrome-os-partner:52679
Change-Id: Iaba103190731fc229566a3b0231cf967522040db
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15742
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: John Zhao <john.zhao@intel.com>
|
|
The previously implementation for loading the FSPM component didn't
handle platforms which expects FSPM to be XIP. For the non-XIP case,
romstage's address space wasn't fully being checked for overlaps.
Lastly, fixup the API as the range_entry isn't needed any longer.
This API change requires a apollolake to be updated as well.
BUG=chrome-os-partner:52679
Change-Id: I24d0c7d123d12f15a8477e1025bf0901e2d702e7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15741
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The current FSP component loading mechanism doesn't handle all the
requirements actually needed. Two things need to be added:
1. XIP support for MemoryInit component
2. Relocating SiliconInit component to not corrupt OS memory.
In order to accommodate those requirements the validation
and header initialization needs to be a separate function.
Therefore, provide fsp_validate_component() to help achieve those
requirements.
BUG=chrome-os-partner:52679
Change-Id: I53525498b250033f3187c05db248e07b00cc934d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15740
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Instead of performing the same tasks in the chipset code move
the common sequences into the FSP 2.0 driver. This handles the
S3 paths as well as saving and restoring the memory data. The
chipset code can always override the settings if needed.
BUG=chrome-os-partner:52679
Change-Id: I098bf95139a0360f028a50aa50d16d264bede386
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15739
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The amount of reserved memory just below the DRAM limit in
32-bit space is defined in the FSP 2.0 specification within
the FSPM_ARCH_UPD structure. There's no need to make the
chipset code set the same value as needed for coreboot.
The chipset code can always change the value if it needs
after the common setting being applied.
Remove the call in soc/intel/apollolake as it's no longer
needed.
BUG=chrome-os-partner:52679
Change-Id: I69a1fee7a7b53c109afd8ee0f03cb8506584d571
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15738
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
The gcc compiler treats sizeof(void) == 1. Therefore requesting
a 1 byte reservation in cbmem and writing a pointer into the
buffer returned is wrong. Fix the size of the request to be
32-bits because FSP 2.0 is in 32-bit space by definition. Also,
since the access to the field happens across stage boundaries
it's important to ensure fixed widths are used in case a later
stage has a different pointer bit width.
BUG=chrome-os-partner:52679
Change-Id: Ib4efc7d5369d44a995318aac6c4a7cfdc73e4a8c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15737
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In case of elog not being stored in CBMEM, calculate flash offset by
using rdev_mmap instead of assuming that the entire flash is mapped just
below 4GiB. This allows custom mappings of flash to correctly convert
the flash offset to mmap address.
BUG=chrome-os-partner:54186
TEST=Verified behavior on reef. mosys able to read out the elog correctly.
Change-Id: I3eacd2c9266ecc3da1bd45c86ff9d0e8153ca3f2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15722
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The SLEEP_STATE_x definitions in the chipsets utilizing
FSP 1.1. driver have the exact same values as the ACPI_Sx
definitions. The chipsets will be moved over subsequently,
but updating this first allows the per-chipset patches
to be isolated.
BUG=chrome-os-partner:54977
Change-Id: I383a9a732ef68bf2276f6149ffa5360bcdfb70b3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15665
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Lee Leahy <leroy.p.leahy@intel.com>
|
|
This driver enables the usage of an external RTC chip PCF8523 which is
connected to the I2C bus. The I2C address of this device is fixed.
One can change parameters in device tree so that the used setup can be
adapted in device tree to match the configuration of the device on the
mainboard.
Change-Id: I2d7e161c9e12b720ec4925f1acfd1dd8ee6ee5f5
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15641
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Some devices allow to retrieve firmware version by reading the same 4
byte register repeatedly until the entire version string is read.
Let's print out TPM firmware version when available. Just in case
something goes wrong limit the version string length to 200 bytes.
CQ-DEPEND=CL:355701
BRANCH=none
BUG=chrome-os-partner:54723
TEST=built the new firmware and ran it on Gru, observed the following
in the coreboot console log:
Connected to device vid:did:rid of 1ae0:0028:00
Firmware version: cr50_v1.1.4792-7a44484
Original-Commit-Id: 1f54a30cebe808abf1b09478b47924bb722a0ca6
Original-Change-Id: Idb069dabb80d34a0efdf04c3c40a42ab0c8a3f94
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/355704
Original-Reviewed-by: Scott Collyer <scollyer@chromium.org>
Squashed with:
tpm: use 4 byte quantities when retrieving firmware version
The CR50 device is capable of reporting its firmware version in 4 byte
quantities, but the recently introduced code retrieves the version one
byte at a time.
With this fix the version is retrieved in 4 byte chunks.
BRANCH=none
BUG=none
TEST=the version is still reported properly, as reported by the AP
firmware console log:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: cr50_v1.1.4804-c64cf24
localhost ~ #
Original-Commit-Id: 3111537e7b66d8507b6608ef665e4cde76403818
Original-Change-Id: I04116881a30001e35e989e51ec1567263f9149a6
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/356542
Original-Reviewed-by: Andrey Pronin <apronin@chromium.org>
Change-Id: Ia9f13a5bf1c34292b866f57c0d14470fe6ca9853
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15573
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The "PC Client Protection Profile for TPM 2.0" document defines SPI
bus addresses for different localities. That definition is not honored
in the cr50 implementation, this patch fixes it: locality zero
register file is based off 0xd40000.
BRANCH=none
BUG=chrome-os-partner:54720
TEST=with the fixed cr50 image and the rest of TPM2 initialization
patches applied factory initialization sequence on Gru succeeds.
Change-Id: I49b7ed55f0360448b9a6602ebd31a3a531608da3
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 43344fff5d58ec235e50030413fc38c98dd0a9a1
Original-Change-Id: I2de6fa6c05d3eca989d6785228d5adde1f2a7ab7
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/355620
Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://review.coreboot.org/15568
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
Change-Id: I2c49d68ea9a8f52737b6064bc4fa703bdb1af1df
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15463
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add a device driver to generate the device and required properties
into the SSDT.
This driver uses the ACPI Device Property interface to generate the
required parameters into the _DSD table format expected by the kernel.
This was tested on the reef mainboard to ensure that the SSDT contained
the equivalent parameters that are provided by the current DSDT object.
Change-Id: Ia809e953932a7e127352a7ef193974d95e511565
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15538
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
There is a second ACPI _DSD document from the UEFI Forum that details
how _DSD style tables can be nested, creating a tree of similarly
formatted tables. This document is linked from acpi_device.h.
In order to support this the device property interface needs to be
more flexible and build up a tree of properties to write all entries
at once instead of writing each entry as it is generated.
In the end this is a more flexible solution that can support drivers
that need child tables like the DA7219 codec, while only requiring
minor changes to the existing drivers that use the device property
interface.
This was tested on reef (apollolake) and chell (skylake) boards to
ensure that there was no change in the generated SSDT AML.
Change-Id: Ia22e3a5fd3982ffa7c324bee1a8d190d49f853dd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15537
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add driver code to initialize Siemens NC FPGA as PCI device.
Beside some glue logic it contains a FAN controller and
temperature monitor.
Change-Id: I2cb722a60081028ee5a8251f51125f12ed38d824
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15543
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The function mainboard_get_mac_address() is used to get a MAC address
for a given i210 PCI device. Instead of passing pure numbers for PCI
bus, device and function pass the device pointer to this function. In
this way the function can retrieve the needed values itself as well as
have the pointer to the device tree so that PCI path can be evaluated
there.
Change-Id: I2335d995651baa5e23a0448f5f32310dcd394f9b
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15516
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The upstream kernel driver is not using the of-style naming for
sdmode-gpio so remove the maxim prefix, and remove the duplicate
entry for the sdmode-delay value as well.
Also fix the usage of the path variable, since the device path uses
a static variable it can't be assigned that early or it will be
overwritten by later calls.
This results in the following output for the _DSD when tested on
reef mainboard:
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
Package (0x02)
{
Package (0x02)
{
"sdmode-gpio",
Package (0x04)
{
\_SB.PCI0.HDAS.MAXM,
Zero,
Zero,
Zero
}
},
Package (0x02)
{
"sdmode-delay",
Zero
}
}
})
Change-Id: Iab33182a5f64c89151966f5e79f4f7c30840c46f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15514
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I22a33e6027a4e807f7157a0dfafbd6377bc1285d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15461
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Any FSP API call may request a reset. This is indicated in API function
return code. Add trivial reset handler code.
BUG=chrome-os-partner:54149
BRANCH=none
TEST=none
Change-Id: Ieb5e2d52ffdaf3c3ed416603f6dbb4f9c25a1a7b
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15334
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
To fully define TPM attachment to a SPI interface both bus and CS
(chip select) settings are required. Add the missing CS configuration
option.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied it is possible to compile in
and run TPM2 SPI driver.
Change-Id: If297df8e5b9526f156ed1414eb9db317d6af5b33
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353913
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15299
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This introduces a SPI TPM driver compliant with the TCG issued "TPM
Profile (PTP) Specification Revision 00.43" which can be found by
googling its title.
The driver implements both the hardware flow control protocol and the
TPM state machine.
The hardware flow control allows to map SPI based TPM devices to the
LPC address space on x86 platforms, on all other platforms it needs to
be implemented in the driver software.
The tis layer is somewhat superficial, it might have to be expanded
later.
A lot more implementation details can be found in the code comments.
Also, it is worth mentioning that this is not a complete version of
the driver: its robustness needs to be improved, delay loops need to
be bound, error conditions need to propagate up the call stack.
BRANCH=none
BUG=chrome-os-partner:52132, chrome-os-partner:50645, chrome-os-partner:54141
TEST=with the rest of the patches applied coreboot is able complete
Chrome OS factory initialization of the TPM2 device.
Change-Id: I967bc5c689f6e6f345755f08cb088ad37abd5d1c
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 5611c6f7d7fe6d37da668f337f0e70263913d63e
Original-Change-Id: I17d732e66bd231c2289ec289994dd819c6276855
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/350124
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15298
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Tested-by: build bot (Jenkins)
|
|
Until now it was assumed that all TPM devices were of the same type
(TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs
and all other boards had I2C connected TPMs.
With the advent of TPM2 specification there is a need to be able to
configure different combinations of TPM types (TPM or TPM2) and
interfaces (LPC, I2C and SPI).
This patch allows to do it. Picking Chrome OS still assumes that the
board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's
Kconfig will trigger including of TPM2 instead.
MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding
SPI_TPM to the board config switches interface choice to SPI, and if
neither of the two is defined, the interface is assumed to be I2C.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that none of the generated board configurations change
as a result of this patch. With the rest of the stack in place it
is possible to configure different combinations of TPM types and
interfaces for ARM and x86 boards.
Change-Id: I24f2e3ee63636566bf2a867c51ed80a622672f07
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 5a25c1070560cd2734519f87dfbf401c135088d1
Original-Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/349850
Original-Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15294
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
This variable name was changed in chip.h but not the consumer
and it was submitted before it was caught.
Change-Id: I7c492b588b2fd854a9eeac36029a46da324a7b1b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15109
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
