September 2022 - coreboot - mail.coreboot.org

[coreboot - Bug #415] (New) RESOURCE_ALLOCATION_TOP_DOWN breaks edk2
by Sean Rhodes May 2, 2025

May 2, 2025

Issue #415 has been reported by Sean Rhodes. ---------------------------------------- Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks edk2 https://ticket.coreboot.org/issues/415 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master ---------------------------------------- CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files-------------------------------- resource_allocatorv4.txt (94 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

3 6

QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed
by Mike Banon Feb. 21, 2024

Feb. 21, 2024

If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore: ... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

6 11

[coreboot - Bug #392] (New) Coreboot 4.16 & 4.17 - SeaBios Windows 10 BSOD "ACPI Error"
by Pawel Radomychelski Jan. 15, 2023

Jan. 15, 2023

Issue #392 has been reported by Pawel Radomychelski. ---------------------------------------- Bug #392: Coreboot 4.16 & 4.17 - SeaBios Windows 10 BSOD "ACPI Error" https://ticket.coreboot.org/issues/392 * Author: Pawel Radomychelski * Status: New * Priority: High * Category: board support * Target version: 4.17 * Start date: 2022-06-18 * Affected versions: 4.16, 4.17, master * Affected hardware: Lenovo ThinkPad X230 Tablet * Affected OS: Windows 10 ---------------------------------------- Since CoreBoot 4.16 my Windows 10 cant boot from SeaBios, i get BSOD with "ACPI Error" very early. Don't know which commit exactly brakes ACPI, but i can say, that in my CoreBoot 4.15 Image from 11/09/2021 Windows 10 is booting just fine from SeaBIOS. Some time later under CoreBoot 4.16 i saw that windows is BSODing. Tried yesterday with CoreBoot 4.17 and its still broken. I think, since CB4.16 there is something broken in ACPI. As i read, the problem is, that ACPI reserves some memory area, which in Windows is reserved for the system. This [[https://ticket.coreboot.org/issues/327]] seems to be a similar problem, but the guy is using TianoCore instead of SeaBIOS. Changing the line OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) to OperationRegion (OPRG, SystemMemory, ASLS, 0x1000) doesnt fix it for SeaBios, but fix it for TianoCore. ---Files-------------------------------- dmesg_cb415.txt (78.9 KB) dmesg_cb417.txt (79.9 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

7 31

[coreboot - Bug #386] (New) ASUS P8Z77-V LX2 - Raminit issue at second boot with two 8GiB DIMMs - bootloop
by gzz5f gzz5f Jan. 15, 2023

Jan. 15, 2023

Issue #386 has been reported by gzz5f gzz5f. ---------------------------------------- Bug #386: ASUS P8Z77-V LX2 - Raminit issue at second boot with two 8GiB DIMMs - bootloop https://ticket.coreboot.org/issues/386 * Author: gzz5f gzz5f * Status: New * Priority: High * Category: board support * Target version: master * Start date: 2022-06-05 * Affected versions: master * Needs backport to: none * Affected hardware: ASUS P8Z77-V LX2 * Affected OS: all ---------------------------------------- I build coreboot today for the ASUS P8Z77-V LX2 and used the latest coreboot master code. The 2 8GiB DIMMs are working fine at first boot. You can start computer, install from a live media the OS and so on. But at the second boot it failes boot forever and its bootooping. It does not make a change if i boot for a second until SeaBIOS output and then turn off the computer or use the computer for longer time. The second boot is always broken. Workaround 1: Remove one of the two 8GiB DIMMs. Then the computer also starts fine after a reboot. Workaround 2: Install two 4GiB DIMMs instead of two 8GiB DIMMs. Then the computer also starts fine after reboot. Workaround 3: At every boot boot for a second with one DIMM. Turn off the computer, insert the second DIMM and start it again. kmalkki told me to rebuid the image with DEBUG_RAM_SETUP=y I then build a second image, with DEBUG_RAM_SETUP=y. The logfile contains the first successfull boot (created with Workaround 3), the poweroff and the poweron with the bootloop. I have let it bootloop few times before turned off the PSU. ---Files-------------------------------- coreboot_logfie.txt (197 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

3 3

[coreboot - Support #387] (New) Support Framework Laptop
by Jun Aruga Jan. 15, 2023

Jan. 15, 2023

Issue #387 has been reported by Jun Aruga. ---------------------------------------- Support #387: Support Framework Laptop https://ticket.coreboot.org/issues/387 * Author: Jun Aruga * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2022-06-05 * Affected hardware: Framework Laptop ---------------------------------------- Dear coreboot developers, I am a user of Framework Laptop[1][2]. Thank you for working to make coreboot work on Framework Laptop! This ticket is to track the task, as I didn't see any other issue tickets about Framework Laptop here. According to the Framework founder's comment[3] below, Framework provided Framework Laptops to the coreboot community. > We've handed three systems that can boot unsigned bootloaders to folks in the coreboot community. Our plan in the near term is to help them create a shim loader that can be signed to run on any Framework Laptop, which then enables anyone to do further coreboot development. Then I saw Matthew's try to make the coreboot work on Framework Laptop,[4] but unfortunately it didn't work at that time.[5] How is the current status? What prevents coreboot from working on the Framework Laptop? How can we, people in the Framework community, help you? As a reference, there is a coreboot specific thread on the Framework community forum.[6] ## References * [1] https://frame.work/ * [2] Framework Computer - Wikipedia - https://en.wikipedia.org/wiki/Framework_Computer * [3] Framework Laptop Mainboard, Hacker News, April 20, 2022 - https://news.ycombinator.com/item?id=31097434 * [4] Matthew tries to port Coreboot to the Framework laptop - February 27, 2022 - https://www.youtube.com/watch?v=Jf_6xW-8tfQ * [5] Matthew Garrett on Twitter, February 27, 2022 - https://twitter.com/mjg59/status/1497788538212917250 * [6] Free the EC! and Coreboot Only - https://community.frame.work/t/free-the-ec-and-coreboot-only/791 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

7 15

Cisco Meraki use coreboot in some MX products and will not provide the source code
by Hal Martin Dec. 22, 2022

Dec. 22, 2022

Hello, Several Cisco Meraki products (MX84, MX250) are using the coreboot bootloader. Meraki are also distributing coreboot builds for these products via their update mechanism. In October 2021, I requested the corresponding coreboot source code for the MX84 from open-source(a)meraki.com. Another individual requested the coreboot source code for the MX250 around the same time. We own the devices in quesiton. To date, Meraki have not provided the source code or provided an explanation as to the delay in providing the source code. The last reply I received was in January, and they have not replied to any of my follow up requests. As coreboot is GPL licensed software, I wanted to inform the coreboot community that I believe Cisco Meraki are not acting in good faith and are, in my opinion, violating the GPL by not providing the coreboot source code upon request. Kind regards, Hal Martin

4 4

[coreboot - Bug #412] (New) x230 reboots on suspend
by Carson Alberding Oct. 21, 2022

Oct. 21, 2022

Issue #412 has been reported by Carson Alberding. ---------------------------------------- Bug #412: x230 reboots on suspend https://ticket.coreboot.org/issues/412 * Author: Carson Alberding * Status: New * Priority: Normal * Target version: none * Start date: 2022-09-02 * Affected versions: master * Related links: https://ticket.coreboot.org/issues/393 * Affected hardware: x230 * Affected OS: windows/arch linux ---------------------------------------- Very similar to issue 393 where the x230 reboots when suspended to RAM. Seems to be an issue with coreboot v4.16 & 4.17 or something is missing in the config (attached). Any insight on this would be appreciated! ---Files-------------------------------- coreboot_config.txt (18.8 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

5 11

[coreboot - Bug #401] (New) edk2 hangs indefiniately
by Sean Rhodes Oct. 19, 2022

Oct. 19, 2022

Issue #401 has been reported by Sean Rhodes. ---------------------------------------- Bug #401: edk2 hangs indefiniately https://ticket.coreboot.org/issues/401 * Author: Sean Rhodes * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: none * Start date: 2022-07-08 * Affected versions: master * Affected hardware: Everything * Affected OS: Doesn't matter ---------------------------------------- Since CB:63555, edk2 will no longer boot and hangs indefiniately Various forks disable MTRR programming in edk2 (such as https://github.com/MrChromebox/edk2/commit/d641ea6920737fd9b9a94210e9a2e763…) but this shouldn't be done as it breaks spec. Workarounds are to revert CB:64804, CB:63550, CB:64803 and CB:63555. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

7 11

FSP 2.4: runtime blobs!
by Arthur Heymans Sept. 30, 2022

Sept. 30, 2022

Hi In august FSP2.4 was released with a new feature/component: FSP-I. https://cdrdv2.intel.com/v1/dl/getContent/736809 FSP-I is a blob that initializes SMM and installs a runtime handler and then locks down SMM. Just as a reminder: SMM is a special CPU mode that is entered via a interrupt (SMI) and is completely invisible to the OS. This used to be for power management but now it's often used to avoid writing proper OS drivers e.g. for RAS features. Extract from section 8: "If an FSP binary provides the FSP-I component, usage of FSP-I can be mandatory for certain processors and chipsets. The Integration Guide will document if FSP-I is mandatory for specific FSP implementations." By design coreboot has as little runtime as possible. We also dislike blobs, as it's an open source project. Having closed source code inside a CPU mode that is completely opaque to the OS is going against those 2 wishes at the same time + there already exists open source code for setting SMM. I'd like to start a discussion about not allowing blob runtimes in coreboot before people start writing code to integrate FSP-I. We have had discussions about which blobs are ok and not in the past, with no clear outcome. We don't have a clear policy about what a blob can or cannot do (it only has to be redistributable iirc?), but even without having a clear line of what is ok or not, a runtime blob running on the main CPU is definitely crossing it in my opinion. What are your thoughts? Do we take a stance against FSP-I integration in coreboot? Are there precedents where blobs runtimes are installed on the main CPU, that I don't know of which could justify FSP-I? P.S. It's quite sad to see this happen after an open letter 361 people signed for a more open FSP. https://openletter.earth/adopting-open-source-firmware-approach-for-intel-f… P.S.2 Not all about FSP2.4 is bad. I like that adds the possibility for 64bit support, though it uses the MSVC ABI instead of SYSV :-( . Arthur

4 5

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com Sept. 27, 2022

Sept. 27, 2022

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1498391: (TAINTED_SCALAR) /src/commonlib/fsp_relocate.c: 229 in pe_relocate() /src/commonlib/fsp_relocate.c: 256 in pe_relocate() ________________________________________________________________________________________________________ *** CID 1498391: (TAINTED_SCALAR) /src/commonlib/fsp_relocate.c: 229 in pe_relocate() 223 rsize = read_le32(&ophdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC].Size); 224 roffset = read_le32(&ophdr->DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress); 225 printk(FSP_DBG_LVL, "relocation table at offset-%x,size=%x\n", roffset, rsize); 226 // TODO - add support for PE32+ also 227 228 offset = roffset; >>> CID 1498391: (TAINTED_SCALAR) >>> Using tainted variable "roffset + rsize" as a loop boundary. 229 while (offset < (roffset + rsize)) { 230 uint32_t vaddr; 231 uint32_t rlen, rnum; 232 uint16_t *rdata; 233 uint32_t i; 234 EFI_IMAGE_DATA_DIRECTORY *relocd; /src/commonlib/fsp_relocate.c: 256 in pe_relocate() 250 printk(FSP_DBG_LVL, "\t\treloc type %x offset %x aoff %x, base-0x%x\n", 251 rtype, roff, aoff, img_base_off); 252 switch (rtype) { 253 case EFI_IMAGE_REL_BASED_ABSOLUTE: 254 continue; 255 case EFI_IMAGE_REL_BASED_HIGHLOW: >>> CID 1498391: (TAINTED_SCALAR) >>> Using tainted variable "aoff" as an index to pointer "pe_base". 256 val = read_le32(&pe_base[aoff]); 257 printk(FSP_DBG_LVL, "Adjusting %p %x -> %x\n", 258 &pe_base[aoff], val, val + delta); 259 write_le32(&pe_base[aoff], val + delta); 260 break; 261 case EFI_IMAGE_REL_BASED_DIR64: ** CID 1498390: Null pointer dereferences (FORWARD_NULL) /src/commonlib/fsp_relocate.c: 650 in relocate_fvh() ________________________________________________________________________________________________________ *** CID 1498390: Null pointer dereferences (FORWARD_NULL) /src/commonlib/fsp_relocate.c: 650 in relocate_fvh() 644 printk(FSP_DBG_LVL, "TE image at offset %zx\n", 645 section_offset); 646 te_relocate(section_addr, section_data); 647 } else if (read_le8(&csh->Type) == EFI_SECTION_PE32) { 648 printk(FSP_DBG_LVL, "PE32 image at offset %zx\n", 649 section_offset); >>> CID 1498390: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "fih_offset". 650 pe_relocate(new_addr, section_data, fsp, *fih_offset); 651 } 652 653 offset += data_size + data_offset; 654 /* Sections are aligned to 4 bytes. */ 655 offset = ALIGN_UP(offset, 4); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0