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>
BUG=chrome-os-partner:29778
TEST=Build coreboot
Change-Id: I805d93e94f73418099f47d235ca920a91b4b2bfb
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/209469
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
this change reduces the code duplication of the bootblock and the romstages for
Nyans.
BUG=none
TEST=Built Nyan, Big, and Blaze. Ran faft on Blaze.
BRANCH=none
Signed-off-by: dnojiri@chromium.org (Daisuke Nojiri)
Change-Id: Ieb9dac3b061a2cf46c63afb2f31eb67ab391ea1a
Reviewed-on: https://chromium-review.googlesource.com/214050
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
This introduces a new kconfig variable to select the VBNV backing
store explicitly instead of inferring it from CPU/SoC architecture.
x86 platforms have historically relied only on CMOS to store VBNV
variables, while ARM-based platforms have traditionally relied on
the EC. Neither of those solutions are going to scale well into
the future if/when CMOS disappears and we make ARM-based systems
without an EC.
BUG=chrome-os-partner:29546
BRANCH=none
TEST=compiled for nyan_blaze and samus
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I4a8dadfb6bb666baf1ed4bec98b29c145dc4a1e7
Reviewed-on: https://chromium-review.googlesource.com/213877
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Vim picked up a missing newline at the end of the last line.
BUG=none
BRANCH=none
TEST=compilation didn't break for nyan_blaze and samus
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ifa859073b866fad859391e54a6ab0a6f258b5b38
Reviewed-on: https://chromium-review.googlesource.com/213876
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
The existing cpu_reset does board-wide reset, thus, should be renamed.
BUG=none
BRANCH=none
TEST=Built firmware for Nyans. Ran faft on Blaze.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I5dc4fa9bae328001a897a371d4f23632701f1dd9
Reviewed-on: https://chromium-review.googlesource.com/212982
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
During a refactor the stage->load address was being returned as
an entry point. That is only true when the first instruction is
the entry point of the stage. Fix the handling of the load and
entry points.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Building still works. vboot still runs on rush.
Change-Id: I65a93c1c785569190406cd23006ea840c0011936
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211010
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
rmodules ccopts contain information about specific arch like armv4,v7. Hence, it
is important to include them in VBOOT_CFLAGS
BUG=None
BRANCH=None
TEST=Compiles correctly for armv4 in rush
Change-Id: I8f5509f753e28046678c3782d6f0b6210559f798
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209979
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Provide functionality to create dynamic classes based on program name and the
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class and compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.
One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for nyan, rush and link.
Change-Id: I3e3aadbe723d432b9b3500c44bcff578c98f5643
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209379
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
The vboot module previously assumed the CPU running the
verfication would also be the one executing the next
stage of execution. That isn't true for all platforms.
Therefore, provide the ability to load and return the
entry point by way of vboot_verify_firmware_get_entry().
vboot_verify_firmware() still does the same thing as
it previously did -- load and run from the current
execution context.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built for nyan.
Change-Id: Id06c3d382edfe84adb170e7f52c12be58b88bab9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209592
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
The arm architectures have a stage_exit() function
which takes a void * pointer as an entry point. Provide
the same API for x86. This can make the booting paths
less architecture-specific.
BUG=chrome-os-partner:30784
TEST=built for nyan.
Change-Id: I4ecfbf32f38f2e3817381b63e1f97e92654c5f97
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5086
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: https://chromium-review.googlesource.com/209591
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to Coreboot's style.
The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation
the bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.
TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Reviewed-on: https://chromium-review.googlesource.com/206065
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
vboot2 abtracts tpm storage as some 'secure' space. Thus, it's firmware's
responsibility to handle vboot specific operations with tpm. This CL just copies
related files from vboot_reference so that we can see how code was modified in
the next CL. Note rollback_index.c/h were renamed to antirollback.c/h.
TEST=none
BUG=none
Branch=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I1792a622058f70a8fcd3c4037547539ad2870420
Reviewed-on: https://chromium-review.googlesource.com/206462
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Doing reset while VBERROR_TPM_REBOOT_REQUIRED occured.
BUG=chromium:389568
TEST=Manual force VBERROR_TPM_REBOOT_REQUIRED returned from VbInit()
and system will reboot.
Change-Id: I9d7c4b3a380a931a728f792b4013b3b9bf65dfae
Signed-off-by: Kevin Cheng <kevin.cheng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/206337
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 32728dd9fc43a95d6f763a85f9cc7a660a66b175)
Reviewed-on: https://chromium-review.googlesource.com/206948
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
This patch has a basic structure of vboot2 integration. It supports only Nyans,
which have bootblock architecture and romstage architecture are
compatible from linker's perspective.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I4bbd4d0452604943b376bef20ea8a258820810aa
Reviewed-on: https://chromium-review.googlesource.com/204522
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains, compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Reviewed-on: https://chromium-review.googlesource.com/204376
Reviewed-by: Randall Spangler <rspangler@chromium.org>
x86 systems run their romstage as execute-in-place from flash, which
prevents them from having writable data segments. In several code pieces
that get linked into both romstage and ramstage, this has been worked
around by using a local variable and having the 'static' storage class
guarded by #ifndef __PRE_RAM__.
However, x86 is the only architecture using execute-in-place (for now),
so it does not make sense to impose the restriction globally. Rather
than fixing the #ifdef at every occurrence, this should really be
wrapped in a way that makes it easier to modify in a single place. The
chromeos/cros_vpd.c file already had a nice approach for a wrapper
macro, but unfortunately restricted it to one file... this patch moves
it to stddef.h and employs it consistently throughout coreboot.
BRANCH=nyan
BUG=None
TEST=Measured boot time on Nyan_Big before and after, confirmed that it
gained 6ms from caching the FMAP in vboot_loader.c.
Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This adds a generic helper function for adding boot reason in the
ChromeOS case. If vboot is enabled, it will use information passed
in via the vboot handoff table in cbmem to determine mode and
reason in the case of recovery.
BUG=chromium:373467
BRANCH=nyan
TEST=built along with follow-up CL and booted on Big under various
modes, verified entry was added to eventlog with "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I50a7aa6d55eb46413fe9929e732d6eb18c758d4b
Reviewed-on: https://chromium-review.googlesource.com/199690
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
If the kernel does not properly handle the TPM and send it a
TPM_SaveState command before suspend then it will not be in
the correct state on resume. In order to easily detect this
case add a new post code for TPM failure and use it in the
vboot resume path.
BUG=chromium:371105
TEST=Build and boot on wtm2.
Change-Id: I412520b521387a8e18ad1c6f5a64b39cdd5c88ec
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199371
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and
COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these
attributes are associated with each of the stages.
BUG=None
BRANCH=None
TEST=Compiled successfully for all mainboard/google boards. Image booted
successfully on link, rambi and nyan.
Change-Id: I10d36ff950712756fb16dcb4d315924d177846b5
Reviewed-on: https://chromium-review.googlesource.com/195574
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Patch to rename coreboot_ram stage to ramstage. This is done in order to provide
consistency with other stage names(bootblock, romstage) and to allow any
Makefile rule generalization. (Required for patches to be submitted later)
CQ-DEPEND=CL:195101
BUG=None
BRANCH=None
TEST=Compiled successfully for all boards under mainboard/google/. Image booted
successfully on link board
Change-Id: I3e2495fc6a5cc91695ae04ffb438dd4ac265be64
Reviewed-on: https://chromium-review.googlesource.com/195059
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Added the empty function clear_recovery_mode_switch (weak)
Problem:
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC is set,
the following will happen:
1. Boot device in recovery mode with Esc + F3 + Pwr.
2. Turn device off with Pwr button.
3. Turn device on with Pwr button.
Device still boots to recovery screen with
recovery_reason:0x02 recovery button pressed.
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC isn't set,
turning the device off and on again
with the Pwr button does a normal boot.
Solution:
Unconditionally clear the recovery flag.
BUG=chromium:279607
BRANCH=TOT
TEST=Compile OK.
Change-Id: Ie1e3251a6db12e75e385220e9d3791078393b1bf
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197780
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Sheng-liang Song <ssl@google.com>
Tested-by: Sheng-liang Song <ssl@google.com>
Length arguments for VbExTpmSendReceive have type uint32_t but it calls function
which expects size_t. This change converts uint32_t to size_t on call and
size_t to uint32_t on return.
BUG=None
BRANCH=None
TEST=Booted Nyan Big to Linux
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I1971488baae2d060c0cddec7749461c91602a4f9
Reviewed-on: https://chromium-review.googlesource.com/198016
This allows the chromeos header and functions to be included
without needing to guard with #if CONFIG_CHROMEOS.
BUG=chrome-os-partner:28234
BRANCH=None
TEST=emerge-rambi coreboot
Change-Id: I523813dc9521d533242ae2d2bc822eb8b0ffa5e2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196265
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If EFS is enabled and vboot didn't tell us it's going to use the display, we
can skip initializing it and save some boot time.
BUG=chrome-os-partner:27094
TEST=Built and booted on nyan without EFS in recovery mode and normal mode.
Built and booted on nyan with EFS in recovery mode and normal mode. Verified
that in normal mode with EFS the display initialization was skipped and boot
time was essentially the same as when display initialization was simply
commented out.
BRANCH=None
Change-Id: I1e2842b57a38061f40514407c8fab1e38b75be80
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192544
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Depending on the platform the underlying regions vboot requires
may not be accessible through a memory-mapped interface. Allow
for non-memory-mapped regions by providing a region request
abstraction. There is then only a few touch points in the code to
provide compile-time decision making no how to obtain a region.
For the vblocks a temporary area is allocated from cbmem. They
are then read from the SPI into the temporarily buffer.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built and booted a rambi with vboot verification.
Change-Id: I828a7c36387a8eb573c5a0dd020fe9abad03d902
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190924
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
