coreboot April 2023

coreboot@coreboot.org

31 participants
43 discussions

[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

Ciao
by lotecma＠proton.me 30 Apr '23

30 Apr '23

Hello everyone !!!!! Inviato con l'email sicura di [Proton Mail](https://proton.me/).

1 0

How open is Google CR50?
by Brian Milliron 29 Apr '23

29 Apr '23

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?

2 2

[Coreboot] Support Intel Ice Lake-D & AMD V3000 CPU
by Justin Lan/WIH/Wistron 26 Apr '23

26 Apr '23

Hi Coreboot, We want to use the Coreboot for promote our customer Intel Ice Lake-D & AMD V3000 CPU board, but I didn't find the Intel Ice Lake-D & AMD V3000 CPU define from release note or source, Could you help to tell me how to select Intel Ice Lake-D & AMD V3000 CPU? Best Regards, Justin Lan [cid:image001.jpg@01D9775A.35E5B9B0] WISTRON TECHNOLOGY CORPORATION l HsinChu Tel: +886-3-5770707 #32542 --------------------------------------------------------------------------------------------------------------------------------------------------------------- This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or distribution of this email or the content of this email is strictly prohibited. If you are not the intended recipient, you may reply to the sender and should delete this e-mail immediately. ---------------------------------------------------------------------------------------------------------------------------------------------------------------

2 1

flashrom reviewers gerrit group
by Anastasia Klimchuk 25 Apr '23

25 Apr '23

Good day coreboot community, We (flashrom) recently has changed the gerrit config for code reviews permissions. I am writing this email because the change impacts coreboot community. From now on, the gerrit group "flashrom reviewers" is set up to have permissions to approve patches in flashrom tree (vote -1..+2). Previously, in the absence of flashrom reviewers, the whole coreboot reviewers group could approve patches. Flashrom reviewers group is much smaller, and consists of developers who are currently active and take responsibility for some area(s) of flashrom tree. Specifically, all people in flashrom's MAINTAINERS file are in the reviewers group (see https://github.com/flashrom/flashrom/blob/master/MAINTAINERS). This means some coreboot reviewers who previously could +2 patches in flashrom tree, won't be able to do this anymore. If this is you: #1 If you don't care about flashrom patches, all good, nothing to do. #2 If you have active knowledge of flashrom code, have sent/reviewed flashrom patches before, and are ready to take responsibility for some area(s) of flashrom tree, this is amazing! Please say this aloud and we can try and translate this into an entry in flashrom MAINTAINERS file. #3 If you are somewhere in between #1 and #2: in any case, all gerrit users can do code reviews (vote -1..+1) and add comments on patches. And if you want to follow the path #2, you are very very welcome to start being more active on flashrom. Thank you for your attention! -- Anastasia.

1 0

Coreboot chat room
by Arne 24 Apr '23

24 Apr '23

Hi, I just created a XMPP chat room about coreboot on our public XMPP server and I would be happy to make it to an official coreboot chatroom. The server is running since 2,5 years and will stay online for at least the next years. Maybe you like to join. So the main question is, can I write in the chatroom description "official coreboot chatroom"? I would also offer the coreboot delevopers a free XMPP chat account on https://ocean.monocles.de/apps/registration/ or https://ocean.monocles.eu/apps/registration/ Thanks for your project and best regards, Arne

2 3

[coreboot - Bug #141] GRUB payload hangs in HP Elitebooks
by Riku Viitanen 22 Apr '23

22 Apr '23

Issue #141 has been updated by Riku Viitanen. File 0005-at-keyboard-timeout.patch added Encountered this while porting Libreboot to 2560p and 9470m. Added a 200 ms timeout in keyboard_controller_wait_until_ready, and everything works fine on both machines now. I'll be contacting upstream. Patch attached for anyone curious. ---------------------------------------- Bug #141: GRUB payload hangs in HP Elitebooks https://ticket.coreboot.org/issues/141#change-1485 * Author: Iru Cai * Status: New * Priority: Normal * Assignee: Iru Cai * Start date: 2017-09-19 ---------------------------------------- There may be some problem when initializing the keyboard controller, but SeaBIOS payload works fine. Using GRUB payload directly or chainload GRUB payload with SeaBIOS will both hang the system. I modified GRUB and find it hangs in set_scancodes(void), when calling the first write_mode. After ``grub_outb (mode, KEYBOARD_REG_DATA);``, the ``keyboard_controller_wait_until_ready()`` function goes to an infinite loop. ~~~ write_mode (int mode) { unsigned i; for (i = 0; i < GRUB_AT_TRIES; i++) { grub_uint8_t ack; keyboard_controller_wait_until_ready (); grub_outb (0xf0, KEYBOARD_REG_DATA); keyboard_controller_wait_until_ready (); grub_outb (mode, KEYBOARD_REG_DATA); keyboard_controller_wait_until_ready (); ack = wait_ack (); if (ack == GRUB_AT_NACK) continue; if (ack == GRUB_AT_ACK) break; return 0; } return (i != GRUB_AT_TRIES); } ~~~ ---Files-------------------------------- seabios.log (31.5 KB) 0005-at-keyboard-timeout.patch (1.09 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

Support Question: "overflow detected" error message on start up (boothole?)
by illuviadeoro＠tutanota.com 20 Apr '23

20 Apr '23

Please tell me who I should contact if the following support question should be directed elsewhere. I have a System 76 computer with coreboot installed. A fine print error message flashes that an "overflow" is detected and I think the file path has "grub" in it. Brief flash, can't see. Is this the boothole vulnerability? It is in the firmware or coreboot, not on a disk grub. I have multiple OS and the message appears independently of loading a particular hard disk, although I have Fedora with the community copr installed on my primary disk. Thanks!

2 1

Re: About device tree in Coreboot
by Martin Roth 20 Apr '23

20 Apr '23

Absolutely, please feel free to comment on it in google docs. Anyone with the URL can comment. If you want to help write it or make changes beyond just commenting, email me off-list for edit access. Martin Apr 20, 2023, 14:33 by maximilian.brune(a)9elements.com: > Maybe it make sense to review that in the google docs? Since its quite a bit of documentation it would probably be easier to review and/or edit it in google docs until publishing on gerrit. We can of course also review it afterwards in gerrit but for the big part its probably easier to do it in google docs via comments and stuff. Just a thought though. > > Max > > Am Do., 20. Apr. 2023 um 19:59 Uhr schrieb Martin Roth via coreboot <> coreboot(a)coreboot.org> >: > >> Here's some devicetree documentation I started working on, but never published. >> >> https://docs.google.com/document/d/1_pEbupbU9K638uvN1qVNvweP5dP4KuunHWq1NBf… >> >> Sorry for the google docs link. I'll see what still needs to be done and push it to documentation folder. >> >> Martin >> >> Apr 17, 2023, 02:29 by >> michal.zygowski(a)3mdeb.com>> : >> >> > Dear Sir or Madam, >> > >> > On 11.04.2023 04:41, Chiang.Gain 江有舜 TAO wrote: >> > >> >> Dear Sir >> >> >> >> >> >> >> >> This is Inventec BIOS team, we are trying to port Coreboot to our Server Board >> >> which is based on Intel CRB ArcherCity. >> >> >> >> We have to add “Devicetree.cb” files under mainboard folder, right ? >> >> >> > >> > That's correct. >> > >> >> >> >> >> >> >> >> We had read the following files but we are still confused and don’t know how to >> >> modify those files to match our design. >> >> >> >> >> >> >> >> Documentation/getting_started/devicetree.md >> >> >> >> Documentation/drivers/dt_entries.md >> >> >> >> >> >> >> >> We would like to know if there are any training materials or further Docs; >> >> particular to “syntax”. >> >> >> >> that we can refer to. >> >> >> > >> > AFAIK there is no training for devicetree in particular. The links above are >> > already quite detailed and I doubt there are better materials than those as of >> > today. I advise to base your devicetree on archercity crb: >> > >> https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/archer… >> > >> > In short how it works: >> > >> > For Sapphire Rapids platform the final devicetree is a merge of >> > >> https://github.com/coreboot/coreboot/blob/master/src/soc/intel/xeon_sp/spr/… >> > and the mainboard's devicetree (the one you trying to create). >> > >> > As the chipset.cb defines all the default devices all you need to do in >> > mainboard's devicetree is to define the board-specific configuration. Each >> > devicetree starts with a chip declaration which has to point to a directory in >> > coreboot source that contains a chip.h file. This chips declaration must be a >> > soc directory, in your case "chip soc/intel/xeon_sp/spr". Each declaration must >> > be closed with an "end" word. Inside the scope of the chip you may place the >> > same declarations as in chipset.cb, but set it to your desired values. E.g. if >> > your design does not use PCIe root port 12 and 13, you can define the following: >> > >> > chip soc/intel/xeon_sp/spr >> > device domain 0 on >> > device pci 1a.0 off end # Intel device 1bb4: PCH PCIe Root Port #12 >> > device pci 1b.0 off end # Intel device 1bb5: PCH PCIe Root Port #13 >> > end >> > end >> > >> > What is important is to keep the scopes intact. One may disable the device by >> > changing "on" to "off". if you would like to override the soc-specific >> > configuration, then you need to look at >> > >> https://github.com/coreboot/coreboot/blob/master/src/soc/intel/xeon_sp/spr/… >> > The entries in devicetree starting with "register" declaration means you want to >> > set a variable defined in chip.h for given chip/soc. And for example if you >> > would like to configure a board specific TCC activation offset (aka CPU >> > throttling thermal threshold), you would need to add the following: >> > >> > >> > chip soc/intel/xeon_sp/spr >> > >> > register "tcc_offset" = "10" >> > >> > device domain 0 on >> > device pci 1a.0 off end # Intel device 1bb4: PCH PCIe Root Port #12 >> > device pci 1b.0 off end # Intel device 1bb5: PCH PCIe Root Port #13 >> > end >> > end >> > >> > The offset is relative to TJmax and the threshold would be TJmax - tcc_offset. >> > >> > I could write a whole essay what you can do with devicetree. It is hard to >> > explain all possibilities in one mail, it would be great if you could be more >> > specific about the problems you have, given that you haven't given any info >> > about your hardware. The devicetree contents are specific to given board design >> > and they may even require implementing new drivers which have to be referenced >> > in the devicetree. Also it may be worth considering coreboot consulting >> > services: >> https://www.coreboot.org/consulting.html >> > This page: >> https://doc.coreboot.org/distributions.html >> > should also give you an overview who is doing coreboot work and ships coreboot >> > on their devices. >> > >> >> >> >> >> >> >> >> Any kind of helps are appreciated. >> >> >> >> >> >> >> >> Thanks >> >> >> >> >> >> >> >> Gain >> >> >> >> >> >> >> >> >> >> >> >> >> >> -------------------------------------------------------------------------------- >> >> >> >> *Confidentiality Note* >> >> 本郵件含有英業達股份有限公司機密資訊、或受法律保護之資料，唯有原發信人指定之收信 >> >> 人得閱讀或使用本郵件之內容。如您並非被指定之收信人，請立即將本郵件及所有附件予以 >> >> 刪除；請勿揭露、儲存或使用本郵件之任何資訊，並請您立即告知原發信人本郵件的傳遞錯 >> >> 誤。謝謝您的合作。 >> >> This e-mail transmission and any attachments contain information from Inventec >> >> Corporation. The information is confidential and/or privileged and intended to >> >> be solely for the use of the individuals or entities named in this e-mail >> >> transmission. If you are not the intended recipient, be aware that any >> >> disclosure, saving or use of the content of this e-mail transmission and >> >> attachments is strictly prohibited. If you have received this email transmission >> >> in error, please notify us immediately, and delete the e-mail and attachments. >> >> We greatly appreciate your cooperation. >> >> >> >> _______________________________________________ >> >> coreboot mailing list -- >> coreboot(a)coreboot.org >> >> To unsubscribe send an email to >> coreboot-leave(a)coreboot.org >> >> >> > >> > Best regards, >> > -- >> > Michał Żygowski >> > Firmware Engineer >> > GPG: 6B5BA214D21FCEB2 >> > >> https://3mdeb.com>> | @3mdeb_com >> > >> >> _______________________________________________ >> coreboot mailing list -- >> coreboot(a)coreboot.org >> To unsubscribe send an email to >> coreboot-leave(a)coreboot.org >>

1 0

[coreboot - Bug #440] superiotool tells you to run it as root and stops even when ran as root
by Nicholas Chin 20 Apr '23

20 Apr '23

Issue #440 has been updated by Nicholas Chin. I found this comment on this GitHub issue, which might explain the strange behaviour we are seeing: https://github.com/zamaudio/intelmetool/issues/20#issuecomment-751562837 > I got this error too, and tracked the issue down. > > iopl() returns an error EPERM (Operation not permitted) - even when invoked as root - if the kernel is in "lockdown mode". One of the things that lockdown mode does is disables userspace access to privileged I/O. > > You can check if you are in lockdown mode as follows: > > $ cat /sys/kernel/security/lockdown none [integrity] confidentiality > > Modern Linux distributions - such as Debian, in my case - will automatically enter lockdown mode (integrity) when the kernel is booted with EFI Secure Boot enabled. To fix the issue I simply disabled Secure Boot and restarted my machine. Could you check if your system is in lockdown mode and if you have secure boot enabled? ---------------------------------------- Bug #440: superiotool tells you to run it as root and stops even when ran as root https://ticket.coreboot.org/issues/440#change-1484 * Author: J Nky * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-11-24 * Affected versions: 4.15 * Affected OS: ubuntu 22.10 ---------------------------------------- On ubuntu 22.10: **sudo superiotool** iopl: Function not implemented Superiotool must be run as root. superiotool tells you to run it as root and stops even when ran as root -- 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 April 2023