December 2023 - coreboot - mail.coreboot.org

Re: geminilake fsp on Google Chromebook?
by Martin Roth Dec. 17, 2023

Dec. 17, 2023

Actually, Intel doesn't have much to do with this. I can look at adding the feature, but the chromeos team would need to evaluate the size differences and decide to whether to enable it. Dec 17, 2023 at 12:09 by coreboot(a)coreboot.org: > Dec 16, 2023 at 20:16 by coreboot(a)coreboot.org: > >> Just a thought, the FSP headers are pretty small. Maybe they can be compressed and added to the firmware image to make this easier, the way we do for the config file. >> > > Considering that coreboot needs to know these FSP address offsets, that would seem an excellent idea. Or, at least a reference to the actual version of the headers used could be added to the firmware image, if a unique header version number exists. > > I notice that in the documentation, referenced at 3rdparty/fsp/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf, Intel mentions Coreboot specifically by name. So maybe the coreboot developers would hold some sway with this idea. > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

Re: geminilake fsp on Google Chromebook?
by James Feeney Dec. 17, 2023

Dec. 17, 2023

Dec 16, 2023 at 20:16 by coreboot(a)coreboot.org: > Just a thought, the FSP headers are pretty small. Maybe they can be compressed and added to the firmware image to make this easier, the way we do for the config file. Considering that coreboot needs to know these FSP address offsets, that would seem an excellent idea. Or, at least a reference to the actual version of the headers used could be added to the firmware image, if a unique header version number exists. I notice that in the documentation, referenced at 3rdparty/fsp/ApolloLakeFspBinPkg/Docs/Apollo_Lake_FSP_Integration_Guide.pdf, Intel mentions Coreboot specifically by name. So maybe the coreboot developers would hold some sway with this idea.

1 0

COM Express type 7 / 6 board?
by ron minnich Dec. 15, 2023

Dec. 15, 2023

I'm looking for a COM Express board, type 6 or 7, that runs coreboot, thought I would start here.

4 5

Re: geminilake fsp on Google Chromebook?
by James Feeney Dec. 15, 2023

Dec. 15, 2023

>> … I expect that that refers to an even newer "release 9" versus a "release 8". And, this "-r9" should also work with the setting: CONFIG_FSP_HEADER_PATH= "src/vendorcode/intel/fsp/fsp2 _0/geminilake/ 2.2.3.1 " Is that correct? > NO! those strings are simply build paths, they have no correlation to the version of headers which need to be used with a given binary/binaries. Google binaries use Google's headers. Intel's binaries use Intel's headers. Then, how do I find whether a particular fspm/fsps set is using the coreboot 2.2.0.0 headers or the 2.2.3.1 headers? Those headers are very similar. > Also, the binaries in my repo would not have anything resembling that build path as it's specific to a Google ChromeOS build system, and my binaries are not from a ChromeOS device. Oops! I was looking at your binaries in 3rdparty/blobs/mainboard/google/octopus/casta/ instead of your binaries from the site-local/Kconfig, 3rdparty/blobs/soc/intel/glk/fsp/release/. $ strings 3rdparty/blobs/soc/intel/glk/fsp/release/Fsp_M.fd |grep -i gemini|head -1 c:\tcwork\bxt_ap7829\Build\GeminilakeFspPkg\RELEASE_VS2013x86\IA32\GeminilakeSiliconPkg\NorthCluster\MemoryInitGlk\MemoryInitFsp\DEBUG\AutoGen.c Where your config is for the edk2 payload, is there any reason that these same edk2 FSP files would not also work with the LinuxBoot payload?

2 1

Re: geminilake fsp on Google Chromebook?
by Matt DeVillier Dec. 14, 2023

Dec. 14, 2023

