This patch removes comments that are not applicable when aligned to
fw_config.c
Platform Mapping Document : Rev0p86
BUG=b:394208231
TEST=Build Ocelot and verify it compiles without any error.
Change-Id: Id258b4e89c522ec438a74a9a149388bcfde125d1
Signed-off-by: Sowmya Aralguppe <sowmya.aralguppe@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88462
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Remove Bluetooth Audio offload to align to fw_config.c
Platform Mapping Document : Rev0p86
BUG=b:394208231
TEST=Build Ocelot and verify it compiles without any error.
Change-Id: I30edbc0a5622e8893469384b853cad323c6ac544
Signed-off-by: Sowmya Aralguppe <sowmya.aralguppe@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88460
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Modify variant configuration to support THC-based touchscreen and
touchpad configurations.
Platform Mapping Document : Rev0p86
BUG=b:394208231
TEST=Build Ocelot and verify it compiles without any error.
Change-Id: I7af8195f76312aa362a6be504b3fec7a81acec06
Signed-off-by: Sowmya Aralguppe <sowmya.aralguppe@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88418
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Pranava Y N <pranavayn@google.com>
Introduce cbfs_preload_wait_for_all() to guarantee that all CBFS preload
contexts complete their tasks before moving forward. This function goes
through each preload context and waits for the corresponding thread to
finish by using thread_join(). If any preload thread runs into an issue,
it records an error message along with the context name.
This addition provides a synchronization point during the boot process
which platform code can leverage, typically when the storage backend
supporting asynchronous file transfer is about to be deactivated.
Change-Id: I3ee27ef2fbfdc19bd75532713966f333ad975861
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88457
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the example, after the short multi-line comment alternative was
added several years ago, when the Wiki was still used.
Change-Id: I401180a9ac7c7cdc45fb8e9ba364823092cea6da
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88492
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
The current style is not part of the coding style [1]. The comment has
five lines, so it’s unclear if the short or long multi-line comment
style should be used. Use the short one, to keep it concise.
[1]: Documentation/contributing/coding_style.md
Change-Id: I500340fd02a54c69db4ca5d753fcb690fae1c520
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88491
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change level from low to high to fix goodix touchscreen issue.
BUG=b:430156965
BRANCH=none
TEST= Build and boot to OS to test touch function work fine.
Change-Id: I9bd16b2a9ebb5699ad4bf04b018aefc6b86b4199
Signed-off-by: Luca Lai <luca.lai@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88432
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Refactor memory layout on x1p42100 to reuse a single reserved region
for all QC image metadata passed from coreboot to QcLib for TME
authentication. Also, reposition the PRERAM_CBMEM_CONSOLE reservation
after the QcLib region to allow for future expansion.
TEST=Successfully booted google/bluey.
Change-Id: I6eea99241c233935c5d99d48093c42bb1424143f
Signed-off-by: Sasirekaa Madhesu <smadhesu@qualcomm.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88485
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The DPTF parameters were defined by the thermal team.
Based on thermal table in 432114256 comment#1
BUG=b:432114256
TEST=emerge-nissa coreboot chromeos-bootimage
Signed-off-by: lizheng <lizheng@huaqin.corp-partner.google.com>
Change-Id: I969f93f384bb2a59f1300478794f48e30997736d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88463
Reviewed-by: Kun Liu <liukun11@huaqin.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Commit 060df17f1d ("soc/intel/alderlake/acpi: Add Kconfig options for SCM and FCM")
set the default to Firmware Connection Manager, as linux commit
c6da62a219d028de10f2e22e93a34c7ee2b88d03 did not work correctly with
Software Connection Manager.
This issue was fixed with linux commit
719e1f561afbe020ed175825a9bd25ed62ed1697, so now that Software
Connection Manager works, default to it for normal builds as well as
ChromeOS ones.
Change-Id: I4393fc4992d602b7214929592f542270002d84ec
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Add support to enable PCIE NOC, Controller and PHY clocks.
The register details are part of HRD-X1P42100-S1 document.
https://docs.qualcomm.com/bundle/resource/topics/HRD-X1P42100-S1/
TEST=Create an image.serial.bin, ensure it boots on X1P42100 and
check clock status
Change-Id: I6007a8315343a2d56d51c8472ace831a10146768
Signed-off-by: Hari L <haril@qualcomm.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
After reboot, the system does not need to serve pending IRQ from
systimer. Therefore, clear systimer IRQ pending bits in init_timer().
For that to work, the systimer compensation version 2.5 needs to be
enabled. Otherwise, inaccurate timestamps may occur after BL31, for
example in depthcharge. As the solution has already been implemented
in time_prepare_v2, mt8189 can adopt this version to fix the issue.
Also remove unnecessary headers in timer.c.
BUG=b:430211678
BRANCH=none
TEST=check the depthcharge timstamp in `cbmem` is correct.
554:finished TPM enable update 399,533 (12,059)
90:starting to load payload 399,541 (8)
15:starting LZMA decompress (ignore for x86) 410,775 (11,234)
16:finished LZMA decompress (ignore for x86) 465,472 (54,697)
99:selfboot jump 487,643 (22,171)
15:starting LZMA decompress (ignore for x86) 490,591 (2,948)
16:finished LZMA decompress (ignore for x86) 502,153 (11,562)
15:starting LZMA decompress (ignore for x86) 502,210 (57)
16:finished LZMA decompress (ignore for x86) 504,510 (2,300)
1000:depthcharge start 534,769 (30,259)
1002:RO vboot init 534,813 (44)
1020:vboot select&load kernel 534,815 (2)
1030:finished EC verification 554,600 (19,785)
1060:finished AuxFW Sync 560,740 (6,140)
1040:finished storage device initialization 612,960 (52,220)
1050:finished reading kernel from disk 639,711 (26,751)
1100:finished vboot kernel verification 710,596 (70,885)
1102:starting kernel decompression/relocation 731,729 (21,133)
1101:jumping to kernel 945,034 (213,305)
Signed-off-by: Vince Liu <vince-wl.liu@mediatek.corp-partner.google.com>
Signed-off-by: Zhanzhan Ge <zhanzhan.ge@mediatek.corp-partner.google.com>
Change-Id: Ic79003b5a5b747a3761fd4612cad6a96ada216b6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88468
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
To promote code reuse and maintainability, move mt8196/timer_prepare.c
to timer_prepare_v2.c. The original timer_prepare.c is renamed to
timer_prepare_v1.c. Also use `mtk_systimer->cntcr` instead of
`SYSTIMER_BASE` for consistency.
BUG=b:379008996
BRANCH=none
TEST=build passed.
Signed-off-by: Vince Liu <vince-wl.liu@mediatek.corp-partner.google.com>
Change-Id: Iab617e7a8bfedb81bcf673edd94d24870df7f751
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88467
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
A recent datasheet review finds that the previously used offset for
the `cnttval` register is incorrect. Since the relevant bits used by
`clear_timer()` have default values of 0, the functionality is not
affected before this fix.
BUG=b:430211678
BRANCH=rauru
TEST=check the timestamp order of depthcharge is correct in `cbmem`
16:finished LZMA decompress (ignore for x86) 895,082 (526)
1000:depthcharge start 941,621 (46,539)
1002:RO vboot init 942,644 (1,023)
1020:vboot select&load kernel 942,645 (1)
1030:finished EC verification 980,005 (37,360)
1060:finished AuxFW Sync 997,302 (17,297)
1040:finished storage device initialization 1,025,910 (28,608)
1050:finished reading kernel from disk 2,174,931 (1,149,021)
1100:finished vboot kernel verification 2,229,874 (54,943)
1102:starting kernel decompression/relocation 2,249,121 (19,247)
1101:jumping to kernel 2,284,317 (35,196)
Total Time: 2,020,762
Change-Id: I018d81de79d6896a31972f925d5a26f41cf942a0
Signed-off-by: Vince Liu <vince-wl.liu@mediatek.corp-partner.google.com>
Signed-off-by: Zhanzhan Ge <zhanzhan.ge@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88480
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently overlaps with bootblock are not detected by our linker script.
So increasing the PSP_SHAREDMEM_BASE + size to an extent that would
overlap with bootblock would be just ignored.
Add another region for the sole purpose of detecting these overlaps.
This may not be the ideal solution, but should sufficient for now.
Also check that the actual loadable segment of bootblock does not use up
more space then that.
Tested: Check that GCC and Clang can still compile it and that the
loadable segment (and therefore what PSP loads into memory) does not
change.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I0f82f9b8655908676dc2d6545e72cb40fe9110e1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86862
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Support variant specific power limits
BUG=b:399236160
TEST=emerge-nissa coreboot and check correct value on dirks.
Change-Id: If09a8f4d157c6fd01aabae1e455e289d3908b39b
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88245
Reviewed-by: Derek Huang <derekhuang@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently .bss and .data are within the PT_LOAD area of the
bootblock.elf and thus are placed and initialized at the correct spot
when PSP loads the BIOS Reset Image into DRAM.
On S3 resume PSP verifies that the "BIOS Reset Image" is unmodified
before it hands over control to such. Due to the use of BSS and DATA
within the BIOS Reset Image and the modifications of such at previous
boot the verification always fails.
This change moves '.bss' and '.data' out of the *first* PT_LOAD area
and moves it into a separate data_segment also marked PT_LOAD. Since
the second PT_LOAD is ignored by AMDCOMPRESS it doesn't end in the area
being verified at S3 resume. Since '.data' is now part of a separate
PT_LOAD a new region is inserted called '.datacopy' which is filled
by using objcopy. In turn the assembly code in bootblock will memcpy
'.datacopy' to '.data'.
TEST: Can still boot on amd/birman+ and on up/squared.
Change-Id: Id159ade3029060ce2ca6abcb723d5bdfe8841c3a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
This patch unifies all the fatcat variants based on
`BOARD_GOOGLE_MODEL_FATCAT` to use the same mainboard part number
`Fatcat`.
BUG=b:430205874
TEST=Able to build/boot fatcat
Change-Id: I13a45e4763abaa9dfe26c53b4e5051d50640291d
Signed-off-by: Pranava Y N <pranavayn@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88353
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This is fairly intuitive upon thinking about it, SeaBIOS has neither
long mode nor PAE page tables, but make it obvious to developers,
and let users know this.
Change-Id: I769c1bdb9d7ea78d56455d125adf3d9bf07a1211
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88453
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Details:
- First set files to compile google/ocelot mainboard w.r.t. WCL FSP
3266_02.
- Change file path for the FSP_HEADER_PATH for WildacatLake.
BUG=b:431683053
TEST=Build Ocelot without any errors.
Change-Id: Iec31b0055bc145d795adef6723511ac07f83406b
Signed-off-by: alokagar <alok.agarwal@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88433
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Bochs display driver uses port I/O functions to initialize the VGA
device, so it could only have been built on x86 architectures so far,
but its supported devices can be used just fine on others on the QEMU
side as long as the emulated platform supports PCI. A previous commit
adds port I/O functions for more including ARM* and RISC-V, which should
enable this driver to be successfully built and used on these as well.
Allow the Bochs display driver to be built for non-x86 QEMU boards by
changing the Kconfig dependencies. Make VGA text framebuffer support
depend on x86, because it isn't usable at the standard 0xB8000 address
on other architectures. Add a dependency on PCI since this is a PCI
device and vexpress-a9 (qemu-armv7) doesn't have the (emulated) hardware
for PCI.
Change-Id: I7f72d7ea13e54ecf89d067394c02b572c5f92d24
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80376
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Sometimes during build you could get this error:
mkdir: cannot create directory 'build': File exists
make[1]: *** [Makefile:48: build] Error 1
make: *** [payloads/external/Makefile.mk:408: payloads/external/LinuxBoot/build/initramfs] Erro
make: *** Waiting for unfinished jobs....
Test 6.3
WWW https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/linux-6.3.tar.xz
Usually this should not happen, because the 'build' target is an
order-only prerequisite, but I assume its still happening, because the
makefile is called twice during a Linuxboot build. Once for the Linux
kernel and once again for the initramfs.
A quick and dirty fix is to add a '-p' to the mkdir command.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I5663d1cb592bec6a8576347dd22223b382cd617f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87821
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
the build directory prerequisite was missing. As far as I know, it
didn't cause any issues, but it should still be there for correctness.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ieba578871af2fe886def059ab1568b85cd641e6e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87820
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
To avoid confusion and make it more obvious that the 'build' target
creates the build directory, append a slash at the end.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I49b4fef859f642cc03c0223cb1773597718e56cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87819
Reviewed-by: Matt DeVillier <matt.devillier@gmail.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>
When running `make what-jenkins-does`, the intel-sec-tools and gowsid
submodules are left with some new files, marking them as dirty.
This changes fixes that.
Change-Id: Ice98c1a61201cbf63580835966b78f053d7853a2
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87380
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a heading for Skylake/Kabylake Lenovo mainboards in anticipation
of additional boards being added in the future. Add a new page for the
T480/T480s, loosely based on the page for the T440p.
Thanks to Askareth on Matrix for the initial draft and copious testing.
Change-Id: I3c7a9ca28be5524b42177b92387f35c6d25b48da
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88439
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These machine have BootGuard fused and requires deguard to
boot coreboot.
Known issues:
- Alpine Ridge Thunderbolt 3 controller does not work
- Some Fn+F{1-12} keys aren't handled correctly
- Nvidia dGPU is finicky
- Needs option ROM
- Power enable code is buggy
- Nouveau only works on linux 6.8-6.9
- Headphone jack isn't detected as plugged in despite correct verbs
Thanks to Leah Rowe for helping with the T480s.
Change-Id: I19d421412c771c1f242f6ff39453f824fa866163
Signed-off-by: Mate Kukri <km@mkukri.xyz>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83274
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Add support for the MEC1653 EC as used by the Thinkpad T480/480s.
Change-Id: If82a7d27eb3163f51565c0c6e60cab60753611a7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Reviewed-by: Máté Kukri <km@mkukri.xyz>
MonotonicCount is required, or UEFITool fails to parse the store.
TimeStamp is required for variables with authenticated attributes.
Change-Id: Iea933c9943ec18ea773700cdf1e3bede0e8ef292
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88424
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This helps with initialising UEFI secure boot variables for the first
boot, for example, by setting PKDefault, KEKDefault, dbDefault and
dbxDefault to the desired certificates.
Tested, and the get subcommand returns the same data that the set
command added. However, EDK2's variable driver (from approximately
edk2-stable202505) asserts that the variable store isn't the expected
size, and UEFITool can't decode it correctly. This is also the case for
other types supported before this patch, suggesting that the bug is in
general variable-handling code in this utility. Will be debugged and
addressed in a follow-up.
Change-Id: If36394bb56388a35882702c93e26e63124fe0a63
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88377
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the header size is equal to fv.length, then `fv_parse()` will go
out-of-bounds when obtaining the variable store data, and obviously,
there is no data if the header takes up all available space.
Change-Id: I0ac46e098a14b51f936cb99f5e6bf83411570bc5
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
We want to distinguish between a variable store that's marked as capable
of storing authenticated variables (basically, checking their signatures
and promising that there's no TOCTOU possible), and a variable with the
authentication-checking enabled.
Change-Id: Ibf6ffbe279961ff54b0988d98a912a8421598e3b
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88423
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of providing an EC_SIG binary blob, generate it at build time
using the mec152x tool. Allows to move the EC_BODY in the fmap without
the need to generate a new EC_SIG.
TEST=Booted on amd/birman_plus without EC_SIG blob.
Change-Id: I2d7a791820d905b088194b290853509f10689fc6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87429
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ec_usb_pd_fw is a board specific utility to generate pointers to
firmware images found in the SPI flash. On some AMD boards the
x86 SPI flash is shared with the EC. The EC can also update the
USB Power Delivery controllers firmware, but it needs to know where
to load the firmware from. It uses pointers stored in the first
128 bytes of the x86 SPI flash.
Add a small utility to generate pointers to the USB PD firmware,
located somewhere in the ROM identified by the FMAP region.
There can be up to 12 USB PD firmwares, depending on the used
vendor or model.
Change-Id: I98717e849592f83eb7bacbfed33a8d4b811a5e18
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87430
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Microchip EC can share the SPI flash with the x86 host. Since
it boots first and does power sequencing, there's no problem with
concurrent access happening. Due to various vendor specific flash
layouts used on x86, the EC needs a pointer to it's own firmware.
The pointer resides at flash offset 0 and is read by MEC152x and
MEC1701 and MEC172x ECs, probably others as well.
The introduced tool generates the EC FW PTR at flash offset 0.
Allows to get rid of hand-crafted binary files (EC_SIG) being used
on AMD mainboards that hardcode the offset and must manually being
checked if those match the FMAP.
When there'll be additional firmware regions added it becomes
unconvienient to maintain those by hand.
Usage output:
Usage: ./util/mec152x/mec152xtool <rom-file> <command>
-h|--help
-f|--fmap_region_name
Command:
GEN_ECFW_PTR - Writes the ECFW PTR
Based on https://chromium.googlesource.com/chromiumos/platform/ec/+/08f5a1e6fc2c9467230444ac9b582dcf4d9f0068/chip/mchp/util/pack_ec_mec172x.py
Change-Id: I3b74c9f65643ad4437de29d4aed307b1a2b33286
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Add Measured Boot that is specific to Apollolake, and is used
for measuring the IBBL, IBB and TXE. The IBB is measured only if it
exists, and only after it has been loaded into the CSE.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I61ce4a34875d6d3357d4088167cdd887bafdff23
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65272
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Copy the IBB into CAR via the CSEs RBP to ensure it has not been
modified.
Test on the StarLite Mk III and Mk IV:
Without VBOOT:
[DEBUG] CSE: IBB Verification Result: PASS
[DEBUG] CSE: IBB Verification Done : YES
[DEBUG] CSE: IBB Size : 88
With VBOOT:
[DEBUG] CSE: IBB Verification Result: PASS
[DEBUG] CSE: IBB Verification Done : YES
[DEBUG] CSE: IBB Size : 102
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I0d4e26834cef4c876e37e414b424a031c11111ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65577
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a loader that will load the IBB into the CSE via the Ring Protocol
Buffer.
All registers were taken from Intel document number #336561.
Change-Id: Ia41e3909f8099d2ea864166e9ea03e10e40a1b68
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65270
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot's method of creating IFWI is to modify an existing IFWI
images by deleting the IBB, replacing the IBBL with the bootblock
and everything else is put in the OBB.
This poses a problem when using Intel's FIT or technologies such
as Boot Guard. The main problem is that the IBB is never verified by
the CSE or copied from SRAM to CAR, so the CSE cannot complete BUP
and stays in recovery mode. The vast majority of the stages in
Apollolake's Secure Boot flow is not met using this method (Intel
document number 597827 summarizes these steps).
This patch series is based on the principles of a patch from Brenton
Dong (CB:17064) creates an IBBL, IBB and OBB binaries with the
correct functions to complete the Secure Boot flow. This is to copy
the IBB from SRAM using the CSE's Ring Buffer Protocol.
These binaries can then be used by FIT or coreboot's existing
method of hacking IFWI together (IFWI_STITCH) via IFWITOOL. If it is
the latter and Boot Guard is enabled, the hashes for IFWI and "ibb+obb"
must be recreated.
Whilst this option doesn't form a complete image, the components it
builds will work as Intel intended them to once stitched correctly into
an IFWI image.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I0deebf04f22f3017ee0c13bf1ca7f6dcc0d458b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This updates FSP UPDs for PCH PM SLP minimum assertion width and reset
power cycle duration to reduce the delays during a global reset and S5
suspend and resume flow.
Reference:
Panther Lake External Design Specification (EDS) Volume 2 (#813032)
BUG=None
TEST=Build a fatcat coreboot and issue a global reset to check the reset
delay is reduced to 1 second. Issue a lid close to suspend to S5 and
wake up by lid open to check the delay is reduced to 1 second.
Change-Id: If94917879125b1a523de131936047b497cce8ba7
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88444
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This configures FSP UPDs for PCH PM minimum assertion widths and
reset power cycle duration per mainboard variants configuration.
This also checks the reset power cycle duration is not be smaller
than SLP_S3, SLP_S4 and SLP_A Minimum Assertion Width.
PchPmSlpS3MinAssert: SLP_S3 Minimum Assertion Width Policy
PchPmSlpS4MinAssert: SLP_S4 Minimum Assertion Width Policy
PchPmSlpSusMinAssert: SLP_SUS Minimum Assertion Width Policy
PchPmSlpAMinAssert: SLP_A Minimum Assertion Width Policy
PchPmPwrCycDur: PCH PM Reset Power Cycle Duration
The Reset Power Cycle Duration starts at 20ms and increases by 20ms
for each step, beginning from 0x0 to 0xFF. Each subsequent increment
corresponds to an additional 20 milliseconds in duration.
Reference:
Panther Lake External Design Specification (EDS) Volume 2 (#813032)
BUG=None
TEST=Build a fatcat coreboot and boot to OS without an issue.
Change-Id: I7234c7539c1e7eb5e2b8c04ccff6c62c853d6807
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88443
Reviewed-by: Pranava Y N <pranavayn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Due to a flaw in the hardware design, the GL9763e replay timer
frequently times out when ASPM is enabled. As a result, the warning
messages will often appear in the system log when the system accesses
the GL9763e PCI config. Therefore, the replay timer timeout must be
masked.
BUG=b:428025481
Sample output on screen:
PCIe Bus Error: severity=Corrected, type=Data Link Layer
device [17a0:e763] error status/mask=00001000/00002000
[12] Timeout
Change-Id: I6f921f40f169d7811b7bd51145023b549e8aee1c
Signed-off-by: Victor Shih <victorshihgli@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88291
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
