| Age | Commit message (Collapse) | Author |
|---|
|
Now that cbfs is adding more metadata in the cbfs file
header one needs to access that metadata. Therefore,
add struct cbfsf which tracks the metadata and data
of the file separately. Note that stage and payload
metadata specific to itself is still contained within
the 'data' portion of a cbfs file. Update the cbfs
API to use struct cbfsf. Additionally, remove struct
cbfsd as there's nothing else associated with a cbfs
region aside from offset and size which tracked
by a region_device (thanks, CBFS_ALIGNMENT!).
BUG=None
BRANCH=None
TEST=Built and booted through end of ramstage on qemu armv7.
Built and booted glados using Chrome OS.
Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11679
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Up to now, the multi-CBFS code path merely looked up files in the "boot
ro" image (ie. the default), disregarding the specified fmap region to
use for CBFS.
The code still relies on the master header being around, which on the
upside allows it to skip an offset at the beginning of the region (eg.
for ARM bootblocks).
This will change later (both the reliance on the master header and the
presence of the bootblock like this).
Change-Id: Ib2fc03eac8add59fc90b4e601f6dfa488257b326
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11805
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
mohonpeak is the reference board for Rangeley. I doubt anyone uses it
or cares about it. We jokingly refer to it as "Moron Peak". It's code
with no known users, so we shouldn't be hauling it around for the
eventuality that someone might use it in the future.
Change-Id: Id3c9fc39e1b98707d96a95f2a914de6bbb31c615
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11790
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
We already have two other code paths for this silicon. Maintaining the
FSP path as well doesn't make much sense. There was only one board to
use this code, and it's a reference board that I doubt anyone still
owns or uses.
Change-Id: I4fcfa6c56448416624fd26418df19b354eb72f39
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11789
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
Certain chipsets provide their own main symbol for verstage.
Therefore, it's necessary to know this so that those chipsets
can leverage the common verstage flow.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built nyan using this option.
Change-Id: If80784aa47b27f0ad286babcf0f42ce198b929e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11777
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In order to support FSP 1.1 relocation within cbfstool
the relocation code needs to be moved into commonlib.
To that end, move it. The FSP 1.1 relocation code binds
to edk2 UEFI 2.4 types unconditionally which is separate
from the FSP's version binding.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: Ib2627d02af99092875ff885f7cb048f70ea73856
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11772
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
vboot_handoff_flag was duplicating the logic to grab the handoff info, that is
already made available with vboot_get_handoff_info.
This uses vboot_get_handoff_info in vboot_handoff_flag instead.
Change-Id: I28f1decce98f988f90c446a3a0dbe7409d714527
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11498
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The vboot verification in a stage proper is unified
replacing duplicate code in the tegra SoC code. The
original verstage.c file is renamed to reflect its
real purpose. The support for a single verstage flow
is added to the vboot2 directory proper.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados.
Change-Id: I14593e1fc69a1654fa27b512eb4b612395b94ce5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11744
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This moves a few vboot-prefixed functions that were defined in chromeos.c to
vboot_common.c, since those are only relevant to vboot and depend on the vboot
handoff data. This allows more separation between CONFIG_CHROMEOS and what
CONFIG_CHROMEOS selects, so that each separate option (such as
CONFIG_VBOOT_VERIFY_FIRMWARE) can be enabled separately.
Thus, the actual definitions of these functions will only be declared when
CONFIG_VBOOT_VERIFY_FIRMWARE is set, so the check before calling
vboot_skip_display_init in bootmode was also adapted.
Change-Id: I52f8a408645566dac0a2100e819c8ed5d3d88ea5
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11497
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This removes the dependency on chromeos and vboot for the sw write protect state
function: vboot_get_sw_write_protect, renamed to get_sw_write_protect_state to
both reflect this change and become consistent with the definition of
get_write_protect_state that is already in use.
Change-Id: I47ce31530a03f6749e0f370e5d868466318b3bb6
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11496
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Currently, erase operation only works if the region is sector-aligned.
These asserts ensure we can erase the region when it's all used up.
Erase operation can be updated to handle unaligned erases by read,
update, write-back cycle. However, these asserts will still remain useful
in case the adjacent region contains critical data and mis-updating it
can cause a critical failure.
Additionaly we should write a FAFT test but it's more reliable to catch
it here since FAFT can fail in many ways.
BUG=none
BRANCH=master
TEST=tested on samus using misaligned nvram region
Change-Id: I3add4671ed354d9763e21bf96616c8aeca0cb777
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fc001a4d3446cf96b76367dde492c3453aa948c6
Original-Change-Id: Ib4df8f620bf7531b345364fa4c3e274aba09f677
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297801
Reviewed-on: http://review.coreboot.org/11654
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This is required the BLOB change Icb7a4f07
"AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4)"
This is tested on Bettong Alfa(DDR3) and Beta(DDR4). Both of the
boards can boot to Windows 8.1. PCIe slots, USB and NIC work.
Change-Id: Ibe141c16f8f9eac2adc5d5f45a1f354fb2a7f33c
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/11148
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
|
|
This is required the BLOB change I67817dc59
AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1).
This is tested on Olive Hill Plus. The board can boot to Windows 7.
PCIe slot, USB and NIC work.
Change-Id: I605df26b61bdffabd74846206ad0b7bf677ebed1
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/11225
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
FSP has some unique attributes which makes integration
cumbersome:
1. FSP header files do not include the types they need. Like
EDKII development it's expected types are provided by the
build system. Therefore, one needs to include the proper
files to avoid compilation issues.
2. An implementation of FSP for a chipset may use different
versions of the UEFI PI spec implementation. EDKII is a
proxy for all of UEFI specifications. In order to provide
flexibility one needs to binding a set of types and
structures from an UEFI PI implementation.
3. Each chipset FSP 1.1 implementation has a FspUpdVpd.h
file which defines it's own types. Commonality between
FSP chipset implementations are only named typedef
structs. The fields within are not consistent. And
because of FSP's insistence on typedefs it makes it
near impossible to forward declare structs.
The above 3 means one needs to include the correct UEFI
type bindings when working with FSP. The current
implementation had the SoC picking include paths in the
edk2 directory and using a bare <uefi_types.h> include.
Also, with the prior fsp_util.h implementation the SoC's
FSP FspUpdVpd.h header file was required since for providing
all the types at once (Generic FSP 1.1 and SoC types).
The binding has been changed in the following manner:
1. CONFIG_UEFI_2_4_BINDING option added which FSP 1.1
selects. No other bindings are currently available,
but this provides the policy.
2. Based on CONFIG_UEFI_2_4_BINDING the proper include
paths are added to the CPPFLAGS_common.
3. SoC Makefile.inc does not bind UEFI types nor does
it adjust CPPFLAGS_common in any way.
4. Provide a include/fsp directory under fsp1_1 and
expose src/drivers/intel/fsp1_1/include in the
include path. This split can allow a version 2,
for example, FSP to provide its own include files.
Yes, that means there needs to be consistency in
APIs, however that's not this patch.
5. Provide a way for code to differentiate the FSP spec
types (fsp/api.h) from the chipset FSP types
(fsp/soc_binding.h). This allows for code re-use that
doesn't need the chipset types to be defined such as
the FSP relocation code.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Change-Id: I894165942cfe36936e186af5221efa810be8bb29
Reviewed-on: http://review.coreboot.org/11606
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Tested-by: build bot (Jenkins)
|
|
There's no reason to have a separate verstage.ld now
that there is a unified stage linking strategy. Moreover
verstage support is throughout the code base as it is
so bring in those link script macros into the common
memlayout.h as that removes one more specific thing a
board/chipset needs to do in order to turn on verstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
With VIRTUAL_DEV_SWITCH moved under 'config CHROMEOS' in all of the
mainboards, this is no longer needed.
Change-Id: I5fbea17969f6b0c3b8a5dcd519ab9d36eb2ad6f1
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11337
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
One may prefer to include vboot from another directory than 3rdparty for
convenience. This is especially the case in Libreboot, where 3rdparty is not
checked out at all.
Change-Id: I13167eb604a777a2ba87c3567f134ef3ff9610e4
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11116
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
$(obj) might be defined either as a relative or an absolute path. Thus, it has
to be filtered out before adding $(top) to it (in case of an absolute path) when
building vboot. It is then provided separately in CFLAGS (as an absolute path).
In addition, VB2_LIB inherits $(obj), so it might also already be an absolute
path, and prefixing $(top) to it doesn't apply. Thus, the absolute path to it
should be passed to the vboot make command.
Change-Id: I13e893ebdf22c4513ee40d9331a30ac7de8f9788
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11120
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
:'<,'>s,\ *$,,
Change-Id: I9fca0e12f02d6fff4644abacecd4a31cea64bbc1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11024
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The AMD AGESA binaryPI sources were incorrectly committed to
3rdparty/blobs. Move them from blobs to vendorcode and fix
Kconfig and Makefile.inc to match.
Change-Id: I55a777553c1203464d7f7f4293b361fedcfa3283
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10982
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The *_SELECTED Kconfig variables are not needed with the
options contained within "if CPU_AMD_AGESA_BINARY_PI"
introduced in e4c17ce8. It also removes the need to
source and select the default prior to selecting the
AGESA source or AGESA PI option.
Change-Id: Iffa366f575f7f155bd6c7e7ece2a985f747c83be
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10981
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Make SB800 code compile with x64 compiler
These fixes probably apply 1:1 to the other SB components
in that directory.
Change-Id: I9ff9f27dff5074d2faf41ebc14bfe50871d9c7f7
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10573
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
Change-Id: Ic6b3c3382a6d3fdc6d716ea899db598910b4fe3e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10581
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
1. Use enable_imc_thermal_zone to enable fan control.
2. The ACPI method ITZE works on Ubuntu 14.04 and Windows 7
but does not work on Windows 8, so I didn't use it.
After this issue is fixed, I'll add ACPI_ENABLE_THERMAL_ZONE
in bettong/Kconfig.
3. Fan control works on Bettong. I used "APU Validation Toolkit"
to test on Windows 8. This tool can put load to APU. The fan's
behaviour is just like bettong/fchec.c defined. When the temperature
is 40 Celsius, the fan start to run.
Change-Id: I0fc22974a7a7cf3f6bdf5f1c66be95219a177e12
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/10721
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Binary PI doesn't provide fan control lib.
HwmLateService.c and ImcLib.c are ported from Kabini PI.
I have tested on AMD Bettong. The two files work.
Change-Id: Ia4d24650d2a5544674e9d44c502e8fd9da0b55d3
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/10719
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 0.5K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f
Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236978
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
TEST=built for samus and veyron_jerry
Change-Id: I7173f46d2ed2e323bff227a484c32c4bb6f6c828
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: http://review.coreboot.org/11028
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Baytrail FSP Gold4 release added 5 PCD options. Update UPD_DATA_REGION
structure to include these new PCD options and initialized the setting
when given in devicetree.cb.
Change-Id: Ic343e79479464972455e42f9352b3bb116c6f80f
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/10838
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
|
|
Assume that it's 64 byte.
Change-Id: I168facd92f64c2cf99c26c350c60317807a4aed4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10919
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Bay Trail SOCs do not integrate LAN controller hence Baytrail FSP has
no LAN control function. Remove PcdEnableLan option from
UPD_DATA_REGION structure.
Change-Id: I9b4ec9d72c8c60b928a6d9755e94203fb90b658f
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/10837
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This can be a problem with freshly updated devices that are periodically
powered on while closed (as explained in the bug report).
In this case, just don't count down. In case of actual errors (where we
want the system to fall back to the old code), this now means that the
retries have to happen with the lid open.
Bump vboot's submodule revision for the vboot-side support of this.
BUG=chromium:446945
TEST=to test the OS update side, follow the test protocol in
https://code.google.com/p/chromium/issues/detail?id=446945#c43
With a servo, it can be sped up using the EC console interface to start
the closed system - no need to wait 60min and plugging in power to get
to that state.
Change-Id: I0e39aadc52195fe53ee4a29a828ed9a40d28f5e6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10851
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change the FrameBufferSize field from UINT64 to UINT32 to match the
Platform Initialization 2.4 specification.
BRANCH=none
BUG=None
TEST=Build and run on cyan
Change-Id: I28dc0608675ed5840863ecd15bd2f57e6b2f4c1d
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10834
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Fix up all the code that is using / to use >> for divisions instead.
Change-Id: I8a6deb0aa090e0df71d90a5509c911b295833cea
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10819
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The many different places to put vboot verification in can be confusing.
Instead of using libverstage (which isn't enough since those functions are
sometimes called outside that, too), mention all stages where it can resides
explicitly.
Change-Id: I9360face822ada7018a1cfdfced8da29b347cbb4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10722
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
That way they're available wherever the verstage code ends up, bootblock,
verstage or romstage.
Change-Id: I6e59a40761f95a98d96a9b72e3bbcc59caae9b1a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10706
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Not all devices have a lid switch, so we need to state this
somehow. Since the alternative would be to extend get_lid_switch()'s
semantics to become a tri-state (open, closed, N/A), do this
through Kconfig.
BRANCH=none
BUG=chromium:446945
TEST=none
Change-Id: Icc50f72535f256051a59925a178fb27b2e8f7e55
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d20a1d1a22d64546a5d8761b18ab29732ec0b848
Original-Change-Id: Ie8ac401fbaad5b5a9f1dec2b67847c81f4cc94aa
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/273850
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Queue: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10692
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Iaadbd52d948000d1ed46865b83bdb0f4926ca429
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10677
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of calling the init function to clear out vboot2 data structures in
multiple places, move the function and call close to verstage_main().
Change-Id: If42e18a8e4581f22f7a7aced70ccbe3188bb0cd5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10701
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Icc3cf64f259d4ebd7900ad91163276774e5422ab
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10661
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Otherwise it'll determine some offsets from uninitialized data and hilarity
ensues.
Change-Id: I6a671987857cfd3f3cd6078aebd13dd09fc79020
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10660
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add new GUID for FSP.
BRANCH=none
BUG=None
TEST=Build and run on strago
Change-Id: I539a59b513f67535436f581e0a79ab53f05682ca
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10587
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I61a9f65a1ac4c95096d0ff071a95984cf219caa8
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10593
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
|
|
VPD strings are not null terminated, so we can't use strcpy
on them in cros_vpd_gets.
BUG=none
BRANCH=none
TEST=add serial_number followed by cam_calib_data to VPD on smaug;
make sure that smaug boots and serial number matches exactly (no garbage)
Change-Id: Id72885517b3d0b1934ba329c1ef0d89a67bd2bb4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 56bbe6688b11043360a046a250d1ea93db4d9f0e
Original-Change-Id: I811dfc2f0830a91410eb69961a6565080ff78267
Original-Signed-off-by: Stephen Barber <smbarber@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/280836
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-on: http://review.coreboot.org/10627
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Instead of having three copies of amdlib, the glue code for Agesa,
let's share the code between all implementations (and come up with
a versioned API if needed at some point in the future)
Change-Id: I38edffd1bbb04785765d20ca30908a1101c0dda0
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10507
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Add all of the PI source that will remain part of coreboot to
build with a binary AGESA PI BLOB. This includes the gcc makefiles,
some Kconfig, and the AGESA standard library functions.
Change vendorcode Makefile and Kconfig so that they can compile
AMD library files and use headers from outside the coreboot/src
tree.
Change-Id: Iad26689292eb123d735023dd29ef3d47396076ea
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/10416
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some patches landed that didn't introduce the Kconfig
options for additional firmware components. Add them.
Change-Id: I0a0b7f0291389d126a7c491f710618a278cfb5d7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The SOUTHBRIDGE_INTEL_FSP_I89XX symbols are never defined in any Kconfig
file or used anywhere in the existing coreboot tree. Removing them as
unnecessary. If the southbridge code ever gets uploaded, these can be
re-added at that point.
Change-Id: I36f9ca8e25e08ce154d10ea9d764a73095590244
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10436
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
As there can be more than one source of firmware assets this
patch generalizes the notion of locating a particular asset.
struct asset is added along with some helper functions for
working on assets as a first class citizen.
Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10264
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
