| Age | Commit message (Collapse) | Author |
|---|
|
Read fw_config value from VPD.
This new option can be used where chrome EC is not supported like
pre-silicon platform and fw_config can be updated by VPD tool in OS.
TEST= boot to OS and read fw_config from vpd
1. Boot to OS
2. Write "fw_config" in VPD
ex) vpd -i "RW_VPD" -s "fw_config"="1"
3. reboot and check fw_config value from coreboot log
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I4df7d5612e18957416a40ab854fa63c8b11b4216
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58839
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Request fw_config values from various sources (as enabled via Kconfig)
until a valid value has been read.
With this change, Chrome EC CBI takes precedence over CBFS fw_config.
TEST=select both configs and check fallback behavior.
1. select both FW_CONFIG_SOURCE_CHROMEEC_CBI and FW_CONFIG_SOURCE_CBFS
2. check log for reading fw_config from CBI and CBFS
Signed-off-by: Wonkyu Kim <wonkyu.kim@intel.com>
Change-Id: I215c13a4fcb9dc3b94f73c770e704d4e353e9cff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
This change adds a helper function `fw_config_probe_dev()` that allows
the caller to check if any of the probe conditions are true for any
given device. If device has no probe conditions or a matching probe
condition, then it returns true and provides the matching probe
condition back to caller (if provided with a valid pointer). Else, it
returns false. When fw_config support is disabled, this function
always returns true.
Change-Id: Ic2dae338e6fbd7755feb23ca86c50c42103f349b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54751
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
fw_config is unprovisioned in the factory for the first boot. This is
the only case where fw_config is left unprovisioned. On first boot in
factory, fw_config gets correctly provisioned by the factory
toolkit. When fw_config is unprovisioned, it is not always possible to
make a guess which device to enable/disable since there can be certain
conflicting devices which can never be enabled at the same time. That
is the reason the original implementation of fw_config library kept
fw_config as 0 when it was unprovisioned.
CB:47956 ("fw_config: Use UNDEFINED_FW_CONFIG to mean unprovisioned")
added support for a special unprovisioned value to allow any callers
to identify this factory boot condition and take any appropriate
action required for this boot (Ideally, this would just involve
configuring any boot devices essential to getting to OS. All other
non-essential devices can be kept disabled until fw_config is properly
provisioned). However, CB:47956 missed handling the
`fw_config_probe()` function and resulted in silent change in behavior.
This change fixes the regression introduced by CB:47956 and returns
`false` in `fw_config_probe()` if fw_config is not provisioned yet.
Change-Id: Ic22cd650d3eb3a6016fa2e2775ea8272405ee23b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54750
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
A mainboard might want to configure some things differently when a
device is in an unprovisioned state. In the case when fw_config comes
from the Chromium EC, an unprovisioned device will not have a FW_CONFIG
tag in its CBI. This patch will set the fw_config value to
UNDEFINED_FW_CONFIG in the case of an error retrieving the value, as
well as adding a function, `fw_config_is_provisioned()` to indicate the
provisioning status.
BUG=none
TEST=remove fw_config from chromium EC CBI, add code to mainboard to
print return value of fw_config_is_provisioned() (`0`), add
fw_config back to CBI, run same test and see `1`.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ib3046233667e97a5f78961fabacbeb3099b3d442
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47956
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Further patches will make use of this raw 64-bit value.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I161893c09da6a44265299f6ae3c3a81249a96084
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46604
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
We all knew this was coming, 32 bits is never enough. Doing this early
so that it doesn't affect too much code yet. Take care of every usage of
fw_config throughout the codebase so the conversion is all done at once.
BUG=b:169668368
TEST=Hacked up this code to OR 0x1_000_0000 with CBI-sourced FW_CONFIG
and verify the console print contained that bit.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I6f2065d347eafa0ef7b346caeabdc3b626402092
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45939
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Make boot state init run before the init_chips code. This allows for
correcting tbt settings at a stage earlier than devicetree parsing.
BUG=b:167983038
TEST=none
Change-Id: I8364746ba311575e7de93fa25241ffef7faf35b4
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45961
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add a backing cache for all successfully probed fw_config fields that
originated as `probe` statements in the devicetree. This allows recall
of the `struct fw_config` which was probed.
BUG=b:161963281
TEST=tested with follower patch
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I0d014206a4ee6cc7592e12e704a7708652330eaf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44782
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This change introduces a new top-level interface for interacting with a
bitmask providing firmware configuration information.
This is motivated by Chromebook mainboards that need to support multiple
different configurations at runtime with the same BIOS. In these
devices the Embedded Controller provides a bitmask that can be broken
down into different fields and each field can then be broken down into
different options.
The firmware configuration value could also be stored in CBFS and this
interface will look in CBFS first to allow the Embedded Controller value
to be overridden.
The firmware configuration interface is intended to easily integrate
into devicetree.cb and lead to less code duplication for new mainboards
that make use of this feature.
BUG=b:147462631
TEST=this provides a new interface that is tested in subsequent commits
Change-Id: I1e889c235a81545e2ec0e3a34dfa750ac828a330
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
