coreboot

coreboot@coreboot.org

3 participants
39681 discussions

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 02 Aug '24

02 Aug '24

Dear community, Please note that our next coreboot leadership meeting is scheduled for Wednesday, August 7,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

Re: RW_MRC_CACHE always displays needs update and boot time is more
by Moorthi M.s 31 Jul '24

31 Jul '24

Hi Paul, > > Thanks for your reply. > > I figured out the issue. > > The ME CPU replayed option is printing as YES, and this forces the MRC > training on each reset. > > Updated the ME firmware, and the issue was solved. > > Regards, > Moorthi S > On Wed, Jul 31, 2024, 12:02 Paul Menzel <pmenzel(a)molgen.mpg.de> wrote: > >> Dear Moorthi, >> >> >> Welcome to coreboot. >> >> Am 31.07.24 um 07:45 schrieb Moorthi M.s: >> >> > I am developing coreboot (ver 4.17) along with UEFI payload for a custom >> > board derived from CFL H RVP11 CRB. >> > >> > I included the CACHE_MRC_SETTINGS to reduce the boot time on subsequent >> > power on. >> > >> > But the time was not reducing and on every power on, around 18 seconds >> are >> > taking between post code 0x92 (Ram Init) and 0x98 (Ram Init Exit). And >> > always prints as " MRC: cache data 'RW_MRC_CACHE' needs update". >> > >> > Because of this coreboot takes around 45 secs to boot. >> > >> > Why every time the MRC cache data is changing? Why the processor is not >> > using the MRC cached data? >> >> Without knowing the code you are using, nobody knows. Did you dump the >> cache data to compare? >> >> > Is there any other configurations needs to be done? >> Unfortunately, you did not provide enough information to answer your >> question. Please provide at least your configuration and the verbose >> logs. Best would be to upload your code (and the schematics). >> >> Also, why do you use coreboot 4.17? 24.05 is the latest release. >> >> >> Kind regards, >> >> Paul >> >> >> PS: Just to mention it, there are coreboot consultants [1], that might >> save you some time in the end. >> >> >> [1]: https://coreboot.org/consulting.html >> >

1 0

RW_MRC_CACHE always displays needs update and boot time is more
by Moorthi M.s 30 Jul '24

30 Jul '24

Hi, I am developing coreboot (ver 4.17) along with UEFI payload for a custom board derived from CFL H RVP11 CRB. I included the CACHE_MRC_SETTINGS to reduce the boot time on subsequent power on. But the time was not reducing and on every power on, around 18 seconds are taking between post code 0x92 (Ram Init) and 0x98 (Ram Init Exit). And always prints as " MRC: cache data 'RW_MRC_CACHE' needs update". Because of this coreboot takes around 45 secs to boot. Why everytime the MRC cache data is changing? Why the processor is not using the MRC cached data? Is there any other configurations needs to be done? Regards, Moorthi S

2 1

New extra-selectors mechanism on superiotool
by Maxim Polyakov 26 Jul '24

26 Jul '24

Hello community! I am adding support for f81866 and f81966 fintek chips in superiotool: https://review.coreboot.org/q/topic:%22fintek%22 However, there are some difficulties to make a dump of the registers of these chips. Their global LDN0 and HWM registers contain fields that switch the register banks of these devices. At the same time, these registers contain fields that should not change after they are configured. For example, <Port Select Register - Index 27h> register contains: BANK_PROG_SEL field[3-2] - Bank select for configuration registers (bank 0/1/2/3) and PORT_4E_EN[4] - 0: The configuration register port is 2E/2F. 1: The configuration register port is 4E/4F. I suggest introducing a new element in chip configuration for such registers - an extra selector: https://review.coreboot.org/c/coreboot/+/83196 It seems to me that this is the optimal solution. This allows superiotool to configure the register fields to select a bank before making a correct dump for the corresponding LDN in automatic mode. Please review. Thx // Regards, // Max

1 0

2024-07-24 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 25 Jul '24

25 Jul '24

