vboot_recovery_mode_enabled() was recently changed to assert() when it
is called before vboot logic has run, because we cannot determine
whether we're going to be in recovery mode at that point and we wanted
to flush out existing uses that pretended that we could. Turns out there
are a bunch of uses like that, and there is some code that is shared
across configurations that can and those that can't.
This patch cleans them up to either remove checks that cannot return
true, or add explicit Kconfig guards to clarify that the code is shared.
This means that using a separate recovery MRC cache is no longer
supported on boards that use VBOOT_STARTS_IN_ROMSTAGE (this has already
been broken with CB:38780, but with this patch those boards will boot
again using their normal MRC caches rather than just die). Skipping the
MRC cache and always regenerating from scratch in recovery mode is
likewise no longer supported for VBOOT_STARTS_IN_ROMSTAGE.
For FSP1.1 boards, none of them support VBOOT_STARTS_IN_BOOTBLOCK and
that is unlikely to change in the future so we will just hardcode that
fact in Kconfig (otherwise, fsp1.1 raminit would also have to be fixed
to work around this issue).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I31bfc7663724fdacab9955224dcaf650d1ec1c3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch improves the response buffer handling for TPM 2.0. Previously
we would allow any command to return no payload, but if there was a
payload we would always try to unmarshal it according to the normal
success response. This was sort of relying on the fact that the TPM
usually returns no additional data after the header for error responses,
but in practice that is not always true. It also means that commands
without a response payload accidentally work by default even though we
did not explicitly add unmarshallig support for them, which seems
undesirable. Adding explicit unmarshalling support for TPM2_SelfTest
which was only supported through this loophole before.
This patch changes the behavior to always accept any amount of payload
data for error responses but not unmarshal any of it. None of our use
cases actually care about payload data for errors, so it seems safer to
not even try to interpret it. For success responses, on the other hand,
we always require support for the command to be explicitly added.
This fixes a problem with the Cr50 GET_BOOT_MODE command where an error
response would only return the subcommand code but no data after that.
Also add support for a second, slightly different NO_SUCH_COMMAND error
code that was added in Cr50 recently.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib85032d85482d5484180be6fd105f2467f393cd2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41100
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change updates memranges_find_entry() to break and return early
if the end address of the hole within the current range entry crosses
the requested limit. This is because all range entries and maintained
in increasing order and so none of the following range entries can
satisfy the given request.
Change-Id: I14e03946ddbbb5d254b23e9a9917da42960313a6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41104
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We use a temporary BAR value to program the thermal settings. To make
this more obvious, factor it out.
Tested with BUILD_TIMELESS=1, Asus P8Z77-V LX2 does not change.
Change-Id: Icda6e4100d954fe28d2624270b5d7ab7ed155e32
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41111
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Similar to bootblock, provide declaration for
verstage_mainboard_early_init() to support early mainboard
initialization if verstage is run before bootblock.
BUG=b:155824234
TEST=Verified that trembyle still builds
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I106213ecc1c44100f1f74071189518563ac08121
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41137
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The hardware IRQ option was not passed to SeaBIOS Makefile and resulted
in HARDWARE_IRQ being permanently disabled regardless of Kconfig
selection in coreboot. On platforms that need the hardware IRQ it caused
hangs at boot menu or iPXE prompts.
TEST=enter SeaBIOS boot menu on Libretrend LT1000
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Iafcfd743177bbcd1ee23e227c74dd8268c4c23c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41147
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
chip_instance structure currently uses a ref_count to determine how
many devices hold reference to that instance. If the count drops to
zero, then it is assumed that the chip instance is a duplicate in
override tree and has a similar instance that is already overriden in
base device tree.
ref_count is currently decremented whenever a device in override tree
matches the one in base device tree and the registers from the
override tree instance are copied over to the base tree instance. On
the other hand, if a device in override tree does not match any device
in base tree under a given parent, then the device is added to base
tree and all the devices in its subtree that hold pointers to its
parent chip instance are updated to point to the parent's chip
instance in base tree. This is done as part of update_chip_pointers.
However, there are a couple of issues that this suffers from:
a) If a device is present only in override tree and it does not have
its own chip (i.e. pointing to parent's chip instance), then it
results in sconfig emiiting parent's chip instance (which can be the
SoC chip instance) in static.c even though it is unused. This is
because update_chip_pointers() does not call delete_chip_instance()
before reassigning the chip instance pointer.
b) If a device is added under root device only in the override tree
and it does not have its own chip instance (i.e. uses SoC chip
instance), then it results in sconfig emitting a copy of the SoC chip
instance and setting that as chip_ops for this new device in the
override tree.
In order to fix the above issues, this change drops the ref_count
field from chip_instance structure and instead adds a forwarding
pointer `base_chip_instance`. This is setup as per the following
rules:
1. If the instance belongs to base devicetree, base_chip_instance is
set to NULL.
2. If the instance belongs to override tree, then it is set to its
corresponding chip instance in base tree (if present), else set to
NULL.
State of base_chip_instance is then used when emitting chips and
devices using the following rules:
1. If a chip_instance has non-NULL base_chip_instance, then that chip
instance is not emitted to static.c
2. When emitting chip_ops for a device, base_chip_instance is used to
determine the correct chip instance name to emit.
BUG=b:155549176
TEST=Verified that the static.c file generated for base/override tree
combination is correct when new devices without chips are added only
to override tree.
Change-Id: Idbb5b34f49bf874da3f30ebb6a6a0e2d8d091fe5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41007
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves the assignment of id for chip instance from
new_chip_instance() to emit_chips(). This is similar to the previous
change for moving dev id assignment to happen much later.
This ensures that the same ID gets assigned to a chip when adding
support for device trees which makes it easier to compare static.c
files.
BUG=b:155549176
Change-Id: I3efa9af5ed91123675be42bce1cb389bad19cb62
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41006
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change drops the id field from struct device as used by
sconfig. It was primarily used for generating unique device names. This
was maintained within device structure so that the order in which the
device tree entries were parsed is clear. Since the ids are assigned
in parsing order, it is problematic when a device is moved from base
devicetree to override tree. The entire parsing order changes which
makes it really difficult to compare what really changed in static.c
file.
By moving the dev name assignment to happen later when doing pass0 of
static.c generation, the difference in static.c file is minimized when
adding support for override trees.
BUG=b:155549176
Change-Id: I31870ace5a2fd7d5f95ab5e30d794c3bc959ed46
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This replaces GPLv2-or-later and GPLv2-only long form text with the
short SPDX identifiers.
Commands used:
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.*of.*the.*License.*or.*(at.*your.*option).*any.*later.*version.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-or-later */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation[.;,].+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This software is licensed under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation,.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
Change-Id: I7a746088a35633c11fc7ebe86006e96458a1abf8
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This driver was previously added for another out-of-tree Librem device, but
forgot to switch over the librem_skl boards to use it. Remove
duplicate functionality from mainboard.c and delete the empty file.
Test: build/boot Librem 13v2 and verify serial number read from CBFS
via dmidecode.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: Ide952197335c6bfbad846c6d6f62be5c4c57e2cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41040
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Every device belongs to a chip. And we already keep that relation by
inheriting the `.chip_info` pointer if downstream devices don't have
another chip specified. So we can also allow to specify `register`
settings at the device level.
Change-Id: I44e6b95d0cd708fef69b152ebc46b869b2bb9205
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40803
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch configures all IP related GPIOs as per mainboard schematics.
Till now, we were relying on FSP to do IP specific GPIO programming but
now we'll program all GPIOs from mainboard.
This will remove ambiguity of GPIO programming done by FSP and coreboot
will do full GPIO programming
Programming GPIOs of following IPs
- I2C
- Emmc
- Display
- CPU specific gpio (SLP lines)
- Cnvi
- SD
BUG=None
BRANCH=None
TEST=compile coreboot and checked that all IP functionality working.
Change-Id: I98583b768cbd8ab4af536b31d758cb1cee93edfb
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40572
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
SdCardPowerEnableActiveHigh is a UPD which controls polarity of SD card
power enable pin. Setting it 1 will set polarity of this pin as Active
high. This patch will allow to control it from devicetree so that it
can be set as per each board's requirement.
BUG=b:155595624
BRANCH=None
TEST=Build, boot JSLRVP, Verified UPD value from FSP log
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Change-Id: Id777a262651689952a217875e6606f67855fc2f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41027
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PMC supports messages that can be used for configuring the USB
Type-C Multiplexer/Demultiplexer.
BUG=b:151646486
TEST=Booted to kernel on volteer board and verified PMC and Mux
agent devices identification.
Change-Id: I00c5f929b2eea5de3f8eba794dbe9b36c8083c52
Signed-off-by: John Zhao <john.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38777
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
