ChromeOS/vboot devices expect the TPM PCRs 0 and 1 to be extended with
digests that attest the chosen boot mode (developer/recovery) and the
HWID in a secure way. This patch uses the newly added vboot2 support
functions to fetch these digests and store them in the TPM.
CQ-DEPEND=CL:245530
BRANCH=veyron
BUG=chromium:451609
TEST=Booted Jerry. Confirmed that PCR0 contains the same value as on my
vboot1 Blaze and Falco (and PCR1 contains some non-zero hash).
Change-Id: I7037b8198c09fccee5440c4c85f0821166784cec
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245119
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 8b44e13098cb7493091f2ce6c4ab423f2cbf0177)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245496
sd->fw_version represents the version of the *current* firmware, which
is not necessarily the same as the one stored in the TPM (and may be 0
in recovery mode). Use the newly added sd->fw_version_secdata instead
which contains a more correct value.
CQ-DEPEND=CL:245531
BRANCH=veyron
BUG=chrome-os-partner:35941
TEST=Booted Jerry in recovery mode, confirmed crossystem tpm_fwver was
corrent (and not 0).
Change-Id: Id95bd8c6412f2e8b2ae643c3b5a3dee13d0d47be
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244591
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit eb8142f69cea34e11f9081caafcaae7a15cc3801)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245495
Our <arch/io.h> headers are a mess and not in any way as
arch-independent as their pathname makes it sound. CL:242404 made this
blow up, but it's really just surprising that this didn't happen
earlier already.
This patch is just a quick fix to make MIPS ChromeOS boards buildable
again while we deal with the real issue of aligning the interfaces.
BRANCH=none
BUG=chromium:451270,chromium:451388
TEST=Booted Jerry, built Falco and Urara.
Change-Id: I509c842d3393bd810e89ebdf0dc745275c120c1d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242504
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit c919c72ddc9d2e1e18858c0bf49c0ce79f2bc506)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243127
Many ChromeOS devices use a GPIO to reset the system, in order to
guarantee that the TPM cannot be reset without also resetting the CPU.
Often chipset/SoC hardware watchdogs trigger some kind of built-in
CPU reset, bypassing this GPIO and thus leaving the TPM locked. These
ChromeOS devices need to detect that condition in their bootblock and
trigger a second (proper) reboot.
This patch adds some code to generalize this previously
mainboard-specific functionality and uses it on Veyron boards. It also
provides some code to add the proper eventlog entry for a watchdog
reset. Since the second reboot has to happen before firmware
verification and the eventlog is usually only initialized afterwards, we
provide the functionality to place a tombstone in a memlayout-defined
location (which could be SRAM or some MMIO register that is preserved
across reboots).
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Run 'mem w 0xff800000 0x9' on a Jerry, watch how a "Hardware
watchdog reset" event appears in the eventlog after the reboot.
Change-Id: I7ee1d02676e9159794d29e033d71c09fdf4620fd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242404
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit fffc484bb89f5129d62739dcb44d08d7f5b30b33)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243123
Turns out there are uses for memlayout regions not specific to vboot2.
Rather than add yet another set of headers for a single region, let's
make the vboot2 one common for chromeos.
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Booted Jerry, compiled Blaze, Cosmos, Ryu and Storm.
Change-Id: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242630
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243122
The first platform that used flash-backed VBNV data has a physical
recovery switch, get_recovery_mode_from_vbnv() was never implemented.
This patch adds get_recovery_mode_from_vbnv() similarly to how it's
implemented for other vbnv storage in other places.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=needs testing
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9cf18c988eaa4b7e720d6c66a02b1c5c63b473e9
Reviewed-on: https://chromium-review.googlesource.com/239978
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 09f1bf96089bf9d159e4220c1f4d99388d709545)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243120
I always had that TODO comment in there but I had already forgotten what
I even meant by it. It's really just a simple cleanup... this function
is (currently) veyron-specific and doesn't belong in common code.
BRANCH=veyron
BUG=None
TEST=Booted Jerry.
Change-Id: I6ce701a15a6542a615d3d81f70aa71662567d4fa
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241190
(cherry picked from commit d188398704575ad2fedc2a715e609521da2332b0)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243098
Even though coreboot always hardcodes the FMAP offset, the same is not
possible for all other tools that manipulate ROM images. Some need to
manually find the FMAP by searching for it's magic number (ASCII
"__FMAP__"). If we do something like 'memcmp(fmap_buffer, "__FMAP__",
...) in coreboot code, it has the unfortunate side effect that the
compiler will output that very same magic number as a constant in the
.rodata section to compare against. Other tools may mistake this for the
"real" FMAP location and get confused.
This patch reverses the constant defined in coreboot and changes the
only use of it correspondingly. It is not impossible but extremely
unlikely (at the current state of the art) that any compiler would be
clever enough to understand this pattern and optimize it back to a
straight memcmp() (GCC 4.9 definitely doesn't), so it should solve the
problem at least for another few years/decades.
BRANCH=veyron
BUG=chromium:447051
TEST=Made sure the new binaries actually contain "__PAMF__" in their
.rodata. Booted Pinky. Independently corrupted both the first and the
last byte of the FMAP signature with a hex editor and confirmed that
signature check fails in both cases.
Change-Id: I725652ef2a77f7f99884b46498428c3d68cd0945
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240723
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242157
The current vbnv flash code mistakenly uses the offset into the NVRAM
area as the absolute offset into the SPI NOR. This causes overwrites
RO section of the flash (when it is not protected) and causes failures
to retrieve the NVRAM contents by the user space apps.
This patch makes sure that the correct offset is used when accessing
NVRAM area in the SPI flash.
BRANCH=storm
BUG=chrome-os-partner:35316
TEST=run the update code on storm.
- no more RO section corruption observed
- running 'crossystem recovery_request=1' at Linux prompt causes the
next boot happen in recovery mode
Change-Id: I86fe4b9a35f7c16b72abf49cfbfcd42cc87937e3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240143
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242152
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Some common VBNV variable offsets were defined in multiple vbnv_*
source files. This moves them to a header so that we can avoid
duplicating them in the future.
BUG=none
BRANCH=none
TEST=compiled for nyan_blaze and rambi
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ifcc13c90a910b86d4f9bb0027d913572c1d6d00b
Reviewed-on: https://chromium-review.googlesource.com/239977
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242151
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
This patch aligns our verstage code to the new API addition in vboot2.
The hardware crypto functions are stubbed out by default and just
pretend that all algorithms are unsupported, causing vboot to fall back
to the normal software hashing code. These weak symbols can be
overridden by individual platform code to provide actual hardware
crypto engine support.
CQ-DEPEND=CL:242124
BRANCH=None
BUG=chrome-os-partner:32987
TEST=Booted Pinky, confirmed vboot falls back to software crypto.
Change-Id: Idf6a38febd163aa2bff6e9a0e207213f01ca8324
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236435
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242138
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 512K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236978
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242137
this change makes vb2_working_data struct point to the vboot work buffer by
the offset instead of by the absolute address, which can be different
depending on the context (e.g. subprocessor v.s. main cpu).
BUG=none
BRANCH=tot
TEST=booted veyron pinky
Change-Id: I4e4c12613304586b7395c5173cf08b8093f59521
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236583
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 93f8b1da2b2c81aa3a33892987a71e9e1e7a8eff)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237027
Reviewed-by: David Hendricks <dhendrix@chromium.org>
this allows each board to decide what to do after firmware verification is
done. some board needs to return back to the previous stage and let the
previous stage kick off the verified stage.
this also makes it more visible what is going to happen in the verstage since
stage_exit now resides in main().
BUG=none
BRANCH=tot
TEST=booted cosmos dev board. booted blaze in normal and recovery mode.
built for all current boards.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I3cb466cedf2a9c2b0d48fc4b0f73f76d0714c0c7
Reviewed-on: https://chromium-review.googlesource.com/232517
Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234063
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Before the change to use vb2_api.h, coreboot needed to know where to
find the vboot2 header files. Now those are all included by
vb2_api.h, so coreboot doesn't need to know about
firmware/2lib/include (and in fact, the 2lib directory is about to go
away).
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
Change-Id: I7f69ca9cf8d45c325219efceca0cb8d1340f7736
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233223
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This will allow vboot2 to continue refactoring without breaking
coreboot, since there's now only a single file which needs to stay in
sync.
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
CQ-DEPEND=CL:233050
Change-Id: I74cae5f0badfb2d795eb5420354b9e6d0b4710f7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233051
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Since we can now reduce our vboot2 work buffer by 4K, we can use all
that hard-earned space for the CBMEM console instead (and 4K are
unfortunately barely enough for all the stuff we dump with vboot2).
Also add console_init() and exception_init() to the verstage for
CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model
requires those functions to be called again at the beginning of every
stage... even though some consoles like UARTs might not need it, others
like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is
expected to be done by the platform-specific verstage entry wrapper, and
already in place for the only implementation we have for now (tegra124).
(Technically, there is still a bug in the case where EARLY_CONSOLE is
set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would
run init_console_ptr() as if they were there first, so the romstage
overwrites the verstage's output. I don't think it's worth fixing that
now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless
use-case and I think we should probably just get rid of the
CONFIG_BOOTBLOCK_CONSOLE option eventually.)
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232614
Apparently our initial submission of 16K was a little too generous for
the vboot2 work buffer, and I hear that we should also be well within
bounds for 12K. This patch reduces the minimum asserted by memlayout so
some of our low-mem boards can get a few more kilobytes back for
discretionary spending. Also changes the required minimum alignment to 8
since that's what the current vboot code aligns it to anyway, and add a
warning comment to make it clearer that this is a dangerous number
people should not be playing with lightly.
BRANCH=None
BUG=None
TEST=Built and booted on Pinky.
Change-Id: Iae9c74050500a315c90f5d5517427d755ac1dfea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232613
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some projects (like ChromeOS) put more content than described by CBFS
onto their image. For top-aligned images (read: x86), this has
traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the
area actually managed by CBFS, as opposed to ROM_SIZE) that is used to
calculate the CBFS entry start offset. On bottom-aligned boards, many
define a fake (smaller) ROM_SIZE for only the CBFS part, which is not
consistently done and can be an issue because ROM_SIZE is expected to be
a power of two.
This patch changes all non-x86 boards to describe their actual
(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a
mainboard Kconfig select (which is the correct place to declare
unchangeable physical properties of the board). It also changes the
cbfstool create invocation to use CBFS_SIZE as the -s parameter for
those architectures, which defaults to ROM_SIZE but gets overridden for
special use cases like ChromeOS. This has the advantage that cbfstool
has a consistent idea of where the area it is responsible for ends,
which offers better bounds-checking and is needed for a subsequent fix.
Also change the FMAP offset to default to right behind the (now
consistently known) CBFS region for non-x86 boards, which has emerged as
a de-facto standard on those architectures and allows us to reduce the
amount of custom configuration. In the future, the nightmare that is
ChromeOS's image build system could be redesigned to enforce this
automatically, and also confirm that it doesn't overwrite any space used
by CBFS (which is now consistently defined as the file size of
coreboot.rom on non-x86).
CQ-DEPEND=CL:231576,CL:231475
BRANCH=None
BUG=chromium:422501
TEST=Built and booted on Veyron_Pinky.
Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229974
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
fmap_find used to read 4096 bytes from the fmap offset blindly. instead, we read
the fmap header first to calcurate the size of the fmap. Then, we read flash
again exactly as much as the discovered fmap.
BUG=none
BRANCH=ToT
TEST=Booted Storm and Peppy. Built all current boards.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Ie5058d181e6565acb70bf108464682dd0e6c1f64
Reviewed-on: https://chromium-review.googlesource.com/231685
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This sets the new VB_INIT_FLAG_BEFORE_OPROM_LOAD flag for VbInit()
to indicate that we are running from early firmware before option
rom loading has occurred so it can do the right thing when it
checks whether or not to tell the system to reboot after setting
the VbNv flag.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=pass FAFT tests on samus
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I6968fcb6cda74e88f56bea6ea9bbf77cc795b8d6
Reviewed-on: https://chromium-review.googlesource.com/230887
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add the common header files for FSP 1.1. The are provided in an
EDK2 style tree to allow direct comparison with the EDK2 tree.
BRANCH=none
BUG=None
TEST=Build with FSP
Change-Id: I6f7316c8a31ec75d3593c950fe227a776a3e18a5
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/229618
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add the common header files for EDK2. These files come from the
open source EDK2 tree https://svn.code.sf.net/p/edk2/code/trunk/edk2
revision 16227. The are provided in an EDK2 style tree to allow
direct comparison with the EDK2 tree.
The following files were modified to remove trailing spaces and add
some #ifndef/#endif conditionals:
* MdePkg/Include/Base.h
* MdePkg/Include/Ia32/ProcessorBind.h
* MdePkg/Include/Uefi/UefiBaseType.h
* MdePkg/Include/X64/ProcessorBind.h
A patch for the files above has been submitted to
edk2-devel@lists.sourceforge.net for inclusion into a future revision
of EDK2's MdePkg.
Note: All the files below were modified to use Linux line termination.
BRANCH=none
BUG=None
TEST=Build with FSP
Change-Id: Icaeb0cde301c7d555e5d55a95932efc1bc315d40
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/229617
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
PHYSICAL_REC_SWITCH is set n by default and y for panther and stumpy.
BUG=none
BRANCH=ToT
TEST=Built nyan_blaze using vboot1/2. Built falco, lumpy, nyan,
blaze, parrot, rambi, samus, storm, pinky with default configuration.
panther and stumpy are not tested because they currently don't build on ToT.
Change-Id: Ic45f78708aaa7e485d2ab459fd1948524edb412f
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227940
Reviewed-on: https://chromium-review.googlesource.com/229602
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This changes copies firmware version from vboot2 shared data to vboot1
shared data. This fixes FAFT firmware_TPMVersionCheck test.
BUG=none
BRANCH=ToT
TEST=firmware_TPMVersionCheck passed on Nyan Kitty.
Change-Id: Idfd282931421dc16cd1aa82c7ccb6c6790a4d0d7
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/230186
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Yen Lin <yelin@nvidia.com>
spi_flash->write returns non-zero on error and zero on success, not the
number of bytes written.
BUG=none
BRANCH=ToT
TEST=Booted storm. Verified successfully nvdata was saved.
Change-Id: If50cc1a62a4f06398d1830cca60085b6f925fff3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229389
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:33395
BRANCH=none
TEST=emerge and test using crossystem
Change-Id: I0d49f85219d45c837a7100e0195bef86da2c6cdd
Signed-off-by: Gediminas Ramanauskas <gedis@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227546
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
this adds a driver for vboot to read and write nvdata in spi flash.
it's assumed that flash contents are erased to 1-bits and write
operations can only change 1-bits to 0-bits.
when all nvram space is used, the driver will erase the whole block
and start the next write from the beginning.
BUG=chrome-os-partner:32774
BRANCH=ToT
TEST=Built for cosmos.
Change-Id: Ia9049f342b21fa4c289cb7b9254ab89ec1ef1699
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226525
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The architectiure check in fmap.c is in fact used to delineate between
platforms where SPI flash is mapped to memory address space and where
it needs to be accessed through CBFS.
In fact cosmos board uses an ARM SOC which also maps SPI flash to
processor address space, this will have to be addressed when that
SOC's support is introduced, for now let's just presume that all but
X86 platforms require CBFS layer to access fmap.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Change-Id: Id135dc63278555a7fc5039a568fb28864f7cb8d1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226180
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds functions looking in the VPD for WiFi calibration
data, and if found, copying the calibration blobs into CBMEM.
Two possible key names templates are used: wifi_base64_calibrationX
and wifi_calibrationX, where X is replaced by the WiFi interface
number. Up to four interfaces can be provisioned.
The calibration data will be retrieved from CBMEM by the bootloader
and placed into the device tree before starting the kernel.
The structure of the WiFi calibration data CBMEM entry is defined
locally: it is a concatenation of the blob names and their contents.
Each blob is padded as necessary to make sure that the size divisible
by four.
To make sure that the exactly required amount of memory is allocated
for the CBMEM entry, the function first scans the VPD, caching the
information about the available blobs and calculating their combined
size.
Then the required size CBMEM entry is allocates and the blobs are
copied into it.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=when this function is called, and the VPD includes calibration
data blobs, the WIFI entry shows up in the list of CBMEM entries
reported by coreboot.
Change-Id: Ibe02dc36ff6254e3b9ad0a5bd2696ca29e1b2be3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225271
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The new API allows to find VPD objects in the VPD cache. There is no
need for the caller to allocate or free the per object memory.
The existing API (cros_vpd_gets) now uses the new function as well.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=verified that MAC addresses still show up in the device tree on
the booted storm device
Change-Id: I6c0b11bb844d6235930124d642da632319142d88
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225258
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Retrieval of the MAC address from the VPD is a Chrome OS specific
feature, required just on one platform so far. There is no need to
look for the MAC address in the VPD on all other Chrome OS boards.
BRANCH=storm
BUG=chromium:417117
TEST=with the upcoming patch applied verified that MAC addresses still
show up in the device tree on storm
Change-Id: I8e6f8dc38294d3ab11965931be575360fd12b2fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223796
Reviewed-by: Julius Werner <jwerner@chromium.org>
In order to display a "update in progress" screen on devices with
a slow EC or PD chip it may be necessary to also load the VGA
Option ROM when doing EC software sync.
This adds config options for VBOOT_EC_SLOW_UPDATE which simply sets
a flag in the input parameters that is already handled by vboot.
It also adds a config option for VBOOT_OPROM_MATTERS which is a bit
more tricky in that it sets a flag in input parameters, but also
needs to keep track of the option rom being loaded and pass that
flag into VbInit as well.
Since VbInit will clear the NV bit for option rom loaded the check
that is done in vboot_wants_oprom() needs to first compare against
the vboot handoff copy of the input flags.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Change-Id: Ic2b34bf9e7c6cc5498413fa1b8dff6e6207c9d0a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223831
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If you try to boot a VBOOT2_VERIFY_FIRMWARE with less than 4K CBFS cache
right now, your system will try and fail to validate the FMAP signature
at (u8 *)0xFFFFFFFF and go into recovery mode. This patch avoids the
memcmp() to potentially invalid memory, and also adds an error message
to cbfs_simple_buffer_map() to make it explicit that we ran out of CBFS
cache space.
BUG=None
TEST=Booted on Veyron_Pinky with reduced CBFS cache, saw the message.
Change-Id: Ic5773b4e0b36dc621513f58fc9bd29c17afbf1b7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222899
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
this adds a flash vbnv driver for vboot to store non-volatile data in a flash
storage.
BUG=chrome-os-partner:32774
BRANCH=none
TEST=Built samus, veyron pinky, and cosmos
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: If5fc1b779722528134ad283fa030f150b3bab55f
Reviewed-on: https://chromium-review.googlesource.com/222258
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Turns out making the compilation of every single source file depend on
the auto-generated build.h in CL:219170 wasn't really such a great idea
for incremental builds. Who would've thought.
However, it's still undesirable that individual Makefiles for sources
that actually include build.h need to add that dependency manually.
Therefore, this patch fixes the issue by using $(generic-deps) as an
order-only prerequisites in rules. This kind of prerequisite is still
made before the target if it doesn't exist, but it is not automatically
updated based on the timestamp. Also removed some additional manual
build.h dependencies that I must somehow overlooked in the old patch.
The files that actually include build.h still get it as a normal
prerequisite through the automatic dependency rule in <filename>.d that
is created by GCC's -MMD option. $(generic-deps) only solves the
chicken-and-egg problem of where build.h comes from in fresh/cleaned
build directories that don't have any .d dependency files yet.
BUG=chrome-os-partner:32622
TEST=Manually did an incremental build with a single changed file.
Confirmed that actual build.h dependencies (id.bootblock.o, console.*.o)
were still remade, but not all other coreboot sources.
Change-Id: I5a830aae6b17dd7d4061a577fd2410b678d6f1f0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221470
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213370
This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get
predefined in their respective stages by make, so that we have one
specific macro for every stage. It also renames __BOOT_BLOCK__ and
__VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency.
This change is intended to provided finer control and clearer
communication of intent after we added a new (optional) stage that falls
under __PRE_RAM__, and will hopefully provide some robustness for the
future (we don't want to end up always checking for romstage with #if
defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) &&
!defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The
__PRE_RAM__ macro stays as it is since many features do in fact need to
differentiate on whether RAM is available. (Some also depend on whether
RAM is available at the end of a stage, in which case #if
!defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be
authoritative.)
It's unfeasable to change all existing occurences of __PRE_RAM__ that
would be better described with __ROMSTAGE__, so this patch only
demonstratively changes a few obvious ones in core code.
BUG=None
TEST=None (tested together with dependent patch).
Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219172
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch started out as an attempt to run linker scripts through the
preprocessor. However, since that required some more infrastructure
changes, the build system is so intertwined, and there are so many other
small issues that turned up and are easier to fix (and get running, and
test thoroughly) in a single go, it turned out a little bigger. In order
of appearance, it:
- wraps direct linker invocations in a macro to avoid the widespread
ifeq($(CONFIG_COMPILER_LLVM_CLANG),y) duplication.
- introduces an $(generic-deps) (equivalent to $(<class>-deps)) variable
for targets that all files depend on
- makes the $(src-to-obj) function usable in multiple places as the
authoritative way to get an output file name (even if the respective
source file is also under build/), and makes it preserve extensions on
everything except %.c and %.S (e.g. %.ld and %.asl)
- replaces the old $(<class>-postprocess) with a single
$(postprocessors) variable. The old ramstage-postprocess was weird
because it contained unescaped $(eval ...)s, meaning it gets executed
as soon as the variable is first substituted (and the other
$(eval ...) in the toplevel Makefile does essentially nothing). The
new mechanism is just $(eval ...)ed directly after the recursive parse
with no further magic. Files can freely append their own (escaped)
content to it and access variables valid in the calling context (like
$(<class>-objs)) directly.
- enhances the existing $(<class>-<type>-ccopts) mechanism with
$(<class>-generic-ccopts) and $(generic-<type>-ccopts) to reduce
duplication.
- makes .ld a type that can be added like a normal class file, causing
it to be preprocessed with the correct #defines for the current class
(needed for a follow-up feature). Migrates all linker scripts to this
mechanism, which allows us to get rid of the weird $(ldoptions)
mechanism (Kconfigs are replaced by preprocessor and no longer need to
be defined as symbols).
- removes duplicate $(INCLUDES) from $(CFLAGS)
- repairs the crazy state of MIPS Makefiles, which seem to have been
copied together from X86 despite having absolutely nothing in common
with that architecture. They were using the same code to paste
assembly pieces and linker scripts together without really needing it
for anything, and even accidentally relied on a Kconfig default set
in the arch/x86 subdirectory (I wish I was kidding). Changed them to
work equivalent to the arm/arm64 Makefiles which are far closer
related (also being SRAM-based platforms).
- moves the x86-specifc $(OPTION_TABLES_H) into the x86 Makefile.inc and
fixes an rule that would've had an empty target if it wasn't defined
- removes the custom ldscript-gathering variables for x86 bootblock and
romstage. The Makefile simply combines all .ld files that have been
added to the respective class now.
- uses the normal class build system to replace some of the custom rules
for autogenerated bootblock/crt0 files on x86, and removes some
hardcoded flags by using the normal $(...-ccopts) variables.
- moves the handling of .asl files from the global Makefile.inc to x86.
Changed to reuse the generic template for the preprocessing and C
compilation steps.
- removed the extra <name>.o linking step before linking an rmodule for
modules that don't require special linker flags (most of them).
- removes the incorrect assumption that there was a global $(LDFLAGS)
from the SMM Makefile.inc (it was named $(LDFLAGFS in one place so it
couldn't have been all that important ;) ).
- allow -j flag for parallel builds to be properly passed through to
vboot child invocation by using special $(MAKE) variable.
BUG=None
TEST=Built for Falco, Nyan_Blaze, Stout, Rush_Ryu and Urara. Binary
diffed old and new coreboot.rom (and some manually uncompressed stages),
confirmed that images/stages are byte-for-byte identical except for some
embedded timestamps and commit hashes. (Addresses in Falco/Stout
ramstages shifting slightly due to different link order for ASL object
files within their directory. Some addresses in Urara ramstage .rodata
and some relocation entries in rmodules moved around due to linking them
in fewer steps.)
Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
this change makes coreboot initialize kernel space and backup space in the tpm
when no firmware space is found in the tpm.
BUG=chrome-os-partner:32410
TEST=Forced factory initialization and verified it went through without errors.
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I777e3cb7004870c769163827543c83665d3732b9
Reviewed-on: https://chromium-review.googlesource.com/220412
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
this change makes prevent execution from falling through to unverified
code when hard_reset is not implemented. it also includes a few touch-ups.
BUG=None
TEST=Booted Veyron Pinky. Verified firmware selection in the log.
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I9b02ab766172a62c98b434c29f310bc4a44f342d
Reviewed-on: https://chromium-review.googlesource.com/219625
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
this allows vb2_working_data to be accessed from stages running on different cpu
architectures.
BUG=none
TEST=Built firmware for Blaze with USE=+/-vboot2. Ran faft on Blaze.
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Ife2844637af8bf9e0d032a50fb516d98b8f80497
Reviewed-on: https://chromium-review.googlesource.com/217835
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
With CONFIG_RETURN_FROM_VERSTAGE false, the verstage loads the romstage over
the bootblock, then exits to the romstage. this is necessary for some SOC
(e.g. tegra124) which runs the bootblock on a different architecture.
With CONFIG_RETURN_FROM_VERSTAGE true, the verstage returns to the bootblock.
Then, the bootblock loads the romstage over the verstage and exits to the
romstage. this is probably necessary for some SOC (e.g. rockchip) which does not
have SRAM big enough to fit the verstage and the romstage at the same time.
BUG=none
TEST=Built Blaze with USE=+/-vboot2. Ran faft on Blaze.
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I673945c5e21afc800d523fbb25d49fdc83693544
Reviewed-on: https://chromium-review.googlesource.com/212365
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
