coreboot

coreboot@coreboot.org

9 participants
39128 discussions

Cr50 is not the only Google security chip
by Vadim Bendebury 06 Feb '23

06 Feb '23

Hello fellow Coreboot enthusiasts, I am not sure if I am the only one annoyed/confused when I see coreboot messages like "Error reading from Cr50" or "Did not recognize Cr50 version format", etc. while the device in fact is using a different GSC (Google Security Chip). Before I go for it - would there be objections to changing the source code (including path and file name changes) from Cr50 to GSC where appropiate? TIA, -vb

1 0

regarding nvme timeout while boot via SeaBIOS
by ritul guru 06 Feb '23

06 Feb '23

Hi All, I am trying to boot to Ubuntu OS on NVMe SSD, NVMe device does get detected but with SeaBIOS payload, observing timeout on nvme_wait, Appreciate any hint to debug this issue. Logs: All threads complete. Searching bootorder for: /pci@i0cf8/*@14,6 All threads complete. Searching bootorder for: HALT Found 0 lpt ports Found 0 serial ports Searching bootorder for: /pci@i0cf8/pci-bridge@2,4/*@0 All threads complete. Scan for option roms Press ESC for boot menu. Searching bootorder for: HALT drive 0x000f6720: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=1000215216 Space available for UMB: c0000-ed000, f5fe0-f6720 Returned 225280 bytes of ZoneHigh e820 map has 16 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000002000000 = 1 RAM 4: 0000000002000000 - 0000000002182000 = 2 RESERVED 5: 0000000002182000 - 000000005aee7000 = 1 RAM 6: 000000005aee7000 - 000000005d000000 = 2 RESERVED 7: 000000005d790000 - 000000005d7f0000 = 2 RESERVED 8: 000000005d7f0000 - 000000005d7f5000 = 1 RAM 9: 000000005d7f5000 - 0000000060000000 = 2 RESERVED 10: 00000000e0000000 - 00000000f0000000 = 2 RESERVED 11: 00000000fec10000 - 00000000fec11000 = 2 RESERVED 12: 00000000fedc2000 - 00000000fedc6000 = 2 RESERVED 13: 00000000fedc9000 - 00000000fedca000 = 2 RESERVED 14: 0000000100000000 - 000000047e300000 = 1 RAM 15: 000000047f340000 - 00000004a0000000 = 2 RESERVED enter handle_19: NULL Booting from Hard Disk... Booting from 0000:7c00 WARNING - Timeout at nvme_wait:147! WARNING - Timeout at nvme_wait:147! WARNING - Timeout at nvme_wait:147! WARNING - Timeout at nvme_wait:147! WARNING - Timeout at nvme_wait:147! *Thanks & RegardsRitul Guru+91-9916513186*

2 2

regarding edk2 payload to boot to uefi aware OS
by ritul guru 06 Feb '23

06 Feb '23

Hi, In earlier coreboot, there was a tianocore payload which has 1. CorebootPayload 2. UEFIPayload I used to boot with CorebootPayload to UEFI aware OS. I see, now it is edk2 payload, is CorebootPayload deprecated? and building alone uefipayload.fd is enough to boot to UEFI aware OS with coreboot BIOS? *Thanks & RegardsRitul Guru+91-9916513186*

2 2

Re: Deprecation of the Intel Quark SoC
by Łukasz Jeleń 06 Feb '23

06 Feb '23

Hi, My background is low level ARM and I want to get familiar with low level x86. I bought galileo v1 because it is cheap, small and handy x86 board. I have built coreboot code. It does not boot "out of the box". I had to add rmu.bin into coreboot.rom. With this logging on uart works. It seems SD/MMC controller also works. Now I'm struggling with: [INFO ] CBFS: Found 'fspm.bin' @0x31c40 size 0x2f000 in mcache @0x80004f84 [ERROR] CBFS ERROR: 'fspm.bin' allocation failure [EMERG] FSPM not available or failed to load! Regards, Łukasz

4 12

Recent board removal for deprecated features LEGACY_SMP_INIT and RESOURCE_ALLOCATOR_V3
by Paul Menzel 05 Feb '23

05 Feb '23

Dear coreboot folks, Two days ago, on November 7th, the change-sets of the topic *drop_LEGACY_SMP_INIT* [1] were submitted after being created on November 2nd [2]. The removal was announced on the list some time ago and was documented in the release notes. 1. RESOURCE_ALLOCATOR_V3 in the 4.16 release notes [3] 2. LEGACY_SMP_INIT in the 4.16, 4.17, and 4.18 release notes [4] (I think that planned deprecations should to be listed in each release note.) Despite the missing RESOURCE_ALLOCATOR_V3 deprecation announcement in 4.17 and 4.18, everything was done formally correct, nevertheless I would have wished, more time would have been given and the actions would have been announced once more on the mailing list. My understanding was always, that code removal will be handled more leniently, if the required changes are being worked on. This was the case here for parallel SMP init [5] and resource allocator v4 [6]. Some change-sets even had a +1 or +2. The request for testing was also fulfilled by the users. Some of the change-sets were even authored by “non-AGESA“ folks, which was awesome to see. Letting this effort go to waste without documenting somewhere, what needed to be done to finish these change-sets makes me sad. 3mdeb also invested resources into implementing some of the features. The last thing I noticed, that at least for the PC Engines board removal, the approval of the maintainers listed in `MAINTAINERS` was not given, and should have been waited for. The +2 itself were also by developers normally not (very) active with AMD AGESA Open Source boards. The points above are just my observations, and, hopefully, things can improve in the future to avoid bad feelings. I am thankful to everyone working on coreboot, and I also understand the frustration of having to maintain several code paths. Although I own and run two of the removed boards, I am fine to move to the branch *4.18_branch* although I am not happy about it, as branches also increase maintenance burden. The main reason for writing this message is to ask, if entities (read 3mdeb) have big interest in getting part of the boards back into the master branch, so that the already made investments are not in vain, and nobody is alienated from working upstream. If that is a goal, this effort should be coordinated as reverting commits is going to become harder and harder. mb/aopen/dxplplusu (Intel) is already worked on to be put back into the master branch [7]. Kind regards, Paul [1]: https://review.coreboot.org/q/topic:drop_LEGACY_SMP_INIT [2]: https://review.coreboot.org/c/coreboot/+/69111/2 [3]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.18/Docum… [4]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.18/Docum… [5]: https://review.coreboot.org/c/coreboot/+/64892 "cpu/amd/family15: Use parallel_mp init" [6]: https://review.coreboot.org/c/coreboot/+/53990 "nb/amd/agesa/family15tn: Enable RESOURCE_ALLOCATOR_V4" [7]: https://review.coreboot.org/c/coreboot/+/69339 "Revert "mb/aopen/dxplplusu: Remove board""

3 2

[coreboot - Bug #453] (New) Intel HDMI / DP Audio device not showing up after libgfxinit
by CoolStar Organization 05 Feb '23

05 Feb '23

Issue #453 has been reported by CoolStar Organization. ---------------------------------------- Bug #453: Intel HDMI / DP Audio device not showing up after libgfxinit https://ticket.coreboot.org/issues/453 * Author: CoolStar Organization * Status: New * Priority: Normal * Target version: none * Start date: 2023-02-05 * Affected versions: master * Needs backport to: 4.15 * Affected hardware: All boards with libgfxinit * Affected OS: Windows 8.1, Windows 10, macOS, Linux ---------------------------------------- Intel HDMI / DP Audio device does not appear on the HD Audio bus after running libgfxinit until after GPU driver initializes in the OS. This can cause a race condition on certain OS's, especially if HDA enumeration runs before the GPU driver initializes the card in the OS (or happens if the GPU driver doesn't run at all, which can happen on all OS's with boot args or uninstalling the GPU driver) -- 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

1 1

[coreboot - Bug #449] ThinkPad T440p fail to start, continous beeping & LED blinking
by Crazy Fox 05 Feb '23

05 Feb '23

Issue #449 has been updated by Crazy Fox. Affected versions 4.19 added Affected versions deleted (4.18) Felix Singer wrote in #note-4: > Does this issue also occur on 4.19 and/or master? Would be great if you could test this. Yes, yesterday I've checked it and still occur on 4.19 ---------------------------------------- Bug #449: ThinkPad T440p fail to start, continous beeping & LED blinking https://ticket.coreboot.org/issues/449#change-1392 * Author: Crazy Fox * Status: In Progress * Priority: Normal * Assignee: Angel Pons * Category: board support * Target version: 4.18 * Start date: 2023-01-14 * Affected versions: 4.19 * Related links: The USBAN error is: ``` [ERROR] shift out of bounds src/northbridge/intel/haswell/pcie.c:85:22 [EMERG] ubsan: unrecoverable error. ``` * Affected hardware: haswell ---------------------------------------- Hi, Team Being corebooted before and works fine on 4.17. After flashing 4.18 my t440p wont startup (black screen, constant beeping & LED blinking). I've tried and retried different nconfigs but result is the same. I know that it is lack of information, but I need to recover the laptop first to grab some logs from it. Log from FT232H's debug is attached, the rest of info (defconfig, flashrom command etc. will upload soon) ---Files-------------------------------- coreboot_t440p_emerg.log (7.85 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

1 0

Status of maintained boards and policies?
by Denis 'GNUtoo' Carikli 03 Feb '23

03 Feb '23

Hi, The MAINTAINERS file has the following: > PC ENGINES ALL MAINBOARDS > M: Piotr Król <piotr.krol(a)3mdeb.com> > M: Michał Żygowski <michal.zygowski(a)3mdeb.com> > S: Supported > F: src/mainboard/pcengines/ But the commit f9decbb0c720662d8e71fe221aef55b7ecf76196 ("mb/*/*: Remove AMD family14 boards") actually removed the apu1 (src/mainboard/pcengines/). Is there some policy somewhere that describes what kind of support to expect from maintained boards? Is there also a policy that explains when boards are removed? Or what to do to prevent boards from being removed? For instance u-boot warns when building that a boards needs to be adjusted to the newer driver model. So just by building u-boot you know in advance what needs to be fixed and for when. I've looked in the Coreboot documentation but I didn't find any information about that. Also is there some public information on how much work it is to avoid a board being removed? Does it require to dedicate someone full time on it? Or does it usually requires less time? Also how changes that break other people's code are decided? Can anyone submit these changes and get them accepted with very few people agreeing to them? Or is there another procedure for these special changes? Denis.

