coreboot

coreboot@coreboot.org

6 participants
39686 discussions

How to get reviews on gerrit? aka. patches ignored for three years.
by Daniel Gröber 05 Oct '23

05 Oct '23

Hi, could someone tell me how I'm supposed to deal with unresponsive reviewers on gerrit? Clearly I must be doing something wrong as the patches have been gathering dust for around three years now. https://review.coreboot.org/q/topic:%22macronix-spi-bp%22 --Daniel

6 11

2023-10-04 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 05 Oct '23

05 Oct '23

# 2023-10-04 - coreboot Leadership Meeting Minutes ## Attendees David Hendricks, Christian Walter, Daniel Maslowski, Felix Held, Jay Talbott, Julius Werner, Karthik Ramasubramanian, Martin Roth, Matt Devillier, Maximilian Brune, Mickey, Simon Glass, Tim Crawford, Werner Zeh, Wilhelmina Asante, Stefan Reinauer. ## Action Items - Martin: Write a tutorial for gerrrit. - OSFF: Look into making a video about using gerrit. - Martin: Write a documentation about vendorcode submodules. - Martin: Work with David to create a vendorcode submodule for intel. - Simon: Will send patches related to RFCv2 for post-build control of the serial console. > Fallback method > Add enums. ## Minutes: ### OSFC 2023 - California Bay-area in October - Next week! * Tickets are available at [https://osfc.io](https://osfc.io) ### sjg - RFCv2: Post-build control of serial console There’s been a lot of discussion about this on the mailing list, but not much contribution from anyone other than Simon and Martin. Are others ambivalent? * There have been complaints about people just doing things without consulting the community first, but this lack of comment makes it feel like that’s just complaining, and it doesn’t actually matter. * Simon will send patches. * Fallback method * Add enums ### Martinr] How do people feel about recording the coreboot leadership meeting and posting them on youtube or something so that others can watch them later? * Martin] I got one comment opposed to this idea because we sometimes discuss things of a more private nature that we don’t want to go into the minutes. If we record a video, these items can’t be private. * [FelixS] I don’t like that for that same reason either. Also, I fear that it becomes more comfortable to do discussions (or even decisions) at the meeting instead of on the mailing list where more people can participate. * Nobody is in favor of this. ### Martinr] Gmail has flattened the minutes to a list instead of maintaining indentation a couple of times. The coreboot blog does the same. What’s the best way to distribute the meeting minutes? * [PatrickG] won’t be there, so put it on here: markdown files in Documentation/? That keeps them for eternity, though… (but so do mailing list and blog posts) * [Martin] If we’re satisfied with just text formatting, we can just keep posting the minutes to the mailing list, it just seems like we could do something with better native formatting. * This makes it hard to have a dialog. * Mailing list should work even if the minutes are just text. * Look at attaching as markdown. * Look at modifying the way we’re taking minutes? * Use a different service - Use a markdown editor to take minutes? - Etherpad - Trippad - [https://codepen.io/](https://codepen.io/).(Online code editor) - [https://hackmd.io/](https://hackmd.io/). (Hackmd.io) - [https://hedgedoc.org/](https://hedgedoc.org/) (hedge) - [https://codi.hostile.education](https://codi.hostile.education) - [https://codepen.io/](https://codepen.io/).(Online code editor) - [https://hackmd.io/](https://hackmd.io/). (Hackmd.io) - [https://hedgedoc.org/](https://hedgedoc.org/) (hedge) - ( [https://codi.hostile.education](https://codi.hostile.education) is Daniel Maslowski's personal instance) * Something that formats the meeting minutes so they can be easily copy+pasted to the mailing list without ruining formatting. ### Martinr] Incentives for work. * In an email exchange Daniel Gröber mentioned that he feels like gerrit gives less incentive to do work as it isn’t seen as widely. Thoughts? * [https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/DPF… _I like to philosophize about incentives. So what incentives does a contributor have to get themselves added to that maintainers list?_ _The cynic in me says: none. It's just hard work nobody wants to do, but that doesn't explain the fact that there are in fact plenty of mostly-volunteer projects with a thriving development community._ _My current theory is, this happens when people see some kind of social reward for doing that hard work._ * One big issue is a lack of hardware. Most modern platforms are not hackable easily. * New platforms are mostly done by companies, so focus on community work? * How can we improve as a community? * Can we find a cheap board that can be ported? Make a class? * FelixS is working on this with the up-extreme - unfortunately a little bit expensive. Has everything that’s needed for development, and are very small. * Need documentation * Simon] Indexed approach to finding docs. * What infrastructure there is. * [Maximilian] Enhance online presence for blogs * Martin] I’m not sure if this is accurate, but I’m often wrong. We could do a number of things, like send merged patches to email, weekly lists of contributors to email, add contributors to release notes, or something similar. * Simon] Gerrit does make patches sort of invisible. * Maximilian] Not sure of the issue with gerrit. * DanielM: Maybe do some gerrit documentation. * Martin is willing to write up a tutorial. * Many people are used to github workflow, which is very different. Need to educate people. * Matt] In the dashboard it shows patches in order of activity - This is frustrating. Documentation could help - how to view patch trains. * FelixH] Multiple people confused about merge conflicts later in the patch train. * Werner] Make a webinar talk about using gerrit? * [FelixS] People could record a video and upload it on our youtube channel as a timeless alternative * Felixs] What can we link to? * https://review.coreboot.org/c/coreboot/+/76937 * Pretty much anything that people think would be useful. ### Martinr] Make vendor code submodules that the vendors are responsible for instead of having that code go directly into coreboot? * Embedded into the structure, not at the top vendor code level. * All submodules will have a copy of the code hosted by coreboot.org * Not forcing vendors to use submodules, but making them available. # Next meeting October 18th, 2023 * [Meeting link](https://meet.google.com/pyt-newq-rbb (https://meet.google.com/pyt-newq-rbb)) * [coreboot Calendar](https://coreboot.org/calendar.html (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 https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj... (https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…)

