coreboot

coreboot@coreboot.org

25 participants
39547 discussions

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

26 Apr '24

Dear coreboot community, We are happy to announce that our upcoming coreboot leadership meeting is scheduled for Wednesday, May 1, 2024. [1] Kindly take a moment to review and 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

question about CFLAGS custom
by Yoshinoya 26 Apr '24

26 Apr '24

Hi, I am studying coreboot source code. I have a question about how to costom CFLGAS. There is a Makefile.inc in the root of source code. I found some CFLAGS_common definition. Could i change CFLAGS setting in this file? And this changes could take effects in the whole coreboot module compile time? Thanks

1 0

[coreboot - Bug #536] (New) Cannot build coreboot-sdk
by Michał Żygowski 25 Apr '24

25 Apr '24

Issue #536 has been reported by Michał Żygowski. ---------------------------------------- Bug #536: Cannot build coreboot-sdk https://ticket.coreboot.org/issues/536 * Author: Michał Żygowski * Status: New * Priority: Normal * Assignee: Martin Roth * Target version: none * Start date: 2024-04-24 ---------------------------------------- I have just tried building coreboot-sdk from scratch and could not get past the step of installing the required packages. Found out that diffutils dependency on libcurl4t64 break libcurl4 (change apt-get to apt to see verbose information message like below): ``` shell > [coreboot-sdk 2/4] RUN useradd -p locked -m coreboot && apt-get -qq update && apt -qqy install --no-install-recommends bash-completion bc bison bsdextrautils bzip2 ca-certificates ccache cmake cscope curl device-tree-compiler dh-autoreconf diffutils exuberant-ctags flex g++ gawk gcc git gnat-13 golang graphicsmagick-imagemagick-compat graphviz lcov less libcapture-tiny-perl libcrypto++-dev libcurl4 libcurl4-openssl-dev libdatetime-perl libelf-dev libfreetype-dev libftdi1-dev libglib2.0-dev libgmp-dev libgpiod-dev libjaylink-dev liblzma-dev libnss3-dev libncurses-dev libpci-dev libreadline-dev libssl-dev libtimedate-perl libusb-1.0-0-dev libxml2-dev libyaml-dev m4 make meson msitools neovim ninja-build openssh-client openssl parted patch pbzip2 pkg-config python3 python-is-python3 qemu-system-arm qemu-system-misc qemu-system-ppc qemu-system-x86 rsync sharutils shellcheck unifont unzip uuid-dev vim-common wget xz-utils zlib1g-dev && apt-get clean: 2.106 2.106 WARNING: apt does not have a stable CLI interface. Use with caution in scripts. 2.106 2.841 diffutils is already the newest version (1:3.10-1). 2.841 diffutils set to manually installed. 2.841 Some packages could not be installed. This may mean that you have 2.841 requested an impossible situation or if you are using the unstable 2.841 distribution that some required packages have not yet been created 2.841 or been moved out of Incoming. 2.841 The following information may help to resolve the situation: 2.841 2.841 Unsatisfied dependencies: 3.001 libcurl4t64 : Breaks: libcurl4 (< 8.7.1-3) 3.004 Error: Unable to correct problems, you have held broken packages. ``` Changing libcurl4 to libcurl4t64 allows the docker to continue the build process of coreboot-sdk. But is this the right thing to do? -- 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 5

[coreboot - Bug #535] (New) T420: Power light stays off after reboot
by frantic from xboot 24 Apr '24

24 Apr '24

Issue #535 has been reported by frantic from xboot. ---------------------------------------- Bug #535: T420: Power light stays off after reboot https://ticket.coreboot.org/issues/535 * Author: frantic from xboot * Status: New * Priority: Low * Target version: master * Start date: 2024-04-24 * Affected hardware: Lenovo ThinkPad T420 ---------------------------------------- I have recently encountered a bug in coreboot where if you reboot the computer, the keyboard power light will stay turned off after it turns back on. Where if you do a clean boot, the light turns on. I am unsure whether this is a coreboot or payload issue. I am using GRUB as my payload. Just run the `reboot` command in Linux and it should be reproducible. Priority set to `Low` as it doesn't affect usability all too much. -- 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 1

[coreboot - Feature #433] (New) Unify TPM drivers in coreboot
by Michał Żygowski 24 Apr '24

24 Apr '24

Issue #433 has been reported by Michał Żygowski. ---------------------------------------- Feature #433: Unify TPM drivers in coreboot https://ticket.coreboot.org/issues/433 * Author: Michał Żygowski * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-24 ---------------------------------------- Add an option to compile all drivers for TPM 1.2, 2.0 TIS and CRB. The motivation is to not build multiple coreboot ROMs for each possible TPM supported by the platform. The tasks would include: - runtime TPM detection (probing TPM_INTF_CAPABILITY and TPM_INTERFACE_ID) - rename the TPM driver functions, make them static and expose them as a driver structure, e.g. struct tpm_driver { void (*init)(void); int (*open)(void); int (*close)(void); int (*sendrecv)(const uint8_t *sendbuf, size_t send_size, uint8_t *recvbuf, size_t *recv_len); } - based on the detected TPM, hook the tpm_driver functions to provide the global TPM API: tis_open, tis_close, tis_init, tis_sendrecv. Some additional API to get vendor/device name could also be considered. -- 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

4 6

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

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