In cases where there are limitations on the mainboard it can be
necessary to limit the used SATA speed even though both, the SATA
controller and disk drive support a higher speed rate. The FSP parameter
'SpeedLimit' allows to set the speed limit.
It should be noted that Gen 3 equals the default value '0'. This means
that inside FSP the same code is executed.
This patch provides a chip config so that this FSP parameter can be
set as needed in the devicetree on mainboard level.
Change-Id: I9c3eda0649546e3a40eb24a015b7c6efd8f90e0f
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75364
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jan Samek <jan.samek@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Check existence of crashlog records in CBMEM before copying them
to BERT, otherwise it can lead to NULL pointer access.
Bug=None
TEST=Able to build. With Meteor Lake SOC related patch, able to
capture and decode crashlog.
Change-Id: I4288011866283a3a5fb8ec9e10cd51b794052b4e
Signed-off-by: Pratikkumar Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75528
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a new Kconfig LINUXPAYLOAD_CMDLINE_VPD_OVERWRITE that can overwrite
Linux payload's kernel command line from VPD. Currently only overwrite
Linux kernel command line 'loglevel' via VPD key 'kernel_log_level'.
TESTED=On OCP Delta Lake, with kernel_log_level set to 0, warm reboot
time can see about 10 seconds improvement comparing to kernel log level
7.
Change-Id: Idf06c7ab9958c940fc3b23d560bb9dade991a6da
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
When the default pci_domain_read_resources() is used,
keep 32-bit memory resources below the limit given by
CONFIG_DOMAIN_RESOURCE_32BIT_LIMIT. This serves as a
workaround for missing/wrong reservations of chipset
resources.
This will help to get more stable results from our own
allocator, but is far from a complete solution. Indvi-
dual platform ASL code also needs to be considered, so
the OS won't assign conflicting resources.
Most platforms have reserved space between 0xfe000000
and the 4G barrier. So use that as a global default.
In case of `soc/intel/common/`, use 0xe0000000 because
this is what is advertised in ACPI and there are traces
of resources below 0xfe000000 that are unknown to core-
boot's C code (PCH_PRESERVED_BASE?).
Tested on QEMU/Q35 and Siemens/Chili w/ and w/o top-
down allocation. Fixes EHCI w/ top-down in QEMU.
Change-Id: Iae0d888eebd0ec11a9d6f12975ae24dc32a80d8c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75102
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on the power sequence of the panel [1] and PMIC datasheet [2],
the power on T2 sequence VSP to VSN should be large than 1ms, but it's
-159us now, and the power off T2 sequence VSP to VSN should be large
than 0ms, but it's less than 0 now. Let's modify the power sequence
to meet the datasheet requirement.
[1] HX83102-J02_Datasheet_v03.pdf
[2] TPS65132-Single-Inductor-Dual-Output-Power-Supply.pdf
BUG=b:282902297
TEST=power sequence T2 pass
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: Ib1625c6a211f849071393f69eaf5c649a8e7f72e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75298
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The TPS65132S is designed to supply positive/negative driven
application. It communicates through standard I2C compatible interface,
and it intergrates a EEPROM whose contents will be loaded into the
register at startup. Since TPS65132S is used in staryu and geralt
projects, we move the implementation to mediatek/common.
The datasheet: TPS65132-Single-Inductor-Dual-Output-Power-Supply.pdf
BUG=b:282902297
TEST=boot starmie to firmware screen
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Change-Id: Iad2c9bdea5824455efcef18b44876111061cfa1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75488
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Don't assume only one IO and one MEM domain resource.
Currently the code is awkward for bridge devices where loops over
resources are done twice. This would be avoided on top of other patches
that improve the allocator (topic:allocator) by adding a top-down mode.
However those patches break the tree and having the option to have
multiple resources per type would make it easier to get those patches in
without breaking the tree.
Change-Id: I3d3a60c9a4438accdb06444e2b50cc9b0b2eb009
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67018
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
This patch refers and backport some of previous work from Linux Kernel
(https://lore.kernel.org/all/1561689337-19390-3-git-send-email-ricardo.
neri-calderon@linux.intel.com/T/#u) that optimizes the MTRR register
programming in multi-processor systems by relying on the CPUID
(self-snoop feature supported).
Refer to the details below:
Programming MTRR registers in multi-processor systems is a rather
lengthy process as it involves flushing caches. As a result, the
process may take a considerable amount of time. Furthermore, all
processors must program these registers serially.
`wbinvd` instruction is used to invalidate the cache line to ensure
that all modified data is written back to memory. All logical processors
are stopped from executing until after the write-back and invalidate
operation is completed.
The amount of time or cycles for WBINVD to complete will vary due to the
size of different cache hierarchies and other factors. As a consequence,
the use of the WBINVD instruction can have an impact on response time.
As per measurements, around 98% of the time needed by the procedure to
program MTRRs in multi-processor systems is spent flushing caches with
wbinvd(). As per the Section 11.11.8 of the Intel 64 and IA 32
Architectures Software Developer's Manual, it is not necessary to flush
caches if the CPU supports cache self-snooping (ss).
"Flush all caches using the WBINVD instructions. Note on a processor
that supports self-snooping, CPUID feature flag bit 27, this step is
unnecessary."
Thus, skipping the cache flushes can reduce by several tens of
milliseconds the time needed to complete the programming of the MTRR
registers:
Platform Before After
12-core (14 Threads) MeteorLake 35ms 1ms
BUG=b:260455826
TEST=Able to build and boot google/rex.
Change-Id: I83cac2b1e1707bbb1bc1bba82cf3073984e9768f
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75511
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
This patch removes the wbinvd call preceding CR0.CD setting in
disable_cache() to improve the boot time performances. According to
some experimental measurements, the wbinvd execution takes between 1.6
up and 6 milliseconds to complete so it is preferable to call it only
when necessary.
According to Intel Software Developer Manual Vol 3.A - 12.5.3
Preventing Caching section there is no need to flush and invalidate
the cache before settings CR0.CD. The documented sequence consists in
setting CR0.CD and then call wbinvd.
We also could not find any extra requirements in the AMD64
Architecture Programmer’s Manual - Volume 2 - Memory System chapter.
This extra wbinvd in coreboot disable_cache() function does not seem
documented and looking into the history of the project got us all the
way back to original commit 8ca8d7665d ("- Initial checkin of the
freebios2 tree") from April 2003.
Even the original disable_cache() implementation (see below) is a bit
curious as the comment list two actions:
1. Disable cache cover by line 74, 75 and 77
2. Write back the cache and flush TLB - Line 78
But it does not provide any explanation for the wbinvd call line 76.
68 static inline void disable_cache(void)
69 {
70 unsigned int tmp;
71 /* Disable cache */
72 /* Write back the cache and flush TLB */
73 asm volatile (
74 "movl %%cr0, %0\n\t"
75 "orl $0x40000000, %0\n\t"
76 "wbinvd\n\t"
77 "movl %0, %%cr0\n\t"
78 "wbinvd\n\t"
79 :"=r" (tmp)
80 ::"memory");
81 }
BUG=b/260455826
TEST=Successful boot on Skolas and Rex board
Change-Id: I08c6486dc93c4d70cadc22a760d1b7e536e85bfa
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Himanshu Sahdev <himanshu.sahdev@intel.com>
Enable drivers for SoundWire codecs and define the topology in
the devicetree for the rex0 variant with the SoundWire daughter
board connected.
+------------------+ +--------------------+
| | | Headphone Codec |
| Intel Meteor Lake| +--->|Cirrus Logic CS42L42|
| SoundWire | | | ID 0 |
| Controller | | +--------------------+
| | |
| Link 0 +----+ +-------------------+
| | | Left Speaker Amp |
| Link 1 | +--->| Maxim MAX98363 |
| | | | ID 0 |
| Link 2 +----| +-------------------+
| | |
| Link 3 | | +-------------------+
| | | | Right Speaker Amp |
+------------------+ +--->| Maxim MAX98363 |
| ID 1 |
+-------------------+
This was tested by booting the firmware and dumping the SSDT table
to ensure that all SoundWire ACPI devices are created as expected with
the properties that are defined in coreboot under \_SB.PCI0:
HDAS - Intel Meteor Lake HDA PCI device
HDAS.SNDW - Intel Meteor Lake SoundWire Controller
HDAS.SNDW.SW00 - Cirrus Logic CS42L42 - Headphone Codec
HDAS.SNDW.SW20 - Maxim MAX98363 - Left Speaker Amp
HDAS.SNDW.SW21 - Maxim MAX98363 - Right Speaker Amp
BUG=b:269497731
TEST=Verified SSDT for SNDW in the OS. Playback and recording are also
validated on google/rex.
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I3e11dc642ff686ba7da23ed76332f7f10e60fade
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73280
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The FBVDD_PWR_EN signal should be inverted in its control level
on Agah v.s. Hades. The original change covered the Hades
implementation, but needs to be updated to invert for Agah. This
change can be removed once we drop support for Agah.
BUG=b:280467267
TEST=built for Hades and Agah
Change-Id: I7f90c03b8d9b859004e5c124bf0a1f7b59921c3d
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75530
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Add ACPI DmaProperty for WLAN device. `is_untrusted` is eventually
ended up by adding DMA property _DSD which is similar to what
`add_acpi_dma_property` does for WWAN drivers, hence it makes sense to
have a unified name across different device drivers.
BUG=b:279676191
BRANCH=firmware-nissa-15217.B
TEST=emerge-nissa coreboot chromeos-bootimage
Change-Id: I6d898a939aa0be31a671d2436a81c34f7a1ec030
Signed-off-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75460
Reviewed-by: Shou-Chieh Hsu <shouchieh@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Derek Huang <derekhuang@google.com>
Add 'common_config.acp_config' to the device tree, so we have the
correct pin configuration.
BUG=b:225320579
TEST=USE=fwconsole emerge-skyrim ... ; verify 'devbeep' works in
depthcharge console
TEST=Boot into ChromeOS, verify YouTube sound works with internal
speakers and headphone jack
TEST=Boot into ChromeOS, verify microphone with Google Meet
Change-Id: Ie2d79408104273d8a53214b683800fa0663c14d3
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74962
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Improve boot time performances by replacing the wbinvd instruction
with multiple clflush to ensure that the SIPI data is written back to
RAM.
According to some experimental measurements, the wbinvd execution
takes between 1.6 up and 6 milliseconds to complete. In the case of
the SIPI data, wbinvd unnecessarily flushes and invalidates the entire
cache. Indeed, the SIPI module is quite small (about 400 bytes) and
cflush'ing the associated cache lines is almost instantaneous,
typically less than 100 microseconds.
BUG=b/260455826
TEST=Successful boot on Skolas and Rex board
Change-Id: I0e00db8eaa6a3cb41bec3422572c8f2a9bec4057
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Suggested-by: Erin Park <erin.park@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75391
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
With the coreboot build process, `UniversalPayloadBuild.sh` calls
`UniversalPayloadBuild.py`. That Python script will unconditionally
build DXE as 64-bit, but accepts an argument for the entry point:
parser.add_argument('-a', '--Arch', choices=['IA32', 'X64'],
help='Specify the ARCH for payload entry module. Default build X64
image.', default ='X64')
Currently, ` -a IA32 -a X64` is passed, and the Python script will
use the `X64` argument, resulting in a payload that won't work with
coreboot.
Remove the `-a X64`, so the resulting build is a 32-bit entry point,
and 64-bit DXE, which works with coreboot.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I8a557d6e155a2938b44036d98f9274cc8b38f156
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73668
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
This function can be called to more easily add a file to CBFS.
Additional file attributes can be added later:
cbfs-files-y += pagetables
pagetables-file := $(objcbfs)/pt
pagetables-type := raw
pagetables-compression := none
pagetables-COREBOOT-position := $(CONFIG_ARCH_X86_64_PGTBL_LOC)
becomes
$(call add-cbfs-file-simple, pagetables, $(objcbfs)/pt, raw, none )
pagetables-COREBOOT-position := $(CONFIG_ARCH_X86_64_PGTBL_LOC)
This is especially useful inside macros where you may want to add
an unknown number of entries.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I72bb2f21fb22f650b7970c7a37a48c10a4af0ed5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The acpigen_resource_[bus_number,io,mmio*] functions didn't make it very
clear that they are generating resource producer ranges and not resource
consumer ranges. To clarify this, change the function names to
acpigen_resource_producer_[bus_number,io,mmio*] and explicitly add the
ADDR_SPACE_GENERAL_FLAG_PRODUCER flag which evaluates to 0, so this
doesn't change the functionality.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I334f38aa8ab418d5577f92b980ff750504e2bb4e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75486
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
The IBM SBP1 is an evaluation platform.
It's utilising:
- 4 SPR sockets, having 16 DIMMs each
- 240C/480T at maximum
- 32x CPU PCIe slots
- 2x M.2 PCH PCIe slots
- Dual 200Gbit/s NIC
- SPI TPM
It has an AST2600 BMC for remote management.
It doesn't have:
- External facing USB ports
- Video outputs
- Audio codec
Test:
The board boots to Linux 5.15 with all 480 cores available.
All PCIe devices are working and no errors in ACPI.
All 64 memory DIMMS are working and M.2 devices can be used.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: Ie21c744224e8d9e5232d63b8366d2981c9575d70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73392
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit enables the build for IO Margining, ensuring that ASPM is
disabled and certain FSP knobs are adjusted in coreboot as below
1. Enable DFXEnable
2. Disable PcieGlobalAspm
3. Disable KtiLinkL1En & KtiLinkL0pEn
Since the FSP UPD does not provide all the necessary knobs for IO
Margining, the following settings need to be applied during the FSP
build process:
1. Enable PcdBiosDfxKnobEnabled
2. Disable PchDmiAspm
3. Enable SataTestMode
4. Enable WmphyMargining
5. Disable IioErrorEn
TEST=Build for IBM sbp1 board.
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: Ie306d12943adb76411d55358548b5cb2eb3a95be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75415
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds support for Intel 800 series chipset. The new chipset
can be uniquely identified by its SPI speed, eSPI speed, and
chipset name.
This commit message is clear and concise, and it accurately describes
the changes that were made to the code. It also includes the following
information:
- Specify the correct chipset name.
"PCH Revision: 800 series Meteor Lake"
- Show the valid eSPI/EC frequency.
"Read eSPI/EC Bus Frequency: 20MHz"
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I70619d9e3ed2bcad86f84a0527e3a0ad13acd706
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch adds two new chromeos_*.fmd files for release and debug FSP
builds targeting rex_ec_ish.
`rex_ec_ish` variant would pack ISH firmware into the CSE boot partition
hence, the blob size is expected to increase. Creates separate flash map
layout to ensure ISH work is not impacting on the regular `rex0` project
SPI flash usage.
BUG=b:284254353
TEST=Able to build google/rex_ish_ec board and boot on target hardware.
Change-Id: Ife4663d3ccf80a928646eadaac4c9ab49ad29055
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75471
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: YH Lin <yueherngl@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch creates a new variant to support the ISH enablement using
Rex platform.The idea here is to leverage the `rex0` code as much as
possible and add specific support for ISH enablement as per the hardware
schematic differences.
BUG=b:284254353
TEST=Able to build google/rex_ish_ec board and boot on target hardware.
Change-Id: I625fd0b31aed998f4e8f2d139827bc212ee8a90b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75470
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: YH Lin <yueherngl@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
EFS header is mapped during PSP verstage and bootblock to read some SPI
configuration. After use it is left unmapped. Unmap the EFS region after
use.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I865f45a3d25bc639eb8435b54aa80895ec4afd27
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75455
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfs_unmap does not unmap the mapped region from the boot device. This
leads to some resource leaks eg. TLB slots in PSP. Explicitly call
rdev_munmap on the address mapped by cbfs_map.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I51b9d066a40103f2ebdf2ef2fc3da13beb467921
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
cbfs_unmap does not unmap the mapped region from the boot device. This
leads to some resource leaks eg. TLB slots in PSP. Explicitly call
rdev_munmap on the address mapped by cbfs_map.
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: If1d355972cc743b8d8c451e1b3f827abd15e98fe
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
On FMAP without RW slots, PSP verstage fails to build because of
reference to FMAP_SECTION_FW_MAIN_A_*. Instead extract the offset and
size of relevant sections using fmap_locate_area().
BUG=b:240664755
TEST=Build and boot to OS in Skyrim with unsigned PSP verstage.
Change-Id: I29997534c6843b47a36655431f79e5c70bd17f9b
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
