summaryrefslogtreecommitdiff
path: root/src/vendorcode/google
AgeCommit message (Collapse)Author
2016-07-27Rename VB_SOURCE to VBOOT_SOURCE for increased clarityPaul Kocialkowski
This renames the VB_SOURCE variable to VBOOT_SOURCE in the build system, providing increased clarity about what it represents. Since the submodule itself is called "vboot", it makes sense to use that name in full instead of a very shortened (and confusing) version of it. Change-Id: Ib343b6642363665ec1205134832498a59b7c4a26 Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-on: https://review.coreboot.org/15824 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-07-25google/chromeos: Add support for saving recovery reason across rebootFurquan Shaikh
On some x86 platforms (skylake, apollolake), we observe reboots at different steps during the FSP initialization. These additional reboots result in loss of recovery request because vboot_reference library clears recovery request on vbnv once verification is complete and it has made a decision about which boot path to take(normal/dev, slot-a/slot-b, recovery). Provide a way to allow mainboards/chipsets to inform recovery module in vboot2 to save recovery reason to survive unexpected reboots. The recovery reason is set in vbnv after vboot_reference library completes its verification and clears the reason in vbnv while jumping to payload. BUG=chrome-os-partner:55431 Change-Id: Ie96be9aeb42c8209d8215943409e6327d6a8bf98 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/15802 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-07-25google/chromeos: Add recovery module in vboot2Furquan Shaikh
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)
2016-07-25vboot: Clean up vboot codeFurquan Shaikh
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)
2016-07-15chromeos: Fill in the firmware id (RO, RW A, RW B) FMAP sectionsPaul Kocialkowski
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>
2016-07-14tpm2: implement locking firmware rollback counterVadim Bendebury
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>
2016-07-13tpm2: add tlcl_force_clear and use it before factory initVadim Bendebury
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>
2016-07-13tpm2: use pcr0 dependent nvram space policy definitionsVadim Bendebury
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>
2016-07-12vboot2: tpm2 factory initialization.Vadim Bendebury
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>
2016-06-30vbnv: Do not initialize vbnv_copy in vbnv layerFurquan Shaikh
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>
2016-06-29vbnv: Do not silently reset cache in read_vbnvFurquan Shaikh
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>
2016-06-23kconfig: allow various tpm type and interface permutationsVadim Bendebury
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>
2016-06-12Kconfig: Set VBOOT_OPROM_MATTERS for relevant non-x86 devicesJulius Werner
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>
2016-05-25vendorcode/google/chromeos/vboot2: use cbmem for postcar region selectionAaron Durbin
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>
2016-05-24vendorcode/chromeos/vbnv: Add CMOS init functionJagadish Krishnamoorthy
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>
2016-05-16vboot: Call verification_should_run directly in the if statementPaul Kocialkowski
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)
2016-05-09xip: Do not pass --xip for early stages if CAR supports code executionFurquan Shaikh
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>
2016-05-03chromeos: Ensure that the last file in FW_MAIN is not also the first onePaul Kocialkowski
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>
2016-04-20vboot: Compile loader in postcar as wellAndrey Petrov
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>
2016-04-05chromeos: Fix adding a bmpblk to GBBPatrick Georgi
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>
2016-04-05chromeos: Add enable-serial GBB flagPatrick Georgi
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>
2016-04-05google/oak: Log hardware watchdog in eventlogJulius Werner
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>
2016-03-29vboot: Handle S3 resume path for TPM initializationDuncan Laurie
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>
2016-03-08Chromeos: Modify wifi_regulatory_domain to use "region" key in VPDHuang, Huki
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>
2016-02-29vboot: Set S3_RESUME flag for vboot context if necessaryDuncan Laurie
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>
2016-02-22cbfs: Add LZ4 in-place decompression support for pre-RAM stagesJulius Werner
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>
2016-02-10chromeos/Kconfig: Remove dependency on GBB_HAVE_BMPFVMartin Roth
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)
2016-02-10google/chromeos: backup -> back upPatrick Georgi
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>
2016-02-09vboot2: Store depthcharge graphic assets only in ROPatrick Georgi
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>
2016-02-09chromeos: Add option to back up VBNV CMOS into flashDuncan Laurie
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>
2016-02-09google/chromeos/vboot2: defer clearing rec mode switchAaron Durbin
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>
2016-02-09chromeos: Make vbnv_flash driver safe for CAR usageDuncan Laurie
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>
2016-02-09chromeos: Remove CONFIG_VBNV_SIZE variableDuncan Laurie
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>
2016-02-09chromeos: Add vbnv wrapper for the different backendsDuncan Laurie
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>
2016-02-04google/chromeos/vboot2: honor boot region device sizeAaron Durbin
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>
2016-02-04google/chromeos: guard cbmem_find() in verstage and bootblockAaron Durbin
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>
2016-02-04chromeos/vboot: allow platform to hook into vboot_reboot()Aaron Durbin
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>
2016-02-04chromeos/vboot: provide support for x86 memory init verificationAaron Durbin
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>
2016-02-03chromeos: Sign FW_MAIN_A and FW_MAIN_BPatrick Georgi
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)
2016-02-03chromeos: Add Kconfig options for GBB flagsPatrick Georgi
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>
2016-02-03chromeos: Create GBB at build timePatrick Georgi
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>
2016-01-28src/: give scripts a .sh extension for easy identificationMartin Roth
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>
2016-01-27chromeos: vpd: Avoid reading uninitialized VPDsJulius Werner
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>
2016-01-27chromeos: Add timestamps to measure VPD read timesJulius Werner
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>
2016-01-22vboot2: Handle slow EC SW sync and graphics driver loadingDuncan Laurie
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>
2016-01-21vboot: Install files into FW_MAIN_A and FW_MAIN_B unless they're for ROPatrick Georgi
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>
2016-01-21Chromeos: Implement wifi_regulatory_domain using "regions" key in VPDFelix Durairaj
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>
2016-01-17intel/skylake: During RO mode after FSP reset CB lose original stateSubrata Banik
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>
2016-01-06commonlib: Add function to hash contents of a CBFS region.Aaron Durbin
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)
2015-12-17vendorcode: google: chromeos: Remove old fmap.c fileJulius Werner
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)
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-16 12:51:32 +0000