| Age | Commit message (Collapse) | Author |
|---|
|
Add recovery module in vboot2 that checks if a recovery request is
pending and returns appropriate reason code:
1. Checks if recovery mode is initiated by EC.
2. Checks if recovery request is present in VBNV.
3. Checks if recovery request is present in handoff for post-cbmem
stages.
4. Checks if vboot verification is complete and looks up selected region
to identify if recovery is requested by vboot library.
BUG=chrome-os-partner:55431
Change-Id: I31e332a4d014a185df2434c3730954e08dc27281
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15800
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
1. Remove unused functions/structures.
2. Add checks for NULL return values.
3. Change prefixes to vb2 instead of vboot for functions used internally
within vboot2/
4. Get rid of vboot_handoff.h file and move the structure definition to
vboot_common.h
5. Rename all functions using handoff structure to have prefix
vboot_handoff_*. All the handoff functions can be run _only_ after cbmem
is online.
6. Organize vboot_common.h content according to different
functionalities.
BUG=chrome-os-partner:55431
Change-Id: I4c07d50327d88cddbdfbb0b6f82c264e2b8620eb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
YangtzeSataResetService implements the SataSetMaxGen2 double.
The value should be only set, if the condition is met.
For testing, add
FchParams_env->Sata.SataMode.SataSetMaxGen2 = FALSE;
to your BiosCallOuts.c, which enables GEN3 for the SATA ports.
Patch is tested with bap/e20xx board, Lubuntu 16.04 Kernel 4.4.
$ dmesg | grep ahci #before patch
ahci 0000:00:11.0: AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
$ dmesg | grep ahci #after patch
ahci 0000:00:11.0: AHCI 0001.0300 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
Change-Id: I17a493b876a4be3236736b2116b331e465b159af
Signed-off-by: Fabian Kunkel <fabi@adv.bruhnspace.com>
Reviewed-on: https://review.coreboot.org/15728
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This fills up the RO_FRID, RW_FWID_A and RW_FWID_B FMAP sections with
the relevant version from KERNELVERSION, padded to the right size and
gap-filled with zeros.
Change-Id: I45c724555f8e41be02b92ef2990bf6710be805c2
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15604
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
TPM1.2 is using the somewhat misnamed tlcl_set_global_lock() command
function to lock the hardware rollback counter. For TPM2 let's
implement and use the TPM2 command to lock an NV Ram location
(TPM2_NV_WriteLock).
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM2_NV_WriteLock command is invoked before RO
firmware starts RW, and succeeds.
Change-Id: I52aa8db95b908488ec4cf0843afeb6310dc7f38b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 2f859335dfccfeea900f15bbb8c6cb3fd5ec8c77
Original-Change-Id: I62f22b9991522d4309cccc44180a5ebd4dca488d
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358097
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15638
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
tlcl_force_clear() needs to be issued each time when the device mode
switches between normal/development/recovery.
This patch adds command implementation using TPM_Clear TPM2 command,
and also invokes it before factory initialization.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM_Clear command succeeds at factory startup and
the boot proceeds normally.
Change-Id: Ia431390870cbe448bc1b6f1755ed17953be9bdf1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 347ff17b97da45fa4df547ff32f9dd2c8972cefd
Original-Change-Id: I2a0e62527ad46f9dd060afe5e75c7e4d56752849
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358095
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15636
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
The TPM2 specification allows defining NV ram spaces in a manner
that makes it impossible to remove the space until a certain PCR is in
a certain state.
This comes in handy when defining spaces for rollback counters: make
their removal depend on PCR0 being in the default state. Then extend
PCR0 to any value. This guarantees that the spaces can not be deleted.
Also, there is no need t create firmware and kernel rollback spaces
with different privileges: they both can be created with the same set of
properties, the firmware space could be locked by the RO firmware, and
the kernel space could be locked by the RW firmware thus providing
necessary privilege levels.
BRANCH=none
BUG=chrome-os-partner:50645, chrome-os-partner:55063
TEST=with the rest of the patches applied it is possible to boot into
Chrome OS maintaining two rollback counter spaces in the TPM NV
ram locked at different phases of the boot process.
Change-Id: I889b2c4c4831ae01c093f33c09b4d98a11d758da
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 36317f5e85107b1b2e732a5bb2a38295120560cd
Original-Change-Id: I69e5ada65a5f15a8c04be9def92a8e1f4b753d9a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358094
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/15635
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
This patch adds a TPM2 specific path in the vboot2 initialization
sequence when the device is turned on in the factory for the first
time, namely two secure NVRAM spaces are created, with different
access privileges.
The higher privilege space can be modified only be the RO firmware,
and the lower privilege space can be modified by both RO and RW
firmware.
The API is being modified to hide the TPM implementation details from
the caller.
Some functions previously exported as global are in fact not used
anywhere else, they are being defined static.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=when this code is enabled the two secure spaces are successfully
created during factory initialization.
Original-Commit-Id: 5f082d6a9b095c3efc283b7a49eac9b4f2bcb6ec
Original-Change-Id: I917b2f74dfdbd214d7f651ce3d4b80f4a18def20
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353916
Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
squashed:
mock tpm: drop unused functions
safe_write() and safe_define_space() functions are defined in
secdata_mock.c, but not used in mocked TPM mode.
The actual functions have been redefined as static recently and their
declarations were removed from src/include/antirollback.h, which now
causes compilation problems when CONFIG_VBOOT2_MOCK_SECDATA is
defined.
Dropping the functions from secdata_mock.c solves the problem.
BRANCH=none
BUG=none
TEST=compilation in mock secdata mode does not fail any more.
Original-Commit-Id: c6d7824f52534ecd3b02172cb9078f03e318cb2b
Original-Change-Id: Ia781ce99630d759469d2bded40952ed21830e611
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/356291
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Icb686c5f9129067eb4bb3ea10bbb85a075b29955
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15571
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Specify the memory initialization parameters in
mainboard/intel/galileo/devicetree.cb. Pass these values into FSP to
initialize memory.
TEST=Build and run on Galileo Gen2
Change-Id: I83ee196f5fb825118a3a74b61f73f3728a1a1dc6
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15260
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.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>
|
|
Boards broken with commit:
062ef1c AGESA boards: Split dispatcher to romstage and ramstage
Boot failure with asus/f2a85-m witnessed around MemMS3Save() call,
message "Save memory S3 data in heap" in verbose agesa logs was
replaced by a system reset.
Default stubs for MemS3ResumeConstructNBBlock() returned TRUE
without initializing the block contents. This would not work for case
with multiple NB support built into same firmware.
MemMCreateS3NbBlock() then returned with S3NBPtr!=NULL with uninitialized
data and MemMContextSave() referenced those as invalid pointers.
There is no reason to prevent booting in the case S3 resume data is not
passed to ramstage, so remove the ASSERT(). It only affects builds with
IDSOPT_IDS_ENABLED=TRUE anyways.
Change-Id: I8fd1e308ceab2b6f4b4c90f0f712934c2918d92d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15344
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
|
|
If read_vbnv finds that the vbnv_copy is not valid, it initializes it
with the correct HEADER_SIGNATURE and other attributes. However, the
vbnv copy is checked for validity and initialized at the vboot layer as
well. Since, vboot is the owner of this data, it should be the one
initializing it. Thus, if read_vbnv sees that the data is not valid,
simply reset it to all 0s and let vboot layer take care of it. This also
removes the need for additional checks to ensure that the dirty vbnv
copy is properly updated on storage.
Change-Id: I6101ac41f31f720a6e357c9c56e571d62e0f2f47
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Add support for a fourth info block type to hwilib. This block
provides new values and is now variable in length.
Change-Id: Ia928b4a98b806ba3e80fb576b78f60bb8f2ea3fc
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15478
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Currently, read_vbnv performs a reset of the vbnv cache if it is not
valid. However, this information is not passed up to the vboot layer,
thus resulting in missed write-back of vbnv cache to storage if vboot
does not update the cache itself.
Update read_vbnv to return a value depending upon whether it wants a
write-back to be performed when save is called.
Return value:
0 = No write-back required
1 = Write-back of VBNV cache is required.
Change-Id: I239939d5f9731d89a9d53fe662321b93fc1ab113
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15457
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
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>
|
|
The VBOOT_OPROM_MATTERS configuration option signals to vboot that the
board can skip display initialization in the normal boot path. It's name
is a left-over from a time when this could only happen by avoiding
loading the VGA option ROM on x86 devices. Now we have other
boards that can skip their native display initialization paths too, and
the effect to vboot is the same. (Really, we should rename oprom_matters
and oprom_loaded to display_skippable and display_initialized or
something, but I don't think that's worth the amount of repositories
this would need to touch.)
The only effect this still has in today's vboot is to reboot and
explicitly request display initialization for EC software sync on
VBOOT_EC_SLOW_UPDATE devices (which we haven't had yet on ARM). Still,
the vboot flag just declares the capability (for skipping display init),
and it should be set correctly regardless of whether that actually makes
a difference on a given platform (right now). This patch updates all
boards/SoCs that have a conditional path based on
display_init_required() accordingly.
BRANCH=None
BUG=chrome-os-partner:51145
TEST=Booted Oak, confirmed that there's no notable boot time impact.
Change-Id: Ic7c77dbd8356d67af7aee54e7869f9ac35241b99
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 9c242f7
Original-Change-Id: I75e5cdda2ba2d111ea50ed2c7cdf94322679f1cd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/348786
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15113
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Scan the boot block when building it with C_ENVIRONMENT_BOOTBLOCK
selected.
TEST=Build and run with Galileo Gen2
Change-Id: I922f761c31e95efde0975d8572c47084b91b2879
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15130
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add car_stage_entry as an optional routine in the checklist.
TEST=Build and run on Galileo Gen2
Change-Id: I52f6aefc2566beac01373dbebf3a43d35032a0df
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15129
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Pass the serial port address to FSP using a UPD value in the MemoryInit
API.
TEST=Build and run on Galileo Gen2
Change-Id: I86449d80310b7b34ac503ebd2671a4052b080730
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15079
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The way dispatcher table is set up prevents linker from
optimizing unused code away, we currently have raminit in ramstage.
Optimize this manually by configuring AGESA_ENTRY booleans for
romstage and ramstage separately. This will remove references in
FuncParamsInfo and DispatchTable -arrays.
All boards now include multi-core dispatcher, it has minimal footprint:
AGESA_ENTRY_LATE_RUN_AP_TASK
ACPI S3 support depends on HAVE_ACPI_RESUME being enabled:
AGESA_ENTRY_INIT_RESUME
AGESA_ENTRY_INIT_LATE_RESTORE
AGESA_ENTRY_INIT_S3SAVE
Disabled for all boards as it was not used:
AGESA_ENTRY_INIT_GENERAL_SERVICES
Change-Id: I7ec36a5819a8e526cbeb87b04dce4227a1689285
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14417
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Follow-up on commits a5d72a3 and 53052fe for f12 and f15.
OEM Hooks are not BiosCallOuts.
Change-Id: Iab22b0d73282a5a1a5d1344397b4430c0ebb81b5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14888
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The definitions of CFG_ would evaluate to incorrect values
when Options.h is included outside buildOpts.c, where all
BLDCFG_ values are defined.
Already done for f16kb.
Change-Id: I5d725b9306027c7c46c6450ab17b692fa948cf5b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14886
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I0a452b6234b02222be82ca8694868e1ffbfceaee
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14396
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ie6effa802f6971c59b5c4e07ca7d98736e27859f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14885
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Tree does not have any AGESA f10 boards. Keep the Danube platform
as a sample configuration file for unlikely future use.
Change-Id: I025aff48fcd0884b45e2a0a993d82f317ede48be
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14884
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Build the <board>_checklist.html file which contains a checklist table
for each stage of coreboot. This processing builds a set of implemented
(done) routines which are marked green in the table. The remaining
required routines (work-to-do) are marked red in the table and the
optional routines are marked yellow in the table. The table heading
for each stage contains a completion percentage in terms of count of
routines (done .vs. required).
Add some Kconfig values:
* CREATE_BOARD_CHECKLIST - When selected creates the checklist file
* MAKE_CHECKLIST_PUBLIC - Copies the checklist file into the
Documenation directory
* CHECKLIST_DATA_FILE_LOCATION - Location of the checklist data files:
* <stage>_complete.dat - Lists all of the weak routines
* <stage>_optional.dat - Lists weak routines which may be optionally
implemented
TEST=Build with Galileo Gen2.
Change-Id: Ie056f8bb6d45ff7f3bc6390b5630b5063f54c527
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15011
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When the vboot cbfs selection runs in postcar stage it should be
utilizing cbmem to locate the vboot selected region.
Change-Id: I027ba19438468bd690d74ae55007393f051fde42
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14959
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Add cmos init helper function.
This function saves the Vboot NV data, calls cmos init
and restores the Vboot NV data.
Change-Id: I8475f23d849fb5b5a2d16738b4d5e99f112883da
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-on: https://review.coreboot.org/14898
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Having CFLAGS with -Os disables -falign-function, for
unlucky builds this may delay entry to ramstage by 600ms.
Build the low-level IO functions aligned with -O2 instead.
Change-Id: Ice6781666a0834f1e8e60a0c93048ac8472f27d9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14414
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Ia4cef7d584e43f1911db2f81d8b86ed406b75aad
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14786
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Using a dedicated variable is slightly less readable and makes the code
less consistent, given that other test functions are called directly in
the if statements.
Change-Id: If52b2a4268acb1e2187574d15cc73a0c1d5fe9bb
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14817
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I6b345670db7df652b8b712b721dfe2905373e0d5
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14630
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: York Yang <york.yang@intel.com>
|
|
Change-Id: I1bd33e423b0fcb69597e001b61c6ea916f5fe44a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14622
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
|
|
PCI device ID of this mini-PCI-e WLAN card is 8086:088e.
With this card inserted on pcengines/apu1 mini-PCI-e slot J17,
system halts late in ramstage, in agesawrapper AMD_INIT_MID.
Offending operation is enabling PCIe ASPM L0s and L1 for the card.
That is, writing PCIe capability block Link Control [1:0] = 11b
in the card's configuration space. AGESA already has a blacklist
for the purpose of masking such unstable ASPM implementations.
Change-Id: I9623699c4ee68e5cdc244b87faf92303b01c4823
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/8496
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Not used as we link AGESA into same romstage and ramstage ELF.
Change-Id: Ia427b9c0cc88b870de75df14bba4ca337a28adff
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14395
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: If48fffee1441b6bb012a8d99abb794f7a35efcf6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14412
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I9faeda508694f950f1b025765e2ac63bc91747fa
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14411
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
File buildOpts.c is a can of worms, pull platform memory
configuration in to OemCustomize.c. This array should be
assigned at runtime instead of linking a modified defaults
table.
Change-Id: I73d9d3fbc165e6c10472e105576d7c40820eaa6a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14528
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
On modern x86 platforms like apollolake, pre-RAM stages verstage and
romstage run within the cache-as-ram region. Thus, we do not need to
pass in the --xip parameter to cbfstool while adding these
stages. Introduce a new Kconfig variable NO_XIP_EARLY_STAGES which is
default false for all x86 platforms. Apollolake selects this option
since it supports code execution with CAR.
Change-Id: I2848046472f40f09ce7fc230c258b0389851b2ea
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14623
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Update the file to match the QuarkFsp code.
TEST=Build and run on Galileo Gen2
Change-Id: I090578d32165d34863548aec0e4a38fe915683c6
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14452
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
In the case where one of the FW_MAIN regions is empty, the last file
(empty) will also appear to be first and have a zero offset, making head
complain.
This is a very borderline use case, since the FW_MAIN_ regions should
have been filled previously, but an extra check doesn't hurt.
Change-Id: I15491c5b4a5e7d1f9fb369cc5fa4e3875e2dad3b
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14472
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Switch all types to uint8_t and the like instead of u8.
Change-Id: Ia12c4ee9e21e2d3166c2f895c819357fa2ed9a94
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/14515
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add a library which unifies access to Siemens specific hardware information
data. This library is meant to be used with Siemens platforms and can be
selected in Kconfig. The needed source of information has to be present
in cbfs.
This lib can be used in romstage and ramstage.
Change-Id: I2c6e003b0c123b4cf6a84906c2b133b8c38c8b1a
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/14505
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Fix is required to compile AGESA ramstage without raminit.
Change-Id: I783883fa7a12e8a647aa432535bb990a47257e9b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14416
Tested-by: build bot (Jenkins)
Reviewed-by: Kerry Sheh <shekairui@gmail.com>
|
|
Change-Id: Ide3202fca75c77ccebf17d61d93945ba7834a13b
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14398
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Compiling libagesa with -O2 would throws error on these.
Change-Id: I04afa42f0ac76677f859ca72f9df2e128762ad3c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14413
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We have not really hit this error, due the test on AGESA_UNSUPPORTED
above.
Change-Id: I6e7d136a1bb46138cc347225bc4c82cfeaff385d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We never define B1_IMAGE or B2_IMAGE. These are about building
CIMx as separate binary modules, while coreboot builds these into
same romstage or ramstage module.
Change-Id: I9cfa3f0bff8332aff4b661d56d0e7b340a992992
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14393
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Kerry Sheh <shekairui@gmail.com>
|
|
This symbol was added to fix a Kconfig lint error after the
Broadwell DE vendorcode was added. Now that the chipset's in
the codebase, it's no longer needed.
Change-Id: Iedb166129c9265cc2cfcc406d98bde92c1a82d2f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14384
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
An unsigned enum expression is always strictly positive;
Comparison with '>= 0' is a tautology, hence remove it.
Change-Id: I910d672f8a27d278c2a2fe1e4f39fc61f2c5dbc5
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: https://review.coreboot.org/8207
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
The codepath was untested and incomplete. It now determines the right
GBB region sizes and puts the data in.
BUG=chromium:595715
BRANCH=none
TEST=none
Change-Id: I2cc47ddd8aa7675375ca5ed5f75632c30c65dd1e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36e026404ed049d61b677ef043a781c8c209dd93
Original-Change-Id: Ib872627740dbd8ac19fc3e2a01464457f38366ed
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/336358
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14239
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This mirrors vboot's flag table.
BUG=chromium:595715
BRANCH=none
TEST=none
Change-Id: I4473eb6c0e073f555e6a692a447e8cc85f8e4eeb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0fc50a6cff5ba900e6407d58a8f18db63b5946a5
Original-Change-Id: Ieabd3f9391ba256557e18386f334558d64a81694
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/336630
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14238
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The MT8173 hardware watchdog can assert an external signal which we use
to reset the TPM on Oak. Therefore we do not need to do the same
double-reset dance as on other Chromebooks to ensure that we reset in a
correct state.
Still, we have a situation where we need to reconfigure the watchdog
early in the bootblock in a way that will clear information about the
previous reboot from the status register, and we need that information
later in ramstage to log the right event. Let's reuse the same watchdog
tombstone mechanism from other boards, except that we don't perform a
second reset and the tombstone is simply used to communicate between
bootblock and ramstage within the same boot.
BRANCH=None
BUG=None
TEST=Run 'mem w 0x10007004 0x8' on Oak, observe how it reboots and how
'mosys eventlog list' shows a hardware watchdog reboot event afterwards.
Change-Id: I1ade018eba652af91814fdaec233b9920f2df01f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 07af37e11499e86e730f7581862e8f0d67a04218
Original-Change-Id: I0b9c6b83b20d6e1362d650ac2ee49fff45b29767
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/334449
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/14234
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The typo is not present anymore in Family 16h (Kabini), so fix it for
the older families (Family 10h, 12h, 14h, 15h, 15h Trinity) too using
the command below.
$ git grep -l ' ne ' src/vendorcode/amd/agesa | xargs sed -i 's/ ne / be /g'
Change-Id: I9cb419251eeec79925f48a5832fac339d40f01d1
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/5543
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
When doing verification of memory init code in verstage vboot
should issue a TPM_Startup(ST_STATE) instead of TPM_Startup(ST_CLEAR)
in order to preserve the flags in TPM_STCLEAR_FLAGS which include
things like physical presence. In doing so we can also skip the rest
of the TPM init work in this function in the S3 resume path.
BUG=chrome-os-partner:50633
BRANCH=glados
TEST=S3 resume on chell and ensure TPM is resumed instead of being
cleared and that 'tpmc getvf|getpf|getf' does not show any difference
in flags between boot and resume.
Change-Id: I7a48eaf7f57d2bc6ebc182178cbe60ceb2ad8863
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f059f39a0f5c2f21e564b9554efacf26a41ad794
Original-Change-Id: I647869202d2f04328764155d3de4cad9edf10ae4
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Previous-Reviewed-on: https://chromium-review.googlesource.com/332434
Original-(cherry picked from commit 5fc7792e4104523569140cd84ce313da721ec34b)
Original-Reviewed-on: https://chromium-review.googlesource.com/332542
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14107
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The Kconfig lint tool is complaining because this symbol doesn't
exist. Create a temporary definition that can be removed when
the chipset is added.
Change-Id: I6a8abffcc91773aae16721ee1f48c4c64bd6b486
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14091
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Initial vendor codes to support Broadwell-DE SoC. This is FSP 1.0 based
project and is based on Broadwell-DE Gold release. Change has been
verified on Intel Camelback Mountain CRB.
Change-Id: I9262c9d70a58f0c7427f0658948adf080f2f6d8f
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: https://review.coreboot.org/14030
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The previous copy of FspUpdVpd.h was not up to date w.r.t. the
FSP release being used for skylake boards. Fix that.
BUG=chrome-os-partner:50863
BRANCH=None
TEST=Built and booted on chell.
Change-Id: I39896c04d35189b0fb2c903eefda4e5b7c57084a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd647f354b8d9946b2217751cf1af845f29191b7
Original-Change-Id: I4ad131af6c563c9c33eb2b9207b13617ff24385d
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/331290
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13984
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
In ChromeOS VPD spec the right name is "region".
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/322851
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
(cherry picked from commit 21ea0663e7f3ffe3aaea6b6ce0e1216fcd9ca23e)
BUG=chrome-os-partner:50516
BRANCH=glados
TEST=build and boot on chell
Change-Id: I4ba9a9c65af3732fa263030640495ab5bea91d1f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 848f18e731eb11dd3037d12607d7364f95e64e34
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Change-Id: Ib96036f9cd76449f170af5c3dd6ef6e8e91ded94
Original-Reviewed-on: https://chromium-review.googlesource.com/329293
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Set the UPD values for MemoryInit.
* Update the FspUpdVpd.h file which specifies the parameters for
MemoryInit.
* Add the necessary values to chip.h to enable values to come from
the mainboard's devicetree.cb file
* Add the parameters to the mainboard's devicetree.cb file
* Locate the platform configuration database file (pdat.bin)
* Copy the data values from the chip_info structure into the UPDs
* Display the UPD values
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Edit .config file and add the following lines:
* CONFIG_DISPLAY_UPD_DATA=y
* Testing successful when the UPD data is displayed before the call to
MemoryInit
Change-Id: Ic64f3d97eb43ea42d9b149769fc96bf78bf804f5
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13896
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
If a platform does verification of the memory init step, and it must
resume with the same slot that it booted from then it needs to set
the vboot context flag when resuming instead of booting. This will
affect the slot that is selected to verify and resume from.
BUG=chromium:577269
BRANCH=glados
TEST=manually tested on chell:
1) ensure that booting from slot A resumes from slot A.
2) ensure that booting from slot B resumes from slot B.
3) do RW update while booted from slot A (so the flags are set to try
slot B) and ensure that suspend/resume still functions properly using
current slot A.
4) do RW update while booted from slot B (so the flags are set to try
slot A) and ensure that suspend/resume still functions properly using
current slot B.
Change-Id: I77e6320e36b4d2cbc308cfb39f0d4999e3497be3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 4c84af7eae7b2a52a28cc3ef8a80649301215a68
Original-Change-Id: I395e5abaccd6f578111f242d1e85e28dced469ea
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/328775
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch ports the LZ4 decompression code that debuted in libpayload
last year to coreboot for use in CBFS stages (upgrading the base
algorithm to LZ4's dev branch to access the new in-place decompression
checks). This is especially useful for pre-RAM stages in constrained
SRAM-based systems, which previously could not be compressed due to
the size requirements of the LZMA scratchpad and bounce buffer. The
LZ4 algorithm offers a very lean decompressor function and in-place
decompression support to achieve roughly the same boot speed gains
(trading compression ratio for decompression time) with nearly no
memory overhead.
For now we only activate it for the stages that had previously not been
compressed at all on non-XIP (read: non-x86) boards. In the future we
may also consider replacing LZMA completely for certain boards, since
which algorithm wins out on boot speed depends on board-specific
parameters (architecture, processor speed, SPI transfer rate, etc.).
BRANCH=None
BUG=None
TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on
Oak to be about ~20ms faster (cutting load times for affected stages
almost in half).
Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13638
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This symbol is not defined.
Change-Id: I2b0a3fca82d85962fc882f237b70702cab0400db
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/13647
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
See discussion on https://review.coreboot.org/13600 and
https://review.coreboot.org/13601
Change-Id: Ia8274b0b296d6b398f75c0d91a6fded4c5f57e10
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13643
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Baytrail FSP MR 005 adds two new fields:
AutoSelfRefreshEnable
APTaskTimeoutCnt
Add the device tree definitions.
Change-Id: I12e2a8b0b5cbeb6b7289cf91f65b25e73007a8de
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/12973
Tested-by: build bot (Jenkins)
Reviewed-by: York Yang <york.yang@intel.com>
|
|
These files aren't updated (or updatable), and as such don't need to be
copied to the RW sections.
Change-Id: Ie78936792ad651fbf8500fc7e34f0899e33a904c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13633
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds a new kconfig option that will back up the VBNV data
from CMOS to flash, and restore it if the CMOS data is invalid
during boot.
This allows special flags to not get lost when power is lost,
RTC reset is triggered, or CMOS is corrupted.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=manually tested on chell:
1-boot and run "enable_dev_usb_boot"
2-reboot and check that it is enabled with crossystem
3-run "mosys nvram clear"
4-reboot and check that it is still enabled
Change-Id: I38103d100117da34471734a6dd31eb7058735c12
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8a356e616c6885d5ae3b776691929675d48a28f9
Original-Change-Id: I06e7ddff7b272e579c704914a0cf8cc14d6994e8
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324122
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13600
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Certain platforms query the recovery mode switch more than just within
vboot during the boot flow. Therefore, it's important that the first call to
get_recovery_mode_switch() is consistent through memory training because
certain platforms use the recovery mode switch to take different action
for memory training. Therefore, defer the clearing of the rec mode
switch to a place when it's known that memory is up and online.
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Three finger salute is honored on chell by retraining memory.
Change-Id: I26ea51de7ffa2fe75b9ef1401fe92f9aec2b4567
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6b0de9369242e50c7ff3b164cf1ced0642c7b087
Original-Change-Id: Ia7709c7346d1222e314bf3ac7e4335a63e9a5144
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/325120
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13604
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This modifies the vbnv_flash driver to make it safe for use
in cache-as-ram by handling the global variables safely.
To make this cleaner all of the variables were moved into
one structure and referenced from there.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=build and boot on chell using following patches to
test backup and restore of vbnv_cmos into flash
Change-Id: I3a17fa51cfd754455502ac2e5f181dae35967f2a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 48876561fa4fb61e1ec8f92596c5610d97135201
Original-Change-Id: Id9fda8467edcc55e5ed760ddab197ab97d1f3d25
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324121
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13599
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The VBNV region size is determined by vboot and is not really
configurable. Only the CMOS implementation defined this config
variable so switch it to use VBNV_BLOCK_SIZE defined by vboot
in vbnv_layout.h instead.
This requires updating the broadwell/skylake cmos reset functions
to use the right constant.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=manually tested on chell
Change-Id: I45e3efc2a22efcb1470bbbefbdae4eda33fc6c96
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e2b803ff3ac30ab22d65d1e62aca623730999a1d
Original-Change-Id: I4896a1a5b7889d77ad00c4c8f285d184c4218e17
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324520
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13598
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add a wrapper around the vbnv implementations and call into the different
backend functions from there. Also move some of the common functions to
the common code and simplify the backend drivers. This will allow some
of the code to be re-used so the CMOS backend can backup the data into
the flash backend.
One side effect of this is that the cache of VBNV was removed from CMOS
and EC backends and moved into the VBNV wrapper, but the flash backend
also still has a separate cache because it has more state and complexity
in the implementation. The wrapper cached data is not used for normal
vbnv_read/vbnv_write because some callers need the ability to force a
write if the backend storage is cleared (i.e. CMOS clear).
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=build and boot on chell
Change-Id: I4d2e0e99af7e8a44aec77ad9991507401babcca6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c30f60434a64f6c0eb9ede45d48ddafff19dd24f
Original-Change-Id: Ia97f6607c5ad837b9aa10b45211137221ccb93a0
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324120
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13597
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Vboot keeps track of the size of the hashed region in each
RW slot. While that size was being used to calculate the hash
it wasn't being honored in restricting the access within the
FMAP region for that RW slot. To alleviate that create a sub
region that covers the hashed data for the region in which
we boot from while performing CBFS accesses.
BUG=chrome-os-partner:49764
BUG=chromium:445938
BRANCH=glados
TEST=Built and booted chell with cbfstool and dev-util patches.
Change-Id: I1a4f45573a6eb8d53a63bc4b2453592664c4f78b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4ac9e84af5b632e5735736d505bb2ca6dba4ce28
Original-Change-Id: Idca946926f5cfd2c87c4a740ad2108010b6b6973
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324093
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13586
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When vboot_handoff_flag() is called in the bootblock or a separate
verstage there's no memory nor the possibility of dram coming online.
Therefore, don't bother to attempt call cbmem_find().
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Built chell with separate verstage which pulls in vboot_common.c
dependency. No more linking errors w/ cbmem_find() not being
around.
Change-Id: I494c93adc1c00459fdfaa8ce535c6b4c884ed0fb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 414ce6aeaff657dc90289b25e5c883562189b154
Original-Change-Id: I8a5f2d154026ce794a70e7ec38883fa3c28fb6e7
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324070
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13580
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Sometimes it's necessary for the platform to perform clean up
tasks prior to reboot when employing vboot. For example, x86 systems
that resume and do vboot verification may need to clear their
sleep control register prior to doing a cold reset so that the
next boot doesn't appear to be a resume. Allow that hook by
introducing vboot_platform_prepare_reboot().
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Ensure vboot_platform_prepare_reboot() called from vboot_reboot().
Change-Id: I622c9181d9fa3048204e3df3223d5dd4b458abca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f31ffc40bde002dec398fd4dd9d2ee9d65df0d7b
Original-Change-Id: I97318cec34494a7fc4b1ecf2cb22715d20e730ff
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323501
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13575
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
For x86 systems which resume through the reset vector one needs to
ensure the the RW slot taken at resume time matches the one at
boot time. The reason is that any assets pulled out of the boot
media need to match how the platform previously booted. To do
that one needs obtain the hash digest of the chosen slot, and it
needs to be saved in a secure place on the normal boot path. On
resume one needs to retrieve the hash digest back to compare it
with the chosen slot. If they don't match resuming won't be
possible.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
CQ-DEPEND=CL:323460
Change-Id: I90ce26813b67f46913aa4026b42d9490a564bb6c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 01a42c0ecfc6d60d1d2e5e36a86781d91d5c47a9
Original-Change-Id: I6c6bdce7e06712bc06cc620a3d7a6a6250c59c95
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323500
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13574
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add the files for minimal Quark X1000 SoC support:
* Declare pei_data structure
* Declare sleep states and chipset_power_state structure
* Specify top of memory
* Empty FspUpdVpd.h file
TEST=None
Change-Id: If741f84904394780e1f29bd6ddbd81514c3e21c9
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13439
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This requires payload integration somewhere to be useful, because
without that, adding it will (hopefully) break the signature.
Change-Id: I67b8267e5040e26353df02d258e92a0610e19a52
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13560
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Use the flags to preset the GBB flags field. The Kconfig defaults are
chosen for a "developer" configuration.
Change-Id: Ifcc05aab10b92a2fc201b663df5ea47f92439a3f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13559
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The GBB contains hardware-specific data plus some configuration. The
latter isn't supported by this change yet and will come later.
The fields that are supported (hardware ID, bmpfv, vboot keys) are
configurable through Kconfig and point to Chrome OS-style default (eg.
developer keys).
While adding vboot keys, the two keys used to sign RW regions are also
added to Kconfig, even if not yet used.
Change-Id: Icfba6061ca83182df560cd36052fbb257826d4b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13558
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Sync and merge useless differences.
Change-Id: I4eea66c35af66d473dd56db9ccf105c878266f22
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: https://review.coreboot.org/7513
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Strip out the AMD internal version tag, e.g.
* @e \$Revision: 63425 $ @e \$Date: 2011-12-22 11:24:10 -0600 (Thu, 22 Dec 2011) $
which are false/inconsistent and serve no real meaning or purpose now.
Change-Id: I4cca0899eba66a1c361ba784c5ac0222b0ee1aa6
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: https://review.coreboot.org/7516
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Since this code is pulled in through commonlib, it will break compilation
of cbfstool on OSX.
Change-Id: I342bfa7e755aa540c4563bb5cd8cccacee39d188
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13525
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Some trivial cleanup.
Change-Id: I866efc4939b5e036ef02d1acb7b8bb8335671914
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13427
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Just rename the two scripts that are in the src/ tree to give them
a .sh extension. Since we generally expect files in the src directory
to be source files, this allows to identify these as scripts easily.
Change-Id: I0ab20a083880370164488d37a752ba2d5a192fdc
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13432
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
There were several spots in the tree where the path to a per class
object file was hardcoded. To make use of the src-to-obj macro for
this, it had to be moved before the inclusion of subdirs. Which is
fine, as it doesn't have dependencies beside $(obj).
Tested by verifying that the resulting coreboot.rom files didn't change
for all of Jenkins' abuild configurations.
Change-Id: I2eb1beeb8ae55872edfd95f750d7d5a1cee474c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13180
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I42200feafed613136f23e37d4ab4c90931698821
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://review.coreboot.org/13038
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This patch adds a check to the VPD parsing code to avoid reading the
whole thing if the first byte ('type' of the first VPD entry) is 0x00
or 0xff. These values match the TERMINATOR and IMPLICIT_TERMINATOR types
which should never occur as the first entry, so this usually means that
the VPD FMAP section has simply never been initialized correctly. This
early abort avoids wasting time to read the whole section from SPI flash
(which we'd otherwise have to since we're not going to find a Google VPD
2.0 header either).
BRANCH=None
BUG=None
TEST=Booted Oak, confirmed that VPD read times dropped from 100ms to
1.5ms.
Change-Id: I9fc473e06440aef4e1023238fb9e53d45097ee9d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 20a726237e03941ad626a6146700170a45ee7720
Original-Change-Id: I09bfec3c24d24214fa4e9180878b58d00454f399
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/322897
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/13467
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This patch adds three timestamps to coreboot and the cbmem utility that
track the time required to read in the Chrome OS Vital Product Data
(VPD) blocks (RO and RW). It's useful to account for these like all
other large flash accesses, since their size is variable.
BRANCH=None
BUG=None
TEST=Booted Oak, found my weird 100ms gap at the start of ramstage
properly accounted for.
Change-Id: I2024ed4f7d5e5ae81df9ab5293547cb5a10ff5e0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b97288b5ac67ada56e2ee7b181b28341d54b7234
Original-Change-Id: Ie69c1a4ddb6bd3f1094b3880201d53f1b5373aef
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/322831
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/13139
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add flag handling for CONFIG_VBOOT_EC_SLOW_UPDATE to indicate
to vboot that it should show the "critical update" screen during
software sync for EC+PD.
In order to make this work on x86 where we do not run graphics
init in the normal path add handling for CONFIG_VBOOT_OPROM_MATTERS
and indicate to vboot when the option rom has been loaded.
BUG=chrome-os-partner:49560
BRANCH=glados
TEST=Build and boot on chell in normal mode with an EC update payload
and ensure that it reboots to enable graphics, shows the "critical
update" screen, and then reboots to disable graphics init again.
Change-Id: I5ca46457798a22e9b08aa2febfec05b01aa788f9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6a1bb8572c3485f64b9f3e759288321b44184e66
Original-Change-Id: I9f66caaac57bb9f05bc6c405814469ef7ddf4d0a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/322781
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13073
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Setup an initial rule to make use of the updatable CBFS regions in fmap.
Change-Id: I1fe1c6e7574854b735760c85590da6e297f6e687
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13060
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Implement wifi_regulatory_domain function by getting country code from
VPD
Original-Reviewed-on: https://chromium-review.googlesource.com/314385
Original-Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Hannah Williams <hannah.williams@intel.com>
Change-Id: Ia6a24df110a3860d404d345571007ae8965e9564
Signed-off-by: fdurairx <felixx.durairaj@intel.com>
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://review.coreboot.org/12743
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
CB used to clear recovery status towards romstage end after FSP
memory init. Later inside FSP silicon init due to HSIO CRC mismatch
it will request for an additional reset.On next boot system resume
in dev mode rather than recovery because lost its original state
due to FSP silicon init reset.
Hence an additional 1 reset require to identify original state.
With this patch, we will get future platform reset info during romstage
and restore back recovery request flag so, in next boot CB can maintain
its original status and avoid 1 extra reboot.
BUG=chrome-os-partner:43517
BRANCH=none
TEST= build and booted Kunimitsu and tested RO mode
Change-Id: Ibf86ff2b140cd9ad259eb39987d78177535cd975
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 40ddc21a97b318510116b7d5c4314380778a40f7
Original-Change-Id: Ia52835f87ef580317e91931aee5dd0119dea8111
Original-Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/302257
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12975
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This corresponds with the changes that have already gone into the
soc/intel/skylake chip.h file and is needed to get skylake platforms
building again.
Change-Id: I15bfee4eff50d6632659953ec8f97a39d8810db3
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13022
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
I think this has a fairly low likelyhood of happening, but if AGESA
can't determine the voltage of the memory, it assignes a value of 255
to the variable that it later uses to read from an 3-value array. There
is an assert, but that doesn't halt AGESA, so it would use some random
value. If the voltage can't be determined, fall back to 1.5v as the
default value.
Fixes coverity warning 1294803 - Out-of-bounds read
Change-Id: Ib9e568175edbdf55a7a4c35055da7169ea7f2ede
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12855
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I7576591b42fa62da2b3bd74f961fb297b85e250d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/4806
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
This has been broken out from http://review.coreboot.org/#/c/10581/
Change-Id: Ia6153115ff75e21657fa8c244c9eb993d0d63772
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://review.coreboot.org/11025
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Provide a common routine to hash the contents of a cbfs
region. The cbfs region is hashed in the following order:
1. potential cbfs header at offset 0
2. potential cbfs header retlative offset at cbfs size - 4
3. For each file the metadata of the file.
4. For each non-empty file the data of the file.
BUG=chrome-os-partner:48412
BUG=chromium:445938
BRANCH=None
TEST=Utilized in chromeos cros_bundle_firmware as well as at
runtime during vboot verification on glados.
Change-Id: Ie1e5db5b8a80d9465e88d3f69f5367d887bdf73f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12786
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This file became obsolete when FMAP code moved to src/lib/ and is no
longer built by any Makefile. Let's remove it to avoid confusing people.
Change-Id: I55639af28f9f3d4c4cb0429b805e3f120ecc374e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/12753
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Now that only CBFS access is supported for finding resources
within the boot media the assets infrastructure can be removed.
Remove it.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12690
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Chrome OS verified boot path supported multiple CBFS
instances in the boot media as well as stand-alone assets
sitting in each vboot RW slot. Remove the support for the
stand-alone assets and always use CBFS accesses as the
way to retrieve data.
This is implemented by adding a cbfs_locator object which
is queried for locating the current CBFS. Additionally, it
is also signalled prior to when a program is about to be
loaded by coreboot for the subsequent stage/payload. This
provides the same opportunity as previous for vboot to
hook in and perform its logic.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
CQ-DEPEND=CL:307121,CL:31691,CL:31690
Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12689
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