On Thu, Dec 14, 2023 at 6:07 PM James Feeney <james(a)nurealm.net> wrote: > > To get it to update values to new default settings, run: > > make savedefconfig && make defconfig KBUILD_DEFCONFIG=${PWD}/defconfig > > The Kconfig in coreboot document is written with developers writing > Kconfig files in mind, but it's got a lot of useful information about how > Kconfig works. > > That helps. It's sort of a "process", building a ".config", rather than a > single "make nconfig" and done. > since you're starting with my defconfigs, you don't need to change anything. They are the exact configs I use to build my release firmware and are known/tested working. > > > all this mess is because you're trying to use an existing config rather > than start from my defconfig, which is designed to work with my repo. The > selections are currently guarded appropriately. ADD_FSP_BINARIES only needs > to be selected if not using the 3rdparty/fsp repo (as it's selected by > default there). > > Ah! Ok, I see that now. I'm stumbling-around, trying to understand config > options. It's overwhelming at first. And it requires learning to "trust > the defaults". > you're not trusting the defaults, you're trusting my configs which are used to build working firmware. The defaults are not sane or there wouldn't be a dozen lines in the defconfigs and a handful more in my site-local/Kconfig > > Some config options for a board are "required - don't touch!", and others > really are "optional". I'm getting a sense of which is which, but there > doesn't seem to really be a "config overview" or centralized guidance. And > it's probably different for every different cpu architecture. > indeed, knowing what can/should be changed in many cases requires being a firmware developer with reasonable familiarity with coreboot, the platform, and the board in question > > >> … Hmm - so, if the blob files referenced in site-local/Kconfig are not > extracted from the stock ChromeOS firmware images for GLK boards, and they > are not built from source by coreboot, then where are they from? > > > they're extracted from another coreboot device which uses newer FSP > blobs than the Google ones. Which is why I use the newer headers. > > Aha! Thanks for that. > > Comparing the latest "bluebird" update, > bios-casta.ro-11297-222-0.rw-11297-411-0.bin, from > chromeos_15604.57.0_octopus_recovery_stable-channel_mp-v32.bin, and your > newer FSP blobs, I see: > > $ strings 2023Dec01/fsps.bin |grep octopus|head -n1 > > /build/octopus/tmp/portage/sys-boot/intel-glkfsp-0.0.1-r9/work/intel-glkfsp-0.0.1/Build/GeminilakeFspPkg/RELEASE_COREBOOT/IA32/GeminilakeFspPkg/FspHeader/FspHeader/OUTPUT/./FspHeader.dll > > $ strings 3rdparty/blobs/mainboard/google/octopus/casta/fsps.bin | grep > octopus | head -n1 > > /build/octopus/tmp/portage/sys-boot/intel-glkfsp-0.0.1-r8/work/intel-glkfsp-0.0.1/Build/GeminilakeFspPkg/RELEASE_COREBOOT/IA32/GeminilakeFspPkg/FspHeader/FspHeader/OUTPUT/./FspHeader.dll > > The most recent bios has that "-r9", versus the "-r8". I expect that that > refers to an even newer "release 9" versus a "release 8". And, this "-r9" > should also work with the setting: > CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/ > 2.2.3.1" > NO! those strings are simply build paths, they have no correlation to the version of headers which need to be used with a given binary/binaries. Google binaries use Google's headers. Intel's binaries use Intel's headers. Also, the binaries in my repo would not have anything resembling that build path as it's specific to a Google ChromeOS build system, and my binaries are not from a ChromeOS device. TBF, this is unnecessarily confusing because Intel chose to not publicly release FSP headers/binaries for Geminilake (or Jasperlake). Everything is set correctly in my repo so that a user who clones my repo/submodules and uses my build script will end up with a functional firmware image for a given board. > Is that correct? > > >

1 0

2023-12-13 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org Dec. 14, 2023

Dec. 14, 2023

