Fix a few more instances of global variable usage in the tlcl
and marshaling code for tpm2.
For the tlcl case this buffer doesn't need to be static as it
isn't used after this function exits.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16393
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Change-Id: Ia739c81d79c6cee9046ae96061045fe4f7fb7c23
Reviewed-on: https://chromium-review.googlesource.com/382073
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In preparation for making this check optional, move it into its own
function. load_self_segments() is already long and we don't want to make
it longer.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=boot on gru and see that BL31 loads and runs correctly
Change-Id: I005e5e4d9b2136605bdd95e9060655df7a8238cb
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/381092
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current CBMEM code contains an optimization that maintains the
structure with information about the CBMEM backing store in a global
variable, so that we don't have to recover it from cbmem_top() again
every single time we access CBMEM. However, due to the problems with
using globals in x86 romstage, this optimization has only been enabled
in ramstage.
However, all non-x86 platforms are SRAM-based (at least for now) and
can use globals perfectly fine in earlier stages. Therefore, this patch
extends the optimization on those platforms to all stages. This also
allows us to remove the requirement that cbmem_top() needs to return
NULL before its backing store has been initialized from those boards,
since the CBMEM code can now keep track of whether it has been
initialized by itself.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16273
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia6c1db00ae01dee485d5e96e4315cb399dc63696
Reviewed-on: https://chromium-review.googlesource.com/377607
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds functionality to compile a C data structure into a raw
binary file, add it to CBFS and allow coreboot to load it at runtime.
This is useful in all cases where we need to be able to have several
larger data sets available in an image, but will only require a small
subset of them at boot (a classic example would be DRAM parameters) or
only require it in certain boot modes. This allows us to load less data
from flash and increase boot speed compared to solutions that compile
all data sets into a stage.
Each structure has to be defined in a separate .c file which contains no
functions and only a single global variable. The data type must be
serialization safe (composed of only fixed-width types, paying attention
to padding). It must be added to CBFS in a Makefile with the 'struct'
file processor.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16272
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Iab65c0b6ebea235089f741eaa8098743e54d6ccc
Reviewed-on: https://chromium-review.googlesource.com/377606
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The timestamp code asserts that the _timestamp region (allocated in
memlayout for pre-RAM stages) is large enough for the assumptions it
makes. This is good, except that we often initialize timestamps
extremely early in the bootblock, even before console output. Debugging
a BUG() that hits before console_init() is no fun.
This patch adds a link-time assertion for the size of the _timestamp
region in memlayout to prevent people from accidentally running into
this issue.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16270
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Change-Id: Ibe4301fb89c47fde28e883fd11647d6b62a66fb0
Reviewed-on: https://chromium-review.googlesource.com/374461
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Explicitly provide a RW view of an FMAP region. This is required
for platforms which have separate implementations of a RO boot
device and a RW boot device.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16203
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ibafa3dc534f53a3d90487f3190c0f8a2e82858c2
Reviewed-on: https://chromium-review.googlesource.com/373365
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The spi_flash_probe() routine was setting a global varible
unconditonally regardless if the probe was for the boot device
or even if the boot devcie was flash. Moreover, there's no need
to report the SPI information if the boot device isn't even SPI.
Lastly, it's possible that the boot device is a SPI flash, but
the platform may never probe (selecting SPI_FLASH) for the
actual device connected. In that situation don't fill anything
in as no correct information is known.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16197
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib0eba601df4d77bede313c358c92b0536355bbd0
Reviewed-on: https://chromium-review.googlesource.com/373360
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current boot device usage assumes read-only semantics to
the boot device. Any time someone wants to write to the
boot device a device-specific API is invoked such as SPI flash.
Instead, provide a mechanism to retrieve an object that can
be used to perform writes to the boot device. On systems where
the implementations are symmetric these devices can be treated
one-in-the-same. However, for x86 systems with memory mapped SPI
the read-only boot device provides different operations.
BUG=chrome-os-partner:55932
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16194
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I0af324824f9e1a8e897c2453c36e865b59c4e004
Reviewed-on: https://chromium-review.googlesource.com/373238
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The common boot device spi implementation is very much
specific to SPI flash. As such it should be moved into
that subdirectory. It's still a high-level option but
it correctly depends on BOOT_DEVICE_SPI_FLASH. Additionally
that allows the auto-selection of SPI_FLASH by a platform
selecting COMMON_CBFS_SPI_WRAPPER which allows for culling
of SPI_FLASH selections everywhere.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16212
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: Ia2ccfdc9e1a4348cd91b381f9712d8853b7d2a79
Reviewed-on: https://chromium-review.googlesource.com/373036
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16228
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I06f138078c47a1e4b4b3edbdbf662f171e11c9d4
Reviewed-on: https://chromium-review.googlesource.com/373035
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide a default value of 0 in drivers/spi as there weren't
default values aside from specific mainboards and arch/x86.
Remove any default 0 values while noting to keep the option's
default to 0.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16192
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61
Reviewed-on: https://chromium-review.googlesource.com/373029
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
CQ-DEPEND=CL:370717
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16193
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Ibdd7c8754f9bf560a878136b1f55238e2c2549d3
Reviewed-on: https://chromium-review.googlesource.com/370711
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
POSTCAR stage has cbmem online. So, all timestamps need to be added to
cbmem timestamp region.
BUG=chrome-os-partner:55848
BRANCH=None
TEST=Verified that timestamps added in postcar show up in cbmem -t.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/16032
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I64af8c1e67b107d9adb09de57c20ea728981f07c
Reviewed-on: https://chromium-review.googlesource.com/368090
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The build fails during postcar when ULZMA compression is not selected.
Fix cbfs.c to support LZ compression for ramstage as well.
The build error is:
build/postcar/lib/cbfs.o: In function `cbfs_load_and_decompress':
/home/lee/coreboot/public/src/lib/cbfs.c:116: undefined reference to
`ulzman'
make: *** [build/cbfs/fallback/postcar.debug] Error 1
TEST=Build and run on Galileo Gen2
Change-Id: I7fa8ff33c0d32e0c5ff5de7918e13e6efb1df38e
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15841
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363383
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Enable the display of cbmem during romstage and postcar. Add a Kconfig
value to prevent coreboot images from increasing in size when this
feature is not in use.
TEST=Build and run on Galileo Gen2
Change-Id: Ib70ad517ebf7d37a7f46ba503b4432c7c04d7ded
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15842
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363381
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
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
BRANCH=None
TEST=None
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)
Change-Id: I4c07d50327d88cddbdfbb0b6f82c264e2b8620eb
Reviewed-on: https://chromium-review.googlesource.com/362971
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The tpm2_marshal_command() function returns a negative value on error,
so we must use a signed type for the return value.
This was found by the coverity scan:
https://scan.coverity.com/projects/coreboot?tab=overview
CID:1357675
CID:1357676
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Found-by: Coverity Scan
Reviewed-on: https://review.coreboot.org/15717
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Change-Id: I56d2ce7d52b9b70e43378c13c66b55ac2948f218
Reviewed-on: https://chromium-review.googlesource.com/362136
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
For some reason the self loader wasn't clearing segments
marked as BSS type. Other segments which weren't fully
written by the file-backed content were being cleared up
to the indicated memsize. Treat segments marked BSS
similarly by clearing their content.
Change-Id: I9296c11a89455a02e5dd18bba13d4911517c04f6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15603
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360210
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
There were two successive calls to prog_set_area() which
duplicated the same logic. Remove the unnecessary redundancy.
Change-Id: I594577f8e7e78d403e7a5656f78e784e98c2c859
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15602
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360209
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
The list insertion operations were open coded at each location.
Add helper functions which provide the semantics needed by
the selfboot code in a single place.
Change-Id: Ic757255e01934b499def839131c257bde9d0cc93
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15601
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360208
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
TPM PCRs are used in Chrome OS for two purposes: to communicate
crucial information from RO firmware and to protect FW and kernel
rollback counters from being deleted.
As implemented in TPM1 compatible way, the PCR extension command
requires a prebuilt digest to calculate a new PCR value.
TPM2 specification introduces a PCR_Event command, where the TPM
itself calculates the digest of an arbitrary length string, and then
uses the calculated digest for PCR extension. PCR_Event could be a
better option for Chrome OS, this needs to be investigated separately.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that the two PCRs are successfully extended before the
RW firmware is called.
Change-Id: I1a9bab7396fdb652e2e3bc8529b828ea3423d851
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358098
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
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: I62f22b9991522d4309cccc44180a5ebd4dca488d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358097
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
The code misses the cases when a response was received but the command
failed. This patch fixes the problem.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=none
Change-Id: I914ab6509d3ab2082152652205802201a6637fcc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358096
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: I2a0e62527ad46f9dd060afe5e75c7e4d56752849
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358095
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
The TPM2 specification allows defining NV ram spaces in such manner,
that it is impossible to remove the space, unless 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 will guarantee that the spaces can not be
deleted.
Also, there is no need in creating 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: I69e5ada65a5f15a8c04be9def92a8e1f4b753d9a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358094
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The command is sent in session mode, but has no parameters associated
with it.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the following patches verified that TPM_Clear command is
handled successfully by the TPM.
Change-Id: Ida19e75166e1282732810cf45be21e59515d88e2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357973
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For coreboot TPM2 use case session header is always of the minimal
possible size, the only difference is that some commands require one
and some - two handles.
Let's refactor common session header marshaling code into a separate
function, it will be useful when more commands marshaling code is
added.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=flashed the TPM and rebooted the device a few times, it
successfully loaded chrome os on every attempt.
Change-Id: I86e6426be5200f28ebb2174b418254018e81da8e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357972
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The function is reusing some variables which confuses the reader as
the variable names do not match their second function.
This patch edits the code for readability without changing
functionality.
BRANCH=None
BUG=chrome-os-partner:50465
TEST=with the rest of the patches applied Kevin still boots into
chrome OS.
Change-Id: I95a07945d9d2b00a69d514014f848802b82dd90f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358915
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The marshaling/unmarshaling code is using integer values to represent
room left in the buffer, to be able to communicate three conditions:
positive number means there is room left in the buffer, zero means
that the exact amount of data in the buffer was unmarshaled and
negative value means that the result of the operation did not fit into
the buffer.
The implementation is wrong though, as it compares directly signed and
unsigned values, which is illegal, as signed values get promoted to
unsigned by the compiler.
This patch changes the marshaling code to use size_t for the size, and
use zero as marshaling failure indication - after all the buffer where
the data is marshaled to should definitely be large enough, and it is
reasonable to expect at least some room left in it after marshaling.
The unmarshaling situation is different: we sure want to communicate
errors to the caller, but do not want to propagate error return values
through multiple layers. This patch keeps the size value in int, but
checks if it is negative separately, before comparing with positive
values.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied kevin successfully boots up.
Change-Id: Ie7552b333afaff9a1234c948caf9d9a64447b2e1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358772
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide common implementations for gpio_base2_value() variants
which configure the gpio for internal pullups and pulldowns.
BUG=chrome-os-partner:54949
BRANCH=None
TEST=Built and used on reef for memory config.
BUG=None
BRANCH=None
TEST=None
Change-Id: I9be8813328e99d28eb4145501450caab25d51f37
Original-Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Original-Reviewed-on: https://review.coreboot.org/15557
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358892
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
TPM2 structure definitions use pointers instead of buffers where
possible. One structure was left behind, replace buffer definition
with a pointer to be consistent.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=compilation succeeds, the code using the changed structure in the
upcoming patches allows to successfully boot chrome OS on Kevin
Change-Id: I9856ac516be13f5892ba8af0526708409a297033
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358771
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Add a function for an SOC to define that will allow it to map the
SOC-specific gpio_t value into an appropriate ACPI pin. The exact
behavior depends on the GPIO implementation in the SOC, but it can
be used to provide a pin number that is relative to the community or
bank that a GPIO resides in.
BUG=None
BRANCH=None
TEST=None
Change-Id: Icb97ccf7d6a9034877614d49166bc9e4fe659bcf
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15512
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358584
Reviewed-by: Martin Roth <martinroth@chromium.org>
That function is no longer used. All users have been updated to
use the ulzman() function which specifies lengths for the input
and output buffers.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ie630172be914a88ace010ec3ff4ff97da414cb5e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15526
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358580
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add functions to convert between seconds and a struct rtc_time. Also
add a function that can display the time on the console.
BUG=chrome-os-partner:52220
BRANCH=none
TEST=(partial) with future commits and after setting RTC on the EC:
boot on gru into linux shell, check firmware log:
localhost ~ # grep Date: /sys/firmware/log
Date: 2016-06-20 (Monday) Time: 18:01:44
Then reboot ~10 seconds and check again:
localhost ~ # grep Date: /sys/firmware/log
Date: 2016-06-20 (Monday) Time: 18:01:54
BUG=None
BRANCH=None
TEST=None
Change-Id: Id148ccb7a18a05865b903307358666ff6c7b4a3d
Original-Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Original-Commit-Id: 3b02dbcd7d
Original-Change-Id: I344c385e2e4cb995d3a374025c205f01c38b660d
Original-Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Original-Reviewed-on: https://chromium-review.googlesource.com/351782
Original-Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Original-Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15301
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358385
Reviewed-by: Martin Roth <martinroth@chromium.org>
Some structures were included in tpm2_tlcl_structures.h but are not
needed for tpm2 commands used by coreboot. Drop them from the include
file.
BRANCH=none
BUG=none
TEST=coreboot image for gru/kevin still builds fine.
Change-Id: I89b46900e5356989f2683d671552ecca5103ef90
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358093
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
TPM commands need to be serialized (marshaled) to be sent to the
device, and the responses need to be de-serialized (unmarshaled) to be
properly interpreted by upper layers.
This layer does not exist in TPM1.2 coreboot implementation, all TPM
commands used there were hardcoded as binary arrays. Availability of
the marshaling/unmarshaling layer makes it much easier to add new TPM
commands to the code.
Command and response structures used in these functions are defined in
Parts 2 and 3 of the TCG issued document
Trusted Platform Module Library
Family "2.0"
Level 00 Revision 01.16
October 30, 2014
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied it is possible to
successfully initialize firmware and kernel TPM spaces.
Change-Id: I202276ef9a43c28b5f304f901ac5b91048878b76
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353915
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
