coreboot

coreboot@coreboot.org

6 participants
39686 discussions

[coreboot - Bug #449] ThinkPad T440p fail to start, continous beeping & LED blinking
by Angel Pons 07 Feb '23

07 Feb '23

Issue #449 has been updated by Angel Pons. https://review.coreboot.org/72806 fixes the UBSAN errors, please review. Note that UBSAN-enabled coreboot still dies later on: ``` Loading module at 0x00030000 with entry 0x00030000. filesize: 0x178 memsize: 0x178 Processing 16 relocs. Offset value of 0x00030000 unaligned access src/lib/rmodule.c:152:27 ubsan: unrecoverable error. ``` So, any users that desire to have a bootable system should keep UBSAN disabled when building coreboot. ---------------------------------------- Bug #449: ThinkPad T440p fail to start, continous beeping & LED blinking https://ticket.coreboot.org/issues/449#change-1394 * 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

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

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

06 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

Gygabyte h61m-ds2
by sergey 01 Feb '23

01 Feb '23

Hi community I have montherboard GA H61M-DS2 I have a tutorial https://doc.coreboot.org/tutorial/part1.html I run the command make and see the following output. Where can I get the description of the file? discription

1 0

Strange power button behavior
by Christopher Davis 01 Feb '23

01 Feb '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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot