coreboot-gerrit June 2023

coreboot-gerrit@coreboot.org

1 participants
5387 discussions

[L] Change in coreboot[master]: soc/intel/alderlake/hsphy: Add possibility to cache HSPHY in flash
by Michał Żygowski (Code Review) 23 Jun '23

23 Jun '23

Michał Żygowski has submitted this change. ( https://review.coreboot.org/c/coreboot/+/68987?usp=email ) Change subject: soc/intel/alderlake/hsphy: Add possibility to cache HSPHY in flash ...................................................................... soc/intel/alderlake/hsphy: Add possibility to cache HSPHY in flash The patch adds a possibility to cache the PCIe 5.0 HSPHY firmware in the SPI flash. New flashmap region is created for that purpose. The goal of caching is to reduce the dependency on CSME and the HECI IP LOAD command which may fail when the CSME is disabled, e.g. soft disabled by HECI command or HAP disabled. This change allows to keep PCIe 5.0 root ports functioning even if CSME/HECI is not functional. TEST=Boot Ubuntu 22.04 on MSI PRO Z690-A and notice PCIe 5.0 port is functional after loading the HSPHY from cache. Signed-off-by: Michał Żygowski <michal.zygowski(a)3mdeb.com> Change-Id: I5a37f5b06706ff30d92f60f1bf5dc900edbde96f Reviewed-on: https://review.coreboot.org/c/coreboot/+/68987 Reviewed-by: Krystian Hebel <krystian.hebel(a)3mdeb.com> Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> --- M Makefile.inc M src/soc/intel/alderlake/Kconfig M src/soc/intel/alderlake/Makefile.inc M src/soc/intel/alderlake/hsphy.c M util/cbfstool/default-x86.fmd 5 files changed, 309 insertions(+), 38 deletions(-) Approvals: Krystian Hebel: Looks good to me, approved build bot (Jenkins): Verified diff --git a/Makefile.inc b/Makefile.inc index b35ec86..ab57abd 100644 --- a/Makefile.inc +++ b/Makefile.inc @@ -1029,6 +1029,15 @@ FMAP_VPD_ENTRY := endif +ifeq ($(CONFIG_INCLUDE_HSPHY_IN_FMAP),y) +FMAP_HSPHY_FW_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x1000) +FMAP_HSPHY_FW_SIZE := $(CONFIG_HSPHY_FW_MAX_SIZE) +FMAP_HSPHY_FW_ENTRY := HSPHY_FW@$(FMAP_HSPHY_FW_BASE) $(FMAP_HSPHY_FW_SIZE) +FMAP_CURRENT_BASE := $(call int-add, $(FMAP_HSPHY_FW_BASE) $(FMAP_HSPHY_FW_SIZE)) +else +FMAP_HSPHY_FW_ENTRY := +endif + # # X86 FMAP region # @@ -1107,6 +1116,7 @@ -e "s,##SMMSTORE_ENTRY##,$(FMAP_SMMSTORE_ENTRY)," \ -e "s,##SPD_CACHE_ENTRY##,$(FMAP_SPD_CACHE_ENTRY)," \ -e "s,##VPD_ENTRY##,$(FMAP_VPD_ENTRY)," \ + -e "s,##HSPHY_FW_ENTRY##,$(FMAP_HSPHY_FW_ENTRY)," \ -e "s,##CBFS_BASE##,$(FMAP_CBFS_BASE)," \ -e "s,##CBFS_SIZE##,$(FMAP_CBFS_SIZE)," \ $(DEFAULT_FLASHMAP) > $@.tmp diff --git a/src/soc/intel/alderlake/Kconfig b/src/soc/intel/alderlake/Kconfig index 0e5a671..664876a 100644 --- a/src/soc/intel/alderlake/Kconfig +++ b/src/soc/intel/alderlake/Kconfig @@ -527,4 +527,30 @@ later platforms so creation of MBP HOB can be skipped for ADL-N and RPL based platforms. +config INCLUDE_HSPHY_IN_FMAP + bool "Include PCIe 5.0 HSPHY firmware in flash" + default n + help + Set this option to cache the PCIe 5.0 HSPHY firmware after it is + fetched from ME during boot. By default coreboot will fetch the + HSPHY FW from ME, but if for some reason ME is not enabled or + visible, the cached blob will be attempted to initialize the PCIe + 5.0 root port. Select it if ME is soft disabled or disabled with HAP + bit. If possible, the HSPHY FW will be saved to flashmap region if + the firmware file is not provided directly in the HSPHY_FW_FILE + Kconfig. + +config HSPHY_FW_FILE + string "HSPHY firmware file path" + depends on INCLUDE_HSPHY_IN_FMAP + help + Path pointing to the PCIe 5.0 HSPHY file. The file can be extracted + from full firmware image or ME region using UEFITool. If left empty, + HSPHY loading procedure will try to save the firmware to the flashmap + region if fetched successfully from ME. + +config HSPHY_FW_MAX_SIZE + hex + default 0x8000 + endif diff --git a/src/soc/intel/alderlake/Makefile.inc b/src/soc/intel/alderlake/Makefile.inc index dbee074..886d532 100644 --- a/src/soc/intel/alderlake/Makefile.inc +++ b/src/soc/intel/alderlake/Makefile.inc @@ -114,4 +114,28 @@ endif +ifeq ($(CONFIG_INCLUDE_HSPHY_IN_FMAP),y) +ifneq ($(call strip_quotes,$(CONFIG_HSPHY_FW_FILE)),) + +# Create the target HSPHY file that will be put into flashmap region. +# First goes the HSPHY size, then hash algorithm (3 - SHA384, default for now), +# the hash digest, padding to max digest size (SHA512 - 64 bytes) and at last the +# HSPHY firmware itself +$(obj)/hsphy_fw.bin: $(call strip_quotes,$(top)/$(CONFIG_HSPHY_FW_FILE)) + printf " HSPHY $(obj)/hsphy_fw.bin\n" + $(shell wc -c $< | awk '{print $$1}' | tr -d '\n' | xargs -0 printf '%08X' | \ + tac -rs .. | xxd -r -p > $@) + $(shell printf '%02X' 3 | xxd -r -p >> $@) + $(shell sha384sum $< | awk '{print $$1}' | tac -rs .. | xxd -r -p >> $@) + $(shell dd if=/dev/zero bs=1 count=16 2> /dev/null >> $@) + $(shell cat $< >> $@) + +add_hsphy_firmware: $(obj)/hsphy_fw.bin $(obj)/fmap.fmap $(obj)/coreboot.pre $(CBFSTOOL) + $(CBFSTOOL) $(obj)/coreboot.pre write -u -r HSPHY_FW -f $(obj)/hsphy_fw.bin + +$(call add_intermediate, add_hsphy_firmware) + +endif +endif + endif diff --git a/src/soc/intel/alderlake/hsphy.c b/src/soc/intel/alderlake/hsphy.c index dacb643..5333a8b 100644 --- a/src/soc/intel/alderlake/hsphy.c +++ b/src/soc/intel/alderlake/hsphy.c @@ -8,6 +8,7 @@ #include <device/mmio.h> #include <device/pci_def.h> #include <device/pci_ops.h> +#include <fmap.h> #include <intelblocks/cse.h> #include <intelblocks/systemagent.h> #include <intelblocks/vtd.h> @@ -29,6 +30,13 @@ #define CPU_PID_PCIE_PHYX16_BROADCAST 0x55 +struct hsphy_cache { + uint32_t hsphy_size; + uint8_t hash_algo; + uint8_t digest[MAX_HASH_SIZE]; + uint8_t hsphy_fw[0]; +} __packed; + struct ip_push_model { uint16_t count; uint16_t address; @@ -105,7 +113,7 @@ return 0; } -static int verify_hsphy_hash(void *buf, uint32_t buf_size, uint8_t *hash_buf, uint8_t hash_alg) +static bool verify_hsphy_hash(void *buf, uint32_t buf_size, uint8_t *hash_buf, uint8_t hash_alg) { struct vb2_hash hash; @@ -125,14 +133,13 @@ hash.algo = VB2_HASH_SHA384; break; } + memcpy(hash.raw, hash_buf, vb2_digest_size(hash.algo)); - if (vb2_hash_verify(vboot_hwcrypto_allowed(), buf, buf_size, &hash) != VB2_SUCCESS) { - printk(BIOS_ERR, "HSPHY SHA hashes do not match\n"); - return -1; - } + if (vb2_hash_verify(vboot_hwcrypto_allowed(), buf, buf_size, &hash) != VB2_SUCCESS) + return false; - return 0; + return true; } static void upload_hsphy_to_cpu_pcie(void *buf, uint32_t buf_size) @@ -156,31 +163,168 @@ } } -void load_and_init_hsphy(void) +static bool hsphy_cache_valid(struct hsphy_cache *hsphy_fw_cache) { - void *hsphy_buf; - uint8_t hsphy_hash[MAX_HASH_SIZE] = { 0 }; - uint8_t hash_type; - uint32_t buf_size = HSPHY_PAYLOAD_SIZE; - size_t dma_buf_size; - pci_devfn_t dev = PCH_DEV_CSE; - const uint16_t pci_cmd_bme_mem = PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY; - uint32_t status; + if (!hsphy_fw_cache) { + printk(BIOS_WARNING, "Failed to mmap HSPHY cache\n"); + return false; + } - if (!is_devfn_enabled(SA_DEVFN_CPU_PCIE1_0) && - !is_devfn_enabled(SA_DEVFN_CPU_PCIE1_1)) { - printk(BIOS_DEBUG, "All HSPHY ports disabled, skipping HSPHY loading\n"); + if (hsphy_fw_cache->hsphy_size == 0 || + hsphy_fw_cache->hsphy_size > HSPHY_PAYLOAD_SIZE || + hsphy_fw_cache->hash_algo <= HASHALG_SHA1 || + hsphy_fw_cache->hash_algo > HASHALG_SHA512) + return false; + + if (!verify_hsphy_hash(hsphy_fw_cache->hsphy_fw, hsphy_fw_cache->hsphy_size, + hsphy_fw_cache->digest, hsphy_fw_cache->hash_algo)) + return false; + + return true; +} + +static bool load_hsphy_from_cache(void) +{ + struct region_device rdev; + struct hsphy_cache *hsphy_fw_cache; + + if (fmap_locate_area_as_rdev("HSPHY_FW", &rdev) < 0) { + printk(BIOS_ERR, "HSPHY: Cannot find HSPHY_FW region\n"); + return false; + } + + hsphy_fw_cache = (struct hsphy_cache *)rdev_mmap_full(&rdev); + + if (!hsphy_cache_valid(hsphy_fw_cache)) { + printk(BIOS_ERR, "HSPHY: HSPHY cache invalid\n"); + if (hsphy_fw_cache) + rdev_munmap(&rdev, hsphy_fw_cache); + return false; + } + + printk(BIOS_INFO, "Loading HSPHY FW from cache\n"); + upload_hsphy_to_cpu_pcie(hsphy_fw_cache->hsphy_fw, hsphy_fw_cache->hsphy_size); + + rdev_munmap(&rdev, hsphy_fw_cache); + + return true; +} + +static void cache_hsphy_fw_in_flash(void *buf, uint32_t buf_size, uint8_t *hash_buf, + uint8_t hash_alg) +{ + struct region_device rdev; + struct hsphy_cache *hsphy_fw_cache; + size_t ret; + + if (!buf || buf_size == 0 || buf_size > (HSPHY_PAYLOAD_SIZE - sizeof(*hsphy_fw_cache)) + || !hash_buf || hash_alg <= HASHALG_SHA1 || hash_alg > HASHALG_SHA512) { + printk(BIOS_ERR, "Invalid parameters, HSPHY will not be cached in flash.\n"); return; } + /* Locate the area as RO rdev, otherwise mmap will fail */ + if (fmap_locate_area_as_rdev("HSPHY_FW", &rdev) < 0) { + printk(BIOS_ERR, "HSPHY: Could not find HSPHY_FW region\n"); + printk(BIOS_ERR, "HSPHY will not be cached in flash\n"); + return; + } + + hsphy_fw_cache = (struct hsphy_cache *)rdev_mmap_full(&rdev); + + if (hsphy_cache_valid(hsphy_fw_cache)) { + /* If the cache is valid, check the buffer against the cache hash */ + if (verify_hsphy_hash(buf, buf_size, hsphy_fw_cache->digest, + hsphy_fw_cache->hash_algo)) { + printk(BIOS_INFO, "HSPHY: cache does not need update\n"); + rdev_munmap(&rdev, hsphy_fw_cache); + return; + } else { + printk(BIOS_INFO, "HSPHY: cache needs update\n"); + } + } else { + printk(BIOS_INFO, "HSPHY: cache invalid, updating\n"); + } + + if (region_device_sz(&rdev) < (buf_size + sizeof(*hsphy_fw_cache))) { + printk(BIOS_ERR, "HSPHY: HSPHY_FW region too small: %zx < %zx\n", + region_device_sz(&rdev), buf_size + sizeof(*hsphy_fw_cache)); + printk(BIOS_ERR, "HSPHY will not be cached in flash\n"); + rdev_munmap(&rdev, hsphy_fw_cache); + return; + } + + rdev_munmap(&rdev, hsphy_fw_cache); + hsphy_fw_cache = malloc(sizeof(*hsphy_fw_cache)); + + if (!hsphy_fw_cache) { + printk(BIOS_ERR, "HSPHY: Could not allocate memory for HSPHY cache buffer\n"); + printk(BIOS_ERR, "HSPHY will not be cached in flash\n"); + return; + } + + hsphy_fw_cache->hsphy_size = buf_size; + hsphy_fw_cache->hash_algo = hash_alg; + + switch (hash_alg) { + case HASHALG_SHA256: + hash_alg = VB2_HASH_SHA256; + break; + case HASHALG_SHA384: + hash_alg = VB2_HASH_SHA384; + break; + case HASHALG_SHA512: + hash_alg = VB2_HASH_SHA512; + break; + } + + memset(hsphy_fw_cache->digest, 0, sizeof(hsphy_fw_cache->digest)); + memcpy(hsphy_fw_cache->digest, hash_buf, vb2_digest_size(hash_alg)); + + /* Now that we want to write to flash, locate the area as RW rdev */ + if (fmap_locate_area_as_rdev_rw("HSPHY_FW", &rdev) < 0) { + printk(BIOS_ERR, "HSPHY: Could not find HSPHY_FW region\n"); + printk(BIOS_ERR, "HSPHY will not be cached in flash\n"); + free(hsphy_fw_cache); + return; + } + + if (rdev_eraseat(&rdev, 0, region_device_sz(&rdev)) < 0) { + printk(BIOS_ERR, "Failed to erase HSPHY cache region\n"); + free(hsphy_fw_cache); + return; + } + + ret = rdev_writeat(&rdev, hsphy_fw_cache, 0, sizeof(*hsphy_fw_cache)); + if (ret != sizeof(*hsphy_fw_cache)) { + printk(BIOS_ERR, "Failed to write HSPHY cache metadata\n"); + free(hsphy_fw_cache); + return; + } + + ret = rdev_writeat(&rdev, buf, sizeof(*hsphy_fw_cache), buf_size); + if (ret != buf_size) { + printk(BIOS_ERR, "Failed to write HSPHY FW to cache\n"); + free(hsphy_fw_cache); + return; + } + + printk(BIOS_INFO, "HSPHY cached to flash successfully\n"); + + free(hsphy_fw_cache); +} + +static void *allocate_hsphy_buf(void) +{ + void *hsphy_buf; + size_t dma_buf_size; + if (CONFIG(ENABLE_EARLY_DMA_PROTECTION)) { hsphy_buf = vtd_get_dma_buffer(&dma_buf_size); if (!hsphy_buf || dma_buf_size < HSPHY_PAYLOAD_SIZE) { printk(BIOS_ERR, "DMA protection enabled but DMA buffer does not" " exist or is too small\n"); - printk(BIOS_ERR, "Aborting HSPHY firmware loading, " - "PCIe Gen5 won't work.\n"); - return; + return NULL; } /* Rather impossible scenario, but check alignment anyways */ @@ -192,20 +336,73 @@ hsphy_buf = memalign(4 * KiB, HSPHY_PAYLOAD_SIZE); if (!hsphy_buf) { - printk(BIOS_ERR, "Could not allocate memory for HSPHY blob\n"); - printk(BIOS_ERR, "Aborting HSPHY firmware loading, " - "PCIe Gen5 won't work.\n"); - return; + printk(BIOS_ERR, "Failed to allocate memory for HSPHY blob\n"); + return NULL; } } + return hsphy_buf; +} + +void load_and_init_hsphy(void) +{ + void *hsphy_buf; + uint8_t hsphy_hash[MAX_HASH_SIZE] = { 0 }; + uint8_t hash_type; + uint32_t buf_size = HSPHY_PAYLOAD_SIZE; + pci_devfn_t dev = PCH_DEV_CSE; + const uint16_t pci_cmd_bme_mem = PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY; + uint32_t status; + + if (!is_devfn_enabled(SA_DEVFN_CPU_PCIE1_0) && + !is_devfn_enabled(SA_DEVFN_CPU_PCIE1_1)) { + printk(BIOS_DEBUG, "All HSPHY ports disabled, skipping HSPHY loading\n"); + return; + } + + /* + * Try to get HSPHY payload from CSME first, so we can always keep our + * HSPHY cache up to date. If we cannot allocate the buffer for it, the + * cache is our last resort. + */ + hsphy_buf = allocate_hsphy_buf(); + if (!hsphy_buf) { + printk(BIOS_ERR, "Could not allocate memory for HSPHY blob\n"); + if (CONFIG(INCLUDE_HSPHY_IN_FMAP)) { + printk(BIOS_INFO, "Trying to load HSPHY FW from cache\n"); + if (load_hsphy_from_cache()) { + printk(BIOS_INFO, "Successfully loaded HSPHY FW from cache\n"); + return; + } + printk(BIOS_ERR, "Failed to load HSPHY FW from cache\n"); + } + printk(BIOS_ERR, "Aborting HSPHY FW loading, PCIe Gen5 won't work.\n"); + return; + } + memset(hsphy_buf, 0, HSPHY_PAYLOAD_SIZE); + /* + * If CSME is not present, try cached HSPHY FW. We still want to use + * CSME just in case CSME is updated along with HSPHY FW, so that we + * can update our cache if needed. + */ if (!is_cse_enabled()) { + if (CONFIG(INCLUDE_HSPHY_IN_FMAP)) { + printk(BIOS_INFO, "Trying to load HSPHY FW from cache" + " because CSME is not enabled or not visible\n"); + if (load_hsphy_from_cache()) { + printk(BIOS_INFO, "Successfully loaded HSPHY FW from cache\n"); + return; + } + printk(BIOS_ERR, "Failed to load HSPHY FW from cache\n"); + } printk(BIOS_ERR, "%s: CSME not enabled or not visible, but required\n", __func__); - printk(BIOS_ERR, "Aborting HSPHY firmware loading, PCIe Gen5 won't work.\n"); - goto hsphy_exit; + printk(BIOS_ERR, "Aborting HSPHY FW loading, PCIe Gen5 won't work.\n"); + if (!CONFIG(ENABLE_EARLY_DMA_PROTECTION)) + free(hsphy_buf); + return; } /* Ensure BAR, BME and memory space are enabled */ @@ -219,19 +416,32 @@ pci_or_config16(dev, PCI_COMMAND, pci_cmd_bme_mem); } - if (heci_get_hsphy_payload(hsphy_buf, &buf_size, hsphy_hash, &hash_type, &status)) { - printk(BIOS_ERR, "Aborting HSPHY firmware loading, PCIe Gen5 won't work.\n"); - goto hsphy_exit; + /* Try to get HSPHY payload from CSME and cache it if possible. */ + if (!heci_get_hsphy_payload(hsphy_buf, &buf_size, hsphy_hash, &hash_type, &status)) { + if (verify_hsphy_hash(hsphy_buf, buf_size, hsphy_hash, hash_type)) { + upload_hsphy_to_cpu_pcie(hsphy_buf, buf_size); + if (CONFIG(INCLUDE_HSPHY_IN_FMAP)) + cache_hsphy_fw_in_flash(hsphy_buf, buf_size, hsphy_hash, + hash_type); + + if (!CONFIG(ENABLE_EARLY_DMA_PROTECTION)) + free(hsphy_buf); + return; + } else { + printk(BIOS_ERR, "Failed to verify HSPHY FW hash.\n"); + } + } else { + printk(BIOS_ERR, "Failed to get HSPHY FW over HECI.\n"); } - if (verify_hsphy_hash(hsphy_buf, buf_size, hsphy_hash, hash_type)) { - printk(BIOS_ERR, "Aborting HSPHY firmware loading, PCIe Gen5 won't work.\n"); - goto hsphy_exit; - } - - upload_hsphy_to_cpu_pcie(hsphy_buf, buf_size); - -hsphy_exit: if (!CONFIG(ENABLE_EARLY_DMA_PROTECTION)) free(hsphy_buf); + + /* We failed to get HSPHY payload from CSME, cache is our last chance. */ + if (CONFIG(INCLUDE_HSPHY_IN_FMAP) && load_hsphy_from_cache()) { + printk(BIOS_INFO, "Successfully loaded HSPHY FW from cache\n"); + return; + } + + printk(BIOS_ERR, "Failed to load HSPHY FW, PCIe Gen5 won't work.\n"); } diff --git a/util/cbfstool/default-x86.fmd b/util/cbfstool/default-x86.fmd index 41be782..f008889 100644 --- a/util/cbfstool/default-x86.fmd +++ b/util/cbfstool/default-x86.fmd @@ -14,6 +14,7 @@ ##SMMSTORE_ENTRY## ##SPD_CACHE_ENTRY## ##VPD_ENTRY## + ##HSPHY_FW_ENTRY## FMAP@##FMAP_BASE## ##FMAP_SIZE## COREBOOT(CBFS)@##CBFS_BASE## ##CBFS_SIZE## } -- To view, visit https://review.coreboot.org/c/coreboot/+/68987?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I5a37f5b06706ff30d92f60f1bf5dc900edbde96f Gerrit-Change-Number: 68987 Gerrit-PatchSet: 12 Gerrit-Owner: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Reviewer: Krystian Hebel <krystian.hebel(a)3mdeb.com> Gerrit-Reviewer: Martin L Roth <gaumless(a)gmail.com> Gerrit-Reviewer: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Reviewer: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: Tarun Tuli <taruntuli(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-MessageType: merged

1 0

[XS] Change in coreboot[master]: util/qemu: Add config for AArch64
by Lean Sheng Tan (Code Review) 23 Jun '23

23 Jun '23

Lean Sheng Tan has submitted this change. ( https://review.coreboot.org/c/coreboot/+/76042?usp=email ) ( 2 is the latest approved patch-set. No files were changed between the latest approved patch-set and the submitted one. )Change subject: util/qemu: Add config for AArch64 ...................................................................... util/qemu: Add config for AArch64 Most arguments taken from the Kconfig help. RAM needs to be >= 531M, as coreboot is linked to reside between 512M..531M. Tested `make qemu` with QEMU 7.2.0. Change-Id: Id7f23918a786bc126188d5caf285e9f532dbb0ed Signed-off-by: Nico Huber <nico.h(a)gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76042 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Arthur Heymans <arthur(a)aheymans.xyz> Reviewed-by: Paul Menzel <paulepanter(a)mailbox.org> Reviewed-by: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> --- M util/qemu/Makefile.inc 1 file changed, 3 insertions(+), 0 deletions(-) Approvals: Felix Singer: Looks good to me, but someone else must approve Paul Menzel: Looks good to me, but someone else must approve Arthur Heymans: Looks good to me, approved build bot (Jenkins): Verified diff --git a/util/qemu/Makefile.inc b/util/qemu/Makefile.inc index 651ef21..e1181ad 100644 --- a/util/qemu/Makefile.inc +++ b/util/qemu/Makefile.inc @@ -26,6 +26,9 @@ # $ # Force QEMU's built-in config # $ make qemu QEMU_CFG_ARGS= +QEMU-$(CONFIG_BOARD_EMULATION_QEMU_AARCH64) ?= qemu-system-aarch64 \ + -M virt,secure=on,virtualization=on -cpu cortex-a53 -m 1G + QEMU-$(CONFIG_BOARD_EMULATION_QEMU_X86_I440FX) ?= qemu-system-x86_64 -M pc QEMU-$(CONFIG_BOARD_EMULATION_QEMU_X86_Q35) ?= qemu-system-x86_64 -M q35 -- To view, visit https://review.coreboot.org/c/coreboot/+/76042?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Id7f23918a786bc126188d5caf285e9f532dbb0ed Gerrit-Change-Number: 76042 Gerrit-PatchSet: 4 Gerrit-Owner: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Reviewer: Lean Sheng Tan <sheng.tan(a)9elements.com> Gerrit-Reviewer: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-MessageType: merged

1 0

[XS] Change in coreboot[master]: allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G
by Lean Sheng Tan (Code Review) 23 Jun '23

23 Jun '23

Lean Sheng Tan has submitted this change. ( https://review.coreboot.org/c/coreboot/+/76090?usp=email ) Change subject: allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G ...................................................................... allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G When moving the code to allocate at the top level in commit 9260ea60bfa4 (allocator_v4: Use memranges only for toplevel), a call to restrict the limit of the resource was dropped. Probably by accident in one of the earliest rebases. Without this call to effective_limit(), 64-bit resour- ces at the top level, i.e. PCI bus 0, were always placed above 4G. Even when this was not requested with the IORESOURCE_ABOVE_4G flag. Tested on kontron/ktqm77 where the issue could be reproduced with x86_64. Without the fix, boot hangs when trying to access the GMA MMIO registers of PCI 00:02.0, which were placed above 4G. Change-Id: Ied3a0695ef5e91f092bf2d442c1c482057643483 Signed-off-by: Nico Huber <nico.h(a)gmx.de> Found-by: 9elements QA Reviewed-on: https://review.coreboot.org/c/coreboot/+/76090 Reviewed-by: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Reviewed-by: Eric Lai <eric_lai(a)quanta.corp-partner.google.com> Reviewed-by: Paul Menzel <paulepanter(a)mailbox.org> Reviewed-by: Lean Sheng Tan <sheng.tan(a)9elements.com> Reviewed-by: Arthur Heymans <arthur(a)aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> --- M src/device/resource_allocator_v4.c 1 file changed, 2 insertions(+), 2 deletions(-) Approvals: Arthur Heymans: Looks good to me, approved Lean Sheng Tan: Looks good to me, approved Paul Menzel: Looks good to me, but someone else must approve build bot (Jenkins): Verified Kyösti Mälkki: Looks good to me, approved Felix Singer: Looks good to me, but someone else must approve Eric Lai: Looks good to me, but someone else must approve diff --git a/src/device/resource_allocator_v4.c b/src/device/resource_allocator_v4.c index e64d8ad..96d4488 100644 --- a/src/device/resource_allocator_v4.c +++ b/src/device/resource_allocator_v4.c @@ -401,8 +401,8 @@ if (!res->size) continue; - if (!memranges_steal(&ranges, res->limit, res->size, res->align, type, &base, - CONFIG(RESOURCE_ALLOCATION_TOP_DOWN))) { + if (!memranges_steal(&ranges, effective_limit(res), res->size, res->align, + type, &base, CONFIG(RESOURCE_ALLOCATION_TOP_DOWN))) { printk(BIOS_ERR, "Resource didn't fit!!!\n"); print_failed_res(dev, res); continue; -- To view, visit https://review.coreboot.org/c/coreboot/+/76090?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ied3a0695ef5e91f092bf2d442c1c482057643483 Gerrit-Change-Number: 76090 Gerrit-PatchSet: 5 Gerrit-Owner: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Eric Lai <eric_lai(a)quanta.corp-partner.google.com> Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Reviewer: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Reviewer: Lean Sheng Tan <sheng.tan(a)9elements.com> Gerrit-Reviewer: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Reviewer: Raul Rangel <rrangel(a)chromium.org> Gerrit-Reviewer: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-MessageType: merged

1 0

[XS] Change in coreboot[master]: allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G
by Lean Sheng Tan (Code Review) 23 Jun '23

23 Jun '23

Attention is currently required from: Angel Pons, Felix Held, Nico Huber, Raul Rangel, Tim Wawrzynczak. Lean Sheng Tan has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/76090?usp=email ) Change subject: allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G ...................................................................... Patch Set 4: (1 comment) Patchset: PS4: getting this in earlier with 3 +2 as without this fix there’s boot hang. -- To view, visit https://review.coreboot.org/c/coreboot/+/76090?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ied3a0695ef5e91f092bf2d442c1c482057643483 Gerrit-Change-Number: 76090 Gerrit-PatchSet: 4 Gerrit-Owner: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Eric Lai <eric_lai(a)quanta.corp-partner.google.com> Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Reviewer: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Reviewer: Lean Sheng Tan <sheng.tan(a)9elements.com> Gerrit-Reviewer: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Reviewer: Raul Rangel <rrangel(a)chromium.org> Gerrit-Reviewer: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Nico Huber <nico.h(a)gmx.de> Gerrit-Attention: Raul Rangel <rrangel(a)chromium.org> Gerrit-Attention: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Attention: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Attention: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Comment-Date: Fri, 23 Jun 2023 08:47:46 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

[XS] Change in coreboot[master]: allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G
by Lean Sheng Tan (Code Review) 23 Jun '23

23 Jun '23

Attention is currently required from: Angel Pons, Felix Held, Nico Huber, Raul Rangel, Tim Wawrzynczak. Lean Sheng Tan has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/76090?usp=email ) Change subject: allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G ...................................................................... Patch Set 4: Code-Review+2 -- To view, visit https://review.coreboot.org/c/coreboot/+/76090?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ied3a0695ef5e91f092bf2d442c1c482057643483 Gerrit-Change-Number: 76090 Gerrit-PatchSet: 4 Gerrit-Owner: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Eric Lai <eric_lai(a)quanta.corp-partner.google.com> Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Reviewer: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Reviewer: Lean Sheng Tan <sheng.tan(a)9elements.com> Gerrit-Reviewer: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Reviewer: Raul Rangel <rrangel(a)chromium.org> Gerrit-Reviewer: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Nico Huber <nico.h(a)gmx.de> Gerrit-Attention: Raul Rangel <rrangel(a)chromium.org> Gerrit-Attention: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Attention: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Attention: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Comment-Date: Fri, 23 Jun 2023 08:46:49 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

[L] Change in coreboot[master]: acpi/acpi.c: Split of ACPI table generation into separate files
by Arthur Heymans (Code Review) 23 Jun '23

23 Jun '23

Attention is currently required from: Felix Singer, Lance Zhao, Tim Wawrzynczak. Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/76008?usp=email ) Change subject: acpi/acpi.c: Split of ACPI table generation into separate files ...................................................................... Patch Set 1: (1 comment) File src/acpi/acpi.c: https://review.coreboot.org/c/coreboot/+/76008/comment/4814e665_900d334f : PS1, Line 213: #if ENV_X86 > Just wondering.. This pp if is missing in the new files. Is that intended? I would assume it should vanish with CB:76009. Just something I noticed. Please mark as resolved if you want to. I can squash it with CB:76009 for clarity. -- To view, visit https://review.coreboot.org/c/coreboot/+/76008?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I5083b26c0d4cc6764b4e3cb0ff586797cae7e3af Gerrit-Change-Number: 76008 Gerrit-PatchSet: 1 Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Reviewer: Lance Zhao <lance.zhao(a)gmail.com> Gerrit-Reviewer: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Attention: Lance Zhao <lance.zhao(a)gmail.com> Gerrit-Attention: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Comment-Date: Fri, 23 Jun 2023 08:26:30 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-MessageType: comment

