It was accidently added and is just dead code.
It doesn't change any functionality.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I868b8c8725fc2240543fb1e9e379ecb5e1471ef4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89898
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
The amdfw.rom will be divided into 3 parts:
PSP Level 1, PSP Level 2A, PSP Level 2B.
The two ISHs are close to L1 and can be combined as a CBFS module.
To do that, move the new_psp_dir for L1 and L2 to separated branches.
The final sequence is EFS, PSP L1, ISH A, ISH B, PSP L2A, BIOS L2A,
PSP L2B, BIOS L2B.
TEST=Google/Skyrim
Change-Id: Id69268619893d78d9b5330052a4fd5b501263f75
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Trying to read a firmware binary for Turin platform results in
"Invalid address(41400) or mode(0)" error. The utility does not
respect the address mode set by the directory header. The address
mode of th entries is valid only if the address mode of the directory
is equal to 2 or 3.
Check the address mode of the directory and use it for entries only
when its value is less than 2.
TEST=Successfuly parse vendor BIOS for Gigabyte MZ33-AR1.
Change-Id: I479bc846bfb334231fdc707274a8ac44b6c384d4
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
According to AMD documentation, starting from Family 17h Models
00h-0Fh, the PSP on-chip boot loader reads the PSP directory pointer
from offset 0x14 in the Embedded Firmware structure, replacing the
previous offset 0x10.
The docs do not specify any special value indicating a change of
offset. Some AMI binaries use a zero address in this directory field,
which caused incorrect offset handling.
Change-Id: I67ab763d070a9580a8269b525b203c932c5b1b95
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88868
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Intel ifdtool can dump the Intel Firmware Descriptor, which is helpful
for debugging and inspecting firmware binaries. This utility lacked
similar functionality, so this patch introduces a `--dump` CLI option
to display decoded information from the embedded firmware header.
Currently, the output includes SPI frequency and read mode for various
AMD family models.
Change-Id: Ideb1076f1d580496dac293882007cfa4672d188b
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88610
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Move the NULL pointer check to the beginning of the fill_dir_header function
before any dereference of the directory pointer. This prevents the potential
segmentation fault that could occur if directory is NULL.
This fixes CID 1540835 - Dereference before null check (REVERSE_NULL).
Change-Id: I12bb146d59839381478034f974b7d408f92ae677
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88617
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds parsing for some more possible firmware blobs on AMD.
These binaries are used on a mainboard based on glinda SOC.
Tested: Boot birman_plus mainboard
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I78d7a9dba71de557e0a9a885d8561eea1f4191ef
Original-signed-off-by: Anand Vaikar <a.vaikar2021@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84373
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The addresses and their modes should now all be correct and we can
therefore treat the case where `addr` and `mode` do not match as an
actual error.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Id12c29648c0437dd082b471689ec3649314dee1c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87298
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
There is no need to treat the APOB_NV binary special anymore, as
the mode and address should now always match for the APOB_NV address.
Since phoenix SOC generation this code even errors out on VBOOT
platforms, because APOB_NV address is actually a BIOS relative address.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I64d43e654e3694d7590edcba9a87c98367a7256c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
In order to not change the actual binaries in too many ways,
commit a7eb390796 ("mb/*/*/*.fmd: Start flash at 0") kept the current
behaviour in which the address mode was set to ADDR_REL_BIOS, but the
address itself was actually a physical address. It has probably only
worked all these years, because PSP/ABL code did apparently ignore the
address mode for this specific binary for generations previous to
phoenix.
Assuming the address mode is actually ignored we might as well use the
right address mode corresponding to the address that is set. That way
tooling that is used to inspect this image is not completely confused.
This sets the ADDR_PHYSICAL address mode to all generations that have
the APOB NV quirk. It therefore only affects these generations (previous
to phoenix).
tested:
Check that the binary is identical on bilby, morphius, kahlee, onyx and
birman_plus. bilby, kahlee, onyx don't have an APOB_NV region. morphius
uses a physical address anyway and birman_plus doesn't have the
apob_nv_quirk.
Check that only the address mode is changed to ADDR_PHYSICAL (and the
checksum of the table) on guybrush, frostflow, crater, chausie.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ib2edfb27ba0fa316f1fbe31bc0ad8e2060a70f48
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87296
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This moves the code to amdfwtool.c, because the subsequent patch needs
it to be there in order to properly update the address_mode.
This patch should not change the binary in ANY way on any platform.
tested: Check that the binary is identical on guybrush, birman_plus,
frostflow, bilby, crater, grunt, myst, onyx_poc, morphius
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I9c64c67ff8b9656516344fdafbfd2254abfceeef
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The current approach has two problems:
- Just because the source address is 0 does not mean it is no
specifically set. A bunch of mainboards specify their APOB_NV base
address at 0 in their FMAP files.
- There is no AMD SOC that has support for this binary, but doesn't give
AMDFWTOOL the base address. It would also not work considering that
AMD common/block/apob code gets the region from the FMAP.
Therefore just remove the check since no mainboard will ever enter the
else branch.
tested: binary identical for at least 1 mainboard on each SOC
generation.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ic85d6b25c95ab12dbcc72d17158591891dd04e97
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87292
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
If the `--help` argument is passed, print the usage and immediately
return. This avoids printing errors about 'invalid config,' which
users don't specify when getting the usage information, and potentially
printing the usage a second time before exiting.
Change-Id: I18bf154ff5177fa0e0aa6a41f0d71980fed7ce55
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Now that we require the FMAP to start at offset 0 in the flash, we can
assume this across the entire codebase and therefore simplify it on
several ends.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ieb1a23f9c0ae8c0e1c91287d7eb6f7f0abbf0c2c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86771
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
FMAP should not contain information about the memory map.
Done with the following command:
"find -name \*.fmd -exec sed -i 's/\(FLASH\).* \(.*\) /\1 \2 /' {} \;"
for AMD:
All addresses that amdfwtool expects as command line parameter have the
ADDR_REL_BIOS (flash address) address_mode setting. One exception is
the *_FW_A_POSITION and *_FW_B_POSITION addresses. But amdfwtool checks
if memory or flash addresses are passed and converts accordingly. So
changing the address from memory -> flash doesn't matter for the
resulting binary.
Since commit 41a162b7a8 ("soc/amd/phoenix/Makefile.inc: Pass APOB_NV
address as offset") and therefore since phoenix SOC, APOB_NV is passed
as flash offset. But before that the memory ABL always assumed a MMIO
address (no matter the address_mode) so we need to add a little quirk
for that.
tested: boot glinda based mainboard and also check that memory training
is still cached successfully in APOB_NV.
Change-Id: Iac86ef9be6b14817a65bf3a7ccb624d205ca3f99
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Add the PLATFORM_FAEGAN element to the 'platform' enum and use it in the
code. The Faegan SoC is similar to the Glinda SoC, but has a different
PSP ID.
Change-Id: I40a3e9981696fc02a44fbf300d1b47060a4a398b
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86940
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ana Carolina Cabral <ana.cpmelo95@gmail.com>
Other types of FWs in the BIOS table are defined by context. So the
BIOS binary should follow that.
TEST=Binary identical test on platforms before mendocino
Tested on Skyrim
Change-Id: I9c2f2983d03c913b28fbd87aa0925a32a4649d62
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85466
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It is more reasonable. And, in later change, the Level 1 should be
split with Level 2 and combined with EFS.
Change locate_bdt2_bios to locate_bdt_bios. This function is more
flexibile and covers both L1 and L2 BIOS directory table.
Change-Id: I74605013cf53a38686f4e1e5a89a4e6a870f1f4b
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84532
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We need to know how many combo entries have been processed.
It will be checked in functions in later change.
Change-Id: I4b026b0630a18d1f46bff98ffe5f11e7f930d7a8
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85590
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clean up the code to make it more logical.
This is for later changes to reorder the PSP Level 1, Level 2, ISH and
BIOS tables.
TEST=Identical test on all AMD platform
Change-Id: I5f7213fd42c7f0ff5ecd9e504a6654cdfb1e3513
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84531
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For A/B recovery, it is better, even though it is not mandatory, to
put BIOS level 2 table next to its PSP level2. So the relative
addresses of BIOS table are the same. So all the data in B could be a
copy of A.
Identical binary test on all non A/B recovery platform.
Booting test on Majolica with A/B recovery enabled.
Change-Id: Ia25277d307329a2fa66d38d1a7fc21b18246cfe6
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84440
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The address field of each PSP or BIOS entry defines the location of
the entry.
For the family newer than Cezanne, the upper 2 bits define the address
mode. In table header, the address mode of the table is set. They have
the same definition.
Address Mode 0: Physical Address
Address Mode 1: Relative Address to entire BIOS image
Address Mode 2: Relative Address to PSP/BIOS directory
Address Mode 3: Relative Address to slot N
In common case, the address mode of entry should be the same as its
table. In spec, it says, "attribute is ignored if the directory
address mode is not 2 or 3",
In the old code, if the header defines address mode as relative BIOS(1),
the entry address mode is not set. That meets the spec. PSP doesn't
use, but amdfwtool can use it to record the address mode and transfer
it to table. That can reduce the code complexity.
Identidal binary test passes on platforms which are not based on
Cezanne, V2000A, Genoa. Booting test passes on Majolica/Cezanne.
Change-Id: I156b315d350d9e7217afc7442ca80277bb7f9095
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84530
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
The fields spi_block_size and base_addr of regular PSP header, lookup
and reserved of combo header, are constants. So we
move the setting statements to the creation functions.
Only update the count, size and fletcher in later function
file_dir_header.
TEST=Binary identical test on all AMD SOC platforms
Change-Id: I55c400e45536a57841b01d7c90d3fef9afa53e78
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84130
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
TEST=Binary identical test on all AMD SOC platform with use_combo
Change-Id: I41c5c6fb5acf92604dd06becf1eda680a1fab545
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84131
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The new layout definition has a new way to support combo.
It packs multiple ISH entries into PSP L1 directory.
TEST=Identical test on all AMD platform
Change-Id: If573cdeaeb56e95d2fed235c9337fab82d622757
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The Max size of L2 table is 0x400. If we set it to other value, the
the A/B recovery image can not boot on Cezanne/Majolica platform.
The affected boards are Birman, Chausie, Skyrim, Mayan. Other boards
are binary identical. Tested on Skyrim and image can boot.
Change-Id: I2c0af6579dbe2a3a61e1fe9c79d69491fd45a5bb
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84194
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support to specify the base and size of the replay-protected
monotonic counter (RPMC) non-volatile storage area in the SPI flash. A
later patch will use this to tell amdfwtool about the location and size
of the corresponding FMAP section.
This code is ported from
github.com/teslamotors/coreboot/tree/tesla-4.12-amd
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Idafa7d9bf64125bcabd9b47e77147bcffee739e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83812
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
The value stored in `gen` is only ever `1` or `0`. Storing `1` causes
Clang to warn, since the only valid values for a 1-bit int are -1 and 0:
```
amdfwtool.c:1487:27: error: implicit truncation from 'int' to a one-bit
wide bit-field changes value from 1 to -1
[-Werror,-Wsingle-bit-bitfield-constant-conversion]
1487 | amd_romsig->efs_gen.gen = EFS_BEFORE_SECOND_GEN;
```
TEST=Rebuilt coreboot; no warning was emitted.
Change-Id: Ibd83be8302e8a717db7e7dc86a403b5648976586
Signed-off-by: George Burgess IV <gbiv@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83412
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
TEST=Identical binary test on all AMD SOC platform
Change-Id: Iece4ba65e0476543a8d472168d93801714330dde
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78281
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Other function calls don't have to worry about the fletcher error.
TEST=Binary identical test on all AMD SOC platform
Change-Id: I7c9d653100b476b52d6d1d80c41d0c3d765f7be3
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81372
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Move the complexity from main to function, so the main flow is easy to
understand.
TEST=Identical test on all AMD SOC platform
Change-Id: Ia549a0d08c2a60b8858440543ac8d8b5259017dd
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
When the table is created, the cookie is known.
When the packing going on, the cookie in header can be checked to see
where we are.
TEST=Identical test on all AMD SOC platform
Change-Id: I300e30292c68a14b44c637b26a13b308dc9c0388
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81254
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Before every integration there is a header creation. We can put them
together. And the parameters for PSP/BIOS tables are useless.
TEST=Identical test on all AMD SOC platform
Change-Id: Ia9d78bb8145855203048208fcd67f8b9cd9d3199
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81253
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The purpose of integration function is to pack the FWs into table. We
need to remove other process. Create a dedicate function to link all
the tables together. And this linking function is only called when
both the level 1 and level 2 directory are created. This simplifies
the main function and logic.
TEST=Identical test on all AMD SOC platform
Change-Id: Ieaf97208e943c79d7b76ea62eea9355138c220b9
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81252
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Instead of being local variables. This can be easier to find all
the tables anywhere.
TEST=Identical test on all AMD SOC platform
Change-Id: I98b7d01e32c75b4f13e23d496cd3de3da900678d
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
For recovery A/B mode, the BIOS tables level 2 are traced by PSP table
instead of ROMSIG. There should not be a dedicated BIOS table, nor a
combo BIOS table.
Change-Id: I8735bd91b32bc9a0e4fc70d293e8d836d5e9c36b
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81137
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It was complicated and weird to check both the cookie and whether one
table is a null pointer. Just checking the cookie is enough.
TEST=Identical test on all AMD SOC platform
Change-Id: Icab74714990f74e11fd5e899661e4e2d41230541
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81208
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The entry in the table has two categaries, file and pointer. For the
pointer, it does not take table space. The ISH, PSP level 2, BIOS
table are all the pointer type. So integration function only packs FWs
located in folder amd_blobs. And only FWs increase the table size.
So the table size is only set once. Later calls only update the count
and fletcher. The table has a header at least, so the size can not be
0.
The fill_dir_header can take the parameter count as 0, such PSP level
1 only with ISH-A and ISH-B. It doesn't have any file type entries.
This actually reverts
https://review.coreboot.org/c/coreboot/+/78274
and adds other changes.
TEST=Identical test on all AMD SOC platform
Change-Id: I5dfbbb55912c8e37243c351427a8df89c12e5da8
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81255
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Align with the function integrating PSP FWs. And it is the integration
function's responsibility.
TEST=Identical test on all AMD platforms
Change-Id: I1a98614f3a5756a462b01085e9565b52cf9a9343
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78280
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Cleanup the messy code. The code left in main is all about filling
tables.
To help to do this,
1. Some local variables are put into global struct.
2. Add some functions. Set some functions to global.
TEST=Identical test on all AMD platforms
Change-Id: Ia25c3fd5de7ae48054359f0f6551d91d7a4f6828
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78311
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The space defined by size of the L1 table can not overlap with ISH
header. For other cases, the size defines the directory and its
content.
The PSP spec does not say it quite clearly. This change is partly
based on guess and can make extraction tool work so far.
Change-Id: Id4fbc6d57d7ea070a9478649a96af92be9441289
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78274
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This is for next CL to move the write_body to another source,
handle_file.c.
https://review.coreboot.org/c/coreboot/+/78305
Removing amdfwtool_cleanup in write_body will not change the
result. Write_body returns to main and amdfwtool_cleanup still ends up
getting called.
Change-Id: I639828498fa45911f430500735e90ddc198b6af5
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78304
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When updating the Makefiles, to keep from having to update two files at
the same time, import Makefile.mk into the external Makefile. This
allows the bulk of the settings to be in a single location.
While I'm here, I adjusted the print statements to match the rest of
coreboot.
Change-Id: Id5b869f49b34b22e6a02fc086e7b42975141a87e
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
When we're building non-AMD processors, don't bother building amdfwtool
unless we're specifically building all of the tools like for abuild.
Change-Id: I9021674a06d65a79e24020790d317ab947c505fe
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80714
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I434940ebb46853980596f7ad55d27a62c90280fa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