1 0

The GIT server on the downloads page is unreachable suddenly
by Gregg Levine 05 Oct '23

05 Oct '23

Hello! I just tried to retrieve a fresh set for the coreboot materials from the site and my WSL set complains that git clone https://review.coreboot.org/coreboot.git does not work because the server is itself unreachable. For example when trying to update an old install of the code on the server and I get this response: fatal: unable to access 'http://review.coreboot.org/p/coreboot/': Could not resolve host: review.coreboot.org ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

2 2

Alderlake-P DDR4 RVP Graphics Problem
by mahesh 05 Oct '23

05 Oct '23

Hi folks, using coreboot version : 4.21 I have an ADL-P DDR4 RVP and am using the Mrchromebox as a UEFI payload. *Method 1: * from the coreboot make menuconfig, under devices ->> Graphic Initialization -> Gop Driver Vbt ->> using the extracted Vbt file from the Stock BIOS with the above config, It boots without problem on the uart console and I can enter the BIOS menu. However, I cannot get HDMI display output like backlight & logo. I inspected the debug log and it says "*Graphics hand-off block not found*" *Method 2:* from the coreboot make menuconfig, under devices ->> Graphic Initialization -> none Vbt ->> using the extracted Vbt file from the Stock BIOS under payload->> IntelGopDriver.efi ( Got from the intel team) with the above config, It boots without problem on the uart console and I can enter the BIOS menu. However, I cannot get HDMI display output like backlight & logo. what should I do? what's the problem ? kindly please advise the solution of this issue.. Thanks in advance..

1 0

gerrit error: Identity in use by another account
by Daniel Gröber 04 Oct '23

04 Oct '23

Hi, Not sure who to poke about gerrit admin stuff. I'm trying to add my primary email address dxld(a)darkboxed.org to my gerrit account which is using a different email, but I'm getting this error: Error 422 (Unprocessable Entity): Identity 'mailto:dxld@darkboxed.org' in use by another account Endpoint: /config/server/email.confirm I suspect the offending account got auto-created as that's my git identity. The problem I'm trying to solve is that gerrit thinks my git ident and gerrit account are two distict people and it keeps adding myself as reviewer to my own patches (even if I remove that ident as reviewer). Thanks, --Daniel

2 2

coreboot Leadership Meeting for October 4, 2023
by coreboot org 02 Oct '23

02 Oct '23

Dear coreboot Community, We are pleased to announce the upcoming coreboot leadership meeting scheduled for October 4, 2023[1]. Please add things you wish to see addressed during the meeting to the agenda[2]. # Current Agenda Items * sjg - RFCv2: Post-build control of serial console * Martinr] How do people feel about recording the coreboot leadership meeting and posting them on youtube or something so that others can watch them later? * Martinr] Gmail has flattened the minutes to a list instead of maintaining indentation a couple of times. The coreboot blog does the same. What’s the best way to distribute the meeting minutes? [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

Qemu with persistent CMOS RAM (save / restore)
by Simon Glass 30 Sep '23

30 Sep '23

Hi, Is it possible to save and restore CMOS RAM with qemu, or some other emulator? I'd like it to be kept in a file on my system, so I can run coreboot multiple times and the CMOS RAM is preserved across runs. For example, if I make a change to a CMOS location, then I'd like that change to still be visible on the next run. Regards, Simon

