coreboot

coreboot@coreboot.org

3 participants
39681 discussions

AMD64 & X86S payload handover
by Nico Huber 23 Apr '24

23 Apr '24

Hi coreboot fellows, yesterday some patches[1] surfaced on Gerrit about a handover for 64-bit x86 payloads. Strictly speaking, we don't have to do anything for this right now, as the original, protected-mode handover would work too. How- ever, there is X86S on the horizon. If you don't know about it, here is the short version: X86S was announced by Intel last year, it's supposed to be a simplified version of AMD64, without real nor protected mode, so 64-bit long mode only. So we have: +----------------+-------+------+ | | AMD64 | X86S | +----------------+-------+------+ | real mode | X | | +----------------+-------+------+ | protected mode | X | | +----------------+-------+------+ | long mode | X | X | +----------------+-------+------+ After a night's sleep, I'm convinced we should keep things as simple as possible on the coreboot side, and hence propose the following: 1. AMD64: Keep the current, 32-bit protected mode handover 2. X86S: Hand over in long mode with a) the pointer to cbtables in RDI (like the first parameter in the System V ABI), b) the guarantee that the payload and cbtables are identity mapped in the current page tables. Rationale: * 1. Allows us to keep compatibility where it's possible. X86S breaks compatibility on purpose but we don't have to break compatibility in the AMD64 case. There is one exception: A future X86S payload could potentially run on AMD64 and vice versa. Though, compatibility could be ensured on the payload end (e.g. having two entry points like the Linux kernel has(*)). * Keeping the current handover where possible would allow to use a new 64-bit payload with a coreboot build from one of the older branches, for instance, without having to modify them all. Existing coreboot binaries for AMD64 systems would stay compatible as well. * 1. requires a 64-bit payload to switch (back) to long mode by itself. This should be straight-forward, though, and can be done with rather few instructions. The necessary page-table setup could be kept small, as long mode supports 1GiB pages. Having to set up its own page ta- tables also avoids problems with assumptions about the prior setup. * Generally, we can't control what downstream does. However, by adding a long-mode handover as late as possible (i.e. the first X86S port), we would encourage everybody to stay compatible. Once the long-mode handover is implemented upstream, it will be easier to create a pay- load that works with some x86 coreboot builds, but not all. Making it X86S only, will limit the room for incompatibility. * 2. a) is probably what people would expect. * 2. b) allows for more flexibility in coreboot, without having to set up much (ideally nothing) special for the payload. If we'd make more guarantees, e.g. a whole 4GiB space identity mapped, it would become more likely that we have to change the mapping for the handover. For instance, if we'd ever decide to add a continuous mapping for a >16M flash chip. That would likely still be compatible with 2. b), though might not be with more elaborate guarantees. So, please share your thoughts :) Best regards, Nico [1] https://review.coreboot.org/c/coreboot/+/81960 https://review.coreboot.org/c/coreboot/+/81964 https://review.coreboot.org/c/coreboot/+/81968 (*) All payloads (builds) until now will be incompatible to X86S. But if we'd encourage to give all 64-bit payloads from now on two en- try points (32- and 64-bit), we could increase the number of pay- loads that are both compatible to X86S and all prior AMD64 core- coreboots.

2 1

Re: Porting Coreboot to a Mini PC
by Matt DeVillier 21 Apr '24

21 Apr '24