1 0

[XS] Change in coreboot[master]: mb/google/brya: Add support for variant_memcfg_init()
by David Wu (Code Review) 23 Jun '23

23 Jun '23

Attention is currently required from: Bob Moragues, Kane Chen, Nick Vaccaro, Tarun Tuli. David Wu has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/75990?usp=email ) Change subject: mb/google/brya: Add support for variant_memcfg_init() ...................................................................... Patch Set 1: (1 comment) Patchset: PS1: > What exactly will the variant_memcfg_init() do? […] That's right. Thanks. -- To view, visit https://review.coreboot.org/c/coreboot/+/75990?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I4926139e36602f87c8317ab4b476636e02f87771 Gerrit-Change-Number: 75990 Gerrit-PatchSet: 1 Gerrit-Owner: David Wu <david_wu(a)quanta.corp-partner.google.com> Gerrit-Reviewer: Bob Moragues <moragues(a)google.com> Gerrit-Reviewer: Eric Lai <eric_lai(a)quanta.corp-partner.google.com> Gerrit-Reviewer: Kane Chen <kane.chen(a)intel.corp-partner.google.com> Gerrit-Reviewer: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-Reviewer: Tarun Tuli <taruntuli(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Tarun Tuli <taruntuli(a)google.com> Gerrit-Attention: Kane Chen <kane.chen(a)intel.corp-partner.google.com> Gerrit-Attention: Bob Moragues <moragues(a)google.com> Gerrit-Attention: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-Comment-Date: Fri, 23 Jun 2023 08:23:53 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Nick Vaccaro <nvaccaro(a)google.com> Gerrit-MessageType: comment

