Remove the weak function stub fill_lb_framebuffer() and guard with the
new `CONFIG_LINEAR_FRAMEBUFFER` instead.
Change-Id: Ia9e477c2d501b249a632968b5636ac803323895a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/19807
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Rename `FRAMEBUFFER_KEEP_VESA_MODE` to `LINEAR_FRAMEBUFFER` and put
it together with new `VGA_TEXT_FRAMEBUFFER` into a choice. There are
two versions of `LINEAR_FRAMEBUFFER` that differ only in the prompt
and help text (one for `HAVE_VBE_LINEAR_FRAMEBUFFER` and one for
`HAVE_LINEAR_FRAMEBUFFER`). Due to `kconfig_lint` we have to model
that with additional symbols.
Change-Id: I9144351491a14d9bb5e650c14933b646bc83fab0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/19804
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Place it into new edid_fill_fb.c, and invert the logic of the Kconfig
guard (NATIVE_VGA_INIT_USE_EDID is now !NO_EDID_FILL_FB). It has to be
selected by all drivers that use MAINBOARD_DO_NATIVE_VGA_INIT but pro-
vide their own fill_lb_framebuffer() implementation.
Change-Id: I90634b835bd8e2d150b1c714328a5b2774d891bd
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/19764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Instead of assuming the mapping of dimm number to SPD SMBus address,
allow the mainboard to provide its own mapping. That way, global
resources of empty SPD contents aren't wasted in order to address
a dimm on a mainboard that doesn't meet the current assumption.
Change-Id: Id0e79231dc2303373badaae003038a1ac06a5635
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19915
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Naresh Solanki <naresh.solanki@intel.com>
The 'cbmem -1' flag that cuts off console output before the last boot
will ignore content from earlier stages if it was truncated due to lack
of pre-CBMEM console space. This patch makes the "log truncated" message
more specific and adds it as an additional cut-off marker to 'cbmem -1'
to counteract that problem.
Also raise the log level of the coreboot banner one step to BIOS_NOTICE
to make it more likely to be included in the output for 'cbmem -1' to
find. (I believe NOTICE is reasonable but I wouldn't want to go as far
as WARN which should be reserved for actual problems. Of course this is
not ideal, but then again, our whole log-level system really isn't... it
would be better if we could make it always print a banner to the CBMEM
console without affecting the UART at the same time, but that would
require a larger amount of work.)
Change-Id: I58288593dfa757e14f4a9da4ffa7e27b0b66feb9
Reported-by: https://ticket.coreboot.org/issues/117
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For some reason the "interface" for adding framebuffer information
is sitting in src/include/vbe.h while also guarding the call to
fill_lb_framebuffer() with vbe_mode_info_valid() along with some
macro if CONFIG_* for good measure.
Move the fill_lb_framebuffer() declaration to coreboot_tables.h and
provide a comment about how it should be used. Also, now that
there's no need for the notion of a global vbe_mode_info_valid()
remove it from the conditional call path of fill_lb_framebuffer().
Change-Id: Ib3ade6314624091ae70424664527a02b279d0c9b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/19729
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
It turns out that there are quite a few other projects that can access
the CBMEM console by now. If we ever want to make another structural or
behavioral change to it, we need to know where these implementations are
so we can make sure they're all getting updated. Let's try to build a
comprehensive list in the file that should be the source of truth for
all (coreboot's own implementation).
Change-Id: Ia3d6a87230f5bfdde9d812bc7154e22880c1377a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19439
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use the iobuf API instead of relying on own buffer management. It
also provides consistency between marshaling and unmarshaling code
paths for propagating return values instead of overloading the values
of existing variables.
BUG=b:36598499
Change-Id: Iec0bbff1312e8e6ec616d1528db8667f32e682c9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19063
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch allows the CBMEM console to persist across reboots, which
should greatly help post factum debugging of issues involving multiple
reboots. In order to prevent the console from filling up, it will
instead operate as a ring buffer that continues to evict the oldest
lines once full. (This means that if even a single boot doesn't fit into
the buffer, we will now drop the oldest lines whereas previous code
would've dropped the newest lines instead.)
The console control structure is modified in a sorta
backwards-compatible way, so that new readers can continue to work with
old console buffers and vice versa. When an old reader reads a new
buffer that has already once overflowed (i.e. is operating in true ring
buffer mode) it will print lines out of order, but it will at least
still print out the whole console content and not do any illegal memory
accesses (assuming it correctly implemented cursor overflow as it was
already possible before this patch).
BUG=chromium:651966
TEST=Rebooted and confirmed output repeatedly on a Kevin and a Falco.
Also confirmed correct behavior across suspend/resume for the latter.
Change-Id: Ifcbf59d58e1ad20995b98d111c4647281fbb45ff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18301
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There's a missing closing brace in fillbits function of jpeg.c which
caused an avalanche of compilation errors.
This was introduced in commit
491c5b60 (src/lib: Move assignment out of if condition)
which was reviewed in gerrit at https://review.coreboot.org/18761 and it
prevents coreboot from building when CONFIG_BOOTSPLASH is set.
Change-Id: Ie10b774875fc25ce2ff613c542c15870e780a761
Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm>
Reviewed-on: https://review.coreboot.org/19032
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are
linked directly into the bootblock or the romstage. However, they're
still compiled with a separate "libverstage" source file class, linked
into an intermediate library and then linked into the final destination
stage.
There is no obvious benefit to doing it this way and it's unclear why it
was chosen in the first place... there are, however, obvious
disadvantages: it can result in code that is used by both libverstage
and the host stage to occur twice in the output binary. It also means
that libverstage files have their separate compiler flags that are not
necessarily aligned with the host stage, which can lead to weird effects
like <rules.h> macros not being set the way you would expect. In fact,
VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86
because their libverstage code that gets compiled into the romstage sets
ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to
run pre-migration.
This patch resolves these problems by removing the separate library.
There is no more difference between the 'verstage' and 'libverstage'
classes, and the source files added to them are just treated the same
way a bootblock or romstage source files in configurations where the
verstage is linked into either of these respective stages (allowing for
the normal object code deduplication and causing those files to be
compiled with the same flags as the host stage's files).
Tested this whole series by booting a Kevin, an Elm (both with and
without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode.
Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18302
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch attempts to finish the separation between CONFIG_VBOOT and
CONFIG_CHROMEOS by moving the remaining options and code (including
image generation code for things like FWID and GBB flags, which are
intrinsic to vboot itself) from src/vendorcode/google/chromeos to
src/vboot. Also taking this opportunity to namespace all VBOOT Kconfig
options, and clean up menuconfig visibility for them (i.e. some options
were visible even though they were tied to the hardware while others
were invisible even though it might make sense to change them).
CQ-DEPEND=CL:459088
Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18984
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The correct way to mock out vboot TPM accesses these days is the
CONFIG_VBOOT_MOCK_SECDATA Kconfig option. There are some remnants of
older TPM-mocking infrastructure in our codebase that are as far as I
can tell inert. Remove them.
Change-Id: I3e00c94b71d53676e6c796e0bec0f3db67c78e34
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18977
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The upcoming Cr50 firmware changes will require the AP to enable the
previously downloaded Cr50 firmware update(s).
A new vendor command (TPM2_CR50_SUB_CMD_TURN_UPDATE_ON) is used for
that. The command accepts one parameter - a timeout value in range of
0 to 1000 ms.
When processing the command the Cr50 checks if the alternative RO or
RW image(s) need to be enabled, and if so - enables them and returns
to the host the number of enabled headers.
If the vendor command requested a non-zero timeout, the Cr50 starts
a timer to trigger system reboot after the requested timeout expires.
The host acts on the number of enabled headers - if the number is
nonzero, the host prepares the device to be reset and waits for the
Cr50 to reboot the device after timeout expires.
This patch also adds more formal vendor command
marshaling/unmarshaling to make future additions easier.
BRANCH=gru,reef
BUG=b:35580805
TEST=with the actual user of this code in the next patch verified that
the cr50 update is enabled as expected.
Change-Id: Ic76d384d637c0eeaad206e0a8242cbb8e2b19b37
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/18945
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: Bad function definition - void init_timer() should probably be void init_timer(void)
ERROR: Prefixing 0x with decimal output is defective
WARNING: Comparisons should place the constant on the right side of the test
WARNING: char * array declaration might be better as static const
TEST=Build and run on Galileo Gen2
Change-Id: I9f618eea95e1f92fa34f4f89da27c0b16ae7f4ee
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18763
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following error detected by checkpatch:
ERROR: do not use assignment in if condition
TEST=Build and run on Galileo Gen2
Change-Id: I5a08d1647db66bd5d480f81e90d473999c222acf
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18761
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following warning detected by checkpatch.pl:
WARNING: macros should not use a trailing semicolon
TEST=Build and run on Galileo Gen2
Change-Id: Ie1d966b0f1f8fff401d6314fd2ef005ab6ac69db
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18764
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following warnings detected by checkpatch.pl:
WARNING: break is not useful after a goto or return
WARNING: Statements terminations use 1 semicolon
WARNING: else is not generally useful after a break or return
WARNING: void function return statements are not generally useful
TEST=Build and run on Galileo Gen2
Change-Id: I6f095c4e9cb1ee4ff2ebdf095ef612e1a8393231
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18762
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following warning detected by checkpatch.pl:
WARNING: storage class should be at the beginning of the declaration
TEST=Build and run on Galileo Gen2
Change-Id: I7d3135466634a4bb84dcef16dbd68754f8d8d6c2
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18760
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following errors detected by checkpatch.pl:
ERROR: open brace '{' following function declarations go on the next
line
ERROR: that open brace { should be on the previous line
ERROR: open brace '{' following struct go on the same line
ERROR: else should follow close brace '}'
TEST=Build and run on Galileo Gen2
Change-Id: I971ada9ba9ba7ce5d8029323710fee1a6166570b
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18759
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following warning detected by checkpatch.pl:
WARNING: line over 80 characters
TEST=Build and run on Galileo Gen2
Change-Id: I5fa3f8e950e2f0c60bd0e8f030342dc8c0469299
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18758
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: spaces required around that '?' (ctx:WxV)
ERROR: spaces required around that '=' (ctx:VxV)
ERROR: spaces required around that '<' (ctx:VxV)
ERROR: spaces required around that '+=' (ctx:VxV)
ERROR: space required after that ',' (ctx:VxV)
ERROR: space required before the open brace '{'
ERROR: space required after that close brace '}'
ERROR: need consistent spacing around '+' (ctx:WxV)
ERROR: need consistent spacing around '*' (ctx:WxV)
ERROR: need consistent spacing around '&' (ctx:VxW)
ERROR: spaces required around that '?' (ctx:VxW)
ERROR: spaces required around that ':' (ctx:VxW)
ERROR: trailing whitespace
ERROR: space prohibited before that '++' (ctx:WxO)
ERROR: space prohibited before that ',' (ctx:WxW)
ERROR: space prohibited after that '!' (ctx:BxW)
ERROR: spaces prohibited around that '->' (ctx:VxW)
ERROR: space prohibited after that '-' (ctx:WxW)
WARNING: space prohibited before semicolon
WARNING: unnecessary whitespace before a quoted newline
WARNING: missing space after return type
Note that lib/libgcov.c and lib/lzmadecode.c are providing false
positives for ERROR: need consistent spacing around '*' (ctx:WxV)
An example is:
void __gcov_merge_add(gcov_type *counters __attribute__ ((unused)),
unsigned int n_counters __attribute__ ((unused))) {}
TEST=Build and run on Galileo Gen2
Change-Id: I0016327a5754018eaeb25bedf42338291632c7c1
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18733
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: code indent should use tabs where possible
ERROR: switch and case should be at the same indent
WARNING: Statements should start on a tabstop
WARNING: please, no spaces at the start of a line
WARNING: please, no space before tabs
WARNING: suspect code indent for conditional statements
WARNING: labels should not be indented
TEST=Build and run on Galileo Gen2
Change-Id: Iebcff26ad41ab6eb0027b871a1c06f3b52dd207c
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18732
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Fix the following warning detected by checkpatch.pl:
WARNING: space prohibited between function name and open parenthesis '('
TEST=Build and run on Galileo Gen2
Change-Id: I8f3c79302dc5eb1861ffb245617a27addf8653ef
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18731
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Fix the following error detected by checkpatch.pl:
ERROR: trailing statements should be on next line
The remaining error is a false positive in libgcov.c where the if
statement spans several lines with conditional compilation directives
intertwined.
TEST=Build and run on Galileo Gen2
Change-Id: I37fcef78e9323340bac1367ae1c5fde334f5ce10
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18730
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
cr50 by default delays nvmem commits internally from the point of
reset to accumulate change state. However, the factory process can
put a board into dev mode through the recovery screen. This state
is stored in the TPM's nvmem space. When the factory process is
complete a disable_dev_request and battery_cutoff_request is performed.
This leads to disabling the dev mode in TPM, but the battery is
subsequently cut off so the nvmem contents never stick. Therefore,
whenever antirollback_write_space_firmware() is called we know there
was a change in secdata so request cr50 to immediately enable nvmem
commits going forward. This allows state changes to happen immediately.
The fallout from this is that when secdata is changed that current
boot will take longer because every transaction that writes to TPM
nvmem space will perform a write synchronously. All subsequent boots
do not have that effect.
It should also be noted that this approach to the implementation is
a pretty severe layering violation. However, the current TPM APIs
don't lend themselves well to extending commands or re-using code
outside of the current routines which inherently assume all knowledge
of every command (in conflict with vendor commands since those are
vendor-specific by definition).
BUG=b:35775104
BRANCH=reef
TEST=Confirmed disablement of dev mode sticks in the presence of:
crossystem disable_dev_request=1; crossystem
battery_cutoff_request=1; reboot;
Change-Id: I3395db9cbdfea45da1f5cb994c6570978593b944
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/18681
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
marshal_blob() was setting an unsigned size (size_t) to a value
of -1 when an error is determined. This is wrong for the current
implementation of the code because the code assumes the buffer
space gets set to 0. Setting an unsigned value to -1 effectively
tells the library the buffer has unlimited amount of space.
BUG=b:35775104
Change-Id: I677a1fd7528bef3ea7420d0a8d0a290e9b15cea3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/18678
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Fix the following error detected by checkpatch.pl:
ERROR: space required before the open parenthesis '('
TEST=Build and run on Galileo Gen2
Change-Id: I8953fecbe75136ff989c9e3cf6c5e155dcee3c3b
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18698
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Fix the following warning detected by checkpatch.pl:
WARNING: braces {} are not necessary for single statement blocks
TEST=Build and run on Galileo Gen2
Change-Id: Ie4b41f6fb75142ddd75103a55e0347ed85e7e873
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18697
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins)
Fix the following errors detected by checkpatch.pl:
ERROR: "foo* bar" should be "foo *bar"
ERROR: "(foo*)" should be "(foo *)"
ERROR: "foo * const * bar" should be "foo * const *bar"
TEST=Build and run on Galileo Gen2
Change-Id: I0d20ca360d8829f7d7670bacf0da4a0300bfb0c1
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18696
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Fix the following warning detected by checkpatch.pl:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
The remaining 37 warnings in gcov-io.c and libgcov.c are all false
positives generated by checkpatch detecting a symbol or function name
ending in _unsigned.
TEST=Build and run on Galileo Gen2
Change-Id: I9f1b71993caca8b3eb3f643525534a937d365ab3
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18695
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Fix the following errors detected by checkpatch.pl:
ERROR: space prohibited after that open parenthesis '('
ERROR: space prohibited before that close parenthesis ')'
TEST=Build and run on Galileo Gen2
Change-Id: I586c5731c080282080fe5ddf3ac82252cb35bdd4
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18636
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It's an attempt to consolidate the access code, even if there are still
multiple implementations in the code.
Change-Id: I4b2b9cbc24a445f8fa4e0148f52fd15950535240
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18265
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Shorten field names of struct cbmem_console since saying "buffer_" in
front of everything is redundant and we can use the gained space to save
some line breaks in the code later. This also aligns the definition with
the version in libpayload.
Change-Id: I160ad1f39b719ac7e912d0466c82a58013cca0f9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18299
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The rule to make spd.bin that's in src/lib is for the 'generic_spd_bin'
implementation. It wasn't guarded though, so it was generating a build
warning for any other platform that generated an spd.bin file.
Sample warning that this fixes:
src/mainboard/gizmosphere/gizmo/Makefile.inc:42:
warning: overriding recipe for target 'build/spd.bin'
src/lib/Makefile.inc:298: warning: ignoring old recipe for target
'build/spd.bin'
Change-Id: Iadd6743f8ae476969bf36f99b918f04c04172d1d
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/18261
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
They were sized to 32-bit alignment, this grows them to 64 bit-aligned.
Change-Id: I494b942c4866a7912fb48a53f9524db20ac53a8c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/18165
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
On Chrome OS devices that use TPM2 parts the platform hierarchy
is disabled by the boot loader, depthcharge. Since the bootloader
isn't involved in resuming a suspended machine there's no equivalent
action in coreboot to disable the platform hierarchy. Therefore, to
ensure consistent state in resume the platform hierarchy in the TPM2
needs to be disabled as well. For systems that resume using the
firmware the platform hierarchy is disabled when utilizing
TPM2 devices.
BUG=chrome-os-partner:61097
BRANCH=reef
TEST=Suspend and resume. Confirmed 'stop trunksd; tpmc getvf; start
trunksd' shows that phEnable is 0.
Change-Id: I060252f338c8fd68389273224ee58caa99881de8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/18096
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
cmos_post_init() is called in src/arch/x86/bootblock_simple.c, and
that function is reponsible for bootstrapping the cmos post register
contents. Without this function being called none of the cmos post
functionality works correctly. Therefore, add a call to lib/bootblock.c
which the C_ENVIRONMENT_BOOTBLOCK SoCs use.
BUG=chrome-os-partner:61546
Change-Id: I2e3519f2f3f2c28e5cba26b5811f1eb0c2a90572
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/18043
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch adds an API to find file by name from
any specific region of fmap.
Change-Id: Iabe785a6434937be6a57c7009882a0d68f6c8ad4
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/17664
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The bootstate machine allows one to schedule work at the
boundaries of each state. However, there are no priorities by
design. As such if there are things that need to be performed
that are interdependent between callbacks there's no way to
do that aside from explicitly putting the call in one of the
callbacks.
This situation arises around BS_OS_RESUME, BS_PAYLOAD_LOAD,
and BS_PAYLOAD_BOOT as those are the states where coreboot is
about to exit. As such, provide an architecture specific hook
at these key places so that one is guaranteed any work done
in arch_bootstate_coreboot_exit() is after all callbacks in
the state machine.
BUG=chrome-os-partner:60657
BRANCH=reef
Change-Id: Icb4afb341ab15af0670501b9d21799e564fb32c6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17767
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The region file library is added to provide the underpinnings for
other libraries that support appending updates when the data changes.
The most recent written data is deemed the latest data associated
with that "file". A good example is the MRC cache which in a follow-up
patch utilizes this library.
BUG=chrome-os-partner:56151
Change-Id: Ic3caf1edbb6f11dbbe27181a87b7b19d1224fffa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17713
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
compute_ip_checksum() doesn't manipulate the data it is passed.
Therefore, mark it as const.
BUG=chrome-os-partner:56151
Change-Id: I54cff9695a886bacd6314aa441d96aaa7a991101
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17714
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add the new time stamps *finalize chips* to track, when the method
`dev_finalize_chips()` is called, so that the real time of
`write_tables()` is known.
Change-Id: I65ca0ec4c07c2eaa14982989cb206d23d8a2293f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/17725
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
In the ACPI header there's an OEM revision field that was previously
just being implicitly set to 0. Allow for a board to provide a
non-zero value for this field.
Change-Id: Icd40c1c162c2645b3990a6f3361c592706251f82
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17650
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of putting all the functions inline just put the
current implementation into a C file. That way all the implementation
innards are not exposed.
Lastly, fix up the fallout of compilation units not including the
headers they actually use.
Change-Id: I01fd25d158c0d5016405b73a4d4df3721c281b04
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17648
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of having callers query the romstage handoff resume
status by inspecting the object themselves add
romstage_handoff_is_resume() so that the same information
can be queried easily.
Change-Id: I40f3769b7646bf296ee4bc323a9ab1d5e5691e21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17647
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add library to:
1. add spd.bin in cbfs, generated from mainboard/spd/*.spd.hex files.
2. runtime get spd data with spd index as input.
3. fetch spd over smbus using early smbus functions.
Change-Id: I44fe1cdb883dd1037484d4bb5c87d2d4f9862bf8
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17434
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
It's hidden behind a configuration option `CONFIG_RAMSTAGE_LIBHWBASE`.
This also adds some glue code to use the coreboot console for debug
output and our monotonic timer framework as timer backend.
v2: Also update 3rdparty/libhwbase to the latest master commit.
Change-Id: I8e8d50271b46aac1141f95ab55ad323ac0889a8d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16951
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Align top of stack to 8 bytes, value documented as FSP1.1 requirement.
Also fix some cases of uintptr_t casted to unsigned long.
Change-Id: I5bbd100eeb673417da205a2c2c3410fef1af61f0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17461
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Currently the tlcl_define_space() function returns the same error
value for any non-zero TPM response code. The thing is that the caller
might want to allow attempts to re-create existing NVRAM spaces. This
patch adds a new API return value to indicate this condition and uses
it as appropriate.
BRANCH=none
BUG=chrome-os-partner:59654
TEST=for test purposes modified the code not to create the firmware
space, wiped out the TPM NVRAM and booted the device. Observed it
create kernel and MRC index spaces on the first boot and then
reporting return code 0x14c for already existing spaces on the
following restarts.
Change-Id: Ic183eb45e73edfbccf11cc19fd2f64f64274bfb2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/17422
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The TPM spaces created by the RO need to have different attributes
depending on the space's use. The firmware rollback counter and MRC
hash spaces are created by the RO code and need to be protected at the
highest level: it should be impossible to delete or modify the space
once the RO exits, and it is how it is done before this patch.
The rest of the spaces should be possible to modify or recreate even
after the RO exits. Let's use different set of NVRAM space attributes
to achieve that, and set the 'pcr0 unchanged' policy only for the
firmware counter and MRC cache spaces.
The definitions of the attributes can be found in "Trusted Platform
Module Library Part 2: Structures", Revision 01.16, section "13.2
TPMA_NV (NV Index Attributes)."
CQ-DEPEND=CL:410127
BRANCH=none
BUG=chrome-os-partner:59651
TEST=verified that the reef system boots fine in both normal and
recovery modes; using tpmc confirmed that firmware, kernel and
MRC cache NVRAM spaces are readable in both and writeable only in
recovery mode.
Change-Id: I1a1d2459f56ec929c9a92b39175888b8d1bcda55
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/17388
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Since tlcl library is used other than just vboot driver, ensure that the
library is initialized only once per stage.
BUG=chrome-os-partner:59355
BRANCH=None
TEST=Verified in recovery mode on reef, tlcl library is initialized only
once in romstage.
Change-Id: I6245fe9ed34f5c174341b7eea8db456b45113287
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17364
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This driver is required for reading and updating TPM space for recovery
MRC data hash in romstage.
BUG=chrome-os-partner:59355
BRANCH=None
TEST=Compiles successfully for reef.
Change-Id: I8edb7af13285a7a192e3d55fc6a11cfe12654bf9
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17270
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add implementation to use actual requirements of ramstage size
for S3 resume backup in CBMEM. The backup covers complete pages of 4 KiB.
Only the required amount of low memory is backed up when ACPI_TINY_LOWMEM_BACKUP
is selected for the platform. Enable this option for AGESA and binaryPI, other
platforms (without RELOCATABLE_RAMSTAGE) currently keep their romstage ramstack
in low memory for s3 resume path.
Change-Id: Ide7ce013f3727c2928cdb00fbcc7e7e84e859ff1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15255
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
If selected, libgnat will be linked into ramstage. And, to support Ada
package intializations, we have to call ramstage_adainit().
Change-Id: I11417db21f16bf3007739a097d63fd592344bce3
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16944
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
All current implementations of ramstage_cache_invalid() were just
resetting the system based on the RESET_ON_INVALID_RAMSTAGE_CACHE
Kconfig option. Move that behavior to a single implementation
within prog_loaders.c which removes duplication.
Change-Id: I67aae73f9e1305732f90d947fe57c5aaf66ada9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17184
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Ron reported some toolchain emitting .sdata sections. Let's ensure
we catch objects in those sections instead of getting dropped on the
floor for architectures which emit those sections.
Change-Id: I0680228f8424f99611914ef5fc31adf5d3891eee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17180
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch enables stage cache to save ~40ms during S3 resume.
It saves ramstage in the stage cache and restores it on resume
so that ramstage does not have to reinitialize during the
resume flow. Stage cache functionality is added to postcar stage
since ramstage is called from postcar.
BUG=chrome-os-partner:56941
BRANCH=none
TEST=built for Reef and tested ramstage being cached
Change-Id: I1551fd0faca536bd8c8656f0a8ec7f900aae1f72
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/16833
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Switch the BL31 (ARM Trusted Firmware) format to payload so that it can
have multiple independent segments. This also requires disabling the region
check since SRAM is currently faulted by that check.
This has been tested with Rockchip's pending change:
https://chromium-review.googlesource.com/#/c/368592/3
with the patch mentioned on the bug at #13.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=boot on gru and see that BL31 loads and runs. Im not sure if it is
correct though:
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 1b440 size 15a75
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x18104800 memsize 0x117fbe0 srcaddr 0x100038 filesize 0x15a3d
Loading segment from ROM address 0x000000000010001c
Entry Point 0x0000000018104800
Loading Segment: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
using LZMA
[ 0x18104800, 18137d90, 0x192843e0) <- 00100038
Clearing Segment: addr: 0x0000000018137d90 memsz: 0x000000000114c650
dest 0000000018104800, end 00000000192843e0, bouncebuffer ffffffffffffffff
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 125150 exit 1
Jumping to boot code at 0000000018104800(00000000f7eda000)
CPU0: stack: 00000000ff8ec000 - 00000000ff8f0000, lowest used address 00000000ff8ef3d0, stack used: 3120 bytes
CBFS: 'VBOOT' located CBFS at [402000:44cc00)
CBFS: Locating 'fallback/bl31'
CBFS: Found @ offset 10ec0 size 8d0c
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x10000 memsize 0x40000 srcaddr 0x100054 filesize 0x8192
Loading segment from ROM address 0x000000000010001c
code (compression=1)
New segment dstaddr 0xff8d4000 memsize 0x1f50 srcaddr 0x1081e6 filesize 0xb26
Loading segment from ROM address 0x0000000000100038
Entry Point 0x0000000000010000
Loading Segment: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
using LZMA
[ 0x00010000, 00035708, 0x00050000) <- 00100054
Clearing Segment: addr: 0x0000000000035708 memsz: 0x000000000001a8f8
dest 0000000000010000, end 0000000000050000, bouncebuffer ffffffffffffffff
Loading Segment: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
using LZMA
[ 0xff8d4000, ff8d5f50, 0xff8d5f50) <- 001081e6
dest 00000000ff8d4000, end 00000000ff8d5f50, bouncebuffer ffffffffffffffff
Loaded segments
INFO: plat_rockchip_pmusram_prepare pmu: code d2bfe625,d2bfe625,80
INFO: plat_rockchip_pmusram_prepare pmu: code 0xff8d4000,0x50000,3364
INFO: plat_rockchip_pmusram_prepare: data 0xff8d4d28,0xff8d4d24,4648
NOTICE: BL31: v1.2(debug):
NOTICE: BL31: Built : Sun Sep 4 22:36:16 UTC 2016
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: plat_rockchip_pmu_init(1189): pd status 3e
INFO: BL31: Initializing runtime services
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x18104800
INFO: SPSR = 0x8
Change-Id: Ie2484d122a603f1c7b7082a1de3f240aa6e6d540
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8c1d75bff6e810a39776048ad9049ec0a9c5d94e
Original-Change-Id: I2d60e5762f8377e43835558f76a3928156acb26c
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376849
Original-Commit-Ready: Simon Glass <sjg@google.com>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16706
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
On resume, TPM2_Starup(STATE) command needs to be sent to the TPM. This
ensures that TPM restores the state saved at last Shutdown(STATE).
Since tlcl_resume and tlcl_startup both use the same sequence for
sending startup command with different arguments, add a common function
that can be used by both.
BUG=chrome-os-partner:58043
BRANCH=None
TEST=Verified that on resume coreboot no longer complains about index
read for 0x1007. Return value is 0 as expected.
Change-Id: Ib8640acc9cc9cdb3ba5d40e0ccee5ca7d67fa645
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16832
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@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: If48d2bf485a23f21c5599670e77a7b8b098f1a88
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 2381e02efa2033857ac06acbc4f0c0dd08de1080
Original-Change-Id: I005e5e4d9b2136605bdd95e9060655df7a8238cb
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381092
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16585
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Implement postcar stage cbmem console support. The postcar stage
is more like ramstage in that RAM is already up. Therefore, in
order to make the cbmem console reinit flow work one needs the cbmem
init hook infrastructure in place and the cbmem recovery called.
This call is added to x86/postcar.c to achieve that. Additionally,
one needs to provide postcar stage cbmem init hook callbacks for
the cbmem console library to use. A few other places need to
become postcar stage aware so that the code paths are taken.
Lastly, since postcar is backed by ram indicate that to the
cbmem backing store.
BUG=chrome-os-partner:57513
Change-Id: I51db65d8502c456b08f291fd1b59f6ea72059dfd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16619
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a stripped-down version of libgnat. This is somehow comparable to
libgcc but for Ada programs. It's licensed under GPLv3 but with the
runtime library exception. So it's totally fine to link it with our
GPLv2 code and keep it under GPLv2.
Change-Id: Ie6522abf093f0a516b9ae18ddc69131bd721dc0c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/11836
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Enable the hexdump function in verstage as it can be useful there for
debugging I2C and TPM transactions.
Change-Id: If9dc4bcc30964e18ff5d8a98559f6306c0adec6f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16528
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The script checkpatch.pl complains about these files. Fix
the warnings.
Change-Id: I4271cc35bb101447a316a75273cf8a6e95ed62d5
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/16011
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
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.
Change-Id: Ia739c81d79c6cee9046ae96061045fe4f7fb7c23
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>
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.
Change-Id: Ia6c1db00ae01dee485d5e96e4315cb399dc63696
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>
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.
Change-Id: Iab65c0b6ebea235089f741eaa8098743e54d6ccc
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>
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.
Change-Id: Ibe4301fb89c47fde28e883fd11647d6b62a66fb0
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>
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
Change-Id: Ibafa3dc534f53a3d90487f3190c0f8a2e82858c2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16203
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
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
Change-Id: Ib0eba601df4d77bede313c358c92b0536355bbd0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16197
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
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
Change-Id: I0af324824f9e1a8e897c2453c36e865b59c4e004
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16194
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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
Change-Id: Ia2ccfdc9e1a4348cd91b381f9712d8853b7d2a79
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16212
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
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
Change-Id: I06f138078c47a1e4b4b3edbdbf662f171e11c9d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16228
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
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
Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16192
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
This reverts commit a83bbf5854.
This was submitted out of order.
Change-Id: Ic5a28faf94c1f1901a72e46343722eb4224c5086
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16226
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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
Change-Id: Ibdd7c8754f9bf560a878136b1f55238e2c2549d3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16193
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
POSTCAR stage has cbmem online. So, all timestamps need to be added to
cbmem timestamp region.
BUG=chrome-os-partner:55848
TEST=Verified that timestamps added in postcar show up in cbmem -t.
Change-Id: I64af8c1e67b107d9adb09de57c20ea728981f07c
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>
With VBOOT_VERIFY_FIRMWARE separated from CHROMEOS, move recovery and
developer mode check functions to vboot. Thus, get rid of the
BOOTMODE_STRAPS option which controlled these functions under src/lib.
BUG=chrome-os-partner:55639
Change-Id: Ia2571026ce8976856add01095cc6be415d2be22e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15868
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
VBOOT_VERIFY_FIRMWARE should be independent of CHROMEOS. This allows use
of verified boot library without having to stick to CHROMEOS.
BUG=chrome-os-partner:55639
Change-Id: Ia2c328712caedd230ab295b8a613e3c1ed1532d9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15867
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@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
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15841
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@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
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15842
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use the newly added check recovery request function from recovery module
in vboot2 to check for a pending recovery request.
BUG=chrome-os-partner:55431
Change-Id: I354cc094f1e5d0044cf13e5bc28246f058d470c6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15801
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
1. Remove unused functions/structures.
2. Add checks for NULL return values.
3. Change prefixes to vb2 instead of vboot for functions used internally
within vboot2/
4. Get rid of vboot_handoff.h file and move the structure definition to
vboot_common.h
5. Rename all functions using handoff structure to have prefix
vboot_handoff_*. All the handoff functions can be run _only_ after cbmem
is online.
6. Organize vboot_common.h content according to different
functionalities.
BUG=chrome-os-partner:55431
Change-Id: I4c07d50327d88cddbdfbb0b6f82c264e2b8620eb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
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
Change-Id: I56d2ce7d52b9b70e43378c13c66b55ac2948f218
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>
Remove and add spaces for a consistent alignment.
Change-Id: I612800cd60d97f50737c235465d7d0a87f2251a8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/15596
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
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 a 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: I38fc88172de8ec8bef56fec026f83058480c8010
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 73388139db3ffaf61a3d9027522c5ebecb3ad051
Original-Change-Id: I1a9bab7396fdb652e2e3bc8529b828ea3423d851
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358098
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15639
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
TPM1.2 is using the somewhat misnamed tlcl_set_global_lock() command
function to lock the hardware rollback counter. For TPM2 let's
implement and use the TPM2 command to lock an NV Ram location
(TPM2_NV_WriteLock).
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM2_NV_WriteLock command is invoked before RO
firmware starts RW, and succeeds.
Change-Id: I52aa8db95b908488ec4cf0843afeb6310dc7f38b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 2f859335dfccfeea900f15bbb8c6cb3fd5ec8c77
Original-Change-Id: I62f22b9991522d4309cccc44180a5ebd4dca488d
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358097
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15638
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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: I3d50a4b67e3592bb80d2524a7c7f264fddbd34ae
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 8f4d6185e13beead7156027e1cb40f7944e46569
Original-Change-Id: I914ab6509d3ab2082152652205802201a6637fcc
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358096
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15637
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
tlcl_force_clear() needs to be issued each time when the device mode
switches between normal/development/recovery.
This patch adds command implementation using TPM_Clear TPM2 command,
and also invokes it before factory initialization.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM_Clear command succeeds at factory startup and
the boot proceeds normally.
Change-Id: Ia431390870cbe448bc1b6f1755ed17953be9bdf1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 347ff17b97da45fa4df547ff32f9dd2c8972cefd
Original-Change-Id: I2a0e62527ad46f9dd060afe5e75c7e4d56752849
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358095
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15636
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The TPM2 specification allows defining NV ram spaces in a manner
that makes it impossible to remove the space until a certain PCR is in
a certain state.
This comes in handy when defining spaces for rollback counters: make
their removal depend on PCR0 being in the default state. Then extend
PCR0 to any value. This guarantees that the spaces can not be deleted.
Also, there is no need t create firmware and kernel rollback spaces
with different privileges: they both can be created with the same set of
properties, the firmware space could be locked by the RO firmware, and
the kernel space could be locked by the RW firmware thus providing
necessary privilege levels.
BRANCH=none
BUG=chrome-os-partner:50645, chrome-os-partner:55063
TEST=with the rest of the patches applied it is possible to boot into
Chrome OS maintaining two rollback counter spaces in the TPM NV
ram locked at different phases of the boot process.
Change-Id: I889b2c4c4831ae01c093f33c09b4d98a11d758da
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 36317f5e85107b1b2e732a5bb2a38295120560cd
Original-Change-Id: I69e5ada65a5f15a8c04be9def92a8e1f4b753d9a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358094
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/15635
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
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: I3c9151e336084160acd3bb1f36f45b4d5efd4a33
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 503ad5e72fd5bd902325d74fd680c17c7c590e36
Original-Change-Id: Ida19e75166e1282732810cf45be21e59515d88e2
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/357973
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15634
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
For coreboot TPM2 the use case session header is always the minimal
possible size, the only difference is that some commands require one
and some require two handles.
Refactor common session header marshalling code into a separate
function. This will be useful when more commands marshalling 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: I9b1697c44f67aab32b9cd556b559a55d5050be06
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: a97a7fa16ceeb484e90e2e1f0573e58a468350b2
Original-Change-Id: I86e6426be5200f28ebb2174b418254018e81da8e
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/357972
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15633
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
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: I396206a64403229ba3921a47b5a08748d8a4b0a3
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 3cf02c365d098c9d2ca57def7cf349ef2291d140
Original-Change-Id: I95a07945d9d2b00a69d514014f848802b82dd90f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358915
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15611
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
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: Ibfbd1b351e35e37c8925a78d095e4e8492805bad
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: b1e862c2a650fa5f6cb25a01fe61e848a696cf17
Original-Change-Id: Ie7552b333afaff9a1234c948caf9d9a64447b2e1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358772
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15610
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some structures were included in tpm2_tlcl_structures.h that 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: Id3a01f7afbddc98b4d14125452ae6a571f1b19cb
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 9375eef5a3f5ed2ba216b1cc8a4ce5c78ebe53d8
Original-Change-Id: I89b46900e5356989f2683d671552ecca5103ef90
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358093
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15608
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
TPM2 structure definitions use pointers instead of buffers where
possible. One structure was left behind. Replace that 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: Iea59943aa0ad6e42fcd479765a9ded0d7a1680d7
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 02b2909b1875ba65cd56cf8e3697a2b67ddaea07
Original-Change-Id: I9856ac516be13f5892ba8af0526708409a297033
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358771
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/15609
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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>
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>
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>
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: I80b3f971e347bb30ea08f820ec3dd27e1656c060
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 0782d9d452efb732e85d1503fccfcb4bf9f69a68
Original-Change-Id: I202276ef9a43c28b5f304f901ac5b91048878b76
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353915
Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15570
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
This is the first approximation of implementing TPM2 support in
coreboot. It is very clearly incomplete, some of the larger missing
pieces being:
- PCR(s) modification
- protection NVRAM spaces from unauthorized deletion/modification.
- resume handling
- cr50 specific factory initialization
The existing TPM1.2 firmware API is being implemented for TPM2. Some
functions are not required at all, some do not map fully, but the API
is not yet being changed, many functions are just stubs.
An addition to the API is the new tlcl_define_space() function. It
abstracts TMP internals allowing the caller to specify the privilege
level of the space to be defined. Two privilege levels are defined,
higher for the RO firmware and lower for RW firmware, they determine
who can write into the spaces.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied Kevin/Gru devices can
initialize and use firmware and kernel spaces
Change-Id: Ife3301cf161ce38d61f11e4b60f1b43cab9a4eba
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: bcc8e62604c705798ca106e7995a0960b92b3f35
Original-Change-Id: Ib340fa8e7db51c10e5080973c16a19b0ebbb61e6
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353914
Original-Commit-Ready: Martin Roth <martinroth@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15569
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
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.
Change-Id: I9be8813328e99d28eb4145501450caab25d51f37
Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Reviewed-on: https://review.coreboot.org/15557
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
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.
Change-Id: Icb97ccf7d6a9034877614d49166bc9e4fe659bcf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15512
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@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.
Change-Id: Ie630172be914a88ace010ec3ff4ff97da414cb5e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15526
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
In order to ease the porting of supporting NHLT endpoints
introduce a nhlt_endpoint_descriptor structure as well as
corresponding helper functions.
Change-Id: I68edaf681b4e60502f6ddbbd04de21d8aa072296
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15486
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
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
Change-Id: Id148ccb7a18a05865b903307358666ff6c7b4a3d
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 3b02dbcd7d9023ce0acabebcf904e70007428d27
Original-Change-Id: I344c385e2e4cb995d3a374025c205f01c38b660d
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/351782
Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15301
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Allow reg_script to be used during the bootblock.
TEST=Build and run on Galileo Gen2
Change-Id: I55fe0be3f50116927b801ce67a3f23bb1931f6e7
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15131
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add asmlinkage to bootblock_main_with_timestamp so that it may be called
directly from the assembly code.
TEST=Build for Amenia and Galileo Gen2
Change-Id: Iefb8e5c1ddce2ec495b9272966b595d5adcebc1c
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15125
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Modern platforms like Apollolake do not use XIP for early stages. In
such cases, cbfs_prog_stage_load should check for NO_XIP_EARLY_STAGES
instead of relying on ARCH_X86 to decide if a stage is XIP.
Change-Id: I1729ce82b5f678ce8c37256090fcf353cc22b1ec
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15045
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new function "gpio_acpi_path()" that can be implemented by
SoC/board code to provide a mapping from a "gpio_t" pin to a
controller by returning the ACPI path for the controller that owns
this particular GPIO.
This is implemented separately from the "acpi_name" handler as many
SOCs do not have a specific device that handles GPIOs (or may have
many devices and the only way to know which is the opaque gpio_t)
and the current GPIO library does not have any association with the
device tree.
If not implemented (many SoCs do not implement the GPIO library
abstraction at all in coreboot) then the default handler will return
NULL and the caller knows it cannot determine this reliably.
Change-Id: Iaa0ff6c8c058f00cddf0909c4b7405a0660d4cfb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14842
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This function will turn a string of ASCII hex characters into an array
of bytes. It will ignore any non-ASCII-hex characters in the input
string and decode up to len bytes of data from it.
This can be used for turning MAC addresses or UUID strings into binary
for storage or further processing.
Sample usage:
uint8_t buf[6];
hexstrtobin("00:0e:c6:81:72:01", buf, sizeof(buf));
acpigen_emit_stream(buf, sizeof(buf));
Change-Id: I2de9bd28ae8c42cdca09eec11a3bba497a52988c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14837
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is useful, for example, in the bootblock, when a timestamp is
available which predates the call to main() in lib/bootblock.c
Change-Id: I17bb0add9f2d8721504b2e534dd6904d1201989c
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14862
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
timestamp_cache_get() would call timestamp_cache_init() whenever it
found a timestamp cache in the TIMESTAMP_CACHE_UNINITIALIZED state.
That means that timestamp_cache_get() will never reurn a cache in the
uninitialized state.
However, timestamp_init() checks against the uninitialized state, as
it does not expect timestamp_cache_get() to perform any initialization.
As a result, the conditional branch can never be reached.
Simply remove the timestamp_cache_init() call from timestamp_cache_get().
Change-Id: I573ffbf948b69948a3b383fa3bc94382f205b8f8
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14861
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The FLASHMAP_OFFSET config variable is used in lib/fmap.c, however
the fmdtool creates a fmap_config.h with a FMAP_OFFSET #define.
Those 2 values are not consistent. Therefore, remove the Kconfig
variable and defer to the #define generated by fmdtool.
Change-Id: Ib4ecbc429e142b3e250106eea59fea1caa222917
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14765
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Extend the serial port description to include the input clock frequency
and a payload specific value.
Without the input frequency it is impossible for the payload to compute
the baud-rate divisor without making an assumption about the frequency.
This breaks down when the UART is able to support multiple input clock
frequencies.
Add the UART_PCI_ADDR Kconfig value to specify the unique PCI device
being used as the console UART. Specify this value as zero when the
UART is not on the PCI bus. Otherwise specify the device using bus,
device and function along with setting the valid bit.
Currently the only payload to consume these new fields is the EDK-II
CorebootPayloadPkg.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Testing is successful when CorebootPayloadPkg is able to properly
initialize the serial port without using built-in values.
Change-Id: Id4b4455bbf9583f0d66c315d38c493a81fd852a8
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14609
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Before multi-CBFS support was added, x86 platforms cached their
ramstage in TSEG so that it could be re-used on the resume
path. However, more resources/assets are being put in cbfs that are
utilized during ramstage. Just caching ramstage does not mean that
correct cbfs region is used for all the data. Thus, provide an option
to allow platforms to skip caching any component for resume.
Change-Id: I0e957a6b859cc7d700aaff67209a17c6558be5de
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14636
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
In If0d4d61ed8ef48ec20082b327f358fd1987e3fb9 the code
was changed from one to two lines in the body of an if()
statement, without adding braces.
Change-Id: Ibbbdf240157adae95151fb2ce0135948caa60108
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14621
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Add the ability to enable the display of the script:
* Added REG_SCRIPT_COMMAND_DISPLAY to enable and disable display output
* Added context values to manage display support
* display_state - Updated by the command to enable or disable display
* display_features - May be updated by step routine to control what
the step displays for register and value
* display_prefix - Prefix to display before register data
* Added REG_SCRIPT_DISPLAY_ON and REG_SCRIPT_DISPLAY_OFF macros to
control the display from the register script
* Added REG_SCRIPT_DISPLAY_REGISTER and REG_SCRIPT_DISPLAY_VALUE as
two features of the common display. With these features enabled
the following is output:
* Write: <optional prefix> register <-- value
* Read: <optional prefix> register --> value
TEST=Build and run on Galileo Gen2
Change-Id: If0d4d61ed8ef48ec20082b327f358fd1987e3fb9
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14553
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It used to use CONFIG_CBFS_SIZE. The plan is that CBFS_SIZE only informs
default*.fmd generation, while everything else derives its information
from there.
Also document the existing assumption that boot media should access the
COREBOOT region (and not any other potentially existing fmap region
containing a CBFS).
Change-Id: I08254e4510f71edf99c2c8b56ac8f92008727c4a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14572
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove the platform_bus_table routine and replace it with a link time
table. This allows the handlers to be spread across multiple modules
without any one module knowing about all of the handlers.
Establish number ranges for both the SOC and mainboard.
TEST=Build and run on Galileo Gen2
Change-Id: I0823d443d3352f31ba7fa20845bbf550b585c86f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14554
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add xor support which enables toggling of a bit:
* REG_SCRIPT_COMMAND_RXW enum value
* REG_*_RXW* macros to support using REG_SCRIPT_COMMAND_RXW
* REG_*_XOR* macros to support using REG_SCRIPT_COMMAND_RXW
* reg_script_rxw routine to perform and/xor operation
* case in reg_script_run_step to call reg_script_rxw
TEST=Build and run on Galileo Gen2
Change-Id: I50a492c7c2643df5dc2d2fa7113e3722c1e480c7
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14495
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Decode each cbfs_payload_segment into native byte order during
segments iteration.
Note :
List ordering has been changed, segments are now always inserted
at the end.
cbfs_serialized.h PAYLOAD_SEGMENT definitions have been changed
to their standard order (big-endian).
Change-Id: Icb3c6a7da2d253685a3bc157bc7f5a51183c9652
Signed-off-by: George Trudeau <george.trudeau@usherbrooke.ca>
Reviewed-on: https://review.coreboot.org/14294
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to de-duplicate common patterns implement one write_tables()
function. The new write_tables() replaces all the architecture-specific
ones that were largely copied. The callbacks are put in place to
handle any per-architecture requirements.
Change-Id: Id3d7abdce5b30f5557ccfe1dacff3c58c59f5e2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14436
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a architecture specific function, arch_write_tables(), that
allows an architecture to add its required tables for booting.
This callback helps write_tables() to be de-duplicated.
Change-Id: I805c2f166b1e75942ad28b6e7e1982d64d2d5498
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
A architecture-specific function, named bootmem_arch_add_ranges(),
is added so that each architecture can add entries into the bootmem
memory map. This allows for a common write_tables() implementation
to avoid code duplication.
Change-Id: I834c82eae212869cad8bb02c7abcd9254d120735
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14434
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The x86 architecture needs to add a forwarding table to
the real coreboot table. Provide a helper function to do
this for aligning the architectures on a common
write_tables() implementation.
Change-Id: I9a2875507e6260679874a654ddf97b879222d44e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14433
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In addition to being consistent with all other architectures,
all chipsets support cbmem so the low coreboot table path is
stale and never taken. Also it's important to note the memory
written in to that low area of memory wasn't automatically
reserved unless that path was taken. To that end remove
low coreboot table support for x86.
Change-Id: Ib96338cf3024e3aa34931c53a7318f40185be34c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14432
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Each arch was calling cbmem_list() in their own write_tables()
function. Consolidate that call and place it in common code
in write_coreboot_table().
Change-Id: If0d4c84e0f8634e5cef6996b2be4a86cc83c95a9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14430
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>
Some ld versions seem to merge the .zeroptr section (NOLOAD, address 0)
with some debug sections (NOLOAD, address 0) which makes the build
explode when the debug sections are then stripped (including the zeroptr
symbol).
Just define zeroptr to be 0, no sections needed, to avoid this
"optimization".
Checked the objdump -dS of code using it that the accesses look sane.
Change-Id: Ia7cb3e5eae87076caf479d5ae9155a02f74b5663
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14344
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Our EDID code had always been aligning the framebuffer's
bytes_per_line (and x_resolution dependent on that) to 64. It turns out
that this is a controller-dependent parameter that seems to only really
be necessary for Intel chipsets, and commit 6911219cc (edid: Add helper
function to calculate bits-per-pixel dependent values) probably actually
broke this for some other controllers by applying the alignment too
widely.
This patch makes it explicitly configurable and depends the default on
ARCH_X86 (which seems to be the simplest and least intrusive way to make
it fit most cases for now... boards where this doesn't apply can still
override it manually by calling edid_set_framebuffer_bits_per_pixel()
again).
Change-Id: I1c565a72826fc5ddfbb1ae4a5db5e9063b761455
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14267
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A long time ago many Chrome OS boards had pages full of duplicated
boilerplate code for the fill_lb_gpios() function, and we spent a lot of
time bikeshedding a proper solution that passes a table of lb_gpio
structs which can be concisely written with a static struct initializer
in http://crosreview.com/234648. Unfortunately we never really finished
that patch and in the mean time a different solution using the
fill_lb_gpio() helper got standardized onto most boards.
Still, that solution is not quite as clean and concise as the one we had
already designed, and it also wasn't applied consistently to all recent
boards (causing more boards with bad code to get added afterwards). This
patch switches all boards newer than Link to the better solution and
also adds some nicer debug output for the GPIOs while I'm there.
If more boards need to be converted from fill_lb_gpio() to this model
later (e.g. from a branch), it's quite easy to do with:
s/fill_lb_gpio(gpio++,\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\));/\t{\1, \2, \4, \3},/
Based on a patch by Furquan Shaikh <furquan@google.com>.
BUG=None
BRANCH=None
TEST=Booted on Oak. Ran abuild -x.
Change-Id: I449974d1c75c8ed187f5e10935495b2f03725811
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14226
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
In order to not muddle arch vs chipset implementations provide
a generic prog_segment_loaded() which calls platform_segment_loaded()
and arch_segment_loaded() in that order. This allows the arch variants
to live in src/arch while the chipset/platform code can implement
their own.
Change-Id: I17b6497219ec904d92bd286f18c9ec96b2b7af25
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14214
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Coreboot and most payloads support three basic pixel widths for the
framebuffer. It assumes 32 by default, but several chipsets need to
override that value with whatever else they're supporting. Our struct
edid contains multiple convenience values that are directly derived from
this (and other properties), so changing the bits per pixel always
requires recalculating all those dependents in the chipset code. This
patch provides a small convenience wrapper that can be used to
consistently update the whole struct edid with a new pixel width
instead, so we no longer need to duplicate those calculations
everywhere.
BUG=None
TEST=Booted Oak in all three pixel widths (which it conveniently all
supports), confirmed that images looked good.
Change-Id: I5376dd4e28cf107ac2fba1dc418f5e1c5a2e2de6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14158
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Certain chipsets don't have a memory-mapped boot media
so their code execution for stages prior to DRAM initialization
is backed by SRAM or cache-as-ram. The postcar stage/phase
handles the cache-as-ram situation where in order to tear down
cache-as-ram one needs to be executing out of a backing
store that isn't transient. By current definition, cache-as-ram
is volatile and tearing it down leads to its contents disappearing.
Therefore provide a shim layer, postcar, that's loaded into
memory and executed which does 2 things:
1. Tears down cache-as-ram with a chipset helper function.
2. Loads and runs ramstage.
Because those 2 things are executed out of ram there's no issue
of the code's backing store while executing the code that
tears down cache-as-ram. The current implementation makes no
assumption regarding cacheability of the DRAM itself. If the
chipset code wishes to cache DRAM for loading of the postcar
stage/phase then it's also up to the chipset to handle any
coherency issues pertaining to cache-as-ram destruction.
Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14140
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch adds support for an alternative ternary number system in
which group of GPIOs can be interpreted. In this system, the digit
combinations that would form a binary number (i.e. that contain no 'Z'
state) are used to represent the lower values in the way they're used in
the normal binary system, and all the combinations that do contain a 'Z'
are used to represent values above those. We can use this for boards
that originally get strapped with binary board IDs but eventually
require more revisions than that representation allows. We can switch
their code to binary_first base3 and all old revisions with already
produced boards will still get read as the correct numbers.
Credit for the algorithm idea goes to Haran Talmon.
BRANCH=None
BUG=None
TEST=Stubbed out the actual GPIO reading and simulated all combinations
of 4 ternary digits for both number systems.
Change-Id: Ib5127656455f97f890ce2999ba5ac5f58a20cf93
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14116
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order for a caller to utilize an rmodule's parameters section
after calling rmodule_stage_load() export the rmodule's parameter
pointer in struct rmod_stage_load.
Change-Id: I9cd51652cf8cdb3fae773256989851638aa1a60f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14139
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Change 13363 (555d6c2) introduced a bug where cbmem_add_bootmem() was
converted to use a new function. Unfortunately instead of passing a
pointer, NULL was passed due to type confusion. This change fixes that
problem by passing address of stack variable instead of NULL.
Change-Id: Ib8e1add3547cda01f71bf1dea14d3e58bdd99730
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
On platforms that didn't use 32-bit addresses, enabling the
CONFIG_TRACE option (Trace function calls) would break the build due
to a cast from a pointer of a different size.
This fixes this warning:
src/lib/trace.c:29:58: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
Change-Id: Iaab13c1891b6af7559ea6982ecc6e74c09dd0395
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13962
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Platforms that need to initialize WRDD package with the regulatory domain
information should implement function wifi_regulatory_domain.
A weak implementation is provided here.
Signed-off-by: fdurairx <felixx.durairaj@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/314384
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Commit-Queue: Hannah Williams <hannah.williams@intel.com>
Tested-by: Hannah Williams <hannah.williams@intel.com>
(cherry picked from commit c25d7221679d1fab830d614eeabfa3436bce6ac1)
BUG=chrome-os-partner:50516
BRANCH=glados
TEST=build and boot on chell
Change-Id: I1cbdf4e940b009c74ee8ed8f4fca85f4f5c943b2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 27bba336e620a2d3d331e350d4f46164e337fabc
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Change-Id: I84e2acd748856437b40bbf997bf23f158c711712
Original-Reviewed-on: https://chromium-review.googlesource.com/329291
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There was no 'early' call into the SoC code prior to console
getting initialized. Not having this enforces the mainboard to
drive the setup of the console which typically just ends up
calling into the SoC code. Provide a SoC early init call
to handle this without having to duplicate the same code
in mainboards utilizing the same SoC.
Change-Id: Ia233dc3ae89a77df284d6d5cf5b2b051ad3be089
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13791
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Fix an error where a variable named 'free' was shadowing the
function 'free'.
src/lib/memrange.c:293:73: error: declaration of 'free' shadows a global
declaration [-Werror=shadow]
Change-Id: Ie57194b392f8f00ed4fd5c76dab27299b00ae293
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13788
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch ports the LZ4 decompression code that debuted in libpayload
last year to coreboot for use in CBFS stages (upgrading the base
algorithm to LZ4's dev branch to access the new in-place decompression
checks). This is especially useful for pre-RAM stages in constrained
SRAM-based systems, which previously could not be compressed due to
the size requirements of the LZMA scratchpad and bounce buffer. The
LZ4 algorithm offers a very lean decompressor function and in-place
decompression support to achieve roughly the same boot speed gains
(trading compression ratio for decompression time) with nearly no
memory overhead.
For now we only activate it for the stages that had previously not been
compressed at all on non-XIP (read: non-x86) boards. In the future we
may also consider replacing LZMA completely for certain boards, since
which algorithm wins out on boot speed depends on board-specific
parameters (architecture, processor speed, SPI transfer rate, etc.).
BRANCH=None
BUG=None
TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on
Oak to be about ~20ms faster (cutting load times for affected stages
almost in half).
Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13638
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add all needed functions to fsp_baytrail so that reg_script can
do full iosf access. To keep it simple, this patch synchronises
iosf access between baytrail and fsp_baytrail.
Change-Id: Ic7f52d7d90c0fe3560fa5a5d96f7fc15062d66d1
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/13742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Only i386 has code to support bounce buffer. For others coreboot
would silently discard part of binary which doesn't work and is a hell to debug.
Instead just die.
Change-Id: I37ae24ea5d13aae95f9856a896700a0408747233
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13750
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add lb_arch_add_records() to allow the architecture code to
generically hook into the coreboot table generation.
BUG=chrome-os-partner:50214
BRANCH=glados
TEST=With all subsequent patches confirmed lb_arch_add_records() is
called when a strong symbol is provided.
Change-Id: I7c69c0ff0801392bbcf5aef586a48388b624afd4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13669
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Add the DEBUG_BOOT_STATE Kconfig value to enable boot state debugging.
Update include/bootstate.h and lib/hardwaremain.c to honor this value.
Add a dashed line which displays between the states.
Testing on Galileo:
* select DEBUG_BOOT_STATE in mainboard/intel/galileo/Kconfig
* Build and run on Galileo
Change-Id: I6e8a0085aa33c8a1394f31c030e67ab3d5bf7299
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13716
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reduce the debug output from FMAP lookups. When we had one or
two FMAP lookups in a boot this was not a big deal, but now that
we do many lookups it is a lot of unnecessary output duplication.
This change reduces these 3 lines:
FMAP: area VBLOCK_A found
FMAP: offset: 200000
FMAP: size: 65536 bytes
To just one line:
FMAP: area VBLOCK_A found @ 200000 (65536 bytes)
And makes the header output only print once:
FMAP: Found "FMAP" version 1.0 at c10000.
FMAP: base = 0 size = 1000000 #areas = 29
BUG=chrome-os-partner:40635
BRANCH=glados
TEST=boot on chell and enjoy non-truncated memconsole
Change-Id: Ib5862b8bfad113a700faae89089557094aa6d499
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6890f36536d4ae6fc4988fc8191b0cff4e33e2e6
Original-Change-Id: Ifefee1ab26e6ee406de552880fbbd5b7916fcadd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/326887
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13695
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We've had a second version of ulzma() that would check the input and
output buffer sizes in libpayload for a while now. Since it's generally
never a bad idea to double-check for overruns, let's port it to coreboot
and use it where applicable. (This requires a small fix in the four byte
at a time read optimization we only have in coreboot, since it made the
stream counter hit the end a little earlier than the algorithm liked and
could trigger an assertion.)
BRANCH=None
BUG=None
TEST=Booted Oak, Jerry and Falco.
Change-Id: Id566b31dfa896ea1b991badf5a6ad9d075aef987
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13637
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch generalizes the approach previously used for ARM32
TTB_SUBTABLES to "auto-detect" whether a certain region was defined in
memlayout.ld. This allows us to get rid of the explicit Kconfig for the
TIMESTAMP region, reducing configuration redundancy and avoiding
confusion when setting up future boards.
(Removing armv4/bootblock_simple.c because it references this Kconfig
and it is a dead file that I just forgot to remove in CL:12076.)
BRANCH=None
BUG=None
TEST=Booted Oak and confirmed that all pre-RAM timestamps are still
there. Built Nyan and Falco.
Change-Id: I557a4b263018511d17baa4177963130a97ea310a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13652
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since we're reaching the timestamp limit on certain platforms (both for
the pre-RAM cache and the final CBMEM region), this patch increases the
amount of space for both. In the pre-RAM case, it achieves this by
always utilizing the full size of the TIMESTAMP() region allocated in
memlayout.ld, rather than arbitrarily limiting it to some constant.
BRANCH=None
BUG=None
TEST=Booted Oak and confirmed that I can once again see all pre-RAM
timestamps after picking in the LZ4 patch series.
Change-Id: Iabb075a48d8d1e3e1811afeaad5ab47e7846c972
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13651
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch added nhlt_soc_serialize_oem_overrides and
nhlt_serilalize_oem_overrides to be able to override oem_id and
oem_table_id.board file can pass specific string by calling
nhlt_soc_serialize_oem_overrides
kernel use these two fields to construct a topology binary name
if the designate file is not found a default dfw_sst.bin will be used
it is optional.
BUG=chrome-os-partner:49570
BRANCH=glados
TEST=Build & Booted kunimitsu board. Verified that kernel
can read new strings.
Change-Id: I00b64fb8bb63de601d3116e0b8941057c1efa230
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 374ce08b2d8a2f4e5dd7f51eacb505dbb77fd171
Original-Change-Id: I03623c8ac81efb5a5ea3ec9c6cd604d2e9294022
Original-Signed-off-by: Fang, Yang A <yang.a.fang@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/322860
Original-Commit-Ready: Yang Fang <yang.a.fang@intel.com>
Original-Tested-by: Yang Fang <yang.a.fang@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13602
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The VBNV region size is determined by vboot and is not really
configurable. Only the CMOS implementation defined this config
variable so switch it to use VBNV_BLOCK_SIZE defined by vboot
in vbnv_layout.h instead.
This requires updating the broadwell/skylake cmos reset functions
to use the right constant.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=manually tested on chell
Change-Id: I45e3efc2a22efcb1470bbbefbdae4eda33fc6c96
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e2b803ff3ac30ab22d65d1e62aca623730999a1d
Original-Change-Id: I4896a1a5b7889d77ad00c4c8f285d184c4218e17
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324520
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13598
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Some of the functions within bootmode.c may be required
by boards in verstage. Therefore, allow this file to be built
in verstage.
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Built chell w/ bootmode.c dependencies in separate verstage.
Change-Id: Id291c1b5cc6594c3ee16c7c3385e682addc0efb6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 084b620e12e7f948087786c0e34d5999a73137a5
Original-Change-Id: I2207819ec1490767cb1cf4b92e34e714783c1c22
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324071
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13581
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Selecting UNCOMPRESSED_RAMSTAGE prevents lzma.c from being compiled for
romstage. Adjust the logic in rmodule.c to prevent calls to the ulzma
routine when UNCOMPRESSED_RAMSTAGE is selected.
TEST=Build and run on Galileo
Change-Id: I7409e082baab3c2a086c57ad5aa9844ba788c7cd
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13591
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The COVERAGE_MAGIC macro has a trailing `4' on it, which makes it a
64-bit large integer, as opposed to a 32-bit unsigned integer, as
originally designated in `util/cbmem/cbmem.c'. Remove this number so
building with CODE_COVERAGE will succeed.
Change-Id: Ib5d7f2704a4c092c3eca6f62e219edb30950d793
Signed-off-by: Jean Lucas <jean@4ray.co>
Reviewed-on: https://review.coreboot.org/13520
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
zeroptr is a linker object pointing at 0 that can be used to thwart
GCC's (and other compilers') "dereferencing NULL is undefined"
optimization strategy when it gets in the way.
Change-Id: I6aa6f28283281ebae73d6349811e290bf1b99483
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: https://review.coreboot.org/12294
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
There were several spots in the tree where the path to a per class
object file was hardcoded. To make use of the src-to-obj macro for
this, it had to be moved before the inclusion of subdirs. Which is
fine, as it doesn't have dependencies beside $(obj).
Tested by verifying that the resulting coreboot.rom files didn't change
for all of Jenkins' abuild configurations.
Change-Id: I2eb1beeb8ae55872edfd95f750d7d5a1cee474c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13180
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When C_ENVIRONMENT_BOOTBLOCK is selected link bootblock using the
memlayout.ld scripts and infrastructure. This allows bootblock on
x86 to utilize all the other coreboot infrastructure without
relying romcc.
Change-Id: Ie3e077d553360853bf33f30cf8a347ba1df1e389
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13069
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Instead of solely relying on malloc for building up an address space
for the range_entry objects allow one to supply a list of free entries
to memranges_init_empty(). Doing this and only calling malloc() in
ramstage allows a memranges oboject to be used in a malloc()-free
environment.
Change-Id: I96c0f744fc04031a7ec228620a690b20bad36804
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13020
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
Mimicking change I7037308d2, always compile mdelay for romstage.
The boards that #included delay.c in the romstage now rely on the linker
instead, which is a desirable cleanup.
Change-Id: I7e5169ec94e5417536e967194e8eab67381e7c98
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13115
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We already do this for lines with all zeroes, so it makes sense to
treat all ones the same, for symmetry.
Change-Id: I4b637b07a49e0c649331aa200995b474dd9a2682
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/12872
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
commit a8aef3ac (cbfs_spi: Initialize spi_flash when initializing
cbfs_cache) introduced a bug that makes the rarely-used unified
CBFS_CACHE() memlayout macro break when used in conjunction with
cbfs_spi.c (since that macro does not define a separate
postram_cbfs_cache region). This patch fixes the problem by making all
three region names always available for both the unified and split
macros in every stage (and adds code to ensure we don't reinitialize
the same buffer again in romstage, which might be a bad idea if
previous mappings are still in use).
BRANCH=None
BUG=None
TEST=Compiled for both kinds of macros, manually checked symbols in
disassembled stages.
Change-Id: I114933e93080c8eceab04bfdba3aabf0f75f8ef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0f270f88e54b42afb8b5057b0773644c4ef357ef
Original-Change-Id: If172d9fa3d1fe587aa449bd4de7b5ca87d0f4915
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/318834
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12933
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These files provide symbols needed by console and uart drivers. This
was not an issue in the past, as we were not setting up a C
environment this early in the boot process.
Change-Id: Ied5106ac30a68971c8330e8f8270ab060994a89d
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/12869
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Mediatek's bootblock needs mdelay, which depends on a udelay
implementation. Compiling the file for bootblock poses no harm:
Either udelay exists (in which case mdelay is usable) or it doesn't in
which case we see exactly the same kind of build time error (just with
udelay instead of mdelay).
Change-Id: I7037308d2d79c5cb1b05bb2b57a0912ad11cd7a6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13049
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Intel's SST (Smart Sound Technology) employs audio support
which may not consist of HDA. In order to define the topology
of the audio devices (mics, amps, codecs) connected to the
platform a NHLT specification was created to pass this
information from the firmware to the OS/userland.
BUG=chrome-os-partner:44481
BRANCH=None
TEST=Tested on glados. Audio does get emitted and some mic recording
works.
Change-Id: I8a9c2f4f76a0d129be44070f09d938c28a73fd27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2472af5793dcffd2607a7b95521ddd25b4be0e8c
Original-Change-Id: If469f99ed1a958364101078263afb27761236421
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/312264
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/12935
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
To continue sharing more code between the tools and
coreboot proper provide cbfs parsing logic in commonlib.
A cbfs_for_each_file() function was added to allow
one to act on each file found within a cbfs. cbfs_locate()
was updated to use that logic.
BUG=chrome-os-partner:48412
BUG=chromium:445938
BRANCH=None
TEST=Utilized and booted on glados.
Change-Id: I1f23841583e78dc3686f106de9eafe1adbef8c9f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12783
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Now that only CBFS access is supported for finding resources
within the boot media the assets infrastructure can be removed.
Remove it.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12690
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Chrome OS verified boot path supported multiple CBFS
instances in the boot media as well as stand-alone assets
sitting in each vboot RW slot. Remove the support for the
stand-alone assets and always use CBFS accesses as the
way to retrieve data.
This is implemented by adding a cbfs_locator object which
is queried for locating the current CBFS. Additionally, it
is also signalled prior to when a program is about to be
loaded by coreboot for the subsequent stage/payload. This
provides the same opportunity as previous for vboot to
hook in and perform its logic.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
CQ-DEPEND=CL:307121,CL:31691,CL:31690
Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12689
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The proper return value to signal an error from cbfs_prog_stage_load()
is -1, not 0.
Change-Id: Ie53b0359c7c036e3f809d1f941dab53f090b84ab
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/12633
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Most devices do not use SPI before they initialize CBMEM. This change
initializes spi_flash in the CBMEM_INIT_HOOK to initialize the postram
cbfs cache so it is not overwritten when boot_device_init is called
later.
BUG=chromium:210230
BRANCH=none
TEST=confirm that the first cbfs access can occur before RAM initialized
and after on panther and jerry.
Change-Id: If3b6efc04082190e81c3773c0d3ce116bb12421f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0ab242786a16eba7fb423694f6b266e27d7660ec
Original-Change-Id: I5f884b473e51e6813fdd726bba06b56baf3841b0
Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/314311
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12601
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently the CBFS mmap cannot be accessed at the beginning of romstage
because it waits until DRAM is initialized. This change first loads CBFS
into SRAM and then switches to using DRAM as the backing once it is
initialized.
BUG=chromium:210230
BRANCH=none
TEST=confirm that the cbfs can be access at the beginning and end of
romstage on different boards.
Change-Id: I9fdaef392349c27ba1c19d4cd07e8ee0ac92dddc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ccaaba266386c7d5cc62de63bdca81a0cc7c4d83
Original-Change-Id: Idabfab99765b52069755e1d1aa61bbee39501796
Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/312577
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12586
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If the timestamp table gets corrupted (separate issue), the
timestamp_sync_cache_to_cbmem() function may add a large number of bogus
timestamp entries.
This causes a flood of "ERROR: Timestamp table full". With logs going
to a serial console, this renders the system essentially unbootable.
There really isn't a need to log that more than once, so log it when the
last slot in the timestamp table is filled.
Change-Id: I05d131183afceca31f4dac91c5edc95cfb1e443f
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: http://review.coreboot.org/12506
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
hexdump currently rounds up length to a multiple of 16.
So, hexdump(ptr, 12) prints 16 hex digits, including 4 garbage bytes.
That isn't desirable and is easy to fix.
Change-Id: I86415fa9bc6cdc84b111e5e1968e39f570f294d9
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: http://review.coreboot.org/12486
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There are few drawbacks reading VPD from SPI flash in user land, including
"lack of firmware level authority" and "slow reading speed".
Since for many platforms we are already reading VPD in firmware (for
example MAC and serial number), caching the VPD data in CBMEM should
will speed up and simplify user land VPD processing without adding
performance cost.
A new CBMEM ID is added: CBMEM_ID_VPD, referring to a structure containing
raw Google VPD 2.0 structure and can be found by the new LB_TAG_VPD in
Coreboot tables.
BRANCH=smaug
BUG=chrome-os-partner:39945
TEST=emerge-smaug coreboot chromeos-bootimage # and boots successfully.
[pg: lots of changes to make it work with what happened in upstream
since 2013]
Change-Id: If8629ac002d52abed7b480d3d06298665613edbf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 117a9e88912860a22d250ff0e53a7d40237ddd45
Original-Change-Id: Ic79f424a6e3edfb6c5d168b9661d61a56fab295f
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/285031
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12453
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The EDID parsing code continued to update _some_ fields of the output
edid but not others if "did_detailed_timing" was already set. It also
then went on to print out this halfway mix of modes each time, despite
the fact that it didn't really update everything.
Let's fix that. We'll reduce code changes by using a temporary copy of
data in detailed_block() and then we'll copy it back if we decide we
should update.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=No more bogus printouts
Change-Id: Idbfa233e0997244c22ef21c892c4473a91621821
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4d69999cdd7ce3cd2c9332ab3f22ea8eb4b6f2e9
Original-Change-Id: Ia72cac7fda2772f26477e43237678fa30feca584
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309541
Original-Reviewed-on: https://chromium-review.googlesource.com/309609
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12444
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The hardcoded clock value for 640x480 was 25.175 MHz. That's a valid
clock to use, but is quite hard to make a non-jittery clock from PLLs.
It's much easier to make 25.200 MHz, so let's do that.
The difference between the two modes is 59.9 Hz vs. 60 Hz and it seems
better to make a non-jittery 60 Hz rather than a very jittery 59.9 Hz.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Insignia monitor works, so do others
Change-Id: I8aa124d04a90f5dcf9cfa923ed3b693fbb4a06d8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e32ce13462101dc60cfed60b6948b7597e93525a
Original-Change-Id: Ia9804afe8011a915e4bec306e863d34ad7e27be5
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309540
Original-Reviewed-by: Stphane Marchesin <marcheu@chromium.org>
Original-(cherry picked from commit 7f32c9f460991e5e3b947117d6ae4080e630a532)
Original-Reviewed-on: https://chromium-review.googlesource.com/309576
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12443
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The set to say that a standard timing was supported was not properly in
the "if" test. That meant that even when standard timings weren't
supported, we thought that they were. That had the side effect of never
using the detailed mode.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=Adafruit panel works now
Change-Id: Ide3ed6c5682840f808d854755dac58e9057e6bda
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c99d3ee8d163fc6be207c5a7df2a7aecd7af7849
Original-Change-Id: Ib67735219fd28516857d9b63f1ba156573f1bea3
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309521
Original-(cherry picked from commit 4e4c2816e2239299bc02e3a57fb18056db62b56c)
Original-Reviewed-on: https://chromium-review.googlesource.com/309552
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12442
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