# 2023-12-13 - coreboot Leadership Meeting Minutes ## Attendees Martin R, Werner Zeh, Christian Walter, Matt DeVillier, Felix Singer, Felix Held, Jay Talbott, Marshall Dawson, Simon Glass, David Hendricks, Maximilian Brune, Jeremy Compostella, Jonathan Hall, Karthik R, Nico H, Mina A, Lean Sheng Tan. ## Open Action Items * 2023-12-13 * Patrick? FelixS?: Look at improving the responsiveness of gerrit. * Swapping issues? * Jenkins taking resources * 504 error code - 500 error code * Same patch pushed twice, same change-ID two different gerrit ids. * Patches showing up as open even after they’re merged * Move coreboot resources off of stefan’s server? * 2023-11-29 * [Open] FelixS: Draft a proof-of-concept proposal to switch to meson. * 2023-11-15 * [Done] Martin: Publish coreboot FAQ https://review.coreboot.org/c/coreboot/+/79441 * 2023-11-01 * [Open] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * No progress yet * 2023-10-18 * [Started](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/th… XKVCP3YIFJEE/) 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. * Move to next year. * [On hold] [pending requirements] MartinR & FelixS: Build a POC front page. * [Open] Arthur: Ask Philip about how to use company logos. * 2023-10-4 * [Started](https://docs.google.com/document/d/1Z8igNdgBG5_Qlr4kKRtlbpKaZo9RUg… 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. * Not started * 2023-09-20 * [Started](https://review.coreboot.org/c/coreboot/+/78832) Martin: Work on [clang-format config update](https://review.coreboot.org/c/coreboot/+/78832). * We can use the clang format version from the coreboot toolchain! * Some issues with clang format - martin will present. * See [CB:78833](https://review.coreboot.org/c/coreboot/+/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](https://review.coreboot.org/c/coreboot/+/78833/4/src/drivers/inte… example to 78833 * Let’s look at running this just for .c files to start with. ## Minutes ### [Martin] Covered open action items ### [Martin] Present Projects & RFCs list ### [Sheng] Decision for Bootflow on Arm64 Server * As mentioned in previous leadership meeting and a special meeting on 05 Dec 2023, the leadership team will make decision on going forward with the proposal here: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/BRW3… WM/ * We’re proposing that there are two additional boot flows added to Arm’s document. https://docs.google.com/document/d/1z3fLdUmbOBKvHJfub8ki9YWjuqpK_1PY0H4BWwm… ### Decision * We’re agreeing to change the coreboot codebase to support the modified bootflow, based on the understanding that the standard coreboot arm bootflow will also be included. If that isn’t accepted, we’ll need to revisit this. If Arm agrees to include both boot flows in their document, we will get the patches merged, but we’d like an agreement from them before that’s done. * Nico: The secure monitor is still an issue. That’s not open source. * [Martin] But the secure boot monitor is not part of coreboot or even called by coreboot in the new boot flow. Let’s have a discussion about it, but there are other topics we want to cover in this meeting. ### [Martin/MaxB] Look at improving the readability of our build system * See https://review.coreboot.org/c/coreboot/+/79230 - this combines a number of changes into a single patch just to see what things would look like. * Please take a look and voice opinions. * Some problems: * Makefiles at the directory tips frequently have `ifeq` blocks surrounding the entire contents. https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/src/… * We probably shouldn’t indent the entire file. * To indent ifeq/ifneq/endif statements inside a target, we need to use spaces instead of tabs. This leads to an ugly mix of spaces and tabs, which can be confusing, and will break the build if it’s done incorrectly. ### [Martin] Cancel the December 27th meeting? * Cancel this! ### [PatrickG, Martin] How to present design proposals? * There’s some tension in the project between “folks write a whole new thingamabob and submit it whole to the project, then get indignant when the project doesn’t adopt it wholesale. To avoid that from happening, we discourage working like that” and “you want to do something? Build a prototype” * Should we document what we think is a good way to approach such situations? * With the example of “make a coreboot build system based on meson”, Patrick mused: “While we discourage folks from dumping a full solution on us, having a partial solution (and that should be more than a userland tool, because those are easy in meson) to offer a glimpse in how it should look is worthwhile. The problems arise when there's so much work sunk into it that rejecting it means rejecting a developer's work of months, which is why that's not a good approach to "dump code on us". * There aren't any hard & fast rules, but - "I got qemu to compile (typically the easiest target) and this is how it looks" seems like a good step in between. - If it takes months to get to that stage, it's probably not worth it, because whatever has been built in that time is as complex as what we have. - "I got qemu to compile, but don't mind the mess in most of the tree. I have a plan how it should look (see src/cpu which is more like it) but I wanted to prove the concept first" already offers something that can be discussed properly without costing too much effort. * Stefan offered that code can be published on Gerrit even when it’s not ready yet (and/or just a prototype). Gerrit does have a “Work In Progress” flag for CLs, after all, so there’s not necessarily a need to set up a branch for such work. * Flow: * Propose the idea to the mailing list * Present a draft * Do a small implementation (Qemu or similar) * Present an RFC * Review on mailing list & in leadership meeting. * ??? * Profit??? * Felixs: Start a forum? Replace the mailing list with a forum? * Felixh: We already have the bugtracker - it uses a different login than gerrit, so it’s already problematic to use. Let’s not create another. * Nico: The mailing list is the most accessible method. Everyone can participate well. * Felixs: Just looking at how other open source projects done today open projects on gitlab or github, and people discuss things there. People today are used to that. People don’t like writing emails. Modern solutions look nicer and are more accessible. * SJG: Mailing list is searchable and everything can be seen later. Other things are more of a walled garden. Replacing the mailing list would be a bad decision. * Nico: Forums are accessible only to people able to use a web browser. * This can at least be an example process, if not the only process. ### [Martin] review of “Setup Option Table” (placeholder name for what was CFR) * We’re more aligned with a build-time approach, with customization of the data structures in mainboard code. If this customization becomes commonplace, we can move functions into lib/sot or something. * Kconfig-based / data-serialization-language (like yaml, ~~cbor or protobuf~~)? * [Setup Option Table requirements](https://docs.google.com/document/d/1WAc6k8k4hUhcUJl-hl9jUfEWh… for *any* solution * Kconfig [Setup Option Tables](https://docs.google.com/document/d/1TWbxKRhsTpid7xyK-yMdsxhfZxZtTTN… h.astha87lu249) * Kconfig [Setup Option Table DSL](https://docs.google.com/document/d/18uApZbuvou9unlL8SdTZ4dTblHD2OGs_Sg… ### [Simon]: Serial RFC * The proof of concept is here https://review.coreboot.org/c/coreboot/+/79317 Now updated to allow use of a CBFS file. * Does the -2 indicate that this is being killed? * [Martin] I don’t think so - I think Julius just wanted to prevent it from going in without agreement. I think he wouldn’t have made so many comments if he just wanted to kill it. * I’ve already stated numerous times that I don’t think that an option method based solely on including the configuration directly into bootblock is the right way to go about things. If we do pursue this, I’d like to be able to see the ability to add the CCB to a separate area in CBFS, which will be far more useful in the long-run, in my opinion. # Next meeting * January 10, 2024. * [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