3 3

Strange power button behavior
by Christopher Davis 31 Jan '23

31 Jan '23

I’m seeing problematic power button behavior on my ASUS C302 (Intel m3-6Y30 Skylake) Flip Chromebooks. With the lid closed the power button will not power on the C302 for a repeatable one hour and 20 seconds after shutdown, which is good, but after that it will. This is a problem because the power button can easily get bumped while the C302 is being transported. When this happens on my ChromeOS C302 the EC powers on the AP and coreboot executes, which in turn boots ChromeOS which shuts down immediately, mitigating the problem. When this happens on my Fedora 35 C302 the EC powers on the AP and coreboot (MrChromebox coreboot_tiano-cave-mrchromebox_20220718.rom UEFI) executes, which in turn boots Fedora 35 which then waits indefinitely for a LUKS passphrase to be entered, eventually resulting in a fully discharged battery. I would like to fix this and need help/advice. I think it’s an EC problem, not a coreboot problem, but I’m not sure. The C source file ec/common/power_button.c contains code in raw_power_button_pressed() that ignores the power button if the laptop lid is closed. That code has changed over time, becoming conditionally compiled depending on CONFIG_POWER_BUTTON_IGNORE_LID, and I don’t know which version of the EC code is in these C302s, but the fact that the power button is ignored with the lid closed for the first one hour and 20 seconds suggests that this code is present in these EC instances. I’m stumped by the change in power button behavior after one hour and 20 seconds. This is repeatable on four C302 laptops. At first I thought this might be a charge leakage problem in hardware lid switch circuitry or something like that, but it’s the same on all four C302 laptops, and is consistently repeatable, so I think that pretty much rules out hardware. That leaves softwwhatare as the cause. Maybe an overflow in a timer? A 32 bit unsigned integer overflow in a microsecond timer occurs in approximately one hour 12 minutes, not one hour 20 seconds, so that’s not it. What could be causing this, and how can it be fixed? I’ve thought about adding code to a custom version of coreboot to request the EC to power down the AP if coreboot is booted while the laptop lid is closed, but I’m not sure this is the best approach. Does coreboot have knowledge of the laptop lid state? I’ve also thought about adding code to a custom linux kernel to shut down during boot if the laptop lid is closed, but by the time the kernel has knowledge of the laptop lid state the boot is already well advanced – better to power down much earlier, in either coreboot or preferably the EC. I would welcome any comments or suggestions for solving this problem. Thank you in advance. -Dindoo

