June 2022 - coreboot - mail.coreboot.org

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

Heads up: Allocator changes
by Nico Huber Aug. 10, 2022

Aug. 10, 2022

Hi coreboot fellows, after two years with the new resource allocator it's time again for some changes[1]. Much less invasive than last time, but again there will be changes in the pattern where resources are placed. So once more this may uncover bugs in case fixed resources are not reserved properly. Reasons for the changes are somewhat the same as always: we haven't finished the support for 64-bit resources. Currently one has to opt in for a placement above 4G with a resource flag, and even this has its limitations. For instance, reserved space for hot-pluggable de- vices can be placed above 4G with a Kconfig setting, but there's no rule what should happen with the resources of cold-plugged devices. In the worst case, allocation for those can fail. Another reason are approaching changes to support multiple PCI host bridges and multiple resource windows per domain. I digress... So everybody is invited to test the patch train. There is a new Kconfig option RESOURCE_ALLOCATION_TOP_DOWN. The default y should work fine, though in case of regressions it would be nice to have it tested with both settings. Cheers, Nico [1] https://review.coreboot.org/q/topic:allocator+status:open

1 1

Intel Quark - a quick update
by Andy Pont July 20, 2022

July 20, 2022

Thanks to the generosity of members of the list there are two Intel Galileo boards, a Gen 1 and Gen 2, on their way to me which should arrive towards the end of the month. As soon as they get here I will start testing the various configs to see what works and what is broken. -Andy.

7 10

I may have misconfigured my Coreboot ROM, what did I do wrong?
by Tristan Young July 15, 2022

July 15, 2022

Today, I internally flashed a Coreboot ROM that I partially built myself to the motherboard of my ThinkPad T440p. But when I restarted my computer, it started constantly beeping, and turning it off and on didn't change that result. Luckily, I fixed it by flashing my previous Coreboot BIOS (SeaBIOS) to the top 4 MiB chip externally using my Raspberry Pi. But there are some things that were different in the build configuration for the newer BIOS, such as trying to use a bootorder file to make SeaBIOS try to boot from my HDD first instead of my CD/DVD drive, as well as setting the options to clear the DRAM on each boot. I also didn't use the cleanbuild option after different build attempts for the newer BIOS. Should I send my .config file so that you can tell if any of the config settings or combinations of them that I chose wouldn't work on my specific model of ThinkPad? And should I also send over an actual 4MiB binary of the BIOS I flashed that didn't work?

3 2

[coreboot - Bug #388] (New) denverton_ns: crash when starting postcar
by King Sumo July 13, 2022

July 13, 2022

Issue #388 has been reported by King Sumo. ---------------------------------------- Bug #388: denverton_ns: crash when starting postcar https://ticket.coreboot.org/issues/388 * Author: King Sumo * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: master * Start date: 2022-06-15 * Affected versions: 4.17, master * Affected hardware: intel harcuvar * Affected OS: all ---------------------------------------- Postcar is crashing when using configured to teardown the CAR using FSP. Therefore the bug may occur in other platforms than denverton as well. See also the discussion here: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2JC3… The bug was instroduced by the following change: * 5315e96abf arch/x86/postcar: Use a separate stack for C execution Attached is a patch with the bug fix. ---Files-------------------------------- fix-postcar-crash.patch (822 Bytes) -- 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

2 2

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

June 28, 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 1490278: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/rockchip/rk3288/soc.c: 16 in soc_init() ________________________________________________________________________________________________________ *** CID 1490278: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/soc/rockchip/rk3288/soc.c: 16 in soc_init() 10 #include <symbols.h> 11 12 #include "chip.h" 13 14 static void soc_init(struct device *dev) 15 { >>> CID 1490278: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "sdram_size_mb() * 1048576U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 16 ram_range(dev, 0, (uintptr_t)_dram, sdram_size_mb() * MiB); 17 if (display_init_required()) 18 rk_display_init(dev, (uintptr_t)_framebuffer, 19 REGION_SIZE(framebuffer)); 20 else 21 printk(BIOS_INFO, "Skipping display init.\n"); ** CID 1490277: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/mainboard/emulation/qemu-armv7/mainboard.c: 42 in mainboard_enable() ________________________________________________________________________________________________________ *** CID 1490277: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/mainboard/emulation/qemu-armv7/mainboard.c: 42 in mainboard_enable() 36 printk(BIOS_EMERG, "No dev0; die\n"); 37 halt(); 38 } 39 40 discovered = probe_ramsize((uintptr_t)_dram, CONFIG_DRAM_SIZE_MB); 41 printk(BIOS_DEBUG, "%d MiB of RAM discovered\n", discovered); >>> CID 1490277: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "discovered * 1048576" with type "int" (32 bits, signed) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "uint64_t" (64 bits, unsigned). 42 ram_range(dev, 0, 0x60000000, discovered * MiB); 43 init_gfx(); 44 } 45 46 struct chip_operations mainboard_ops = { 47 .enable_dev = mainboard_enable, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0