January 2023 - coreboot - mail.coreboot.org

[coreboot - Feature #433] (New) Unify TPM drivers in coreboot
by Michał Żygowski Sept. 7, 2025

Sept. 7, 2025

Issue #433 has been reported by Michał Żygowski. ---------------------------------------- Feature #433: Unify TPM drivers in coreboot https://ticket.coreboot.org/issues/433 * Author: Michał Żygowski * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-24 ---------------------------------------- Add an option to compile all drivers for TPM 1.2, 2.0 TIS and CRB. The motivation is to not build multiple coreboot ROMs for each possible TPM supported by the platform. The tasks would include: - runtime TPM detection (probing TPM_INTF_CAPABILITY and TPM_INTERFACE_ID) - rename the TPM driver functions, make them static and expose them as a driver structure, e.g. struct tpm_driver { void (*init)(void); int (*open)(void); int (*close)(void); int (*sendrecv)(const uint8_t *sendbuf, size_t send_size, uint8_t *recvbuf, size_t *recv_len); } - based on the detected TPM, hook the tpm_driver functions to provide the global TPM API: tis_open, tis_close, tis_init, tis_sendrecv. Some additional API to get vendor/device name could also be considered. -- 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 7

[coreboot - Bug #415] (New) RESOURCE_ALLOCATION_TOP_DOWN breaks edk2
by Sean Rhodes May 2, 2025

May 2, 2025

Issue #415 has been reported by Sean Rhodes. ---------------------------------------- Bug #415: RESOURCE_ALLOCATION_TOP_DOWN breaks edk2 https://ticket.coreboot.org/issues/415 * Author: Sean Rhodes * Status: New * Priority: Low * Target version: none * Start date: 2022-09-07 * Affected versions: master ---------------------------------------- CB:41957 enabled RESOURCE_ALLOCATION_TOP_DOWN by default, which stopped edk2 from booting. The commit has been reverted, so this ticket is just to post logs. ---Files-------------------------------- resource_allocatorv4.txt (94 KB) -- 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 6

[coreboot - Feature #420] (New) Use standard format of TPM event log
by Krystian Hebel Aug. 7, 2024

Aug. 7, 2024

Issue #420 has been reported by Krystian Hebel. ---------------------------------------- Feature #420: Use standard format of TPM event log https://ticket.coreboot.org/issues/420 * Author: Krystian Hebel * Status: New * Priority: Normal * Target version: none * Start date: 2022-10-12 * Related links: [1] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementa… [2] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05… ---------------------------------------- Currently coreboot uses proprietary format for TPM event log. TCG has standardized log formats, differently for TPM1.2 (aka legacy or SHA1) [1] and TPM2.0 (aka crypto agile) [2], both of which can be parsed by Linux kernel and exposed in sysfs. I don't know of any tool outside of cbmem which can parse coreboot format; this includes payloads which may be interested in continuing chain of trust started by coreboot. Another incompatibility is caused by vboot's assignment of PCRs. Roles of PCRs are roughly specified by TCG in both of mentioned documents, they are more or less compatible with each other, but not with current coreboot code. These changes could break assumptions made by existing platforms, so they should be made as Kconfig options. This is a tracking issue to collect subtasks that need to be done in order to support standard event log formats. -- 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 12

QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed
by Mike Banon Feb. 21, 2024

Feb. 21, 2024

If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore: ... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

6 11

Re: Deprecation of the Intel Quark SoC
by Łukasz Jeleń March 2, 2023

March 2, 2023

Hi, My background is low level ARM and I want to get familiar with low level x86. I bought galileo v1 because it is cheap, small and handy x86 board. I have built coreboot code. It does not boot "out of the box". I had to add rmu.bin into coreboot.rom. With this logging on uart works. It seems SD/MMC controller also works. Now I'm struggling with: [INFO ] CBFS: Found 'fspm.bin' @0x31c40 size 0x2f000 in mcache @0x80004f84 [ERROR] CBFS ERROR: 'fspm.bin' allocation failure [EMERG] FSPM not available or failed to load! Regards, Łukasz

4 14

COREBOOT and FSP CONFIGURATION for INTEL TIGERLAKE BOARD
by Renuka Pande Feb. 26, 2023

Feb. 26, 2023

Hi, I am trying to configure coreboot and fsp for Intel Tigerlake Board. I am facing the following issues: While building coreboot, in the menuconfig command, in mainboard section, if the ON BOARD EC is selected as INTEL EC, when make command is given, it is giving "Makefile:215" error. If the ON BOARD EC is selected as Chrome EC, then only the make is successful. But it is displaying the following warning: "coreboot has been built without Intel Firmware Descriptor. . . . " The mainboard vendor and model are selected as Intel and Tigerlake UP3 RVP respectively. Can you please help in solving this issue? It would be of great help if you could explain how to build coreboot and fsp for Tigerlake Board. Thanking you in anticipation. Thanks and Regards, Renuka

2 1

Re: Status of maintained boards and policies?
by Martin Roth Feb. 23, 2023

Feb. 23, 2023

Hey Denis, My reply got out of control here. Apologies for the length, feel free to ignore the top and just skip to my replies. :) The points you bring up are definitely valid, but coreboot isn't Linux. We don't have the same infrastructure, or investment from companies. coreboot has no "full time" contributors as such. We have a number of contributors from various companies who need to get their products shipped, but they all have varying amounts of time to spend on the project. It's a tiny tiny fraction of what Linux gets. I don't mean to say that coreboot is a small project - we're not. In the past year, we've gotten contributions from over 350 different people. Most of these contributions are from people who work on coreboot as a job. Those aren't the people who keep the project alive though. There are really just a couple of dozen people at any given time who actually do the work on the coreboot project outside of the individual patches they're assigned to do for their jobs. Unfortunately, that's simply not enough people to maintain all of the platforms and chips in the tree the way things are currently. We could do something like add a requirement that each platform added needs to donate two (or choose an arbitrary number) boards to the coreboot project that we install somewhere and test on a (daily/weekly/monthly) basis to make sure that they're working. Currently we don't have the funds or a place to do that. It also puts a burden on an individual who wants to add a board to the coreboot tree. It creates problems for companies that use coreboot for an embedded system that isn't easy to test. Looking forward: coreboot just got our first "large" donation from Google to support the build servers for the next year. Until now, the build servers have mainly been running from my house. We've reached the point where the project can no longer run as a hobby-project on a hobby-project budget. If we're going to actually be more than a hobby-project going forward, I think we're going to need to expand our scope and make changes to the way we do things. This is going to require making changes to better define how things like code deprecation is handled. I think you're right that we need some way to guarantee that boards added to coreboot aren't going to be dropped again in a short period of time, but that requires investment from companies using coreboot to make sure that it happens. When a chip is added to coreboot, how long is a company expected to maintain that chip in the coreboot repository? If we make it too short, nobody wants to develop mainboards for it. If we make that time too long, chip vendors aren't going to want to add their chips to the tree. I'm not sure how to balance that. Jan 3, 2023, 17:17 by GNUtoo(a)cyberdimension.org: > On Tue, 3 Jan 2023 18:38:02 +0100 (CET) > Martin Roth <gaumless(a)tutanota.com> wrote: > >> Hi Denis, >> - Responses inline >> > Hi, > > Thanks for the answers. > >> Jan 2, 2023, 17:16 by GNUtoo(a)cyberdimension.org: >> >> > Hi, >> > >> > The MAINTAINERS file has the following: >> > >> >> PC ENGINES ALL MAINBOARDS >> >> M: Piotr Król <piotr.krol(a)3mdeb.com> >> >> M: Michał Żygowski <michal.zygowski(a)3mdeb.com> >> >> S: Supported >> >> F: src/mainboard/pcengines/ >> >> >> > >> > But the commit f9decbb0c720662d8e71fe221aef55b7ecf76196 ("mb/*/*: >> > Remove AMD family14 boards") actually removed the apu1 >> > (src/mainboard/pcengines/). >> > >> > Is there some policy somewhere that describes what kind of support >> > to expect from maintained boards? >> Yes, It's in the maintainers file itself: >> >> Supported: Someone is continuously paid to look after >> this and a reaction to review requests can be expected >> within a few days, a month at most. >> > [...] > >> Because the maintainers may not notice the patches, it's always >> suggested to reach out to the maintainers directly for reviews. >> > As I understand that file tells only about patch review delays and not > what kind of patches are acceptable or not or who is supposed to do the > work of converting a board to the newer APIs. I'm mostly interested in > two last aspects. > > For instance as a Linux contributor, I can send a patch to add a > computer (like a smartphone for instance) or contribute fixes and new > support to existing drivers, and usually the code gets maintained > somehow automatically: > - New patches are required not to break existing code, so they have to > take care to either keep the compatibility with the old code or > update it along the way. > > Though older code doesn't necessarily benefit from new features (for > instance, for ARM, if nobody converts old C board code to the > devicetree, it will still works if people compile support for that > ARM computer, but the resulting kernel will only be able to boot on > that computer). > > The code quality requirements is usually very high in order to reduce > the amount of time required to maintain the code. > > - If I'd contribute a driver instead, I may end up being its maintainer > somehow, so I'd have to review patches. Who will maintain the driver > might also be part of the discussion when upstream will decide or not > to accept the patch for the new driver. > > - Users can test the code and report bugs. If the bugs are reported > during patch review, the burden to fix the bug is on the person who > sent the patch. > > Since there are different policies in Coreboot, I'm trying to > understand if it's possible to somehow find ways to get the same kind > of assurances than with Linux so that specific mainboards will not be > removed, and if so how to do it, how much resources it requires, etc. > We don't currently have any way to make this assurance. It depends on a number of things. Imagine that there's a mainboard maintainer, but no chipset maintainer. If the chipset isn't being maintained and is being removed from ToT because it's not supported and has become problematic, it's not like the mainboard can stay independently. As far as the resources needed, that's difficult for me to say. It depends on the chipset and the changes that are needed. Remember that the boards that are removed from ToT are not gone. We've created branches, and the boards that have been removed from ToT can be maintained on those branches. We have builders set up to test patches pushed to those branches for that reason. Those boards may not get all of the latest features automatically, but do they really need all of the latest features? Does the KGPE-D16 need an eSPI driver? No - it doesn't support eSPI. Because coreboot is a firmware project, it's very different than something that's pure software and can be tested easily. If people want to keep the chipsets and boards on ToT, we need to have people actually working to keep them there. There are a very few people at coreboot doing a LOT of work to keep the project running. We can't do everything for every board on our own. We need other volunteers who own the boards to test them, submit bugs and patches, and help with the project. Without that, coreboot has no way of even knowing if a board is actually working. > If I look at Linux, in the worst case scenario I can look at the number > of maintainers for a given driver and expect that the maintainers will > at worse, work full time on reviewing patches, so that can be roughly > calculated. > > There is also information on how to setup automatic test infrastructure > (for instance with LAVA) so the resources needed for that can also be > predicted somehow. > > Here this interest me because I'm trying to evaluate if it makes sense > for me and other interested people to contribute big changes to > Coreboot, for instance by adding back a mainboard like the Asus > KGPE-D16. If we do a lot of work and that this work is removed right > after, it's not worth it, so it's best to check beforehand than to have > some drama if the huge work is removed. > > The issue with Coreboot is that I'm unsure if I can do the same kind of > calculation than with Linux: The APU1 was removed despite the fact that > the mainboard was "supported". > As mentioned in the scenario above, the mainboard was marked as being supported, but the chipset was not. Unless someone is willing to step up as the supporter of the chipset, I don't know what to tell you. We can't really keep the mainboard without the chipset. I don't know if there's something similar in the linux hierarchy to look at, but if there is, I'd be interested in knowing how it's handled there. > So this is why I'm trying to understand how much work it is to convert > boards and for that understanding how deprecation are decided could > give me hints of the amount of work to expect in the worst case. > >> The usual reason is progress: Infrastructure module X has been >> replaced byinfrastructure module X+1. Removing X helps keep the >> sources manageableand likely opens opportunities to improve the >> codebase even more. >> > Here I am wondering precisely how the deprecation of module X is > decided. For instance can anyone convert some code in Rust and expect > everybody else to learn Rust and rewrite everything in Rust? > > Is it up to maintainers of each module to decide when to deprecate > module X in favor of module X+1? > This is typically suggested on the mailing list, beaten to a pulp, then discussed in the coreboot leadership meeting for a decision > If so what are usually the factors taken into account? I assume that if > there is too much change to do (like completely rewriting Coreboot in > Rust), I assume that they won't be able to force a change like that on > the rest of the Coreboot contributors. If that's the case it gives some > indication of the amount of work required to convert to newer modules. > > It also brings the question of what is taken into account when deciding > to deprecate module X. For instance is the maintainability of each > "modules" the only concern, or are the amount of supported mainboards > and end users a concern too? > > Is the amount of work needed to convert from module X to module X+1 > taken into account? And is there usually some documentation that > explains how to do the conversion? Or are do people need to find out by > looking at the release notes and other boards being converted? > We don't currently have a written policy about it. >> > Is there also a policy that explains when boards are removed? Or >> > what to do to prevent boards from being removed? >> > >> We do have that policy, though it could probably be written a bit >> more plainly. >> >> Here's the search in the coreboot documentation. >> https://doc.coreboot.org/search.html?q=deprecation&check_keywords=yes&area=… >> >> Here's the template for the release notes: >> >> Deprecation notices are part of release notes to act as a warning: at >> somepoint in the future some part of coreboot gets removed. That >> point must beat least 6 months after the release of the notice and it >> must be right aftersome release: That is, the specified release must >> still contain the part inquestion while one git commit later it might >> be removed. >> > That is good: at least we have a way to find that out. > >> > For instance u-boot warns when building that a boards needs to be >> > adjusted to the newer driver model. So just by building u-boot you >> > know in advance what needs to be fixed and for when. >> > >> > I've looked in the Coreboot documentation but I didn't find any >> > information about that. >> > >> >> Someone could definitely add something to put up a notice when doing >> the build, but that doesn't exist right now. If it's not something >> that you're interested in doing, you could file a bug if you think it >> should be added.` >> > I'm not sure I'm the right person to do that, and if so how I could do > it. I could probably propose a patch to the documentation though, if > it's the right place to do it. > > For the code, it's probably best if it's done in the commit that > deprecates something. For instance for CONFIG_LEGACY_SMP_INIT, we could > add the following to the Makefile in the top directory: > > ifneq ($(CONFIG_LEGACY_SMP_INIT),) > @echo "+----------------------- /!\ WARNING /!\ ---------------------+" > @echo "| CONFIG_LEGACY_SMP_INIT is deprecated. |" > @echo "| It will be removed in Coreboot release 4.18 (November 2022).|" > @echo "| Please migrate your mainboard to CONFIG_PARALLEL_MP, |" > @echo "| or it will be removed right after the Coreboot 4.18 release.|" > @echo "| See the Coreboot release notes[1] for more details. |" > @echo "| [1]Documentation/releases/coreboot-4.16-relnotes.md |" > @echo "+-------------------------------------------------------------+" > endif > > If we add that at the end of the Makefile, to have it show up at the > end of the build. We could also add a deprecation target if needed. > This way if we do that and that we use a similar format for all > deprecations, people building Coreboot will most likely see it. > > This way users will not have to read all the release notes at each > releases to catch that kind of issues, and if distributions start > packaging coreboot or other projects based on Coreboot, then they would > see that too. > I'm all in favor of that. I'll add it to the discussion of the coreboot leadership meeting on the 11th. Martin

4 6

Recent board removal for deprecated features LEGACY_SMP_INIT and RESOURCE_ALLOCATOR_V3
by Paul Menzel Feb. 6, 2023

Feb. 6, 2023

Dear coreboot folks, Two days ago, on November 7th, the change-sets of the topic *drop_LEGACY_SMP_INIT* [1] were submitted after being created on November 2nd [2]. The removal was announced on the list some time ago and was documented in the release notes. 1. RESOURCE_ALLOCATOR_V3 in the 4.16 release notes [3] 2. LEGACY_SMP_INIT in the 4.16, 4.17, and 4.18 release notes [4] (I think that planned deprecations should to be listed in each release note.) Despite the missing RESOURCE_ALLOCATOR_V3 deprecation announcement in 4.17 and 4.18, everything was done formally correct, nevertheless I would have wished, more time would have been given and the actions would have been announced once more on the mailing list. My understanding was always, that code removal will be handled more leniently, if the required changes are being worked on. This was the case here for parallel SMP init [5] and resource allocator v4 [6]. Some change-sets even had a +1 or +2. The request for testing was also fulfilled by the users. Some of the change-sets were even authored by “non-AGESA“ folks, which was awesome to see. Letting this effort go to waste without documenting somewhere, what needed to be done to finish these change-sets makes me sad. 3mdeb also invested resources into implementing some of the features. The last thing I noticed, that at least for the PC Engines board removal, the approval of the maintainers listed in `MAINTAINERS` was not given, and should have been waited for. The +2 itself were also by developers normally not (very) active with AMD AGESA Open Source boards. The points above are just my observations, and, hopefully, things can improve in the future to avoid bad feelings. I am thankful to everyone working on coreboot, and I also understand the frustration of having to maintain several code paths. Although I own and run two of the removed boards, I am fine to move to the branch *4.18_branch* although I am not happy about it, as branches also increase maintenance burden. The main reason for writing this message is to ask, if entities (read 3mdeb) have big interest in getting part of the boards back into the master branch, so that the already made investments are not in vain, and nobody is alienated from working upstream. If that is a goal, this effort should be coordinated as reverting commits is going to become harder and harder. mb/aopen/dxplplusu (Intel) is already worked on to be put back into the master branch [7]. Kind regards, Paul [1]: https://review.coreboot.org/q/topic:drop_LEGACY_SMP_INIT [2]: https://review.coreboot.org/c/coreboot/+/69111/2 [3]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.18/Docum… [4]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/tags/4.18/Docum… [5]: https://review.coreboot.org/c/coreboot/+/64892 "cpu/amd/family15: Use parallel_mp init" [6]: https://review.coreboot.org/c/coreboot/+/53990 "nb/amd/agesa/family15tn: Enable RESOURCE_ALLOCATOR_V4" [7]: https://review.coreboot.org/c/coreboot/+/69339 "Revert "mb/aopen/dxplplusu: Remove board""

3 2

Status of maintained boards and policies?
by Denis 'GNUtoo' Carikli Feb. 3, 2023

Feb. 3, 2023

Hi, The MAINTAINERS file has the following: > PC ENGINES ALL MAINBOARDS > M: Piotr Król <piotr.krol(a)3mdeb.com> > M: Michał Żygowski <michal.zygowski(a)3mdeb.com> > S: Supported > F: src/mainboard/pcengines/ But the commit f9decbb0c720662d8e71fe221aef55b7ecf76196 ("mb/*/*: Remove AMD family14 boards") actually removed the apu1 (src/mainboard/pcengines/). Is there some policy somewhere that describes what kind of support to expect from maintained boards? Is there also a policy that explains when boards are removed? Or what to do to prevent boards from being removed? For instance u-boot warns when building that a boards needs to be adjusted to the newer driver model. So just by building u-boot you know in advance what needs to be fixed and for when. I've looked in the Coreboot documentation but I didn't find any information about that. Also is there some public information on how much work it is to avoid a board being removed? Does it require to dedicate someone full time on it? Or does it usually requires less time? Also how changes that break other people's code are decided? Can anyone submit these changes and get them accepted with very few people agreeing to them? Or is there another procedure for these special changes? Denis.

3 3

[coreboot - Bug #451] (New) Fix POST code handling
by Felix Singer Jan. 30, 2023

Jan. 30, 2023

Issue #451 has been reported by Felix Singer. ---------------------------------------- Bug #451: Fix POST code handling https://ticket.coreboot.org/issues/451 * Author: Felix Singer * Status: New * Priority: Normal * Target version: none * Start date: 2023-01-29 ---------------------------------------- coreboot supports writing POST codes to I/O port 80. There are various Kconfigs that deal with POST codes, which don’t have effect on most platforms. The code to send POST codes is scattered in C and Assembly, some use functions, some use macros and others simply use the `outb` instruction. The POST codes are duplicated between stages and aren’t documented properly. ## Tasks * Guard Kconfigs with a depends on to only show on supported platforms * Remove duplicated Kconfigs * Replace `outb(0x80, ...)` with calls to `post_code(...)` * Update Documentation/POSTCODES * Use defines from console/post_codes.h where possible * Drop duplicated POST codes * Make use of all possible 255 values ## Requirements * Knowledge in the coreboot build system and the concept of stages * Other knowledge: Little experience with C and x86 Assembly * Hardware requirements: Nothing special ## Mentors * Patrick Rudolph patrick.rudolph(a)9elements.com * Christian Walter christian.walter(a)9elements.com -- 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 3