1 0

[coreboot - Bug #451] (New) Fix POST code handling
by Felix Singer 30 Jan '23

30 Jan '23

Issue #451 has been reported by Felix Singer. ---------------------------------------- Bug #451: Fix POST code handling https://ticket.coreboot.org/issues/451 * Author: Felix Singer * Status: New * Priority: Normal * Target version: none * Start date: 2023-01-29 ---------------------------------------- coreboot supports writing POST codes to I/O port 80. There are various Kconfigs that deal with POST codes, which don’t have effect on most platforms. The code to send POST codes is scattered in C and Assembly, some use functions, some use macros and others simply use the `outb` instruction. The POST codes are duplicated between stages and aren’t documented properly. ## Tasks * Guard Kconfigs with a depends on to only show on supported platforms * Remove duplicated Kconfigs * Replace `outb(0x80, ...)` with calls to `post_code(...)` * Update Documentation/POSTCODES * Use defines from console/post_codes.h where possible * Drop duplicated POST codes * Make use of all possible 255 values ## Requirements * Knowledge in the coreboot build system and the concept of stages * Other knowledge: Little experience with C and x86 Assembly * Hardware requirements: Nothing special ## Mentors * Patrick Rudolph patrick.rudolph(a)9elements.com * Christian Walter christian.walter(a)9elements.com -- 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 3

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot