If both CONFIG_SEPARATE_ROMSTAGE and CONFIG_BOOTBLOCK_CONSOLE are not
set, compilation will fail with errors indicating redefinitions of
various console methods.
When BOOTBLOCK_CONSOLE is not set, the __CONSOLE_ENABLE__ macro in
include/console/console.h evaluates to zero when compiling the
bootblock, resulting in various console methods being defined as stubs
in the header. In a typical build with a separate bootblock and
romstage, this will not cause a conflict as the non-stub definitions
found in the console/*.c files are added conditionally to the bootblock
depending on CONFIG_BOOTBLOCK_CONSOLE.
When SEPARATE_ROMSTAGE is not set, the list of romstage objects gets
added to the bootblock. Since the console sources were unconditionally
added to romstage, the non-stub definitions were able to slip into the
bootblock, causing a redefinition of the stubs.
Avoid this by conditionally adding these sources to romstage depending
on CONFIG_SEPARATE_ROMSTAGE. If SEPARATE_ROMSTAGE is set, the non-stub
definitions are handled in the same way as they were before. If it is
not set, the union of bootblock and romstage objects will only include
the non-stub definitions based on CONFIG_BOOTBLOCK_CONSOLE, which uses
existing console/Makefile.mk rules for the bootblock.
TEST=qemu-i440fx builds successfully with all possible settings of
CONFIG_SEPARATE_ROMSTAGE and CONFIG_BOOTBLOCK_CONSOLE.
Change-Id: I59b3f0c52a4338b1573e0a647bc16cec4943fd7f
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83088
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
As of commit ee12634872 (nb/sandybridge,sb/bd82x6x: Configure USB from
southbridge devicetree) and earlier commits, the USB port configuration
should be located in the devicetree instead of the mainboard_usb_ports
array, typically located in the boards early_init.c.
TEST=USB ports still function; and the USBIRx, USBPDO, USBOCM1, and
USBOCM2 RCBA registers in the inteltool dump did not change between
an E6430 build before and after the sb/intel/bd82x6x that moved the
usb config to the devicetree.
Change-Id: Ia5aa03a5894a8ef29e863470925a223f52e0ab70
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83006
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of using a relative path for the submodules, specify the sub-
module URLs as pointing at coreboot.org, using https.
While the relative path works well for coreboot itself, when the repo
is forked and fetched from from anywhere other than review.coreboot.org,
this file either needs to be modified, or all the submodules need to be
checked out as well.
Change-Id: Ie4f95c70a7f194d1073dc561c9f33dcc108060cc
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80552
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The host bridge PCI device ID can be changed by the firmware. There
is no documentation about it, though. There's 'official' IDs, which
appear in spec updates and Windows drivers, and 'mysterious' IDs,
which Intel doesn't want OSes to know about and thus are not listed.
For the sake of completeness, add the PCI device IDs for Clarkdale.
Though coreboot only supports Arrandale, both of them are Ironlake.
It is possible that the Management Engine handles changing the PCI
device ID, which would not happen when using a broken ME firmware.
Change-Id: I85a48fcf0e0e62f42fe147a5d4e2d557b2143e5b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60215
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Trying to probe RAM space to figure out top of memory causes an
exception on RISC-V virtual machines with recent versions of QEMU, but
we temporarily enable exception handlers for that and use it to help
detect if a RAM address is usable or not. However, QEMU docs recommend
reading device information from the device-tree blob it provides us at
the start of RAM.
A previous commit adds a library function to parse device-tree blob that
QEMU provides us. Use it to determine top of memory in RISC-V QEMU
virtual machines, but still fall back to the RAM probing approach as a
last-ditch effort.
Change-Id: I9e4a95f49ad373675939329eef40d7423a4132ab
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The OpenTitan HW implements the same firmware interface as the Ti50
H1D3C hardware variant; it just has a different DID_VID. Allow this new
DID_VID to be recognized correctly.
BUG=b:324940153
Change-Id: Iaacf6d88bc6067948756c465aac1cd8b24ecae1f
Signed-off-by: Jett Rink <jettrink@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83033
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch eliminates coreboot from loading microcode from RW CBFS
(when the RO descriptor is locked, which indicates a fixed RO image)
because the kernel can already patch the microcode on BSPs and APs
while booting to OS.
This may be a chance to lower the burden on the AP FW side because
patching microcode on in-field devices is subject to firmware updates,
which are rarely published and, if required, must go through the
firmware qualification testing procedure (which is costly, unlike
kernel updates for ucode updates).
1. The FIT loads the necessary microcode from the RO during reset.
2. Reloading microcode from RW CBFS impacts boot time
(~60ms, core-dependent).
3. The kernel can still load microcode updates.
ChromeOS devices leverage RO+RW-A/RW-B booting. The RO's microcode is
sufficient for initial boot, and the kernel can apply updates later.
BUG=none
TEST=Verified boot optimization; in-field devices skip RW-CBFS microcode
loading when RO is locked.
Change-Id: I68953d45d3624aba0a3be28bc7b266b7621ddcc4
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82999
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While both APL and GLK load the CPU microcode from FIT, only GLK
supports the PRMRR/SGX feature. When this feature is supported, the
FIT microcode load will set the msr (0x08b) with the patch id/revision
one less than the revision in the microcode binary. This results in
coreboot attempting (and failing) to reload the microcode again in
ramstage. Avoid the microcode reload attempt for GLK by using a SoC-
specific microcode update check which accounts for the off-by-1 when
comparing versions.
Implementation is based on the one used for SKL and CNL, but modified
based on feedback in comments on Gerrit.
TEST=build/boot google/reef (electro) and google/octopus (ampton),
verify in cbmem console log that CPU microcode update in ramstage is
skipped due to already being up to date, and that GLK uses the
SoC-specific check and APL uses the non-specific/general one.
Change-Id: Iab97f23d4388d5057797bb13f585db821c735bd0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83037
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When dynamically generating the DOD (Display Output Device) device
address (_ADR), don't set the DOD constraint flags; only set them when
using the address value to generate the DOD package.
This fixes ACPI brightness control functionality under Windows 11.
Before: Name (_ADR, 0x80010400)
After: Name (_ADR, 0x00000400)
TEST=build/boot Win11 on google brya (banshee), ensure display
brightness controls present and functional.
Ref: ACPI Spec 6.5 Appendix B.6.1 - _ADR
Change-Id: I1d710c6e55e6cb1d20d580bd784221ee1482b871
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83025
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Removed an extra space character from the `printf` format string in
`dump_exception_state` to ensure proper alignment of register values
when printed during exception handling.
BUG=b:336265399
TEST=Built and booted google/rex64 successfully.
Verified correct alignment in exception state dumps.
Change-Id: I8ff92775e32ee754967b1b0a43cd68971b4aadfc
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83047
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
OpenSBI got bigger and doesn't fit anymore in 128K which causes coreboot
to not compiler anymore because the region overlaps with ramstage
This patch simply increases the size and uses the OpenSBI linker macro
instead.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: If1ccaafbf91dae986c470020faf9c0b4fba448e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83046
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Enable the fixed boot mode option in the VBT and set it to 1920x1080,
so that drobit boards equipped with 4K screens are legible at boot.
TEST=build/boot drobit w/4K screen using edk2 payload, verify boot
resolution set to 1080p and UEFI menus readable without a magnifying
glass.
Change-Id: If1f9e36d9bbdc2955ba890e2832aa64af9ba8f73
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Update autoport for:
1. Commit ee12634872 ("nb/sandybridge,sb/bd82x6x: Configure USB from
southbridge devicetree")
2. Commit 94625d2aae ("sb/intel/bd82x6x: Allow actual USBIRx values
for native USB config")
As a side effect of #2 above, no more (broken anyway) FIXME comment
will be written for usb_port_config.
Change-Id: I3b8f44d9de19a7446e2fbcbce1aab6ec6583ebe3
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82656
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This commit defines the panel_cfg register for the Razer Blade Stealth
(Kaby Lake). This enables libgfxinit support. These values are derived
from the stock firmware. First, VBIOSes were extracted from the stock
firmware. Then, intelvbtool was used to extract the VBT from each of the
VBIOS tables. Finally, intel_vbt_decode from igt-gpu-tools was used to
extract the register values. Although there were multiple VBIOSes
present in the firmware, all VBIOSes across both firmwares (on version
1.50 for the H2U and 8.02 for the H3Q) had the same register values.
Change-Id: I4c8b26ffb7a70d08655986084a714206d9d0c96a
Signed-off-by: Reagan Bohan <xbjfk.github@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82458
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 88decca14f ("ACPI: Add helper fill_fadt_extended_pm_io()")
moved the population of the extended FADT to a separate function, but
incorrectly placed that function call before various length fields were
populated, leading to spurious validation errors in the cbmem boot log.
Correct this by moving the call to fill_fadt_extended_pm_io() after
the required fields are populated.
TEST=build/boot google/slippy (wolf), verify no FADT errors in cbmem
console log.
Change-Id: I1f8522e4813e6071692206f2b7ad2a2f5086071e
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83035
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
All of the Dell Latitudes from GM45 and until at least Haswell use a
derivative of the MEC5035 EC, and I have been actively working on
coreboot support for this EC and boards that use it. Rename the "E6400
MAINBOARD" section to "DELL LATITUDE" and add mb/dell/snb_ivb_latitude
and mb/dell/e7240 as additional paths.
Change-Id: I7ba46980bfc8569a85593e415f01cc83fe7d67d7
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83008
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 45e4ab4a66 (mb/*: Update SPD mapping for sandybridge boards)
changed the way in which SPD addresses are set up for SNB/IVB boards,
but autoport was not updated to reflect these changes. Result is:
register "spd_addresses" = "{0x50, 0x51, 0x52, 0x53}" # FIXME: Put proper SPD map here"
The stray quote at the end is irritating, but is hard to get rid of
without substantial refactoring of autoport's guts. But, given that
this is a FIXME comment, anyone using autoport should just drop the
comment after verifying the SPD map, so it's not a big deal.
In addition, update the corresponding section of the README, which
was horrendously out-of-date.
Change-Id: I6ad38f53afc4fafb45be7f086723cc0782a965ed
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82405
Reviewed-by: Keith Hui <buurin@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The word "experimental" has been removed from the help text for
HAVE_X86_64_SUPPORT Kconfig. This is because the x86_64 architecture
has now been officially tested and enabled for several x86 SoC
platforms.
This work will provide us with the foundation we need to begin working
with Intel's next-generation SoC platform (which requires to support
64-bit mode of booting by default).
Therefore, we can now remove the word "experimental" from the
"HAVE_X86_64_SUPPORT" Kconfig help text.
TEST=Able to build and boot google/rex64 in 64-bit mode to ChromeOS.
Change-Id: Ibd629f4e2722f3cbabbe297d4481790c9fa9226a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83009
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