you are of course free to do exactly that, or my MrChromebox firmware if you prefer coreboot + UEFI. But ultimately, the only reason you have that option is because others felt it was worth the additional price to support the company paying for the coreboot development., so you might consider donating to the SFF, coreboot.org, or whosever work you decide to use "for free" On Sat, Apr 20, 2024 at 12:23 PM Mason Corkern <corkernm(a)berea.edu> wrote: > yeah no thanks. I'll just buy the $300 exact hardware and then flash the > firmware from Purism's website for free and save a bunch of money 😉 > > Thanks, > Mason Corkern > ------------------------------ > *From:* Matt DeVillier <matt.devillier(a)gmail.com> > *Sent:* Wednesday, April 3, 2024 8:36 PM > *To:* Mason Corkern <corkernm(a)berea.edu> > *Cc:* coreboot <coreboot(a)coreboot.org> > *Subject:* Re: [coreboot] Porting Coreboot to a Mini PC > > *[EXTERNAL SENDER]* > that's still going to cost more than $400. Add a zero and I'll think about > it ;-) > > On Wed, Apr 3, 2024, 7:30 PM Mason Corkern <corkernm(a)berea.edu> wrote: > > Yeah, I only want the port, not ongoing support. > > Thanks, > Mason Corkern > ------------------------------ > *From:* Matt DeVillier <matt.devillier(a)gmail.com> > *Sent:* Wednesday, April 3, 2024 8:25 PM > *To:* Mason Corkern <corkernm(a)berea.edu> > *Cc:* coreboot(a)coreboot.org <coreboot(a)coreboot.org> > *Subject:* Re: [coreboot] Porting Coreboot to a Mini PC > > *[EXTERNAL SENDER]* > The minisforum MiniPC you have linked is a completely different device > from the one offered by Purism/Nitrokey; the only thing similar is the form > factor. > > coreboot support has to be added on a per-mainboard basis, so the > Minisforum device you linked would need to be ported by someone who > understands coreboot and x86 firmware (or who has a lot of free time to > learn). And the mainboard on the device would need to be unencumbered by > things like Intel Bootguard (which fortunately IME most devices like that > are, but it's not a guarantee). > > If you want not just a coreboot port, but ongoing support, it's going to > cost you a heck of a lot more than the $400 you think Purism/Nitrokey are > "overcharging" by. And I say that as the developer who did the initial port > on the Purism Librem Mini/Mini v2 boards. > > -Matt > (speaking on behalf of myself, not any present or past employer) > > On Wed, Apr 3, 2024 at 5:43 PM Mason Corkern <corkernm(a)berea.edu> wrote: > > Greetings, > > I recently purchased a Mini PC from mini forums, a company based in Hong > Kong [1]. I want to replace their custom BIOS with Coreboot since it's > FOSS. Prisim and Nitro has been able to install Coreboot, but they said > they did a custom port for the motherboard/cpu and they overcharge by $400 > and justify it due to the R&D spent on porting Coreboot to the minipc [2]. > Has anyone tried porting Coreboot for similar boars and/or made a tutorial? > I couldn't find it when I googled around and looked in docs. > > > > 1. Minisforum NAB6/NPB7 Intel i7-12650H/Intel i7-13700H > <https://store.minisforum.com/products/minisforum-nab6?variant=44164535288053> > 2. Purism– Librem Mini <https://puri.sm/products/librem-mini/> and NitroPC > 1 | shop.nitrokey.com <https://shop.nitrokey.com/shop/nitropc-1-132>. > 3. > > Thanks, > Mason Corkern > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org > >

1 0

[coreboot - Bug #499] coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build
by Christian Walter 17 Apr '24

17 Apr '24

Issue #499 has been updated by Christian Walter. Oberon 4071 wrote: > coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce > coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 > Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 > > coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. > > I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. > > Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. > > I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). We fixed the issue in our edk2 here: https://github.com/9elements/edk2/commit/d965778103bfe2badd815c6fe35d278658… ---------------------------------------- Bug #499: coreboot will not boot edk2 on Lenovo T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, cannot disable this setting during build https://ticket.coreboot.org/issues/499#change-1807 * Author: Oberon 4071 * Status: New * Priority: Normal * Assignee: Nico Huber * Start date: 2023-06-29 * Affected versions: 4.21 * Needs backport to: none * Related links: https://review.coreboot.org/c/coreboot/+/76198 https://review.coreboot.org/c/coreboot/+/76199 * Affected hardware: lenovo/t440p ---------------------------------------- coreboot revision in git: feb27dcbf3fc685b070c950a16e8adec958bc1ce coreboot revision (git describe --tags): 4.20-520-gfeb27dcbf3 Tested payloads: edk2 from MrChromebox revision uefipayload_202304 and uefipayload_202306 coreboot will not boot my Lenovo ThinkPad T440p with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled, when using the edk2 payload (MrChromebox version, either uefipayload_202304 or uefipayload_202306). The display sometimes turns on, indicating that some of the hardware initialization was successful, but the payload will not start. I tried to disable CONFIG_RESOURCE_ALLOCATION_TOP_DOWN in .config, but the build process insists on leaving this config enabled. This seems to be caused by the RESOURCE_ALLOCATION_TOP_DOWN setting changed to "def_bool y" in src/device/Kconfig in commit 5226301765ded70e0ef640e5252bbaca8cd14451 (allocator_v4: Treat above 4G resources more natively). The make target for building coreboot seems to automatically rerun olddefconfig, causing this setting to always remain enabled no matter what was previously saved in the .config file. Modifying src/device/Kconfig to change RESOURCE_ALLOCATION_TOP_DOWN to "def_bool n" appears to fix the problem on my machine. I have attached my .config file (with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled to reproduce the problem). ---Files-------------------------------- .config (20.7 KB) console.log (128 KB) cbmem.txt (151 KB) cbmem_seabios_with_resource_allocation_top_down.txt (41.1 KB) dmesg_change_76199.txt (56.7 KB) cbmem_change_76199.txt (120 KB) cbmem.txt (116 KB) cbmem_top_down_n.txt (163 KB) dmesg_top_down_n.txt (58.2 KB) dmesg.txt (58.3 KB) cbmem.txt (166 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

2024-04-17 coreboot Leadership Meeting Canceled
by mina＠coreboot.org 15 Apr '24

15 Apr '24

Dear community, Kindly be informed that the coreboot leadership meeting scheduled for Wednesday, April 17, 2024, has been canceled. We apologize for any inconvenience this may cause and appreciate your understanding. Best Regards, Mina Asante

1 0

Found how to work some LEDs on P8Z77-M. Looking for implementation guidance.
by Keith Hui 15 Apr '24

15 Apr '24

What an eye opener. Yesterday I stumbled upon some boardviews for my board, and the pro variant. That could also let me sort out the pro's serial port without one actually on hand, but that's for another time. The power button have never blinked while in S3 like it's supposed to. I found that it is connected to GPIO27 on the PCH. I could adjust the PCH GPIO config to make it blink. What is the best approach if I want it to blink before entering S3, and stop it blinking after coming out of? Thanks Keith

2 1

Windows XP 0xA5 BSoD at IASL_VERSION Address
by Grayson Guarino 14 Apr '24

14 Apr '24

Greetings, I am not the most familiar with how Coreboot, SeaBIOS, BIOSes in general, and ACPI work, so forgive me if I am unclear. I am trying to install Windows XP SP3 on a Thinkpad T420 which has been upgraded with an Intel i7-3632QM. I am running Coreboot (commits c4e68f6080/09eb8d0c9b) and SeaBIOS (v1.16.3/commit d239552). I have listed two versions for both Coreboot and SeaBIOS because the former is a sensible recent build of both, while the latter is an attempt to build Coreboot with ACPI 1.0 support (and the latter SeaBIOS commit was chosen as it was made around the same time as the Coreboot commit). It seems like ACPI 1.0 backwards compatibility was dropped at commit be3979c, which could be incorrect. What I am noticing is that regardless of whether I use the newer or older Coreboot build, Windows XP's installer shows a blue screen of death with the following STOP code: [Newer build] STOP: 0x000000A5 (0x00000011, 0x00000008, 0xF794B280, 0x20230628) [Older build] STOP: 0x000000A5 (0x00000011, 0x00000008, 0xF794B280, 0x20200110) Parameter 4 for each of these STOP codes matches the date of the IASL version in both. Do you have any suggestions for how I can further attempt to debug this? I'm struggling to find the release where ACPI v1.0 compatibility was officially dropped, so if it is not 09eb8d0c9b, let me know and I will attempt to rebuild and flash again. Thank you, Grayson

4 5

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 12 Apr '24

12 Apr '24

Dear community, We are happy to announce that the next coreboot leadership meeting is scheduled for Wednesday, April 17, 2024. [1] Kindly take a moment to update the current agenda items with matters you wish to see addressed during the meeting. [2] Thank you for your continued commitment to the coreboot project. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

BIOS Flashing
by Orion Brewer 11 Apr '24

11 Apr '24

Is there a coreboot BIOS flash available for an unknown motherboard in a customized PC? The motherboard is more than 10 years old. If there is a coreboot BIOS flash for it, will it add secure boot and TPM 2.0? -- Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.

2 1

e1000e ULP issue
by Mr. Gadha 09 Apr '24

09 Apr '24

Using Maciej Pijanowski's m920q review, I was able to get coreboot booting on a Lenovo m720q. However, I get a strange error in Linux under coreboot. e1000e 0000:00:1f.6 0000:00:1f.6 (uninitialized): Failed to disable ULP There is also a potentially related ACPI complaint: ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - \_SB_.PCI0.IGBE (20230331/dspkginit-438) The gbe Ethernet controller is built in: 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V (rev 10) Several other existing boards seem also have I219 devices but I couldn’t find any special handling for this. I'm not familiar with ULP, but it seems the ME could turned it on. I still have the original ME and GBE sections in the flash. Has anyone seen this issue before? Or should I try to add coreboot code to disable ULP in the Ethernet PHY? (seems a bit strange). Thanks!

3 2

Invalid links on GitHub platform
by Ricky Tigg 08 Apr '24

08 Apr '24

Hello. At https://github.com/coreboot/coreboot, links https://review.coreboot.org/plugins/gitiles/coreboot/+/HEAD https://review.coreboot.org/coreboot.git are invalid. Regards.

2 1

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