We need to change OC pin for type C USB3 ports and it depends
on the board design. Allowing it to be filled by devicetree will
make it easier to change the mapping based on the board design.
BUG=b:184660529
TEST="emerge-volteer coreboot" compiles without error.
Change-Id: I5058a18b1f4d11701cebbba85734fbc279539e52
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Updated CPU ID and IGD ID for Alder Lake as per EDS.
TEST=Code compilation works and coreboot is able to boot and identify
new device Ids.
Change-Id: I2759a41a0db1eba5d159edfc89460992914fcc3c
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
GPIO communities 0, 1, and 4 have virtual wire indexes & bits for at
least some of their groups; add the known information into the community
definitions. This patch is ported form tigerlake.
Change-Id: I2f1e2413d06e8afe4233d7111763cb45b78f845b
Signed-off-by: Deepti Deshatty <deepti.deshatty@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
gcc 11.1 complains when we're passing a type* into a function that was
declared to get a type[], even if the ABI has identical parameter
passing for both.
To prepare for newer compilers, adapt to this added constraint.
Change-Id: I5a1b3824a85a178431177620c4c0d5fddc993b4f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Intel PDGs starting from Skylake / Sunrise Point state that, different
from the general recommendation in digital electronics, unconnected
GPIOs defaulting to GPIO mode do explicitly not require termination.
The reason for this is, that these GPIOs have the `GPIORXDIS` bit set,
which effectively disconnects the pad from the internal logic by
disabling the input buffer.
This bit - besides `GPIOTXDIS` - can also be set explicitly by using
the gpio macro `PAD_NC(pad, NONE)`.
In some cases, a pull resistor may be required due to bad board design
or when a vendor sets the RX/TX disable bits together with a pull
resistor and schematics are not available to check if the pad is really
unconnected or just unused. In this case the pull resistor should be
kept.
Pads defaulting to native functions usually don't need special handling.
However, when pads requiring external pull-ups are missing these due to
bad board design, they should be configured with `PAD_NC` to disconnect
them internally.
Rewrite the documentation to reflect these new findings.
Also clarify the comment in soc/intel gpio code accordingly.
Change-Id: Id01b197ebe8f2b8bb4ecf3d119ec2298b26d9be0
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52139
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
soc_memory_init_params() does not only configure memory init parameters.
Despite its name, it also configures many other things. Therefore, merge
it into its caller function platform_fsp_memory_init_params_cb() to
prevent confusions.
Built clevo/l140cu with BUILD_TIMELESS=1. coreboot.rom remains the same.
Change-Id: Id3b6395ea5d5cb714a412c856d66d4a9bcbd9c12
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52491
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We need to modify update CmdMirror and LpDdrDqDqsRetraining parameters
for ADLRVP board.
Allowing this parameters to be filled by devicetree will allow
flexibility to update values as per board designs.
Note that both UPDs are applicable for both DDR and Lpddr memory types.
BUG=None
BRANCH=None
TEST=Build works and UPD values have been filled correctly
Change-Id: I55b4b4aee46231c8c38e208c357b4376ecf6e9d9
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51027
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
On tgl, we noticed system hang if a shutdown is triggered before fsps.
The dut is unable to shutdown properly due to tcss is stuck before
tcss_init in fsps.
This change enable power button smi on jsl, tgl, adl after fsps.
it can also prevent a shutdown failure due to lack of fsps init on
certain ip.
BUG=b:186194102, b:186815114
TEST=Power on the system and pressing power button repeatedly doesn't
cause the system hang during shutdown.
Change-Id: I70b871f2676a89bc782116e02beba5c20ec51eef
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
If a power button SMI is triggered between where it is currently
enabled and before FSP-S exits, when the SMI handler disables
bus mastering for all devices, it inadvertently also disables
the PMC's I/O decoding, so the register write to actually go into
S5 does not succeed, and the system hangs.
This can be solved by skipping the PMC when disabling bus
mastering in the SMI handler, for which a callback,
smihandler_soc_disable_busmaster is provided.
BUG=b:186194102, b:186815114
TEST=Power on the system and pressing power button repeatedly doesn't
cause the system hang during shutdown.
Change-Id: I1cf5cf91ebad4a49df6679e01fc88ff60c81526c
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52873
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The CMOS option system does not support negative integers. Thus, retype
and rename the option API functions to reflect this.
Change-Id: Id3480e5cfc0ec90674def7ef0919e0b7ac5b19b3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
TGL boards using the Type-C subsystem for USB Type-C ports without a
retimer attached may require a DC bias on the aux lines for certain
modes to work. This patch adds native coreboot support for programming
the IOM to handle this DC bias via a simple devicetree
setting. Previously a UPD was required to tell the FSP which GPIOs were
used for the pullup and pulldown biases, but the API for this UPD was
effectively undocumented.
BUG=b:174116646
TEST=Verified on volteer2 that a Type-C flash drive is enumerated
succesfully on all ports. Verified all major power flows (boot, reboot,
powerdown and S0ix/suspend) still work as expected.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I70e36a41e760f4a435511c147cc5744a77dbccc0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51649
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The CPU can have its own Port IDs when addressing GPIO communities, which
differ from the PCH PCR IDs.
1) Add a field to `struct pad_community` that can hold this value when
known.
2) Add a function to return this value for a given GPIO pad.
Change-Id: I007c01758ae3026fe4dfef07b6a3a269ee3f9e33
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52590
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
GPIO communities 0, 1, and 4 have virtual wire indexes & bits for at
least some of their groups; add the known information into the community
definitions.
Change-Id: Icc4581e61ee904cbd998738962d360a58d24bc35
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52589
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some SoCs may define virtual wire entries for certain GPIOs. This patch
allows SoC code to provide the mappings from GPIO pads to virtual wire
indexes and bits when they are provided. Also a function
`gpio_get_vw_info` is added to return this information.
Change-Id: I87adf0ca06cb5b7969bb2c258d6daebd44bb9748
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52588
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adding GPIO definition for community 3 which is CPU reserved GPIO used
by CPU side PCIe root ports. We did not have this definition since
FSP used to program this GPIOs. Now, instead of FSP, coreboot programs
CPU PCIe GPIOs for CLKSRC and lanes to put GPIOs in native mode.
Thus adding definition of this virtual GPIOs in this CL.
BUG=None
BRANCH=None
TEST=Check if correct registers are being programmed
Change-Id: I481ea7e3ba948bf6d37b97d08c675a18ee68125d
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Earlier we did not have definition for BIT27 for PAD_CFG0 register, we
will use this BIT to enable "virtual wire messaging for native function"
If this bit is enabled, whenever change is detected on the pad, virtual
wire message is generated and sent to destination set by native function.
This bit must be set while enabling CPU PCIe root port programming for
ADL and thus defining a new macro to set native pad function along with
NAF_VWE bit to make GPIO programming easier from coreboot.
BUG=None
BRANCH=None
TEST=Code compilation works fine and if we use this macro to program
GPIO, proper bit is getting set in PAD_CFG register
Change-Id: I732e68b413eb01b8ae1a4927836762c8875b73d2
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52782
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The only use case for FSP-T in coreboot is for 'Intel Bootguard'
support at the moment. Bootguard can do verification FSP-T but there
is no verification on whether the FSP found by walkcbfs_asm is the one
actually verified as an IBB by Bootguard. A fixed pointer needs to be
used.
TESTED on OCP/Deltalake, still boots.
Change-Id: I1ec8b238384684dccf39e5da902d426d3a32b9db
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52850
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
From tests this does not lock down SMRAM and it's also not possible to
read back what is written, be it via PCI mmconfig or io ops. The
FSP integration can be assumed to be bogus on this point.
Change-Id: Ia0526774f7b201d2a3c0eefb578bf0a19dae9212
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51532
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PL2 override value is already declared under common code in power_limit.h file.
Removing this duplicate PL2 override from soc specific header file.
BRANCH=None
BUG=None
TEST=Built and tested on brya
Change-Id: I1424f36fbe038d478f4b8f6257d78d4a3ede3258
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The usage of `pci_devfn_t` here is misleading, as these intentionally
store the `PCH_DEVFN_*` macros so they can be used across `smm` and
`ramstage` without requiring the device model. Update to `unsigned int`
instead, as `pci_devfn_t` implies the data is an MMCONF-compatible PCI
devfn offset.
Change-Id: Ic8880de984e6eceda4cbe141e118f3a5fdd672a2
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52808
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the recent switch to SMM module loader v2, the size of the SMM for
module google/volteer increased to above 64K in size, and thus failed to
install the permanent SMM handler. Turns out, the devicetree is all
pulled into the SMM build because of elog, which calls
`pci_dev_is_wake_source`, and is the only user of `struct device` in
SMM. Changing this function to take a pci_devfn_t instead allows the
linker to remove almost the entire devicetree from SMM (only usage left
is when disabling HECI via SMM).
BUG=b:186661594
TEST=Verify loaded program size of `smm.elf` for google/volteer is
almost ~50% smaller.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I4c39e5188321c8711d6479b15065e5aaedad8f38
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52765
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Kconfig change which enables the hwp cppc acpi support is to get the
maximum performance of each CPU to check and enable Intel Turbo Boost
Max Technology.
BUG=none
BRANCH=none
TEST=check GCPC and CPC generated in acpi tables for each CPU
Change-Id: I5d93774e8025466f1911cf77459910fe872bfcc8
Signed-off-by: ravindr1 <ravindra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51795
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`soc_vtd_resources` from the else-part is unused since Cannon Lake was
removed. Thus, drop it and that if-else-condition.
Change-Id: I21689d1eae6952a80c98096443e7506a1466c07e
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52775
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Remove useless help texts since they don't add any more value.
Change-Id: Iabcaec1bc8abe2c4628105752e49247e946fcfe7
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52786
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove useless help texts since they don't add any more value.
Change-Id: Id8a15681a98ceb648814662545f5a3bf0f14b95c
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52777
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Provide a SOC_INTEL_SKYLAKE_LGA1151_V2 option to select correct defaults
for the combination of a Union Point PCH with LGA1151v2.
As of the year 2021 it's common for motherboards with Z370, H310C
or B365 PCHs, which are meant to be paired with Coffee Lake CPUs.
Intel provides AmberLakeFspBinPkg to support this combination,
which implements Intel FSP External Architecture Specification v2.1.
Details:
1) Provide SOC_INTEL_SKYLAKE_LGA1151_V2 option that selects
PLATFORM_USES_FSP2_1, SOC_INTEL_COMMON_SKYLAKE_BASE and
SKYLAKE_SOC_PCH_H.
2) Add Amberlake FSP support.
If SOC_INTEL_SKYLAKE_LGA1151_V2 is set, use AbmerLakeFspBinPkg instead
of KabylakeFspBinPkg.
3) Enable Coffee Lake CPUs support.
If SOC_INTEL_SKYLAKE_LGA1151_V2 is set, select
MAINBOARD_SUPPORTS_COFFEELAKE_CPU.
4) Increase stack and heap size in CAR.
If FSP_USES_CB_STACK is set (it's selected by PLATFORM_USES_FSP2_1),
update DCACHE_BSP_STACK_SIZE and FSP_TEMP_RAM_SIZE values.
5) Update maximal number of supported CPUs.
If MAINBOARD_SUPPORTS_COFFEELAKE_CPU is set, set MAX_CPUS to 16.
Signed-off-by: Timofey Komarov <happycorsair@yandex.ru>
Change-Id: I7b6b9c676da55088cb5a12a218ea58d349ee440c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52692
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The Z370, H310C and B365 PCHs use the same silicon as 200-series
PCHs and they are supported by soc/intel/skylake codebase
(not by soc/intel/cannonlake). Mentioned PCHs are meant to be paired
with Coffee Lake CPUs, so add the corresponding microcodes.
Signed-off-by: Timofey Komarov <happycorsair@yandex.ru>
Change-Id: I479c648e40c4c607d29f8cdd913fdbd6d7d7d991
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The code is already compiled in on all platforms. Use it as it provides
the same functionality. Note that GCAP is no longer R/WO on these
platforms. However, select `AZALIA_LOCK_DOWN_R_WO_GCAP` just in case.
This will be dropped in a follow-up.
Tested on Prodrive Hermes, still detects and initializes both codecs.
Change-Id: I75424559b2b4aca63fb23bf4f8d5074aa1e1bb31
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50795
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Intel document 335192-004 contains the PCI device IDs for Z370 and
H310C, but lacks the ID for B365. The ID appears on some websites:
https://linux-hardware.org/index.php?id=pci:8086-a2cc-1849-a2cc
Change-Id: Iea3c435713c46854c5271fbc266f47ba4573db52
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52703
Reviewed-by: Timofey Komarov <happycorsair@yandex.ru>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The code name for these PCHs is Union Point, abbreviated as `UPT`. There
are some 300-series Union Point PCHs (H310C, B365, Z370) which are meant
to be paired with Coffee Lake CPUs instead of Skylake or Kaby Lake CPUs,
and referring to them as `KBP` (Kaby Point, I guess) would be confusing.
Tested with BUILD_TIMELESS=1, HP 280 G2 remains identical.
Change-Id: I1a49115ae7ac37e76ce8d440910fb59926f34fac
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52700
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Timofey Komarov <happycorsair@yandex.ru>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These PCHs are used with Xeon-SP processors, which use different code.
Change-Id: I05f67cd57aa9f867e2fab88cd49e0384073a0b20
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52699
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Timofey Komarov <happycorsair@yandex.ru>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove elog.c from EHL soc as EHL does not support chromebook and
hence does not need it.
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: If66adfe15d00feb0a7fb5e1ced92006a4adebdb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50173
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GPIOs are divided into different communities. Each community
consists of one or more GPIO groups. We need to configure the
groups in coreboot so that they are mapped properly.
GPIO communities should be properly configured in GPIO_CFG and
MISCCFG registers. GPP_* defines in gpio_soc_defs.h are configured
in GPIO_CFG register while the PMC_GPP_* in pmc.h.
GPIO communities in coreboot should match with the kernel gpio
communities also. Kernel reads the ASL file from coreboot. This
patch adds the proper community mapping in ASL code to match with
kernel code. In gpio_soc_defs.c file we are indexing the groups
correctly. In gpio.h file we define all the gpio devices as kernel
populates sysfs with separate gpio device for each community. This
patch is created based on Intel EHL PCH Datasheet with Document
number 614109 and Chapter 21.
Also update GPIO COM3 Port ID and 2 GPIO register values
(HOSTSW_OWN_REG_0 & PAD_CFG_BASE) respectively.
Signed-off-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
Change-Id: Ifc609b3d6ab9ea2b807dc0f178ec99f95d2db4cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The VT-d specification states that device scope for remapping hardware
unit which has DRHD_INCLUDE_PCI_ALL flags must be the last in the list
of hardware unit definition structure. This change fixes the devices
list in the DMAR DRHD structure.
BUG=None
TEST=Built image successfully.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I14c34ad66a5ee8c30acabd8fe5a05c22087f9120
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52477
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
