coreboot July 2024

coreboot@coreboot.org

18 participants
20 discussions

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 22 Jul '24

22 Jul '24

Dear coreboot community, Please be reminded that our upcoming leadership meeting is scheduled for Wednesday, July 24,2024.[1] You are encouraged to review the current agenda and share your thoughts or suggest issues you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda Items ### [Elyes] * [Submodules] chromeec and opensbi are a pain (#83466 and #83464 ) Not only they have not been updated for more than two years, they can block future improvements (as testing & prepare for C23 see [https://qa.coreboot.org/job/coreboot-toolchain/1646/testReport/junit/(root)… CV_RV64_/] * [prepare for experimental and incomplete C23] If we opt to test and prepare for C23, and if we have to choose one functionality, would it be the use of nullptr constante and nullptr_t type ? (N3042) see [https://review.coreboot.org/c/coreboot/+/83459/8] Is that the right way? * One more question: If you have to choose only one “thing” that would improve the coreboot code (ISO C11 / 17) what would it be? ## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing * OSFC will be in Bochum Germany - September 3-5, 2024 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://www.coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 19 Jul '24

19 Jul '24

Dear community, Please note that our next coreboot leadership meeting is scheduled for Wednesday, July 24,2024.[1] Kindly update the current agenda with matters you wish to see dicussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

[ANNOUNCE] Go utility *hda-decoder*
by Paul Menzel 15 Jul '24

15 Jul '24

Dear coreboot and Linux folks, The utility *hda-decoder* written by Nicholas Sudsgaard was just submitted to the coreboot repository [1][2]. > util: Add hda-decoder > > This tool helps take off the burden of manually decoding default > configuration registers. Using decoded values can make code more > self-documenting compared to shrouding it with magic numbers. > > This is also written as a module which allows easy integration with > other tools written in Go (e.g. autoport). Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/80470 [2]: https://review.coreboot.org/plugins/gitiles/coreboot/+/b205f4e53ec30487ea1c…

1 0

Announcement: Official V0.9.1 Release for Universal Payload Sepcification
by Lean Sheng Tan 13 Jul '24

13 Jul '24

Hi everyone, After 2 years of endless discussions and relentless effort, we officially landed the V0.9 (and V0.9.1) of *Universal Payload Specification (UPL)* yesterday!!! V0.9 formally introduces using Device Trees as the standardized Payload Handoff Format to pass data from Platform Init (e.g. coreboot) to Payload (e.g. UEFI payload or LinuxBoot). This reduces the data handoff friction and proprietary handoff formats currently exist in each and every firmware project (e.g. HOB, coreboot table). A brief historical background: Universal Payload started as a sub-project under Intel's Universal Scalable Firmware Initiative. Since its introduction, Intel has been actively seeking for the firmware community's input to help make it a reality, to help standardise a common architecture and interfaces between Platform Init and Payload. Later on, 9elements actively collaborated with Intel to work with all major firmware projects (coreboot, U-Boot, edk2, Linuxboot) with the support of all architecture (x86, Arm, RISC-V). We have been actively promoting and collecting feedback in every means we could (mailing lists, OSFC, OCP Global Summit, COSCUP). I could not find words to summarize the 2 years tireless efforts made by all the UPL contributors: with about *2-4 meetings per month since May 2022*; countless back and forth discussion and some compromises made in between to find common ground that fits all Firmware solutions and projects; some technical setbacks with failed POCs and then persistent testings on coding sites; new expectations and issues pop up now and there that setback the initial timeline again and again... I owe all of them my greatest gratitude for their hard work. I would like to specially thanks *Vincent Zimmer* from Intel for making this happen in the first place - early commitment from *ARM*, Intel/ edk2 / Slimbootloaders maintainers, *Chasel Chiu* and *Dong Guo*, *Maximilian Brune* and *Arther Heymans* from coreboot, *Dhaval Sharma* and *Aaron Durbin* from Rivos, and *Simon Glass* & *Ron Minnich* who are both great visionaries in the Open Firmware world. In short, this is truly the first ever community effort that brings all firmware communities to collaborate together, in the very common goal to make Open Source Firmware a better place for everyone. For sure, this cannot and never will please everyone, and like all things there are always many issues in the first revision. Hence, I sincerely pledge to all of you, to help and contribute to this spec. This is an open invitation, as we follow the ethos of "*For Community, By Community*", the first open source spec that is owned by all the open firmware communities. Please refer here for the latest spec: *universalpayload.github.io/spec <http://universalpayload.github.io/spec>* Feel free to contribute here: *https://github.com/UniversalPayload/spec <https://github.com/UniversalPayload/spec>* WIP coreboot patch: *https://review.coreboot.org/c/coreboot/+/76591 <https://review.coreboot.org/c/coreboot/+/76591>* Last but not least, I also wanted to specially thank 9elements Cyber Security for all the support since the very beginning that helps me to navigate through all the hurdles and issues for the past 2 years. Let's continue to work together for a better Open Source Firmware for everyone. Thanks, Sheng

