Use C-style comments everywhere, and follow the coding style.
Tested with BUILD_TIMELESS=1, Asus P5QL PRO remains identical.
Change-Id: I3ef96c5f6553ad50cee7d7f5614128b62a89e4ea
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The caches have already been enabled during MP-init,
so these function calls are redundant. Remove them.
Change-Id: Ia9be1a3388d8e7c73c35a1c68b3dd5bc488658c2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49383
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Fix C code to match comment and assembly implementation.
Tested on Prodrive hermes:
The microcode spinlock is no longer used.
Change-Id: I21441299f538783551d4d5ba2b2e7567e152d718
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49304
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change affects Intel CPUs only. As most platforms are doing
uCode update using FIT, they aren't affected by this code either.
Update microcode in MP-init using a single spinlock when running on
a Hyper-Threading enabled CPU on pre FIT platforms.
This will slow down the MP-init boot flow.
Intel SDM and various BWGs specify to use a semaphore to update
microcode on one thread per core on Hyper-Threading enabled CPUs.
Due to this complex code would be necessary to determine the core #ID,
initializing and picking the right semaphore out of CONFIG_MAX_CPUS / 2.
Instead use the existing global spinlock already present in MPinit code.
Assuming that only pre-FIT platforms with Hyper-Threading enabled and at
most 8 threads will ever run into this condition, the boot delay is
negligible.
This change is a counterproposal to the previous published patch series
being much more unsophisticated.
Change-Id: I27bf5177859c12e92d6ce7a2966c965d7262b472
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49303
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Eaglelake MRC 2.55 does this, and also stalls for less time.
Change-Id: Iaaefd32c341a490e5c129df865407ec3f8da8212
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
To allow other platforms to reuse this code, extract it into a separate
compilation unit. Since HPET is enabled through the southbridge, place
the code in the southbridge scope. Finally, select the newly-added
Kconfig option from i82801gx and replace lpc.c `enable_hpet` function.
Change-Id: I7a28cc4d12c6d79cd8ec45dfc8100f15e6eac303
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49365
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
On Coffee Lake systems prog_locate_hook() is called with PROG_POSTCAR.
For this reason the early check is not executed.
Add check for prog->type == PROG_POSTCAR, but execute
verified_boot_early_check() once.
BUG = N/A
TEST = Build and boot on Facebook FBG1701 and Intel CoffeeLake system
Change-Id: Ia3bd36064bcc8176302834c1e46a225937d61c20
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48852
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
make olddefconfig on other projects using USE_VENDORCODE_ELTAN results in error.
USE_VENDORCODE_ELTAN unmet direct dependencies.
Remove dependency on VBOOT for USE_VENDORCODE_ELTAN.
TEST = Build and boot on Facebook FBG1701
Change-Id: I5881c334955c73ae0f1a693f95ceb1aee62ee898
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48690
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
This struct isn't used anywhere else, so there's no need to name it.
Change-Id: I22eda07f14096d2b7400e6ab715641ffd68fbc08
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reported-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49444
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The default value is not sufficient to correctly configure the Type-C
ports as it has all ports disabled by default. On Volteer ports 0
and 1 are enabled so setting this value to 0x3 and correctly
keeping the IomPortPadCfg values at 0 for ports that have a
retimer and ports that are not configured. These values were set
to 0x90000000 to avoid s0ix issues which arose from the UsbTcPortEn
value being incorrect.
BUG=b:159151238
BRANCH=firmware-volteer-13672.B
TEST=Built image for Voxel and verified that s0ix cycles complete
without any issues
Change-Id: Ib4f2bd0f68debd4e97ccaab9e1d8a873dc4e4d9f
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48814
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As a requirement of TCSS this setting needs to be correctly set
to determine what Type-C ports are enabled on the platform. Without
this value correctly set there can be adverse effects on the other
TCSS specific values.
BUG=b:159151238
BRANCH=firmware-volteer-13672.B
TEST=Built image for Voxel and verified that S0ix cycles no longer
fail when the IomPortPad is set to 0
Change-Id: I6c5260cda71041439fe89d15bd3cafd4052ef1e7
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48813
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
These are no longer really useful. We can also enable Power Resource
ACPI debug in the kernel if we want these messages.
BUG=none
BRANCH=zork
TEST=emerge-zork and verify debug messages are no longer posted
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I936e816266825f1c59377c2e079ffe1a5188838c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Target added to INTERMEDIATE all operate on coreboot.pre, each modifying
the file in some way. When running them in parallel, coreboot.pre can be
read from and written to in parallel which can corrupt the result.
Add a function to create those rules that also adds existing
INTERMEDIATE targets to enforce an order (as established by evaluation
order of Makefile.inc files).
While at it, also add the addition to the PHONY target so we don't
forget it.
BUG=chromium:1154313, b:174585424
TEST=Built a configuration with SeaBIOS + SeaBIOS config files (ps2
timeout and sercon) and saw that they were executed.
Change-Id: Ia5803806e6c33083dfe5dec8904a65c46436e756
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49358
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ACPI part still needs some more code to be in place, so add that
later.
TEST=Together with the currently not merged rest of the amdfw patch
train applied this results in working serial console in bootblock in
Majolica.
Change-Id: Ia844e86a80c19026ac5b47a5a1e91c2553ea5cca
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49378
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since the functions that get called by the coreboot console
initialization code aren't in the SOC-specific code anymore, the SOC's
uart.c can be included unconditionally in the build now. This also
replaces the STONEYRIDGE_UART Kconfig option with the common
AMD_SOC_CONSOLE_UART one.
Change-Id: I09c15566a402895d6388715e8e5a802dc3c94fdd
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49375
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This will result in less code duplication when the common AMD SoC UART
support gets used for more AMD SoCs.
Change-Id: Id1786f32324de3e3947d792c599e2019705c5a85
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49373
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This partially reverts commit 6f8f9c969b
by moving CONSOLE_UART_BASE_ADDRESS back to the SoC-specific code, since
the number and base addresses of UARTs turned out to be rather SoC-
specific. The help text for the AMD_SOC_CONSOLE_UART option also
contained those base addresses, so remove that as well.
Change-Id: I01211ec62421c56f22ed611313d6245a05bdea67
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49372
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The UARTs in the Picasso SoC are memory mapped, but there is also some
hardware support that isn't used by any board to make the UARTs behave
like the ones found on legacy x86 machines from the 90s.
In the MMIO mode the MMIO address of the UART controller is passed to
the OS via ACPI. The OS expects the base clock of the UART controller to
be 48MHz (see the cz_uart_desc struct in drivers/acpi/acpi_apd.c and
drivers/tty/serial/8250/8250_dw.c in the Linux kernel) in this case. It
is also possible to enable additional decodes from four 8 byte legacy
I/O locations used for serial ports to the different UART controllers,
which doesn't disable the MMIO access though. The legacy I/O-mapped
serial ports are usually expected to have a base clock of 16*115200Hz
which the hardware can also provide to the UART's baud rate generator.
So there are two possible valid configurations to use the UARTs; either
MMIO access in combination with a 48MHz base clock or the legacy I/O
decode with a ~1.8MHz base clock.
The existing code unconditionally generates ACPI objects for all enabled
UARTs, so those shouldn't be put into legacy mode and switching the base
clock to ~1.8MHz was only done in the case that the UART was used as
coreboot console UART which still used the MMIO access, but the lower
base clock. Since no board even selects this option and it's rather
invasive to properly implement this feature, just drop the corresponding
broken code.
TEST=SoC UART console still works on Mandolin.
Change-Id: I26fa8fdfc781b583ba56ac4dbcbbfb6100e84852
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reported-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49371
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is causing boot errors on zork:
coreboot-v1.9308_26_0.0.22-18590-g4598a7bed945 Wed Dec 16 17:32:25 UTC 2020 bootblock starting (log level: 8)...
Family_Model: 00820f01
PSP boot mode: Development
Silicon level: Pre-Production
PMxC0 STATUS: 0x800 BIT11
I2C bus 3 version 0x3132322a
DW I2C bus 3 at 0xfedc5000 (400 KHz)
FMAP: area FW_MAIN_B found @ 312000 (3137280 bytes)
ASSERTION ERROR: file 'src/commonlib/bsd/cbfs_mcache.c', line 106
BUG=b:177323348
TEST=Boot ezkinil to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I1f2bbdd9c87c4efdfb0042e90a20b489fa0efced
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
While unused, this allows use of a common initialisation
code for GNVS allocation.
Change-Id: Ie84b5a3e16d3baa12bcd5dadac0b1f7edb323272
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Update PL1 min and max values for Delbin systems
BUG=b:168958222
BRANCH=None
TEST=Build and verify on delbin system
Signed-off-by: Deepika Punyamurtula <deepika.punyamurtula@intel.com>
Change-Id: I2152f0dbeb0ae463b78464571b6c434830f0082a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49364
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Reviewed-by: Zhuohao Lee <zhuohao@chromium.org>
The S3/S4 workaround is specific to Panther Point stepping A0, and it is
wrongly implemented. Rewrite the whole function as per reference code.
Since this runs in SMM, be overly cautious and double-check everything.
Do not rely on GNVS to determine if xHCI is enabled. Instead, check
whether the corresponding bit in the Function Disable register is set.
Only Panther Point has xHCI, so exit early if this is not the case.
Change-Id: Iabce6c52fac781dc694f5b589fab2e9fe438f3f5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49130
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This will allow CSE RW FW updates and also fixes the problem where no sound is emitted from the speakers.
BUG=b:174338903
BRANCH=firmware-volteer-13672.B
TEST=emerge-volteer coreboot
Signed-off-by: hao_chou <hao_chou@pegatron.corp-partner.google.com>
Change-Id: I875f6b32c4053ef6d23ad7606cd35a129a78c306
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49290
Reviewed-by: Zhuohao Lee <zhuohao@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Compilation has been broken in commit I022468f6957415ae68a7a7e70428ae6f82d23b06
Adding a missing define solved this. See https://cgit.freebsd.org/src/tree/sys/sys/fcntl.h#n319
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Change-Id: I3433e4c9269880d3202dd494e5b2e962757a6b87
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This change lets IOM consider all USB connected devices as device
attached(DA) scenario. While connecting a typec-to-a dongle, IOM would
disable TC cold and help to resolve enemuration failure after usb3
device is plugged into the dongle.
BUG=b:173054070
TEST=Build and boot on delbin.
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: I0ad0322693b4f8fbf1000b24eb21dddcebec686b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49244
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: John Zhao <john.zhao@intel.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The name `..._index` is confusing since the maximum index of an array is
not `ARRAY_SIZE(array)` but `ARRAY_SIZE(array) - 1`.
Rename `uart_max_index` to `uart_ctrlr_config_size` to make the name
match the variable´s value.
Change-Id: I7409c9dc040c3c6ad718abc96f268c187d50d79c
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Initiate overridetree.cb based on latest schematic.
BUG=b:174266035
TEST=Build Test
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I31e5ac1703476083ac71dac30b0a3299b38384c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Follow latest schematic to fill gpio table.
BUG=b:174266035
TEST=Build Test
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I3a983605b5139ff8510a0cf225e6564b9215cb1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Two USB2 ports 4 and 9 are assigned to type C connectors on Voxel board.
This update configures these USB2 ports for Type C which will allow USB2
port reset message upstream from PCH to CPU to recover a USB3 device
that downgraded to USB2 to upgrade back to USB3.
BUG=b:176575892
TEST=Booted to kernel on Voxel board and verified usb2 port reset
message enable bits through pch xhci_mmio_base + R_XHCI_MEM_U2PRM_U2PRDE
where the offset register R_XHCI_MEM_U2PRM_U2PRDE has value 0x92f4.
Validated various USB3 devices enumeration.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ia370a449a41701e690c1c507d70bedfce2076a65
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49053
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.corp-partner.google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When building as part of the coreboot build system, use the same
mechanism as other tools (cbfstool, amdfwtool, ...) so that abuild
builds ifdtool once into sharedutils instead of once per board (while
avoiding other race conditions, too).
Change-Id: I42c7b43cc0859916174d59cba6b62630e70287fd
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49312
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
It is only used in one place, and there's two other equivalent macros.
Change-Id: I7c8241e28f688abd2df8180559dd02ee441c7023
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The bugs happen on real hardware or in qemu with KVM enabled.
The very same code runs on some real devices and it runs in qemu
with KVM disabled.
The bugs are so strange that no root cause could be found yet.
Change-Id: I01050f2e38f92c6b96e3258a5b619aa9ee685acc
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44733
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Get rid of using eax and reload counter on race condition.
Change-Id: Ie4b9957d8aa1f272ff1db5caf2c69d1e1f086a03
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47714
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Angel Pons