MRC only uses the SPD data for the first index, and ignores the rest.
Moreover, index 1 corresponds to the second DIMM on the first channel,
which does not exist on ULT (only one DIMM per channel is supported).
Copy the SPD to the first DIMM on channel 1 instead. Adjust northbridge
code to retrieve the serial number from the correct SPD data block.
Tested on Google Wolf, both channels are still correctly detected.
Change-Id: Ic60ff75043e6b96a59baa9e5ebffb712a100a934
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The artifacts can then be run on test system.
Change-Id: I2300af7b9be5fbb42a874566971854b93292885e
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51293
Reviewed-by: Harshit Sharma <harshitsharmajs@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SLP_S0_GATE# signal is used in conjunction with the PCH's SLP_S0# to
provide an indication to the rest of the platform when the system is
entering its software-initiated low-power state (i.e. S0ix). This lets
the platform distinguish between opportunistic S0ix entry and the runtime
suspend mechanism.
BUG=b:180401723
TEST=abuild
Change-Id: I7fe2e3707465778baf56283617a8485a94f2dbca
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50881
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
OIPG is a Package. Define the type so it doesn't default to UnknwonObj.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I068ed4ae95967aa884506c4971ee2e2dba7b5e4f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51537
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes the unknown reference errors for OIPG. Since Majolica
doesn't actually have any of the GPIOs ChromeOS uses, we leave
the arrays empty.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifeae84e0ccab187a4e7131cd6ea9e1336d79df67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51536
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GPIOs should be configured in ramstage even if they are configured in an
earlier stage.
BUG=b:180721208
TEST=builds
Signed-off-by: Mathew King <mathewk@chromium.org>
Change-Id: I9896db41dbe2812856357510bc4420482e73ab3d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51547
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It is currently only used in this translation unit.
Signed-off-by: Mathew King <mathewk@chromium.org>
Change-Id: Ib779a38306fb45320f3e4eb71f63630023d59906
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51535
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When running coreboot unit tests on a recent clang version, it helpfully
throws an error on memset(..., 0xAA, 0) because it thinks you probably
made a typo and meant to write memset(..., 0, 0xAA) instead. I mean, who
would ever memset() a buffer of zero bytes, right? Unfortunately, unit
tests for memset() want to do exactly that. Wrapping the argument in
parenthesis silences the warning.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I21aeb5ec4d6ce74d5df2d21e2f9084b17b3ac6e3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51617
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
In case the VPD variable cannot be read.
Change-Id: I79fae6f4b4aad91a4040387ca6ddee8dfcc34d90
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51559
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: I2e4f1d1551141c6225e762631e52d71357112425
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51562
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Configure early GPIOs in verstage if it is run in PSP otherwise
configure them in bootblock.
BUG=b:182211161
TEST=builds
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Ic1faeea59462319c1652c69034b4dde01669e13b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51493
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Mathew King <mathewk@chromium.org>
Don't use 'is' and 'is not' for comparison with literals. This fixes
warnings like:
.../mbn_tools.py:1097: SyntaxWarning: "is not" with a literal. Did you mean "!="?
if int(off) is not 0:
Change-Id: Idd68acfcbd1a07cbbb9ab41d9581c4850a431445
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
If the board settings aren't valid, Port E uses the settings for earlier
board revisions, which is undesired. Disable Port E by default on R04+.
Change-Id: I03bd50b915a2120283b77179debaa735bb7ef027
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51529
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The data needed to compute the permanent smbase for a core, when
relocating, is present in the ramstage data which the stub located at
DEFAULT_SMBASE (0x30000) calls back to. There is no need to fetch this
from via the stub params.
Change-Id: I3894c39ec8cae3ecc46b469a0fdddcad2a8f26c4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50763
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is only consumed by the stub and not by the relocation handler or
the permanent handler, so move it out of the runtime struct.
Change-Id: I01ed0a412c23c8a82d88408be058a27e55d0dc4d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
These stub params need to be synced with the code in smm_stub.S and
are consumed by both the smmloader and smmloader_v2. So it is better
to have the definition located in one place.
Change-Id: Ide3e0cb6dea3359fa9ae660eab627499832817c9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50761
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The idea is to get rid of having 2 different smmloaders so add this
option only to qemu/q35 to get it buildtested.
Change-Id: Id4901784c4044e945b7f258b3acdc8d549665f3a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51525
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested with and without -enable-kvm, with -smp 1 2 and 32.
Change-Id: I612cebcd2ddef809434eb9bfae9d8681cda112ef
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48262
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All platforms implement those and using a no-op function is not
expected, so it is better to fail the build if the soc specific code
is not implemented.
Change-Id: Id946f5b279dcfa6946381b9a67faba6b8c1ca332
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51522
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We are currently writing invalid ACPI tables. We are missing the GPP
ACPI names. There is an assert in acpi_device_write_pci_dev that checks
to see if we have a scope, but by default asserts don't halt, so we were
writing a NULL scope.
BUG=b:171234996
TEST=Boot majolica and dump ACPI tables
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I6a861ad1b9259ac3b79af76e18a9354997b0491e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51542
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In pursuit of the goal of eliminating the proliferation of raw region
devices to represent CBFS files outside of the CBFS core code, this
patch removes the get_spd_cbfs_rdev() API and instead replaces it with
spd_cbfs_map() which will find and map the SPD file in one go and return
a pointer to the relevant section. (This makes it impossible to unmap
the mapping again, which all but one of the users didn't bother to do
anyway since the API is only used on platforms with memory-mapped
flash. Presumably this will stay that way in the future so this is not
something worth worrying about.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iec7571bec809f2f0712e7a97b4c853b8b40702d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch rewrites some parts of the Agesa refcode loader to eliminate
the passing of raw rdevs between functions, so that we can get rid of
cbfs_boot_locate() in favor of more high-level APIs.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I2a6e1158ed7425c69c214462bc52e8694a69997a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50349
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In pursuit of the eventual goal of removing cbfs_boot_locate() (and
direct rdev access) from CBFS APIs, this patch replaces all remaining
"simple" uses of the function call that can easily be replaced by the
newer APIs (like cbfs_load() or cbfs_map()). Some cases of
cbfs_boot_locate() remain that will be more complicated to solve.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Icd0f21e2fa49c7cc834523578b7b45b5482cb1a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The CBFS stage header is part of the file data (not the header) from
CBFS's point of view, which is problematic for verification: in pre-RAM
environments, there's usually not enough scratch space in CBFS_CACHE to
load the full stage into memory, so it must be directly loaded into its
final destination. However, that destination is decided from reading the
stage header. There's no way we can verify the stage header without
loading the whole file and we can't load the file without trusting the
information in the stage header.
To solve this problem, this patch changes the CBFS stage format to move
the stage header out of the file contents and into a separate CBFS
attribute. Attributes are part of the metadata, so they have already
been verified before the file is loaded.
Since CBFS stages are generally only meant to be used by coreboot itself
and the coreboot build system builds cbfstool and all stages together in
one go, maintaining backwards-compatibility should not be necessary. An
older version of coreboot will build the old version of cbfstool and a
newer version of coreboot will build the new version of cbfstool before
using it to add stages to the final image, thus cbfstool and coreboot's
stage loader should stay in sync. This only causes problems when someone
stashes away a copy of cbfstool somewhere and later uses it to try to
extract stages from a coreboot image built from a different revision...
a debugging use-case that is hopefully rare enough that affected users
can manually deal with finding a matching version of cbfstool.
The SELF (payload) format, on the other hand, is designed to be used for
binaries outside of coreboot that may use independent build systems and
are more likely to be added with a potentially stale copy of cbfstool,
so it would be more problematic to make a similar change for SELFs. It
is not necessary for verification either, since they're usually only
used in post-RAM environments and selfload() already maps SELFs to
CBFS_CACHE before loading them to their final destination anyway (so
they can be hashed at that time).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I8471ad7494b07599e24e82b81e507fcafbad808a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since prog_locate() was eliminated, prog_rdev() only ever represents the
loaded program in memory now. Using the rdev API for this is unnecessary
if we know that the "device" is always just memory. This patch changes
it to be represented by a simple pointer and size. Since some code still
really wants this to be an rdev, introduce a prog_chain_rdev() helper to
translate back to that if necessary.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If7c0f1c5698fa0c326e23c553ea0fe928b25d202
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This messes up the bare structs.
Change-Id: I5a13bd9f4b11530a6dd5f572059fed851db44757
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51436
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
IPMI OEM command set processor information has already been implemented
in u-root payload:
efdc3a30ec
Also this command has a higher chance to see BMC KCS timeout issue when
coreboot log level is 4, which can be avoided if this command is run at
a later stage such as LinuxBoot.
Signed-off-by: JingleHsuWiwynn <jingle_hsu@wiwynn.com>
Change-Id: If0081e5195cbd605e062723c197ac74343f79a13
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51276
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch sets up cse_fw_sync() call in the romstage. The cse_fw_sync()
must be called after DRAM initialization.
Test=Verified on Alderlake platform
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I6779f4a9e140deebf7f3cecd9fc5dac18813f246
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51441
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch sets the HDMI audio mode to 8T as required by the latest FSP
version v2081_02
TEST: HDMI audio codecs detection is failing without this change.
Change-Id: Ie5a825da7d199c9ee61e64d8f4ee7dec28fdaacd
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
This patch disables the xDCI which is causing PC8 to PC10 state
transitions during sleep.
TEST: Confirmed that the transition is happening with this change.
Change-Id: I9bbf7b52c36954600d7e66f9b03fad39b8881a5f
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
This change updates the release notes for coreboot-4.14 to add
deprecation notice for SAR support in VPD for Chrome OS platforms.
BUG=b:173465272
Change-Id: If6d511a22a3a2a31671dac91e57e801134d4ecf8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51486
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, if `get_wifi_sar_cbfs_filename()` returns NULL, then
`get_wifi_sar_limits()` assumes that the default filename is used for
CBFS SAR file. This prevents a board from supporting different models
using the same firmware -- some which require SAR support and some
which don't.
This change updates the logic in `get_wifi_sar_limits()` to return
early if filename is not provided by the mainboard. In order to
maintain the same logic as before, current mainboards are updated to
return WIFI_SAR_CBFS_DEFAULT_FILENAME instead of NULL in default
case.
Change-Id: I68b5bdd213767a3cd81fe41ace66540acd68e26a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51485
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that SAR support in VPD is deprecated in coreboot, there is no
need for a separate Kconfig `WIFI_SAR_CBFS` as the SAR table is only
supported as a CBFS file. This change drops the config `WIFI_SAR_CBFS`
from drivers/wifi/generic/Kconfig and its selection in
mb/google/.../Kconfig.
wifi_sar_defaults.hex is added to CBFS only if
CONFIG_WIFI_SAR_CBFS_FILEPATH is not empty because current mainboards
do not provide a default SAR file in
coreboot. Thus, CONFIG_WIFI_SAR_CBFS_FILEPATH is updated to have a
default value of "".
BUG=b:173465272
Cq-Depend: chromium:2757781
Change-Id: I0bb8f6e2511596e4503fe4d8c34439228ceaa3c7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
SAR table in VPD has been deprecated for Chrome OS platforms for > 1
year now. All new Chrome OS platforms have switched to using SAR
tables from CBFS.
This change drops the support for SAR table in VPD from coreboot to
align with the factory changes. `get_wifi_sar_limits()` is thus
updated to look for SAR file in CBFS only.
Anyone building ToT coreboot for an already released Chrome OS
platform with SAR table in VPD will have to extract the "wifi_sar" key
from VPD and add it as a file to CBFS using following steps:
- On DUT, read SAR value using `vpd -i RO_VPD -g wifi_sar`
- In coreboot repo, generate CBFS SAR file using:
`echo ${SAR_STRING} > site-local/${BOARD}-sar.hex`
- Add to site-local/Kconfig:
```
config WIFI_SAR_CBFS_FILEPATH
string
default "site-local/${BOARD}-sar.hex"
```
BUG=b:173465272
Change-Id: I21d190dcc9f3554fab6e21b4498e7588a32bb1f0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch rewrites the last few users of prog_locate() to access CBFS
APIs directly and removes the call. This eliminates the double-meaning
of prog_rdev() (referring to both the boot medium where the program is
stored before loading, and the memory area where it is loaded after) and
makes sure that programs are always located and loaded in a single
operation. This makes CBFS verification easier to implement and secure
because it avoids leaking a raw rdev of unverified data outside the CBFS
core code.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7a5525f66e1d5f3a632e8f6f0ed9e116e3cebfcf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch removes the prog_locate() call for all instances of loading
payload formats (SELF and FIT), as the previous patch did for stages.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I582b37f36fe6f9f26975490a823e85b130ba49a2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49336
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch removes the prog_locate() step for stages and rmodules.
Instead, the stage and rmodule loading functions will now perform the
locate step directly together with the actual loading. The long-term
goal of this is to eliminate prog_locate() (and the rdev member in
struct prog that it fills) completely in order to make CBFS verification
code safer and its security guarantees easier to follow. prog_locate()
is the main remaining use case where a raw rdev of CBFS file data
"leaks" out of cbfs.c into other code, and that other code needs to
manually make sure that the contents of the rdev get verified during
loading. By eliminating this step and moving all code that directly
deals with file data into cbfs.c, we can concentrate the code that needs
to worry about file data hashing (and needs access to cbfs_private.h
APIs) into one file, making it easier to keep track of and reason about.
This patch is the first step of this move, later patches will do the
same for SELFs and other program types.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia600e55f77c2549a00e2606f09befc1f92594a3a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49335
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The --alignment flag is currently only handled by cbfstool add, but
there seems little reason to not handle it for all file-adding commands
(the help text actually mentions it for add-stage as well but it doesn't
currently work there). This patch moves the related code (and the
related baseaddress handling) into cbfs_add_component(). As a nice side
effect this allows us to rearrange cbfs_add_component() such that we can
conclusively determine whether we need a hash attribute before trying to
align the file, allowing that code to correctly infer the final header
size even when a hash attribute was implicitly added (for an image built
with CBFS verification enabled).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Idc6d68b2c7f30e5d136433adb3aec5a87053f992
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47823
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If we spot any error in the file, treat it as untested and
broken copy-paste.
Change-Id: Idd13b8b006fce7383f3f73c3c0a5d51a71c0155b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38313
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Angel Pons