1 0

RFC: Post-build control of serial console
by Simon Glass 29 Sep '23

29 Sep '23

Hi, RFC: Post-build control of serial console It is annoying to have to create and maintain two completely different builds of coreboot just to enable or disable the console. It would be much more convenient to have a 'silent' flag in the image, which can be updated as needed, without needing to rebuild coreboot. For example, if something goes wrong and coreboot hangs, it would be nice to be able to enable serial on the same image, then boot it again to see how far it gets. I propose a 'Coreboot Control Block' (CCB) which can hold a small number of such settings. It is designed to be available very early in bootblock, before CBFS is ready. It is able to control the output of the very first bootblock banner. early silicon-init, etc. It is built as part of the bootblock image, so can be accessed simply as a static C struct within the bootblock code. That means that the code overhead is very low and we could perhaps enable it by default. The bootblock can have a CBFS file attribute that indicates that it contains a CCB and the offset where it is stored. Other coreboot stages can read this as well, or it could be duplicated in a separate file. We can provide options in cbfstool to get and set settings in the CCB. This makes it easy to use this feature, e.g. to enable silent: cbfstool coreboot.rom ccb-set -n serial -V silent Why not use a separate CBFS file? - Boards typically read the entire bootblock and start execution from it. The console is started early so the settings are needed before CBFS is available. By putting the CCB inside the bootblock, it can control things from an early stage. Why not CMOS RAM / VVRAM? - If we allocate some space in CMOS for console / logging settings, then it would allow a similar feature. But it involves changing settings on the device. Each board would need to provide some CMOS options for this feature as part of the layout file. It would not be possible to enable console output without running some code on the device to update the CMOS RAM. Why not use Firmware Handoff to pass the CCB to following stages? - We could do that, particularly if CCB attracts some additional features, such as logging. Regards, Simon

3 5

google/brya/var/crota: selfboot jump reached after 1.2 s
by Paul Menzel 28 Sep '23

28 Sep '23

