Config items depends on USE_VENDORCODE_ELTAN but are VBOOT specific.
Correct dependency of these items on VENDORCODE_ELTAN_VBOOT.
BUG = NA
TEST = Boot facebook FBG-1701 with possible combinations of Eltan
security.
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Change-Id: Icd1c3e5c70ca562190308752f45aac734826649a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52132
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I5e10e5d0b80986e1e73573a86a957985840fe0b3
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55727
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I64ab77bc49d93aca1da0126d849e69ff75b182a3
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55726
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I8ca0813e18da0f95eb9293b6d0bbdf933a1e7039
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55725
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I568cd39792eba1bbace4901e96d708d80f73c60a
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55724
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I038e43deead70d598cf26f320dd9993f17591b88
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55723
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:14.1: enabled 0`.
Change-Id: I0e400ded7ba268a5f289b0ac568598e0dad1899a
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55722
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
1. Replace all pcidev_path_on_root() and is_dev_enabled() functions
combination with is_devfn_enabled().
2. Remove unused local variable of device structure type
(struct device *).
3. Replace pcidev_path_on_root() and dev->enabled check with
is_devfn_enabled() call.
4. Leave SATA, eMMC controller FSP UPDs at default state if
controller is not enabled and FSP UPDs are set to disable.
TEST=Able to build and boot without any regression seen on ICLRVP.
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: Id6861af3b5d1ce4f44b6d2109301bd4f5857f324
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55721
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Our existing native function gpio configuration macro (PAD_NF) only sets
the pull. For PCIe reset, we now need to be able to set it to its
native function (PCIE_RST_L), and drive it low, then high.
BUG=b:182805349
TEST=Configure GPIO, see correct behavior.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I636371517c99f94f76834abc4575795d51aa0368
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55652
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PSP_Verstage will enable eSPI early in the boot sequence. If the
platform isn't using psp_verstage, the system can hang on the first
port 80h postcode that comes out because they aren't routed to an
active device until eSPI is configured.
BUG=b:191370340
TEST=Build without PSP_Verstage, verify system doesn't hang.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I37fbb251cd79609b856c4480ca29ce94b08897d7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55738
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
One of the reason FSP-T support had to be kept in place was for
Intel Bootguard. This now works with native CAR code, so there is no
reason to keep FSP-T as an option for these platforms.
APL did not even build with FSP_CAR and finding FSP-T using walkcbfs
was only recently fixed using FMAP, so there can be no doubt that this
option was never used with coreboot master.
Change-Id: I0d5844b5a6fd291a13e5f467f4fc682b17eafa63
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Bootguard sets up CAR/NEM on its own so the only thing needed is to
find free MTRRs for our own CAR region and clear that area to fill in
cache lines.
TESTED on prodrive/hermes with bootguard enabled.
Change-Id: Ifac5267f8f4b820a61519fb4a497e2ce7075cc40
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This adds a macro to find an available MTRR(s) to set up CAR.
This added complexity is not required on bootpaths without bootguard
but with bootguard MTRR's have already been set up by the ACM so
we need to figure out at runtime which ones are available.
Change-Id: I7d5442c75464cfb2b3611c63a472c8ee521c014d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This motherboard is somewhat similar to the p8h61-m_pro, but also different.
It has two exposed RAM slots with a pinout for four, and it's an OEM
variant used in PCs ASUS sold in stores.
Signed-off-by: Hunter Sell <alicelyralain@gmail.com>
Change-Id: Id08349feb0aeaf21406f814f6d19bbe0d9312a4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Using `config_of(dev)` to access `dev->chip_info` will make coreboot die
if the latter is NULL, which is the case for devices detected at runtime
(i.e. not statically declared in the devicetree). Given that the code is
designed to work when the PEG config is all-zeroes (devicetree default),
dying because `dev->chip_info` is NULL is foolish and unwarranted.
Introduce a helper function that returns a pointer to devicetree config
when available, and otherwise returns a pointer to a zero-filled static
struct. In addition, avoid an out-of-bounds access in the very unlikely
case where the device's function is too large.
Tested on Asrock B85M Pro4, can now boot when `device pci 01.0 on end`
is commented out in its devicetree. Without this commit, it could not.
Change-Id: Ia2d3a03da9eab601fb834b0c51a8a51c9ae14c33
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55690
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
PEG bifurcation is strapped to x8/x8 on this board, but only the first
port is used. Disable the PEG device at 00:01.1 because it is unused.
Should fix booting with commit ae999503f6
(nb/intel/haswell/pcie.c: Add missing pre-ASPM init). The `config_of()`
function call added in that commit makes coreboot die if any PEG device
that is enabled by strapping is not present in the devicetree. While it
is true that the PEG code should not use `config_of()`, this PEG device
should still be disabled on this board as it is never used.
Change-Id: I16809e081f9a56ba2f1fdfcb4b8289d75161056b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55687
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Máté Kukri <kukri.mate@gmail.com>
Remove some redundant parts of devicetree comments. This used to happen
when using autoport, but has been fixed at some point.
Tested with BUILD_TIMELESS=1, Lenovo T440p remains identical.
Change-Id: Ie24b5430c7771c9ce4dda6c9a10d70ee9000df7c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
An error in script did not set the attribute properly:
- Entry CS0 is not used as sensor, but as ground,
- Entry CS1 is used as the startup sensor.
This fixes a regression caused by commit
689c25b9d6 (drivers/i2c: sx9310: Replace register map with descriptive names)
EQ=b:173341604
BRANCH=volteer
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Change-Id: I92c01209031e9a917d95b1cb2537b0ce7b93e66d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51893
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We moved from gitweb to cgit to gitiles and some of the URL schemes
were lost during the transitions. Update to the gitiles scheme so
board-status links work again.
Change-Id: Id2a840bf89fab172e0eab21e303ac0c4666b6751
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55594
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The patch moves CSE Lite RW status check out of CSE RW update logic as
the RW sanity check has to be done irrespective of CSE RW update logic
is enabled or not. If coreboot detects CSE Lite RW status is not good,
the coreboot triggers recovery.
TEST=Verified boot on Brya
Signed-off-by: Sridahr Siricilla <sridhar.siricilla@intel.com>
Change-Id: I582b6cf24f8894c80ab461ca21f7c6e8caa738bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55619
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Pass the info if the non-graphics HD audio controller device is enabled
or disabled in the board's devicetree via a UPD to the FSP so that it
knows if it should enable or disable the corresponding device.
TEST=When adding "device ref hda on end" to the devicetree of
amd/majolica the non-graphics HD Audio controller shows up in lspci and
when that line isn't added the PCIe device doesn't show up.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9f5e164d308906bfc788e5c2674c13c7b2ebf471
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Currently the FSP only has one switch to disable both AHCI controllers.
If at least one of the two AHCI controller devices is enabled in the
board's devicetree, set the SATA enable UPD to 1 and otherwise set it to
0. Setting the UPD value to 0 when both AHCI controllers are disabled
saves around 60ms in boot time.
BUG=b:191385289
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I84e7c8bf2ab08c8254271ddfefd2e4e7d8c2e87b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55669
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Matt Papageorge <matthewpapa07@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use devfn_disable() for disabling a PCI device rather than
using `dev->enabled = 0`.
Also, use is_devfn_enabled() to get the device current state prior
updating the FSP-S UPD for XDCI.
TEST=FSP-S disabled XDCI when `xdci_can_enable` returns 0 and XDCI
is disabled at PCI enumeration `PCI: 00:15.1: enabled 0`.
Change-Id: I449beae59d2f578c027d8110c03fa79f516c3fe9
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
On platforms where the boot media can be updated externally, e.g.
using a BMC, add the possibility to enable writes in SMM only. This
allows to protect the BIOS region even without the use of vboot, but
keeps SMMSTORE working for use in payloads. Note that this breaks
flashconsole, since the flash becomes read-only.
Tested on Asrock B85M Pro4 and HP 280 G2, SMM BIOS write protection
works as expected, and SMMSTORE can still be used.
Change-Id: I157db885b5f1d0f74009ede6fb2342b20d9429fa
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40830
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
