coreboot

coreboot@coreboot.org

17 participants
39654 discussions

[coreboot - Bug #444] Flaky gitconfig tests are breaking builds
by Martin Roth 17 Nov '23

17 Nov '23

Issue #444 has been updated by Martin Roth. Category set to build system ---------------------------------------- Bug #444: Flaky gitconfig tests are breaking builds https://ticket.coreboot.org/issues/444#change-1699 * Author: Martin Roth * Status: New * Priority: Normal * Category: build system * Target version: none * Start date: 2022-12-20 ---------------------------------------- The gitconfig tests are failing when they can't delete a directory they created in /tmp, and this is causing builds to fail randomly. Because it's not a part of the test itself, but part of the cleanup, the failure doesn't get captured, and jenkins appears to be failing for no good reason. Someone should figure out what's causing the rm -rf to fail and fix it so that the builders stop failing. -- 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

[coreboot - Bug #475] (New) mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c does not work as intended
by Bill XIE 17 Nov '23

17 Nov '23

Issue #475 has been reported by Bill XIE. ---------------------------------------- Bug #475: mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c does not work as intended https://ticket.coreboot.org/issues/475 * Author: Bill XIE * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: master * Start date: 2023-03-30 * Affected versions: 4.15, 4.16, 4.17, 4.18, 4.19, master * Affected hardware: x200 ---------------------------------------- Date back to coreboot 4.9, mainboard_vbt_filename() in src/mainboard/lenovo/x200/blc.c calls get_blc_pwm_freq_value(NULL), making the following if condition always falling to the first, not to mention null dereference on strcmp() in get_blc_pwm_freq_value(). In order to determine the correct vbt filename at runtime, edid ascii string should be obtained first. This issue may be distantly related to #474. -- 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 4

[coreboot - Support #485] (New) Request for Support for Intel Xeon 1700 D Processor Family in Coreboot(Ice Lake)
by Rajat Dongre 17 Nov '23

17 Nov '23

Issue #485 has been reported by Rajat Dongre. ---------------------------------------- Support #485: Request for Support for Intel Xeon 1700 D Processor Family in Coreboot(Ice Lake) https://ticket.coreboot.org/issues/485 * Author: Rajat Dongre * Status: New * Priority: Immediate * Assignee: Rajat Dongre * Target version: none * Start date: 2023-04-27 ---------------------------------------- Hi, I am writing this email to request support for the Intel Xeon 1700 D processor family (Ice Lake) in Coreboot. As you may be aware, the support for the IceLake SOC has been removed, and I am using a processor from the same family. I would appreciate any help or guidance on how to bring up my processor using Coreboot. I have been using Coreboot for some time and am familiar with its functionalities, but I am facing difficulties with the processor mentioned above. and Can I used to older version of coreboot where you give support for the Ice lake but the Intel Xeon 1700 D processor family launch in Dec 2022. so I have doubt I will work for this SOC as the Icelake is not updated from last 4 years in coreboot. I would be grateful if you could provide any relevant documentation, code, or instructions to help me with my request. I believe that my request will not only benefit me but also other members of the community who are facing similar challenges. Thank you for your time and consideration, and I look forward to hearing from you soon. -- 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

5 6

[coreboot - Other #479] (New) [legal] ISC License copyright violation in ubsan
by Jonas Termansen 17 Nov '23

17 Nov '23

Issue #479 has been reported by Jonas Termansen. ---------------------------------------- Other #479: [legal] ISC License copyright violation in ubsan https://ticket.coreboot.org/issues/479 * Author: Jonas Termansen * Status: New * Priority: Normal * Target version: none * Start date: 2023-04-09 ---------------------------------------- Hi :) coreboot has removed my copyright statement from the ubsan implementation, which violates my copyright as licensed to you under the terms of the ISC License: ``` * Copyright (c) 2014, 2015 Jonas 'Sortie' Termansen. * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * ... ``` The file in question is: https://github.com/coreboot/coreboot/blob/master/src/lib/ubsan.c The file does clearly state it's forked from my original ubsan implementation: https://gitlab.com/sortix/sortix/-/blob/master/libc/ubsan/ubsan.c However, the coreboot copy has removed my copyright notice, which is one of only two terms of the license. It's fine that the permission notice has been changed to `SPDX-License-Identifier: ISC` which is unambiguously information preserving, but removing my copyright notice is a loss of information. The copyright notice was removed in https://github.com/coreboot/coreboot/commit/16849bbe0c8a79277e1a682dcb42eaf… which moved my name to AUTHORS. Although a mention in AUTHORS is appreciated, it removes the association between the file's contents and my identity and my moral rights to my work. Although the full information is available in the git history, that's not good enough. I'm concerned that further copies of the file in other projects may lose the authorship information entirely. Please restore my copyright notice at the top of the file :) Jonas 'Sortie' Termansen -- 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 4

[coreboot - Bug #500] (New) libgfxinit bootsplash only supports jpeg and does not support extended resolutions
by Thierry Laurion 17 Nov '23

17 Nov '23

Issue #500 has been reported by Thierry Laurion. ---------------------------------------- Bug #500: libgfxinit bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500 * Author: Thierry Laurion * Status: New * Priority: Normal * Assignee: Patrick Georgi * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * Related links: https://github.com/coreboot/coreboot/blob/master/src/lib/jpeg.c https://git.seabios.org/seabios.git/ https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad… WiP PoC: https://github.com/osresearch/heads/pull/1403 * Affected hardware: iGPU driven by libgfxinit * Affected OS: All ---------------------------------------- For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAt… Short version: - libgfxinit bootsplash through jpeg.c supports VESA old resolutions (1024x768) - libgfxinit bootsplash through jpeg.c doesn't support native resolutions (1366x768) - libgfxinit bootsplash image creation requires voodoo skills explained at https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017 - Basically, I do not think libgfxinit bootsplash is currently used otherwise there would be way more bug reports. Seabios is mostly used. - Seabios bootsplash code should be borrowed (lgplv3) which supports both BMP and JPEG and is not 13yo. - Coreboot should permit stiching of compressed bmp by default and deprecate old jpeg.c in tree - By doing so, more people could promote coreboot directly from coreboot raminit (Heads currently does that) Longer version: - OSes are attacking legacy BIOS mode for a while now, and the next steps are to deprecate DRM drivers in initrd - To phase DRM out, simplefb and simpledrm are promoted instead where final OS will be in charge of deploying bigger unified kernels containing/initrd which will contain the accelerated DRM and fb drivers - Currently deploying DRM drivers inside of linuxboot (heads) on Intel iGPU requires to include i915drmfb, coreboot linux command lines hacks to have the FB address exposed (tainting the kernel) and kexec hacked to expose exposed fb address to next kernel (see https://github.com/osresearch/heads/pull/1378) - Doing currently adds more then 500kb of in-kernel drivers, which bloats the firmware. In case of measured boot, that bigger payload needs to be measured prior of being read and jumped into (8-10 seconds under 5.10 kernel compared to 4-6 seconds under 4.14) - To have legacy BIOS survive this ecosystem attack against legacy boot, coreboot needs to push for a more generic way to provide a framebuffer (GOP/Native unified approach) - With libgfxinit/GOP/native gfx init and the kernel config adapted, linux can efficiently be used as a bootloader and be enabled by simplefb (https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad…) - The part missing is having coreboot drive the framebuffer with a native size bootsplash as everyone else does so that the waiting time to boot in kernel/payload is not a scary moment, and that the bootsplash doesn't restrict the size of the framebuffer configured under coreboot nor limit the UX. Actual state: - libgfxinit needs to have jpeg supported resolution to bootsplash (CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024) - libgfxinit bootsplash needs to have a 1024x768 voodoo crafted jpeg (https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-…) - Problem is that doing so, the whole console is limited to that resolution showing black borders on each side of the screen to compensate (1366 != 1024, so (1366-1024)/2 is the loss pixel width on each side of the screen for 1366x764, same applying to all other resolutions since needs to be 4x4 for jpeg.c to do its job. Desired state: - flat bmp support in native format just like seabios support, where coreboot compressed them prior of adding it into CBFS. - support for all crazy resolutions we currently have, not being stuck in 2000. - Be able to promote coreboot from raminit code. ---Files-------------------------------- signal-2023-07-13-164022.jpeg (269 KB) signal-2023-07-13-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) -- 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

4 10

[coreboot - Bug #511] (Needs Testing) [STM/PE][BUG][SMMSTORE] Coreboot doesn't boot if SMMSTOREv2 driver Kconfig option is enabled
by Elias Souza 17 Nov '23

17 Nov '23

Issue #511 has been reported by Elias Souza. ---------------------------------------- Bug #511: [STM/PE][BUG][SMMSTORE] Coreboot doesn't boot if SMMSTOREv2 driver Kconfig option is enabled https://ticket.coreboot.org/issues/511 * Author: Elias Souza * Status: Needs Testing * Priority: High * Category: coreboot common code * Target version: 4.21 * Start date: 2023-10-09 * Affected hardware: is necessary testing in newest hardwares include Haswell and Kaby Lake, but idk if affect other platforms different than Sandybridge * Affected OS: All ---------------------------------------- For some reason the SMMSTOREv2 looks to break SMMSTORE support in STM/PE during boot. Coreboot: 4.21 HARDWARE: Gigabyte H61M-DS2 with Ivybridge processor Payload: EDK2 SMMSTORE: SMMSTOREv2 A example with other guy using https://www.reddit.com/r/coreboot/comments/10rakni/comment/k444jz1/?context… * According with the reddit user crazyfox-ua " The same for me on T440p & X230t (both with edk2) - just blank screen. Disabled STM brings both laptops back to life. CB logs says nothing strange IMO (last record is "[DEBUG] Jumping to boot code at <hex here>". Is necessary to test if others payloads is affected by this bug -- 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

5 11

[coreboot - Bug #512] (Needs Testing) 1MiB heap breaks TSEG stage cache resume on many platforms
by Bill XIE 17 Nov '23

17 Nov '23

Issue #512 has been reported by Bill XIE. ---------------------------------------- Bug #512: 1MiB heap breaks TSEG stage cache resume on many platforms https://ticket.coreboot.org/issues/512 * Author: Bill XIE * Status: Needs Testing * Priority: High * Assignee: Patrick Georgi * Category: coreboot common code * Target version: master * Start date: 2023-10-27 * Affected versions: master * Related links: https://review.coreboot.org/c/coreboot/+/78270 https://review.coreboot.org/c/coreboot/+/78623 * Affected hardware: GM45, Ivy Bridge * Affected OS: GNU/Linux ---------------------------------------- commit 44a48ce7a46c ("Kconfig: Bring HEAP_SIZE to a common, large value") proves to break S3 resume from TSEG stage cache on many platforms, including GM45 and Ivy Bridge. ``` coreboot-4.21-587-g9b230ae29557 Fri Oct 13 18:35:11 UTC 2023 x86_32 postcar starting (log level: 7)... Timestamp - start of postcar: 248582576 Timestamp - end of postcar: 248589814 S3 Resume Error: Can't find stage_cache 57a9e100 in imd ramstage cache invalid. board_reset() called! system_reset() called! ``` It seems that the commit above has not experienced many test for S3 resume before getting merged. The default heap size may have to be reconsidered. -- 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

3 2

2023-11-15 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 16 Nov '23

16 Nov '23

Apologies for the oversight! There was a mistake with the date provided in the initial minutes. Please find the corrected version below. # 2023-11-15 - coreboot Leadership Meeting Minutes ## Attendees Martin Roth, Wilhelmina Asante, Matt DeVillier, Maximilian Brune, Tim Crawford, Felix Held, Julius Werner, Jonathan Hall, Nico Huber, Jeremy Compostella , Karthik Ramasubramanian, Felix Singer, Benjamin Doron, David Hendricks, Sergio Moreira, Solomon Alan-Dei, Simon Glass, Lean Sheng Tan. ## Open Action Items * 2023-11-15 * [Open] Martin: Publish coreboot FAQ * [Open] Martin: Make announcement about changing release numbers in the release notes of the final 4.xx release. Following releases will use year.month.sub release format. 24.02 (24.02.00 implied) would go to 24.02.01 if a release update is needed. The next release, 3 months later, would be 24.05. * 2023-11-01 * [Open] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * 2023-10-18 * [Started] MattD and WernerZ :Work on compiling a list of website requirements from the mailing list. * No feedback yet - Matt will continue to gather feedback. * Probably have all of the community input - Need to capture the requirements as a starting point. * [On hold pending requirements] MartinR & FelixS: Build a POC front page. * [Open] Arthur: Ask Philip about how to use company logos. * [Prototyped] Martin: Create coreboot governance page * Please review and give comments. * 2023-10-4 * [Started] Martin: Write a tutorial for gerrit - Feel free to help. * [Open] OSFF: Look into making a video about using gerrit. * Discussed with Christian who felt this was a good plan. * Look at next year. * [Open] Martin: Write a document about vendorcode submodules. * 2023-09-20 * [Started] Martin: Work on clang-format config update. * We can use the clang format version from the coreboot toolchain! * Some issues with clang format - martin will present. * See CB:78833 for what the current format’s changes will look like. * [David] #defines for bits in headers lose their indenting. Maybe we should have clang-format ignore headers for now. Smaller issues can be handled on a "use your best judgement" basis. * [Done] Martin to add bitfield example to 78833. * Let’s look at running this just for .c files to start with. ## Minutes ### [Martin] Proposal: Agenda items needing a decision must be on the agenda by the time it’s sent to the mailing list on Monday. * To give everyone a chance to participate in the decisions being made, we should make sure that all agenda contains all items being discussed well ahead of time. I’d propose that we send out an initial agenda calling for any additional items on the Friday before the meeting, then an updated, final agenda on the Monday before the meeting. (Thank you Mina!) We encourage people to update the agenda document before the meeting with any thoughts they have before the meeting, whether or not they can actually attend the meeting. Posting responses to the mailing list for the agenda items should also be acceptable - those responses can be collected into the meeting minutes, at least with a summary and a link. * FelixH: Maybe move the freeze to tuesday? No strong feelings. * Nico: I don’t know that this will really help - Things addressed in the meeting still can’t be discussed on the mailing list. Proposal might help but can also slow things down. * FelixS: Leadership meeting could just become the discussion channel. The meeting shouldn’t be the first place to announce an issue. People should start discussions with a new thread for every issue. * Martin: Do we really need separate email threads about every issue? Can people not read and respond to the agenda? * FelixS: The actual content is hidden in the agenda. Having a separate thread gets people more involved. * FelixH: Agenda being sent out is a huge improvement over what we had before. Not a fan of mailing lists. * Sheng: Agree with not forcing people to write threads - some people prefer talking over writing to the mailing list. * FelixS: Not trying to force anything, but the mailing list reaches more people. * FelixH: The leadership meeting allows people to contribute more easily. * DavidH: We should take input in multiple forms for controversial decisions. Not everything needs to be discussed. We already generally ask to spawn a thread on the mailing list for controversial issues. **Decision: Let’s try the original plan as Martin proposed for now - If there are any decisions that should have been made on the mailing list, please let us know. If there are any issues that need to be worked out, we can look at how the plan needs to be modified.** ### [Martin] I’d like to nominate Jérémy Compostella for core developer status. * Jeremy’s first patch at coreboot was in September of 2016, and he’s definitely done a lot more recently. CB:16524 He’s volunteered as *the* maintainer for the x86 platform code - no simple task. He’s shown himself to be extremely capable both in his reviews and in his own patches. Statistics as of 2023_11_08 - 81 Patches, 93 Reviews, 41 Comments. **Decision: No objections, tentatively approved. If there are any objections, please email David, Matt or Werner before Friday.** ### [Martin] coreboot 4.22 to be released this friday. * Felix will send out another email.(Action Item) ### [Martin] Change the coreboot versioning from 4.xx to year.month format? * We’d note this in the 4.22 release notes, and the next release would be 24.02. Current number is meaningless. - Matches us up with linux distros. **Decision: We will change the format - Martin to announce in release notes.** ### [Benjamin] Add support for calling SMM payloads * To support UEFI secure boot effectively, we need to perform the verification and SPI write steps of its variables together, in SMM. Consequently, we need the payload to initialize SMM, and on S3 resume, to relocate these SMBASEs (because the payload is not on the boot path). We would like approval for this use-case. While this was developed for EDK2, to support secure boot, note that it’s not UEFI-specific (other potential payloads must have similar design), and contains nothing specific to secure boot. We are also pursuing future work to share SMM between coreboot and the payload. * Allows enablement of secureboot. * Considered just using smm store as it is - but this just submits the write. Downside can call the SMI. * Considered bringing the entire variable stack into coreboot. EEK! * Following what intel is doing for UPL, enabling payload to install SMM - takes care of its own variable stack. * Don’t init SMM on cold boot. * Passes data in cb tables - (fairly) silicon agnostic (intel specific). - not strictly required) * Can Payload init SMM on its own? * On S3 resume, payload isn’t on resume path. Coreboot would take data saved and trigger an SMI from coreboot so we can continue. * Dammit, looks something like UEFI - just because that’s what’s currently supported - any other solution would need to do something similar. * FelixH: On the AMD SOCs - SOC specific in SMI handler. How would these hook into the payload handler? The payload would need to know about the specifics. Solves one problem, but creates other issues. Makes payload non-hardware agnostic. * Benjamin: User can decide to include and support secureboot or not. Open source currently. * Martin: What prevents hardware vendors from forcing the inclusion of closed source binaries to support their hardware? * Benjamin: Nothing - but the person doing the compile gets to decide. * Sheng: Huge security impact. Currently we can’t do any secureboot. coreboot currently has no way to handle this currently. * Nico: Any other solution would do something similar - is this actually true? We have vboot that does things differently. Have you considered not doing things with SMM. * Benjamin: Vboot covers the boot path, doesn’t cover the final bootloader. * Nico: true, but it could verify the variables when they’re consumed. * Benjamin: The problem is that smm store can’t prevent people from writing. * Nico: If you don’t use SMMstore, there are other possibilities. * Benjamin: can’t call back into vboot * Nico: why would you need to? * Benjamin: Take the concept of vboot and put it into libpayload & the payload. * MattD: What about the effort to share smm between vboot & payload? Can that address some of these issues? * Benjamin: The concerns are more about licensing. About 2 big steps away from being able to test sharing. ### [Martin] Plans for the 24.02 release * We’d like to start creating and announcing plans for upcoming releases that the entire project can work toward. These can be maintenance, new features, documentation goals, or hopefully some of each. -[Maintenance] Chipset device trees for all SOCs. * MattD: Would be good to have 3-5 big scope items for each release. ### [Martin] Look at adding Go and Rust to the toolchain * Go: We’re already using tools written in Go as a part of the build, and they currently use the system toolchain, leaving droppings outside of the coreboot and $obj folders as a part of the build. Additionally, we want the binary we produce to be reproducible - I’m not sure if that’s currently a problem or not. SBOM, STM * Can probably drop this for now? * Rust: Rust is starting to be used more and more widely as a system programming language. The Linux kernel is accepting Rust. Oxide’s entire codebase is in Rust. The Oreboot project is using Rust. While I’m not personally a fan of Rust, I can see the need to support it coming. * MattD:Can gather more engagement with support for more popular languages. * MaxB:Is this just about tooling or actually adding code? * MartinR:Toolchain for now, but this would start the direction of accepting rust. *MaxB: How would it look to start adding rust code? * FelixH - doing the SMI handler in rust would be interesting. * Nico: On the matter of integrating different languages - looked at it with ADA, same applies to rust. Would need good interface code. We’d need to create bindings for rust - then we could start creating things like drivers. * Benjamin: Would this be a maintenance issue? Would we need strict rules around languages for specific areas to allow for maintainers for each of the areas? * FelixH: Can we just start with tooling and payloads and see how it goes? ### [Sheng] Winter Hackathon hosted by 9E * November 17th - 19th * So far, ~35 people are planning on attending. * (https://opensourcefirmware.foundation/events/osff-fall-hackathon-2023/) ### [Martin] Fosdem: Open Source Firmware, BMC and Bootloader Room * Call for participation * (https://lists.fosdem.org/pipermail/fosdem/2023q4/003524.html) * Submission Deadline: 11-Dec-2023 @ 23:59:59 UTC * Acceptance Notification: 13-Dec-2023 * Final Schedule Posted: 15-Dec-2023 ### [Martin] Syspro servers here, but not set up yet * These will be used for non-critical builds. * Need help setting up BSD server. ## Closed Action Items * [Done] Martin: Note the slowdown of syncing the master branch to the 4.22 release notes - Updates are now weekly & branch will be removed at 4.23 release. * [Done] PatrickG: Slow down the updates of the master branch. * [Done] Martin: Send out an email to the mailing list about running devicetree.cb files through the C preprocessor to get feedback. * FelixH don’t use a preprocessor. * What problem are we trying to solve? If just adding Kconfig then preprocessor opens up too much. * Julius - Macros are easier to write - sconfig is hard to learn. # Next meeting * November 29, 2023 * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [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 https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Leadership Meeting Minutes
by mina＠coreboot.org 16 Nov '23

16 Nov '23

# 2023-11-15 - coreboot Leadership Meeting ## Attendees Martin Roth, Wilhelmina Asante, Matt DeVillier, Maximilian Brune, Tim Crawford, Felix Held, Julius Werner, Jonathan Hall, Nico Huber, Jeremy Compostella , Karthik Ramasubramanian, Felix Singer, Benjamin Doron, David Hendricks, Sergio Moreira, Solomon Alan-Dei, Simon Glass, Lean Sheng Tan. ## Open Action Items * 2023-11-15 * [Open] Martin: Publish coreboot FAQ * [Open] Martin: Make announcement about changing release numbers in the release notes of the final 4.xx release. Following releases will use year.month.sub release format. 24.02 (24.02.00 implied) would go to 24.02.01 if a release update is needed. The next release, 3 months later, would be 24.05. * 2023-11-01 * [Open] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * 2023-10-18 * [Started] MattD and WernerZ :Work on compiling a list of website requirements from the mailing list. * No feedback yet - Matt will continue to gather feedback. * Probably have all of the community input - Need to capture the requirements as a starting point. * [On hold pending requirements] MartinR & FelixS: Build a POC front page. * [Open] Arthur: Ask Philip about how to use company logos. * [Prototyped] Martin: Create coreboot governance page * Please review and give comments. * 2023-10-4 * [Started] Martin: Write a tutorial for gerrit - Feel free to help. * [Open] OSFF: Look into making a video about using gerrit. * Discussed with Christian who felt this was a good plan. * Look at next year. * [Open] Martin: Write a document about vendorcode submodules. * 2023-09-20 * [Started] Martin: Work on clang-format config update. * We can use the clang format version from the coreboot toolchain! * Some issues with clang format - martin will present. * See CB:78833 for what the current format’s changes will look like. * [David] #defines for bits in headers lose their indenting. Maybe we should have clang-format ignore headers for now. Smaller issues can be handled on a "use your best judgement" basis. * [Done] Martin to add bitfield example to 78833. * Let’s look at running this just for .c files to start with. ## Minutes ### [Martin] Proposal: Agenda items needing a decision must be on the agenda by the time it’s sent to the mailing list on Monday. * To give everyone a chance to participate in the decisions being made, we should make sure that all agenda contains all items being discussed well ahead of time. I’d propose that we send out an initial agenda calling for any additional items on the Friday before the meeting, then an updated, final agenda on the Monday before the meeting. (Thank you Mina!) We encourage people to update the agenda document before the meeting with any thoughts they have before the meeting, whether or not they can actually attend the meeting. Posting responses to the mailing list for the agenda items should also be acceptable - those responses can be collected into the meeting minutes, at least with a summary and a link. * FelixH: Maybe move the freeze to tuesday? No strong feelings. * Nico: I don’t know that this will really help - Things addressed in the meeting still can’t be discussed on the mailing list. Proposal might help but can also slow things down. * FelixS: Leadership meeting could just become the discussion channel. The meeting shouldn’t be the first place to announce an issue. People should start discussions with a new thread for every issue. * Martin: Do we really need separate email threads about every issue? Can people not read and respond to the agenda? * FelixS: The actual content is hidden in the agenda. Having a separate thread gets people more involved. * FelixH: Agenda being sent out is a huge improvement over what we had before. Not a fan of mailing lists. * Sheng: Agree with not forcing people to write threads - some people prefer talking over writing to the mailing list. * FelixS: Not trying to force anything, but the mailing list reaches more people. * FelixH: The leadership meeting allows people to contribute more easily. * DavidH: We should take input in multiple forms for controversial decisions. Not everything needs to be discussed. We already generally ask to spawn a thread on the mailing list for controversial issues. **Decision: Let’s try the original plan as Martin proposed for now - If there are any decisions that should have been made on the mailing list, please let us know. If there are any issues that need to be worked out, we can look at how the plan needs to be modified.** ### [Martin] I’d like to nominate Jérémy Compostella for core developer status. * Jeremy’s first patch at coreboot was in September of 2016, and he’s definitely done a lot more recently. CB:16524 He’s volunteered as *the* maintainer for the x86 platform code - no simple task. He’s shown himself to be extremely capable both in his reviews and in his own patches. Statistics as of 2023_11_08 - 81 Patches, 93 Reviews, 41 Comments. **Decision: No objections, tentatively approved. If there are any objections, please email David, Matt or Werner before Friday.** ### [Martin] coreboot 4.22 to be released this friday. * Felix will send out another email. ### [Martin] Change the coreboot versioning from 4.xx to year.month format? * We’d note this in the 4.22 release notes, and the next release would be 24.02. Current number is meaningless. - Matches us up with linux distros. **Decision: We will change the format - Martin to announce in release notes.** ### [Benjamin] Add support for calling SMM payloads * To support UEFI secure boot effectively, we need to perform the verification and SPI write steps of its variables together, in SMM. Consequently, we need the payload to initialize SMM, and on S3 resume, to relocate these SMBASEs (because the payload is not on the boot path). We would like approval for this use-case. While this was developed for EDK2, to support secure boot, note that it’s not UEFI-specific (other potential payloads must have similar design), and contains nothing specific to secure boot. We are also pursuing future work to share SMM between coreboot and the payload. * Allows enablement of secureboot. * Considered just using smm store as it is - but this just submits the write. Downside can call the SMI. * Considered bringing the entire variable stack into coreboot. EEK! * Following what intel is doing for UPL, enabling payload to install SMM - takes care of its own variable stack. * Don’t init SMM on cold boot. * Passes data in cb tables - (fairly) silicon agnostic (intel specific). - not strictly required) * Can Payload init SMM on its own? * On S3 resume, payload isn’t on resume path. Coreboot would take data saved and trigger an SMI from coreboot so we can continue. * Dammit, looks something like UEFI - just because that’s what’s currently supported - any other solution would need to do something similar. * FelixH: On the AMD SOCs - SOC specific in SMI handler. How would these hook into the payload handler? The payload would need to know about the specifics. Solves one problem, but creates other issues. Makes payload non-hardware agnostic. * Benjamin: User can decide to include and support secureboot or not. Open source currently. * Martin: What prevents hardware vendors from forcing the inclusion of closed source binaries to support their hardware? * Benjamin: Nothing - but the person doing the compile gets to decide. * Sheng: Huge security impact. Currently we can’t do any secureboot. coreboot currently has no way to handle this currently. * Nico: Any other solution would do something similar - is this actually true? We have vboot that does things differently. Have you considered not doing things with SMM. * Benjamin: Vboot covers the boot path, doesn’t cover the final bootloader. * Nico: true, but it could verify the variables when they’re consumed. * Benjamin: The problem is that smm store can’t prevent people from writing. * Nico: If you don’t use SMMstore, there are other possibilities. * Benjamin: can’t call back into vboot * Nico: why would you need to? * Benjamin: Take the concept of vboot and put it into libpayload & the payload. * MattD: What about the effort to share smm between vboot & payload? Can that address some of these issues? * Benjamin: The concerns are more about licensing. About 2 big steps away from being able to test sharing. ### [Martin] Plans for the 24.02 release * We’d like to start creating and announcing plans for upcoming releases that the entire project can work toward. These can be maintenance, new features, documentation goals, or hopefully some of each. -[Maintenance] Chipset device trees for all SOCs. * MattD: Would be good to have 3-5 big scope items for each release. ### [Martin] Look at adding Go and Rust to the toolchain * Go: We’re already using tools written in Go as a part of the build, and they currently use the system toolchain, leaving droppings outside of the coreboot and $obj folders as a part of the build. Additionally, we want the binary we produce to be reproducible - I’m not sure if that’s currently a problem or not. SBOM, STM * Can probably drop this for now? * Rust: Rust is starting to be used more and more widely as a system programming language. The Linux kernel is accepting Rust. Oxide’s entire codebase is in Rust. The Oreboot project is using Rust. While I’m not personally a fan of Rust, I can see the need to support it coming. * MattD:Can gather more engagement with support for more popular languages. * MaxB:Is this just about tooling or actually adding code? * MartinR:Toolchain for now, but this would start the direction of accepting rust. *MaxB: How would it look to start adding rust code? * FelixH - doing the SMI handler in rust would be interesting. * Nico: On the matter of integrating different languages - looked at it with ADA, same applies to rust. Would need good interface code. We’d need to create bindings for rust - then we could start creating things like drivers. * Benjamin: Would this be a maintenance issue? Would we need strict rules around languages for specific areas to allow for maintainers for each of the areas? * FelixH: Can we just start with tooling and payloads and see how it goes? ### [Sheng] Winter Hackathon hosted by 9E * November 17th - 19th * So far, ~35 people are planning on attending. * (https://opensourcefirmware.foundation/events/osff-fall-hackathon-2023/) ### [Martin] Fosdem: Open Source Firmware, BMC and Bootloader Room * Call for participation * (https://lists.fosdem.org/pipermail/fosdem/2023q4/003524.html) * Submission Deadline: 11-Dec-2023 @ 23:59:59 UTC * Acceptance Notification: 13-Dec-2023 * Final Schedule Posted: 15-Dec-2023 ### [Martin] Syspro servers here, but not set up yet * These will be used for non-critical builds. * Need help setting up BSD server. ## Closed action items * [Done] Martin: Note the slowdown of syncing the master branch to the 4.22 release notes - Updates are now weekly & branch will be removed at 4.23 release. * [Done] PatrickG: Slow down the updates of the master branch. * [Done] Martin: Send out an email to the mailing list about running devicetree.cb files through the C preprocessor to get feedback. * FelixH don’t use a preprocessor. * What problem are we trying to solve? If just adding Kconfig then preprocessor opens up too much. * Julius - Macros are easier to write - sconfig is hard to learn. # Next meeting * November 15, 2023 * [Meeting link](https://meet.google.com/pyt-newq-rbb) * [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 https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

Boot time optimization on a CMOS battery less hardware platform
by Moorthi M.s 16 Nov '23

16 Nov '23

Hi, I am developing coreboot along with Uefipayload for a custom board derived from CFL H RVP11 CRB. Modifications are done as per the custom board and the board was booted and working fine. Without CMOS battery, the board takes around 28 seconds for booting and it goes through 2 resets. But with CMOS battery, it takes only 15 seconds for booting and it skips the FSPS reset. Is there any method available in coreboot to reduce the boot time to 15 seconds same as with CMOS battery configuration on a CMOS battery less (without CMOS battery) hardware platform? Thanks & Regards, Moorthi S

1 0

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