Dear Google Chromebook folks, I got a Dell Latitude 5340 Chromebook with coreboot-v1.9308_26_0.0.22-26491-g38c6637296 With hot MRC cache, ChromeOS login screen is reached after around six seconds, which is great. According to the firmware time stamps in `chrome://system`, coreboot takes 1.2 until starting depthcharge: 82 entries total: 990:CSME ROM started execution 0 944:CSE sent 'Boot Stall Done' to PMC 119,000 945:CSE started to handle ICC configuration 119,000 (0) 946:CSE sent 'Host BIOS Prep Done' to PMC 123,000 (4,000) 947:CSE received 'CPU Reset Done Ack sent' from PMC 307,000 (184,000) 0:1st timestamp 342,717 (35,717) So the Converged Security Engine alone takes 342 ms – as long as coreboot takes to execute on older systems. 11:start of bootblock 352,538 (9,821) 12:end of bootblock 358,690 (6,151) 501:starting to load verstage 358,693 (3) 502:finished loading verstage 359,785 (1,092) 5:start of verified boot 361,037 (1,252) 503:starting to initialize TPM 361,739 (701) 504:finished TPM initialization 450,095 (88,356) 88 ms is high, but I think common for TPM initialization. 505:starting to verify keyblock/preamble (RSA) 471,441 (21,345) 506:finished verifying keyblock/preamble (RSA) 476,234 (4,793) 507:starting to verify body (load+SHA2+RSA) 476,256 (22) 508:finished loading body 679,079 (202,822) Another 200 ms is spent here. 509:finished calculating body hash (SHA2) 686,553 (7,473) 510:finished verifying body signature (RSA) 688,054 (1,501) 511:starting TPM PCR extend 690,511 (2,456) 512:finished TPM PCR extend 719,107 (28,596) 513:starting locking TPM 719,107 (0) 514:finished locking TPM 733,290 (14,183) 6:end of verified boot 747,454 (14,163) 13:starting to load romstage 747,563 (108) 14:finished loading romstage 747,575 (12) 1:start of romstage 747,587 (12) 515:starting EC software sync 747,596 (8) 516:EC vboot hash ready 749,955 (2,359) 517:waiting for EC to allow higher power draw 753,883 (3,928) 518:finished EC software sync 755,385 (1,501) 948:starting CSE firmware sync 756,428 (1,043) 949:finished CSE firmware sync 759,141 (2,712) 970:loading FSP-M 760,597 (1,456) 2:before RAM initialization 760,603 (5) 950:calling FspMemoryInit 785,801 (25,198) 951:returning from FspMemoryInit 825,967 (40,165) 550:starting to load ChromeOS VPD 826,013 (45) 551:finished loading ChromeOS VPD (RO) 826,099 (86) 552:finished loading ChromeOS VPD (RW) 826,132 (32) 3:after RAM initialization 826,196 (64) 4:end of romstage 827,576 (1,379) 100:start of postcar 836,651 (9,074) 101:end of postcar 836,651 (0) 8:starting to load ramstage 836,655 (3) 15:starting LZMA decompress (ignore for x86) 836,701 (46) 16:finished LZMA decompress (ignore for x86) 866,740 (30,039) 9:finished loading ramstage 866,880 (139) 10:start of ramstage 866,929 (48) 17:starting LZ4 decompress (ignore for x86) 867,936 (1,006) 18:finished LZ4 decompress (ignore for x86) 907,401 (39,465) 30:device enumeration 913,217 (5,816) 971:loading FSP-S 923,807 (10,589) 954:calling FspSiliconInit 934,237 (10,430) 955:returning from FspSiliconInit 968,817 (34,579) 962:calling FspMultiPhaseSiInit 968,822 (5) 963:returning from FspMultiPhaseSiInit 1,146,574 (177,751) 177 ms are spent here in the FSP blob? 942:before sending EOP to ME 1,146,823 (248) 40:device configuration 1,149,840 (3,016) 50:device enable 1,162,440 (12,600) 60:device initialization 1,167,018 (4,578) 114:started elog init 1,168,482 (1,464) 115:finished elog init 1,170,862 (2,379) 15:starting LZMA decompress (ignore for x86) 1,174,928 (4,065) 16:finished LZMA decompress (ignore for x86) 1,175,208 (280) 70:device setup done 1,186,831 (11,622) 75:cbmem post 1,187,518 (686) 80:write tables 1,187,593 (75) 85:finalize chips 1,195,483 (7,889) 553:started TPM enable update 1,204,169 (8,685) 554:finished TPM enable update 1,223,291 (19,122) 90:starting to load payload 1,223,317 (26) 15:starting LZMA decompress (ignore for x86) 1,223,459 (141) 16:finished LZMA decompress (ignore for x86) 1,236,494 (13,035) 943:after sending EOP to ME 1,240,485 (3,990) 99:selfboot jump 1,240,607 (122) 1000:depthcharge start 1,248,752 (8,144) 1002:RO vboot init 1,249,204 (452) 1020:vboot select&load kernel 1,249,228 (23) 1040:finished storage device initialization 1,282,580 (33,352) 1050:finished reading kernel from disk 1,288,042 (5,461) 1100:finished vboot kernel verification 1,295,930 (7,887) 1101:jumping to kernel 1,314,111 (18,180) Total Time: 1,314,072 I thought ChromeOS requirement is to reach `selfboot jump` below (still quite high) one second. Or is the actually met by not counting from power-on but from 1st timestamp? Does somebody know, why the CSE takes so long? Is Intel aware of that and going to improve that? I think there was something similar in the past, where Duncan Laurie(?), experienced, that coreboot was faster than the ME initialization, and had to wait for the Intel ME to send the ready signal. I think Intel improved on that later on? Kind regards, Paul

2 1

CML v1 / v2 FSP
by Jonathon Hall 27 Sep '23

27 Sep '23

Hi all, As many of you probably know, Comet Lake v1/v2 have different FSP binaries, and hence separate Kconfigs `SOC_INTEL_COMETLAKE_1` and `..._2`. In short, the same SKU could be either depending on the stepping. We're getting new steppings in future batches of products, which will move them from CML v1 to CML v2. These aren't otherwise "new versions" of the product. It would simplify life for my customers if they had the same firmware image. From an initial look it seems reasonable to embed both FSPs and select at runtime using the CPUID as suggested by Intel: * The headers for both FSPs are equivalent (differ only in comments), so there should be no issue switching at runtime * The _1 / _2 Kconfigs are only used to select FSP headers/binary, nothing else * It'll cost some flash space, so separate _1 / _2 should continue to exist, but in my case that tradeoff is fine Has anyone looked into this in the past? Is there any other reason this is not a good idea? From my initial look, I would try: * Add another Comet Lake Kconfig, say `SOC_INTEL_COMETLAKE_1_2` (or `..._1_AND_2`, etc.) * Embed a second FSP - probably add an optional `FSP_FD_PATH_2` to the FSP 2.0 Kconfig, the `..._1_2` SoC Kconfig would then put its second FSP here * Add a second `FSP_M_CBFS`/`FSP_S_CBFS` (the names of the files in cbfs) * For `SOC_INTEL_COMETLAKE_1_2`, select the correct cbfs name based on CPUID. Those are only used in a few places, so the impact wouldn't be very large. Thanks, Jonathon

2 2

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