Issue #478 has been reported by Robert Gruber.
----------------------------------------
Bug #478: X200 booting takes a long time
https://ticket.coreboot.org/issues/478
* Author: Robert Gruber
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-04-04
* Affected versions: 4.15, 4.16, 4.17, 4.18, 4.19, master
* Needs backport to: master
----------------------------------------
dmesg: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
After a period of time the boot finished by auto-switching to hpet. Setting kernel parameter directly to clocksource=hpet the system is booting fast.
Why is the faster clocksource tsc not working and tells coreboot is broken ?
--
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
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
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
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
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
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
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/tagshttps://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
>
>
> ---------- 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
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