2 1

VxWorks 7 rebooting with UEFI payload
by Moorthi M.s 10 Jul '24

10 Jul '24

Hi, I am developing coreboot along with UEFI payload for a custom board derived from CFL H RVP11 CRB. Modifications are done as per the custom board and board was booted to CentOS and Windows. When we try to boot VxWorks 7 with native UEFI loader, the board was rebooting. But the same UEFI loader and VxWorks image is booting with BIOS version of the same custom board. Is there any modification need to be done to boot VxWorks 7? Thanks & best regards, Moorthi S

1 0

2024-07-10 - coreboot Leadership Meeting Canceled
by mina＠coreboot.org 09 Jul '24

09 Jul '24

Dear community, Please note that tomorrow's coreboot leadership meeting has been canceled because there are no items on the agenda to discuss. Thank you. Best regards, Mina.

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 08 Jul '24

08 Jul '24

Dear coreboot community, At the moment, there are no topics listed on the agenda for the leadership meeting this Wednesday. If there are no additions by the end of the day tomorrow, the meeting would have to be cancelled. If you have any topics you would like to discuss, kindly add them to the agenda items.[1] Thank you. Best regards, Mina. [1](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

Enforcing coreboot as lowercase
by Arthur Heymans 07 Jul '24

07 Jul '24

Hi The coreboot trademark is registered as lowercase. We enforce this in for instance commits, even when normal grammar would dictate uppercase at the start of a sentence. This makes sense for very well known brands, companies and products like "eBay", "iPhone", "AMD". They are all very well known trademarks and they have some uppercase letter in them in atypical places. For these words grammar exceptions seems reasonable. Coreboot is a reasonably well known as a project, but little people know about the specificity of the trademark. This often causes confusion on people either reading "coreboot" at the start of a sense, where it looks grammatically wrong, making it even look unprofessional in the eyes of some. This is because there is no other uppercase letter inside coreboot that would make it a typical exception to regular grammar rules. People getting into the project making the mistake at the start of a sentence, might get the wrong impression of too many idiosyncrasies. On top of that it takes a non zero amount of effort on people in the project to educate others on this trademark thing. Also trademark are typically a bit more broad than exactly how they are registered. I cannot start a company called iNTel or aMD that makes chips. I cannot put a product on the market called "IPHoNE". I think the same applies to "coreboot". So my question is: can we relax the trademark in lowercase enforcement? I would suggest to simply allow both ways. Arthur Heymans

7 8

Question about DISB handling in memory init
by Joursoir 06 Jul '24

06 Jul '24

Hello there, I have been studying the memory initialization process on the Alder Lake platform, like what's going on before and after utilizing FSP-M binary. And while I was studying sources I stumbled upon the following function (src/soc/intel/alderlake/pmutil.c): ``` /* Set the DISB after DRAM init */ void pmc_set_disb(void); ``` It's actually defined in every Intel SoC header and contains SoC-specific implementation. The comment and name function assert that func sets the DISB bit. And yes, it does it. However, I opened Intel 600 Series Chipset Family for IoT Edge Platform Controller Hub (PCH) Datasheet, Volume 2 (dated October 2022, Revision 001) and it asserts the opposite: ``` DRAM Initialization Scratchpad Bit (DISB): <skipped text>. BIOS is expected to set this bit prior to starting the DRAM initialization sequence and to clear this bit after completing the DRAM initialization sequence. BIOS can detect that a DRAM initialization sequence was interrupted by a reset by reading this bit during the boot sequence. If the bit is 1, then the DRAM initialization was interrupted. ``` So it suggests *clearing* the bit after DRAM init. Why does coreboot do the opposite? I was trying to study git history to find out, but it didn't give me any answer to my question as well. So maybe somebody on the mailing list knows more about it? Is it a typo in the Intel docs? -- Joursoir

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 05 Jul '24

05 Jul '24

Dear community, Please note that our next coreboot leadership meeting is scheduled for Wednesday, July 10,2024.[1] Kindly update the current agenda with matters you wish to see dicussed during the meeting[2] Thank you. Best regards, Mina Asante. [1](https://www.coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

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 July 2024