1 0

[XS] Change in coreboot[master]: cpu/qemu-x86: Allow up to 255 cores
by Arthur Heymans (Code Review) 23 Jun '23

23 Jun '23

Attention is currently required from: Arthur Heymans, Kyösti Mälkki. Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/63483?usp=email ) Change subject: cpu/qemu-x86: Allow up to 255 cores ...................................................................... Patch Set 23: (1 comment) Commit Message: https://review.coreboot.org/c/coreboot/+/63483/comment/2f093790_e5d27927 : PS12, Line 11: invalid" is being logged when attempted. > Regions are now .bss? Yes. I guess a number higher than 255 is advisable now too. -- To view, visit https://review.coreboot.org/c/coreboot/+/63483?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I9eea91fb09f47de8b06de9fa7eb2ad66ef4dc7e2 Gerrit-Change-Number: 63483 Gerrit-PatchSet: 23 Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Arthur Heymans <arthur.heymans(a)9elements.com> Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Arthur Heymans <arthur.heymans(a)9elements.com> Gerrit-Attention: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Comment-Date: Fri, 23 Jun 2023 08:23:16 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Arthur Heymans <arthur.heymans(a)9elements.com> Comment-In-Reply-To: Arthur Heymans <arthur(a)aheymans.xyz> Comment-In-Reply-To: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-MessageType: comment