# 2024-07-24 - coreboot Leadership Meeting ## Attendees Martin Roth, Felix Singer, Felix Held, David Hendricks, Marshall Dawson, Maximilian Brune, Lean Sheng Tan, Nico Huber, Matt DeVillier, Werner Zeh, Paule Panter, Ron Minnich, Julius Werner, Jason Glenesk, Mina Asante. ## 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 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-03-20 * Martin:To Add a note to the gerrit guidelines to email the leadership for further discussion and guidance when code submissions are not up to standard. * 2024-03-06 * Martin: To update gerrit contributing guidelines documentation. (https://doc.coreboot.org/contributing/index.html) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api] * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [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_/) ) * [Martin] I did a little work towards this a while back, looking at fixing chromeec by turning it from a submodule into something more like what we do for payloads. This would let different mainboards specify different versions. Unfortunately, this makes the CI very difficult, as one platform could check out a different version as another platform is building it. I’d suggest we just abandon chromeec from the build completely. Even Google never used it as a part of the coreboot build. * Julius mentioned that there was recently a discussion inside google about using the shared header. * Martin: The chromeEC submodule is huge and in my opinion we should just continue copying the single header file. * Decision: Drop ChromeEC submodule from coreboot. * [Max] regarding OpenSBI: The pain point is mostly src/arch/riscv/opensbi.c since it includes the sbi/fw-dynamic.h from the opensbi repo. I feel the pain since I have had trouble with it in the past too. There are 3 solutions I can think of. 1. We remove it and merge [https://review.coreboot.org/c/coreboot/+/83284] I will try to merge it anyway, since vendors tend to fork OpenSBI rather than upstreaming it. 2. We rewrite src/arch/riscv/opensbi.c to not include the opensbi header. Shouldn’t be too hard to add the structs and types that we need ourselfs. 3. We remove it and implement our own SBI implementation (very unlikely) * Ron (mostly) revived the SBI functionality from 10 years ago. The idea to remove the openSBI header is a good one. * Max - there are only a couple of structures we need. Will prepare a patch this week. ### [Elyes] 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? * [Max] As a side note: If we use C23 I would like to make use of some of its features in coreboot code in general. For example using the “#embed” for our unit tests and using a separation to write long memory addresses (e.g. write 0xFFFF_FFFF instead of 0xFFFFFFFF) * Julius: I’d advocate we don’t do this - this is something brought in from c++ to address things that aren’t generally applicable to coreboot. It’d be very intrusive. * Ron: Unless there’s some benefit that we don’t currently see, what’s the point? * Julius: There’s no objection to using C23 in general, but the nullptr_t type doesn’t gain us anything. Max++ * Decision: Not looking to pursue this currently. ### [Sheng] RFC for UPL support patch by Max *[https://review.coreboot.org/c/coreboot/+/76591] * Please review. * Matt: Some of the names could be improved. * Martin: Let’s put this discussion off until next week - I’ll make sure that it’s in the list of patches to review. * UPL Spec is in github - please contribute. * [https://universalpayload.github.io/spec] * U-boot support: [https://patchwork.ozlabs.org/project/uboot/list/?series=416058] * Edk2 as well. Linuxboot will follow after ### [Nico] Flashprog releases and HW support * Flashprog does regular releases now. Is it ok to announce them on the coreboot ML (about every 3~4 months)? Just checking if anybody has feelings against it… * Probably a little more delicate: What to do about stale "Flashrom support" lines in docs and board_info.txt where it's known broken? remove? replace w/ Flashprog? do nothing? * Martin: Let’s add a line for flashprog support. If flashrom is broken on a platform mark it as no. * David: Do we want to create a CSV list for flash programs instead of separated lines? * Martin: this seems reasonable to me. * Nico: We’d need to update the various scripts to generate the website and lint the file. Nico can take a look at this. * Matt: Sure, we can even add non-open firmware flash packages. # Next Leadership Meeting * August 7,2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting. # coreboot leadership meeting minutes [2024-07-24](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1…

1 0

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

← Newer
1
...
5
6
7
8
9
10
11
...
3969
Older →

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