Currently, the PCIe bridge 00:15.2 is not detected by coreboot, causing
the connected network device also to be missing.
This is caused by not configuring the third of the four PCIe General
Purpose Ports (GPP) of the AMD Fusion Controller Hub (FCH), which can be
exposed as one to four PCIe devices.
So, enable it in AGESA but disable enumeration in coreboot. Otherwise,
the serial console stops working in romstage after
[…]
PCI: 00:15.1 bridge ctrl <- 0013
PCI: 00:15.1 cmd <- 06
PCI: 00:15.2 bridge ctrl <- 0013
PCI: 00:15.2 cmd <- 07
and the system hangs in the payload (SeaBIOS banner is shown on VGA
attached monitor).
TEST=Serial console and payload works, and Linux 5.10-rc2 configures
PCIe bridge. Output of `lspci -t`:
-[0000:00]-+-00.0
+-00.2
+-01.0
+-01.1
+-10.0
+-10.1
+-11.0
+-12.0
+-12.2
+-13.0
+-13.2
+-14.0
+-14.2
+-14.3
+-14.4-[01]--
+-14.5
+-15.0-[02]--
+-15.1-[03]----00.0
+-15.2-[04]----00.0
+-18.0
+-18.1
+-18.2
+-18.3
+-18.4
\-18.5
Change-Id: Ia1d60a212b0d249c7d8b3f8ec16baf5e93c985da
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46527
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The idea is to split the “mainboard” category into “variants” and
“carrierboards”, in the case when we use the COMe module together
with the Carrier Board instead of a single monolithic motherboard.
Previously, the “variants” category defined the type of motherboard,
which has a number of differences from the base one, for example, it
differed in the size or type of memory, and in the configuration of
the interfaces. Thus, there is no need to create a separate directory
in src/mainboard for a board that is similar in configuration to the
base board. But for a COMe module, “variants” contains different
variants of only this module, and the entire Carrier Board configuration
is allocated to a separate category - “carrierboards”, and each of the
variants can be used with one of the many boards in “carrierboards”.
For example, in the case of the Kontron mAL10 COMe module, variant
refers to the COMe-mAL10 or COMe-m4AL10 module type. They differ in the
type of memory (DDR3L or DDR4), and maybe they differ in some chips (see
more in https://www.kontron.com/products). However, all variants contain
the same type of processor/SoC.
The "carrierboards" directory can be able contain both the Kontron's
Evalution carrier boards (such as Eval Carrier2 T10 and COMe
Ref.Carrier-i T10 TNI) and third party vendor backplanes that are
compatible with the COMe modules from “variants”.
Thus, the src/mainboard/<module-name> directory contains the common
configuration code for all variants from src/mainboard/<module-name>/
variants, which can be supplemented/redefined with a configuration from
src/mainboard/<module-name>/carrierboard/<vendor-carrierboard-name>.
This architectural solution will be able to systematize and simplify
understanding of the code structure for COMe modules and will allow
vendors to add/maintain their code in a separate directory.
This work is also the first step towards to union of all carrierboards
into the global category in src/carrierboard on a par with all boards
from src/mainboard.
The patch takes this into account in the build system and adds
CARRIER_DIR component to use the “carrierboards” category, as it has
done for VARIANT_DIR.
TEST = Build ROM image for Kontron mAL10 COMe module together with T10
TNI carrier board (https://review.coreboot.org/c/coreboot/+/39133).
Change-Id: Ic6b2f8994b1293ae6f5bda8c9cc95128ba0abf7a
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42609
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fill in some blanks for 4.13, mark it done, add template for 4.14.
Also update the list of vboot supported boards.
Change-Id: Ie593efe515136a3b06620db6f0dbe3da00df7e9b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47801
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The PCH IOAPIC is not PCI discoverable.
Linux checks the BDF set in DMAR against the PCI class if it is a PIC,
which 00:1F.0 for instance isn't.
The SINIT ACM on the other hand bails out with ERROR CLASS:0xA, MAJOR
3, MINOR 7 if the BUS number is 0.
Change-Id: I9b8d35a66762247fde698e459e30ce4c8a2c7eb0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47538
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Don't rely on the FSP-S setting the HPET and IOAPIC BDF. This makes
coreboot in control of these settings.
Change-Id: I937ebf05533019cb1a2be771ef3b9193a458dddf
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47537
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
This makes coreboot more robust as it does not need to rely on syncing
values set by FSP and coreboot.
Change-Id: I2d954acdb939e7cb92d44b434ae628d7d935d776
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47533
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: I68f63c79d04cb2cddb92c9f6385459723f8858bd
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47532
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Top of Temp RAM is used as bootloader stack, which is the
_car_region_end area. This area is not equal to CAR stack area as
defined in car.ld file.
Use _ecar_stack (end of CAR stack) as starting stack location.
Tested VBOOT, Vendorboot security and no security on Facebook FBG1701.
Change-Id: I16b077f60560de334361b1f0d3758ab1a5cbe895
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47737
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The auxadc (auxiliary analogue-to-digital conversion) is a unit
to identify the plugged peripherals or measure the temperature
or voltages.
The MT8183 auxadc driver can be shared by multiple MediaTek SoCs
so we should move it to the common folder.
Signed-off-by: Po Xu <jg_poxu@mediatek.com>
Change-Id: Id4553e99c3578fa40e28b19a6e010b52650ba41e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
coreboot might not store wifi SAR values in VPD and may store it in
CBFS. Logging the message with 'error' severity may interfere
with automated test tool.
Lowering severity to BIOS_DEBUG avoids this issue.
BUG=b:171931401
BRANCH=None
TEST=Severity of message is reduced and we don't see it as an error
Change-Id: I5c122a57cfe92b27e0291933618ca13d8e1889ba
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
SystemMemoryMapHob
This field from SystemMemoryMapHob can be used to define error
correction type in SMBIOS type 16.
Tested=On OCP Delta Lake, the value is expected.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I0009a287a64f16e926f682e389af3248aeb85bdf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47505
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is required for CBnT.
Change-Id: I290742c163f5f067c8d529ddca8e2d8572ab6e6a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47449
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is required for CBnT.
Change-Id: Idfd5c01003e0d307631e5c6895ac02e89a9aff08
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46499
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- enable microcode in cbfs (won't boot without microcode)
- force num fit entry to 1 to avoid crash in cbfstool/fit.c
- re-enable FSP-CAR (tested to boot, while I couldn't boot with NEM)
- enable io driver for uart in legacy mode (ie emulating legacy port by
configuring the pci to legacy io address and hiding the pci device)
Signed-off-by: Julien Viard de Galbert <julien@vdg.name>
Change-Id: Ibc5ce91118c6052af23642fb3461f574cd888dea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
The IOSAV_By_BW_MASK_ch registers are not per-rank. To preserve original
behavior, use a for-populated-channels loop instead of for-all-channels.
Tested on Asus P8H61-M PRO, still boots.
Change-Id: I6db35c41cd05420ceaeda93255f5ed73598a5bdd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47609
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
These are simply read MPR training, using the MPR pattern mode in MR3.
Change-Id: Icdc60572e0ee0b59dcb5dee1e1aceccfda79f029
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
After aggressive read training, program nominal Vref for the current
channel, not only channel 0. This simple mistake can easily degrade
memory margins, especially when running at high speed (overclocking).
Tested on Asus P8H61-M PRO, still boots.
Change-Id: I12630fe33c5c786c8ec131c45c27180c3887d354
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This function simply determines the best delay for the TX DQ PIs.
Change-Id: If44c4f661d8c81fe41532ce2bfe3718392b9fe94
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47625
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Write training needs to update mode register 1, but `write_mrreg` will
clobber the IOSAV sequence. Reference code uses one four-subsequence to
unset Qoff in MR1, run the test, and finally set Qoff again. This will
be implemented in future changes, and will use the newly-added helper.
Change-Id: I06a06a7bdd43dbde34af4ea2f90e00873eefe599
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The intent here is to clear the register, so a simple write will work.
Change-Id: I547805059e911942ac2cac7bd2165af23d926a2b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Also fuse two per-channel loops together.
Tested on Asus P8H61-M PRO, still boots.
Change-Id: Iacc66f4364290a66d60d483055abef6e98223d16
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47607
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
There's no need to use `struct timA_minmax`, since most cases only care
about the difference between logic delay deltas. The final step does use
the minimum logic delay across all lanes, but it's a special case.
Tested on Asus P8H61-M PRO, still boots.
Change-Id: I1da95520ac915ab003e1a839685cbf5f1970eb6a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47604
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
A new field was defined for different keyboard layouts, so add this field
to the list and provide the two options that were defined.
Change-Id: Ic357446725e34221040705929d54cbce94c5ab8b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The various platform BARs are not always the same size across different
SOCs, so use the defined size rather than a hardcoded value.
This results in the following change on TGL which increased the MCHBAR
size to 128K:
-system 00:00: [mem 0xfedc0000-0xfeddffff] has been reserved
+system 00:00: [mem 0xfedc0000-0xfedc7fff] has been reserved
And fixes the following error output from the kernel:
resource sanity check: requesting [mem 0xfedc0000-0xfedcdfff],
which spans more than pnp 00:00 [mem 0xfedc0000-0xfedc7fff]
Change-Id: I82796c2fc81dec883f3c69ae7bdcedc7d3f16c64
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47378
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
To avoid "unknown post code 0x55" entries in the event log on cold boot
clear the post code before doing the CSE initiated reset.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I68078c04230dbc24f9cc63b1ef5c435055aa1186
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47257
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Set the default state of the TCSS PCIe RP0 to hidden so that coreboot
does not allocate resources to this hotplug root port. The default
behavior on the reference design is that there is only one USB4 port
attached to port C1 while port C0 is only a USB3 port.
Meanwhile the Voxel and Terrador variants do have USB4 on both C0 and
C1 ports, so these boards change the default to 'on' so that coreboot
does allocate resources for the hotplug port.
BUG=b:159143739
BRANCH=volteer
TEST=build volteer and voxel and check the resulting static.c to
ensure the device is hidden or not. Also boot with the two different
configurations and ensure resources are assigned or not. Finally
check that S0ix still functions with the C0 port set to 'hidden'
after authorizing a PCIe tunnel on port C1.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I8bb05ae8cd14412854212b7ed189cfa43d602c1d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47198
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to allow override trees to hide/unhide a device copy
the hidden state to the base device. This allows a sequence
of states like:
chipset.cb: mark device 'off' by default
devicetree.cb: mark device 'hidden' (to skip resource allocation)
overridetree.cb: mark device 'on' for device present on a variant
BUG=b:159143739
BRANCH=volteer
TEST=build volteer variants with TCSS RP0 either hidden or on
and check the resulting static.c to see if the hidden bit is
set appropriately.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Iebe5f6d2fd93fbcc4329875565c2ebf4823da59b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47197
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is an issue with the storage device being mis-detected on exit
from S0ix which is causing the root device to disappear if the power
is actually turned off via RTD3.
To work around this read the RX state of the pin and apply the IOSSTATE
setting to drive a 0 or 1 back to the internal controller. This will
ensure the device is detected the same on resume as on initial boot.
BUG=b:171993054
TEST=boot on volteer with PCIe NVMe and SATA SSD installed in the M.2
slot and ensure this pin is configured appropriately. Additionally
test with PCIe RTD3 enabled to ensure suspend/resume works reliably.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I85542151eebd0ca411e2c70d8267a8498becee78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47255
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shreesh Chhabbi <shreesh.chhabbi@intel.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Expose a config option that allows enabling the FSP UPD which controls
Precision Time Measurement for a particular PCIe root port.
This UPD is enabled by default in FSP but interferes with achieving
deeper S0ix substates so in order to prevent it from needing to be
explicitly disabled for every root port this change makes disabling it
the default and allows it to be enabled if needed.
BUG=b:160996445
TEST=boot on volteer with PTM disabled by default for all root ports
and ensure S0i3.2 substate can be achieved.
Change-Id: Icb51b256eb581d942b2d30fcabfae52fa90e48d4
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46856
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable the PCIe RTD3 driver for the PCIe attached SD card interface
and provide the enable/reset GPIOs. These GPIOs are common across
all variants so this is implemented in the baseboard devicetree with
an fw_config probe if the device is present. The RTS5261 device
does not have an enable GPIO so it is disabled in a workaround in
mainboard.c, along with marking the SD-Express device as external.
BUG=b:162289926, b:162289982
TEST=Tested on Delbin platform to ensure the system can enter the
S0i3.2 substate and suspend/resume is stable.
enabling this for the regular Genesys
Change-Id: I40fe05829783c7bce2a2c4c1520a4a7430642e26
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Enable Runtime D3 for the volteer variants that have GPIO power control
of the NVMe device attached to PCIe Root Port 9.
Enable the GPIO for power control for variants that do not already have
it configured to allow the power to be disabled in D3 state.
BUG=b:160996445
TEST=tested on delbin
Change-Id: I6ebf813c6c3364fec2e489a9742f04452be92c45
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46262
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This SOC overrides the common PMC device and instantiates the PMC device
in the SSDT. It needs to call the common PMC function to provide the
IPC mailbox method.
The common PCIe RTD3 driver can also be enabled which will allow
mainboards to enable Runtime D3 power control for PCIe devices.
BUG=b:160996445
TEST=boot on volteer with this driver enabled for the NVMe device in the
devicetree and disassemble the SSDT to ensure the RTD3 code is present.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ifa54ec3b8cebcc2752916cc4f8616fcb6fd2fecc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Wisley Chen