1 0

[XS] Change in coreboot[master]: acpi/acpigen.c: Ignore compiler warning about stack overflowing
by Arthur Heymans (Code Review) 23 Jun '23

23 Jun '23

Attention is currently required from: Felix Held, Lance Zhao, Nico Huber, Paul Menzel, Tim Wawrzynczak. Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/76007?usp=email ) Change subject: acpi/acpigen.c: Ignore compiler warning about stack overflowing ...................................................................... Patch Set 1: (1 comment) Patchset: PS1: > What compiler did you test with? Just the regular one from crossgcc. Nothing special. -- To view, visit https://review.coreboot.org/c/coreboot/+/76007?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I5d445d151db5e6cc7b6e13bf74ce81007d819f1d Gerrit-Change-Number: 76007 Gerrit-PatchSet: 1 Gerrit-Owner: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Reviewer: Lance Zhao <lance.zhao(a)gmail.com> Gerrit-Reviewer: Lean Sheng Tan <sheng.tan(a)9elements.com> Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Lance Zhao <lance.zhao(a)gmail.com> Gerrit-Attention: Nico Huber <nico.h(a)gmx.de> Gerrit-Attention: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Attention: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Attention: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Comment-Date: Fri, 23 Jun 2023 08:19:58 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-MessageType: comment

