coreboot May 2023

coreboot@coreboot.org

10 participants
28 discussions

[coreboot - Bug #484] (New) No keyboard with secondary payloads coreinfo, nvramcui, tint and probably others as well
by Robert Gruber 09 May '23

09 May '23

Issue #484 has been reported by Robert Gruber. ---------------------------------------- Bug #484: No keyboard with secondary payloads coreinfo, nvramcui, tint and probably others as well https://ticket.coreboot.org/issues/484 * Author: Robert Gruber * Status: New * Priority: Normal * Target version: none * Start date: 2023-04-26 * Affected versions: 4.15, 4.16, 4.17, 4.18, 4.19, master * Needs backport to: master * Affected hardware: X200, T500, X220, X230 and probably others as well ---------------------------------------- When coreboot was compiled with default parameters any secondary payload I tried (coreinfo, nvramcui, tint) does not recognize keyboard input. I found a simple workaround in libpayload until this behavior is fixed (please see attachment). Depending on used hardware I switch from ehci (X200, T500) to xhci (X220, X230) driver and vice verse. Both drivers (ehci and xhci) together obviously cause this problem. However, this is the default in libpayload configuration. ---Files-------------------------------- usb_ehci.sh (1.02 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 8

[coreboot - Bug #446] Optiplex 9010 No Post
by Martin Roth 08 May '23

08 May '23

Issue #446 has been updated by Martin Roth. Category set to board support Hi Aaron, any update on this bug? ---------------------------------------- Bug #446: Optiplex 9010 No Post https://ticket.coreboot.org/issues/446#change-1522 * Author: Aaron Burton * Status: New * Priority: Normal * Category: board support * Target version: 4.19 * Start date: 2023-01-09 ---------------------------------------- Working with an Optiplex 9010 SFF, configured and built coreboot as usual against the Optiplex 9010 SFF platform in menuconfig. Left every other setting alone in terms of configuration. Included EC firmware, ME, GBE, IFD blobs from stock firmware into my build. Turns on with fans at normal speed (not full blast), but no keyboard illumination or display output. Using SeaBIOS 1.16.1. Any suggestions as to what may be going on? Thanks. -- 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

[coreboot - Bug #445] (Closed) Thinkpad X200 wifi issue
by Martin Roth 08 May '23

08 May '23

Issue #445 has been updated by Martin Roth. Category set to board support Status changed from New to Closed Marking as resolved, but we should look at a better method of making sure the GPIOs for an individual platform have the flexibility to adjust the timing to meet any card's power-on spec. ---------------------------------------- Bug #445: Thinkpad X200 wifi issue https://ticket.coreboot.org/issues/445#change-1521 * Author: Masc Masc * Status: Closed * Priority: Normal * Category: board support * Target version: none * Start date: 2023-01-06 * Affected versions: 4.18 ---------------------------------------- Compiled coreboot latest revision from source and built a coreboot rom image for X200 with SeaBIOS (also tried with Grub as a payload). The laptop beeps and the power LED flashes at startup and the wifi card does not work (cannot enable wifi in OS). The operating system is Debian Bullseye and the wifi card is an Atheros AR5B95. The OS boots normally, but no wifi is available. The wifi card has been tested and works fine with latest stable libreboot release. ---Files-------------------------------- config (18.1 KB) cbmem.txt (42.4 KB) dmesg.txt (62.8 KB) lspci_nn_libreboot.txt (2.42 KB) lspci_tv_libreboot.txt (1.47 KB) lspci_vvvxx_libreboot.txt (31.1 KB) lspci_nn_coreboot.txt (2.42 KB) lspci_tv_coreboot.txt (1.48 KB) lspci_vvvxx_coreboot.txt (31.6 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

[coreboot - Bug #483] `make iasl` can't fetch R10_20_22.tar.gz since it stores it under a different name
by First name * Last name * 08 May '23

08 May '23

Issue #483 has been updated by First name * Last name *. Martin Roth wrote in #note-1: > I can't reproduce this issue. It downloaded the tarball fine for me. > > Downloading and verifying tarballs ... > * R10_20_22.tar.gz (downloading from https://github.com/acpica/acpica/archive/refs/tags/R10_20_22.tar.gz)... 0%... hash verified (560d9e43692e1957bcf24a9bdd663ffe77da88dd) > Downloaded tarballs ... ok > Unpacking and patching ... > * R10_20_22.tar.gz > o acpica-R10_20_22_iasl.patch > > Going to the ACPICA site on github shows that this is the correct URL: > https://github.com/acpica/acpica/tags > https://github.com/acpica/acpica/archive/refs/tags/R10_20_22.tar.gz > > Closing the issue as rejected. The problem is not about the URL, but about the name wget saves the archive under. buildgcc doesn't request a specific name from wget, but expects it to store the downloaded file at a specific name. Apparently you don't have `content-disposition = on` in your `/etc/wgetrc` so it happens to work for you. ---------------------------------------- Bug #483: `make iasl` can't fetch R10_20_22.tar.gz since it stores it under a different name https://ticket.coreboot.org/issues/483#change-1520 * Author: First name * Last name * * Status: Rejected * Priority: Normal * Target version: none * Start date: 2023-04-19 * Affected versions: master ---------------------------------------- ``` Downloading and verifying tarballs ... * R10_20_22.tar.gz (downloading from https://github.com/acpica/acpica/archive/refs/tags/R10_20_22.tar.gz)..... Failed to download R10_20_22.tar.gz. make[1]: *** [Makefile:24: build_iasl] Error 1 ``` ``` ‰ cat ./util/crossgcc/sum/R10_20_22.tar.gz.cksum 560d9e43692e1957bcf24a9bdd663ffe77da88dd tarballs/R10_20_22.tar.gz ‰ sha1sum util/crossgcc/tarballs/acpica-R10_20_22.tar.gz 560d9e43692e1957bcf24a9bdd663ffe77da88dd util/crossgcc/tarballs/acpica-R10_20_22.tar.gz ``` -- 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

[coreboot - Bug #480] (New) amd/common/acpi/gpio_bank_lib.asl: IASL remarks: Creation of named objects within a method is highly inefficient, use globals or method local variables instead
by Paul Menzel 08 May '23

08 May '23

Issue #480 has been reported by Paul Menzel. ---------------------------------------- Bug #480: amd/common/acpi/gpio_bank_lib.asl: IASL remarks: Creation of named objects within a method is highly inefficient, use globals or method local variables instead https://ticket.coreboot.org/issues/480 * Author: Paul Menzel * Status: New * Priority: Normal * Target version: none * Start date: 2023-04-10 * Affected versions: master ---------------------------------------- Building AMD boards using AMD common code like *google/kahlee (Careena)* or *google/myst*, IASL show the remarks below: ``` $ git log --oneline --no-decorate -1 f2e8865d76 soc/amd/common/blk/pcie: Program LTR max latencies $ make menuconfig […] $ make -j4 Intel ACPI Component Architecture ASL+ Optimizing Compiler/Disassembler version 20200925 Copyright (c) 2000 - 2020 Intel Corporation dsdt.asl 49: Name(BUFF, Buffer(Local0) {}) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.S2BF) dsdt.asl 117: OperationRegion (GPDW, SystemMemory, Local0, 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GPRD) dsdt.asl 126: OperationRegion (GPDW, SystemMemory, Local0, 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GPWR) dsdt.asl 134: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.STXS) dsdt.asl 143: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.CTXS) dsdt.asl 152: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GRXS) dsdt.asl 162: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4) Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GTXS) ASL Input: dsdt.asl - 33891 bytes 1278 keywords 901 source lines AML Output: dsdt.aml - 13412 bytes 909 opcodes 369 named objects Compilation successful. 0 Errors, 0 Warnings, 7 Remarks, 295 Optimizations, 46 Constants Folded IASL 3150 warning types were ignored! IASL build/dsdt.aml disassembled correctly. ``` Moved to common in [commit 251d305e73f7 (soc/amd/stoneyridge: Move GPIO support to common)](https://review.coreboot.org/c/coreboot/+/32651). -- 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 - Bug #483] (Rejected) `make iasl` can't fetch R10_20_22.tar.gz since it stores it under a different name
by Martin Roth 08 May '23

08 May '23

Issue #483 has been updated by Martin Roth. Status changed from New to Rejected I can't reproduce this issue. It downloaded the tarball fine for me. Downloading and verifying tarballs ... * R10_20_22.tar.gz (downloading from https://github.com/acpica/acpica/archive/refs/tags/R10_20_22.tar.gz)... 0%... hash verified (560d9e43692e1957bcf24a9bdd663ffe77da88dd) Downloaded tarballs ... ok Unpacking and patching ... * R10_20_22.tar.gz o acpica-R10_20_22_iasl.patch Going to the ACPICA site on github shows that this is the correct URL: https://github.com/acpica/acpica/tags https://github.com/acpica/acpica/archive/refs/tags/R10_20_22.tar.gz Closing the issue as rejected. ---------------------------------------- Bug #483: `make iasl` can't fetch R10_20_22.tar.gz since it stores it under a different name https://ticket.coreboot.org/issues/483#change-1518 * Author: First name * Last name * * Status: Rejected * Priority: Normal * Target version: none * Start date: 2023-04-19 * Affected versions: master ---------------------------------------- ``` Downloading and verifying tarballs ... * R10_20_22.tar.gz (downloading from https://github.com/acpica/acpica/archive/refs/tags/R10_20_22.tar.gz)..... Failed to download R10_20_22.tar.gz. make[1]: *** [Makefile:24: build_iasl] Error 1 ``` ``` ‰ cat ./util/crossgcc/sum/R10_20_22.tar.gz.cksum 560d9e43692e1957bcf24a9bdd663ffe77da88dd tarballs/R10_20_22.tar.gz ‰ sha1sum util/crossgcc/tarballs/acpica-R10_20_22.tar.gz 560d9e43692e1957bcf24a9bdd663ffe77da88dd util/crossgcc/tarballs/acpica-R10_20_22.tar.gz ``` -- 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

Re: How open is Google CR50?
by Andrey Pronin 08 May '23

08 May '23

> > > ---------- Forwarded message --------- > From: Brian Milliron via coreboot <coreboot(a)coreboot.org> > Date: Fri, Apr 28, 2023 at 4:52 PM > Subject: [coreboot] Re: How open is Google CR50? > To: ron minnich <rminnich(a)gmail.com> > CC: coreboot(a)coreboot.org <coreboot(a)coreboot.org> > > > Thanks. I'm not really looking to build my own custom hardware, just > evaluate what's already out there. I was hoping someone here would know if > this chip is fully open or not. > Hi Brian, I'm leading the h/w security (that includes cr50 firmware) team at ChromeOS and I had this message forwarded to me as I'm not on the coreboot mailing list. Not sure if there was more discussion since, but here are some top-level details re cr50/GSC openness. Let me know if you have further questions. - Google security chip is not an open hardware, the datasheet for it is not generally available. And you won't be able to run arbitrary code on it - it accepts only firmware signed with Google keys. - The bootloader firmware stage for Google security chip is not open source. - cr50 is the name of the main firmware stage that runs on the chip. cr50 implements the applications required for ChromeOS. It is open source on chromium.org. I also liked the suggestion earlier in the thread of looking at opentitan.org if you are interested in open hardware. > > > ------------------------------ > *From:* ron minnich <rminnich(a)gmail.com> > *Sent:* Friday, April 28, 2023 5:28 PM > *To:* Brian Milliron <Brian.Milliron(a)foresite.com> > *Cc:* coreboot(a)coreboot.org <coreboot(a)coreboot.org> > *Subject:* Re: [coreboot] How open is Google CR50? > > if you want the open source part, you want to go with opentitan.org, I > can put you in touch with folks if your company has interest. > > On Fri, Apr 28, 2023 at 2:52 PM Brian Milliron via coreboot < > coreboot(a)coreboot.org> wrote: > > I'm trying to decide if the Google Titan Security chip CR50 is trustworthy > or not. I see it has some open source, but I'm not certain if the whole > thing is open source or if there are some binary blobs included. Does > anyone here know? > > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org > -- Andrey

2 6

[coreboot - Project ideas #451] Fix POST code handling
by Alexander Goncharov 08 May '23

08 May '23

Issue #451 has been updated by Alexander Goncharov. File Fix_POST_code_handling_GSoC_Joursoir.pdf added Just in case, I attach my unselected GSoC project proposal on this topic ---------------------------------------- Project ideas #451: Fix POST code handling https://ticket.coreboot.org/issues/451#change-1514 * 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 ---Files-------------------------------- Fix_POST_code_handling_GSoC_Joursoir.pdf (102 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

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2023