On AM5 desktop platforms the addressing mode for L2 directories
is table-relative (2). However, the L2 pointers and L1 directories
always use the BIOS relative address mode (1) in AM5 combo images.
Force the BIOS-relative address mode for L1 directories whenever
the tool attempts to use table-relative address mode for L1
directories and their entries.
TEST=Boot bootblock on MSI PRO B850-P.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The combo images on AM5 platform may have multiple ISH structures
which point to the same PSP L2 directories, but differ with PSP IDs.
Do not return prematurely from the PSP directory parsing. Instead,
let the tool print the duplicated PSP L2 address, but do not parse it
again. This lets the other entries in given directory to be parsed
and printed (if the L2 pointer is not the last entry in the directory).
Add printing ISH structures to determine the PSP IDs supported by
given PSP L2 directories.
TEST=Parse MSI PRO B850-P vendor BIOS.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The value ot EFS offset 0x54 is the USB BIOS Update (UBU) pointer.
It is mentioned in doc 55758.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The offset mask should match the ROM file size. The AM5 combo images
may contain BIOS relative addresses exceeding 16MiB boundary. Unlike
server parts, where the SPI flash space is paged into 16MiB parts,
the desktop parts do not have such limitation.
Preserve the old mask for cases where physical addressing is used and
supports only 16MiB flashes.
TEST=Parse MSI PRO B850-P vendor BIOS.
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Sort entries by type in ascending order and change the directories
where certain entries should be placed. The goal is to be as close
to reference AGESA implementation as possible. Otherwise the
Gigabyte MZ33-AR1 platform does not boot.
Building a working image is only possible with blobs from Turin PI
packages currently, due to this issue:
https://github.com/openSIL/amd_firmwares/issues/1
TEST=Build and run coreboot image for Gigabyte MZ33-AR1 and see
console messages from bootblock.
Change-Id: Id42f59f8295425158c8c1fa7c25d09f3398e2a39
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Gigabyte BMC can perform BIOS updates using RBU files. These files
are raw BIOS images appended with #GBT#ROM magic string and a 16bit
image checksum. No additional image verification required from BMC side
to accept an image.
TEST=Pack Gigabyte MZ33-AR1 coreboot image into RBU file and perform
udpate via BMC.
Change-Id: I91433239bfb08687c778e149a8da3b5cc55e7695
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
The PSP soft fuse is a 64bit value which does not use address mode
bits. Those address mode bits are also part of the soft fuse value,
thus must not be hardcoded to 0.
Change-Id: I5a3e078800653d15baf1939fdce11a60031b9978
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Replace hardcoded values of address mode with its corresponding
enum value to increase code readability.
Change-Id: Ib2d97f36aa19235a312558e397f97e2607476e61
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Add new entries supported by AMD Turin platform. Some of them, like
S3 images, are required to boot the platform.
Change-Id: Icf6a7d67ccba2c50174a8ee70ef5300c22f920dc
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Clear whole EFS structure on creation, instead of a partial clear.
Reference AGESA implementation on Genoa and Turin set the unused
fields to zero as well.
Change-Id: I7cdefd29dc95b9e212b0cd6f21b184d5c7a44a2b
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Set the EFS structure for Genoa and Turin platforms. According
to Gigabyte MZ33-AR1 binary analysis, the Genoa and Turin platforms
use the Fam15h fields for SPI read mode and speed. Fill the newly
added eSPI configuration on these platforms.
Change-Id: I661b66ecf0f30a3a8887b114d2c0c6f62584759e
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
AMD server platforms have additional fields for eSPI configuration
in the EFS structure. It is read by PSP to configure eSPI bus early.
Change-Id: I2fdde016ba800df2b5e198b0dab5cc29339e418a
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Print more information about embedded firmware structure and the
directories.
TEST=Print EFS and BIOS/PSP headers using Giabyte MZ33-AR1 BIOS image.
Change-Id: I3dc1f26deaad0497e5811128e9d613b4069468c9
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Previously, `KconfigBool` was used to generate selects (if the option
value is true) or bool option overrides (if the option value is false).
This approach is not particularly flexible: one cannot have conditions
for selects, and bool option overrides can only disable options.
Introduce a new `KconfigStatement` map of Kconfig names to conditions.
An empty condition string means that no condition is to be added. Also
update uses of `KconfigBool` to `KconfigSelect` to preserve autoport's
current behaviour.
TEST=Generated files for HP ProBook 4740s (Sandy Bridge) do not change.
Change-Id: I88666ce0d761c1d393ac602196229ec0878fed42
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90585
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
It updates the target variable that is used for `clang -target`.
Simply because the format was wrong. According to the documentation the
format of the so called "target triple" is:
<arch><sub>-<vendor>-<sys>-<env>
with:
arch = x86_64, i386, arm, thumb, mips, etc.
sub = for ex. on ARM: v5, v6m, v7a, v7m, etc.
vendor = pc, apple, nvidia, ibm, etc. (can be omitted)
sys = none, linux, win32, darwin, cuda, etc.
env = eabi, gnu, android, macho, elf, etc.
In case of powerpc that causes an issue when trying to update clang to
version 21. The target parameter for clang ends up being
"powerpc64-none-unknown-linux-gnu". After testing, it turns out that in
clang version 18 that is actually a valid target parameter, although not
according to the documentation. In clang 21 however its not valid so fix
it accordingly.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I958416e6c56459766794830fbeac57ac827ffdd9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
GCC's configure script requires gnat1, gnatbind, and gnatmake to be
available as unversioned executables in PATH when building with Ada
support. The previous detection logic only checked for gnat1 and used
a lenient searchtool check for gnatbind, which could incorrectly
enable Ada support when gnatmake was missing, causing configure to
fail with "GNAT is required to build ada".
In GNAT 15+, tools may only be available as versioned executables
(e.g., gnatbind-15, gnatmake-15), but GCC configure still requires
unversioned names. This change:
1. Adds explicit checks for gnatbind and gnatmake (unversioned)
2. Updates have_gnat() to require all three tools
3. Detects GNAT 15+ versioned tools and provides helpful error
messages with instructions to create symlinks
4. Falls back to generic installation instructions if no GNAT tools
are found
This prevents the configure error and provides clear guidance for
users with GNAT 15+ installations.
Change-Id: Idc16ec48612e88fc9bdd16b343ae267aa20490f3
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
AMD_FW_GFXIMU_2 entry has the same type value as AMD_FW_SRAM_FW_EXT.
The tool may integrate one of these blobs incorrectly, because
it searches for the first entry of given type in the amd_psp_fw_table.
AMD_FW_GFXIMU_2 could have been added by mistake, because there is no
board that actually defines PSP_GFX_IMMU_FILE_2 in fw.cfg file.
Change-Id: I7e1f38c77156d06e9e6d801bdfa9b9eefcbb374e
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90388
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>