1 0

[XS] Change in coreboot[master]: allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G
by Arthur Heymans (Code Review) 23 Jun '23

23 Jun '23

Attention is currently required from: Angel Pons, Felix Held, Nico Huber, Raul Rangel, Tim Wawrzynczak. Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/76090?usp=email ) Change subject: allocator_v4: Fix top-level allocations w/o IORESOURCE_ABOVE_4G ...................................................................... Patch Set 4: Code-Review+2 -- To view, visit https://review.coreboot.org/c/coreboot/+/76090?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Ied3a0695ef5e91f092bf2d442c1c482057643483 Gerrit-Change-Number: 76090 Gerrit-PatchSet: 4 Gerrit-Owner: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Eric Lai <eric_lai(a)quanta.corp-partner.google.com> Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Reviewer: Felix Singer <service+coreboot-gerrit(a)felixsinger.de> Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Gerrit-Reviewer: Paul Menzel <paulepanter(a)mailbox.org> Gerrit-Reviewer: Raul Rangel <rrangel(a)chromium.org> Gerrit-Reviewer: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Nico Huber <nico.h(a)gmx.de> Gerrit-Attention: Raul Rangel <rrangel(a)chromium.org> Gerrit-Attention: Tim Wawrzynczak <inforichland(a)gmail.com> Gerrit-Attention: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Attention: Felix Held <felix-coreboot(a)felixheld.de> Gerrit-Comment-Date: Fri, 23 Jun 2023 08:19:02 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit June 2023