Re: coreboot Meetings Announcement And Agenda Call
by Julius Werner Dec. 11, 2023

Dec. 11, 2023

[edit: that was meant to go to the list, too] On Mon, Dec 11, 2023 at 3:12 PM Julius Werner <jwerner(a)chromium.org> wrote: >> >> ### [Simon]: Serial RFC >> * The proof of concept is here https://review.coreboot.org/c/coreboot/+/79317 >> * Does the -2 indicate that this is being killed? >> * [Martin] I don’t think so - I think Julius just wanted to prevent it from going in without >> agreement. I think he wouldn’t have made so many comments if he just wanted to kill it. >> * I’ve already stated numerous times that I don’t think that an option method based solely on >> including the configuration directly into bootblock is the right way to go about things. If we do >> pursue this, I’d like to be able to see the ability to add the CCB to a separate area in CBFS, >> which will be far more useful in the long-run, in my opinion. > > > Unfortunately I'll be on a plane this Wednesday and won't be able to join this discussion. Would you mind if we move this to next meeting?

2 2

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org Dec. 11, 2023

Dec. 11, 2023

Dear community, Kindly note that the upcoming coreboot leadership meeting is scheduled for Wednesday, December 13, 2023.[1] You are welcome to add things you wish to see addressed during the meeting to the current agenda items. [2] ## Current Agenda Items ### [Martin] Cover open action items ### [Martin/MaxB] Look at improving the readability of our build system * See https://review.coreboot.org/c/coreboot/+/79230 - this combines a number of changes into a single patch just to see what things would look like. ### [Martin] Cancel the December 27th meeting? ### [PatrickG, Martin] How to present design proposals? * There’s some tension in the project between “folks write a whole new thingamabob and submit it whole to the project, then get indignant when the project doesn’t adopt it wholesale. To avoid that from happening, we discourage working like that” and “you want to do something? Build a prototype” * Should we document what we think is a good way to approach such situations? * with the example of “make a coreboot build system based on meson”, Patrick mused: “While we discourage folks from dumping a full solution on us, having a partial solution (and that should be more than a userland tool, because those are easy in meson) to offer a glimpse in how it should look is worthwhile. The problems arise when there's so much work sunk into it that rejecting it means rejecting a developer's work of months, which is why that's not a good approach to "dump code on us". * There aren't any hard & fast rules, but - "I got qemu to compile (typically the easiest target) and this is how it looks" seems like a good step in between. - If it takes months to get to that stage, it's probably not worth it, because whatever has been built in that time is as complex as what we have. - "I got qemu to compile, but don't mind the mess in most of the tree. I have a plan how it should look (see src/cpu which is more like it) but I wanted to prove the concept first" already offers something that can be discussed properly without costing too much effort. * Stefan offered that code can be published on Gerrit even when it’s not ready yet (and/or just a prototype). Gerrit does have a “Work In Progress” flag for CLs, after all, so there’s not necessarily a need to set up a branch for such work. ### [Martin] Localization of non-console strings for coreboot * With the addition of an early display, we’re looking at printing text to the screen directly from coreboot. Localization is being added for this, but the current patch uses the localization code from vboot. This isn’t a security related feature so shouldn’t depend on the rest of VBOOT being enabled. https://review.coreboot.org/c/coreboot/+/79054 * We also just had an RFC about storing setup engine strings. It seems like we’d want to make sure that whatever plan we have in place also supports localization for those strings as well. * How do we want to handle localization in coreboot? It seems like we’re going to be adding more strings that will be presented to the user. ### [Martin] review of “Setup Option Table” (placeholder name for what was CFR) * We’re more aligned with a build-time approach, with customization of the data structures in mainboard code. If this customization becomes commonplace, we can move functions into lib/sot or something. * Kconfig-based / data-serialization-language (like yaml, cbor or protobuf)? * [Setup Option Table requirements](https://docs.google.com/document/d/1WAc6k8k4hUhcUJl-hl9jUfEWh… * [Setup Option Tables](https://docs.google.com/document/d/1TWbxKRhsTpid7xyK-yMdsxhfZxZtTTN… h.astha87lu249) * [Setup Option Table DSL](https://docs.google.com/document/d/18uApZbuvou9unlL8SdTZ4dTblHD2OGs_Sg… ### [Martin/others] Look at writing a doc stating what coreboot is * It’s been argued that this shouldn’t be called a “spec”, but Daniel Maslowski pointed out that coreboot is being defined by others as something that we aren’t, because we don’t have a good definition of what we are. Whatever we want to call it, it seems like a good plan to have *something* discussing what coreboot is. ### [Simon]: Serial RFC * The proof of concept is here https://review.coreboot.org/c/coreboot/+/79317 * Does the -2 indicate that this is being killed? * [Martin] I don’t think so - I think Julius just wanted to prevent it from going in without agreement. I think he wouldn’t have made so many comments if he just wanted to kill it. * I’ve already stated numerous times that I don’t think that an option method based solely on including the configuration directly into bootblock is the right way to go about things. If we do pursue this, I’d like to be able to see the ability to add the CCB to a separate area in CBFS, which will be far more useful in the long-run, in my opinion. [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

geminilake fsp on Google Chromebook?
by James Feeney Dec. 10, 2023

Dec. 10, 2023

Comparing the git trees for the current stock coreboot and for your MrChromebox-4.21, I'm wondering about the .config differences generated by nconfig at CONFIG_FSP_HEADER_PATH=. ./src/soc/intel/apollolake/Kconfig has: config FSP_HEADER_PATH default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0" if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE default "src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1" if SOC_INTEL_GEMINILAKE default "3rdparty/fsp/ApolloLakeFspBinPkg/Include/" But, "make nconfig" in the MrChromebox tree, nonetheless, produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.3.1"' in the .config, somehow, despite the above, while the stock coreboot "make nconfig" instead produces 'CONFIG_FSP_HEADER_PATH="src/vendorcode/intel/fsp/fsp2_0/geminilake/2.2.0.0"', as might be expected. Can someone explain why there is the "if VENDOR_GOOGLE && SOC_INTEL_GEMINILAKE" consraint for the fsp? Is fsp 2.2.3.1 actually still the correct configuration when using the fsp.bin files extracted from the stock Google ChromeOS? Thanks James

3 4

Need help with porting coreboot.
by bud Dec. 8, 2023

Dec. 8, 2023

Hello, I would like some help with porting coreboot using autoport. I do not understand most of the instructions given in the documentation, for example: "Grab coreboot tree" Which coreboot tree? This one?: git clone ssh://review.coreboot.org:29418/coreboot or this one?: git clone https://review.coreboot.org/coreboot.git Apart from this, I have many other issues with understanding the documentation I would really appreciate it if you could provide step by step instructions with the commands to execute, without any vague instructions from the documentation. Thank you, bud (NOTE: I apologize if my tone of writing sounded rude.)

2 1