coreboot August 2024

coreboot@coreboot.org

12 participants
28 discussions

[coreboot - Bug #522] (Closed) `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function.
by Martin Roth 22 Aug '24

22 Aug '24

Issue #522 has been updated by Martin Roth. Status changed from New to Closed Fixed with https://review.coreboot.org/c/coreboot/+/79905/ ---------------------------------------- Bug #522: `region_overlap()` function might not work as expected due to an integer overflow in `region_end()` function. https://ticket.coreboot.org/issues/522#change-1895 * Author: Vadim Zaliva * Status: Closed * Priority: Normal * Category: coreboot common code * Target version: none * Start date: 2023-12-27 * Affected versions: master * Related links: https://review.coreboot.org/q/topic:enforce_region_api ---------------------------------------- `region_overlap()` function checks whether or not two memory regions overlap. Memory regions are represented as a region struct that contains the region's offset and size. This function then relies on `region_end()` function to compute the end of the region. `region_end()` function is susceptible to an integer overflow, which might result in the incorrect behaviour of `region_overlap()` function. An example of inputs that lead to wrong behaviour: ``` struct region r1 = {SIZE_MAX - 10, 20}; struct region r2 = {SIZE_MAX - 20, 15}; ``` It returns 0, but since the regions actually overlap, it should return 1. `region_overlap()` function is used in `smm_region_overlaps_handler()` function, which is itself used in SMI handlers to validate address values that come from an untrusted environment. This is necessary to prevent security vulnerabilities such as described in [BARing the System by Yuriy Bulygin, Oleksandr Bazhaniuk et al.](https://www.c7zero.info/stuff/REConBrussels2017_BARing_the_system.pdf) We do not have an example of an exploit based on this incorrect behaviour and are aware of the existence of one. However, theoretically, this could lead to security vulnerabilities. This bug was found during an ongoing [Coreboot Formal Verification Project](https://zaliva.org/UCSC-Twisted-Presentation-20231211.pdf), which aims to prove some important security properties of the coreboot’s SMI handler for the Gemini Lake/Octopus platform using Coq proof assistant and Verified Software Toolchain framework. ---Files-------------------------------- diff.txt (930 Bytes) -- 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

2024-08-21 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 22 Aug '24

22 Aug '24

# 2024-08-21 - coreboot Leadership Meeting ## Attendees Martin Roth, Maximilian Brune, Werner Zeh, Nico Huber, Felix Held, Jon Murphy, Jonathan Hall, Karthik R, Matt DeVillier, Julius Werner, David Hendricks, Ron Minnich, Felix Singer, Mina Asante. ## Announcements & Events * OSFC will be in Bochum Germany - September 3-5 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api] * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Martin] coreboot relies on VBOOT, but the API isn’t stable. Currently we can’t build coreboot without vboot at all. How do we want to handle this? * [Matt] For the majority of chromebooks, vboot is used in downstream builds, so has become a requirement. However one can’t update just the RW portion because the API has changed. You’re basically committing to a single version of coreboot & vboot when you create an RO. * Do we want to fork VBOOT? * This would create a number of issues * We can have multiple versioned VBOOT submodules. * Create a new VBOOT submodule version * Can we create submodules based on the final patch of vboot version * Julius: The real solution is to fix the board. * Can Google help us to specify and stabilize ABI versions? * Julius: coreboot has this own issue itself - When we update the car layout for example * Jon: Just because there are issues in one area doesn’t mean we shouldn’t try to fix it in other areas. We can look at fixing the different areas individually. * Julius: This would halt progress if we can’t change things. * Martin: we’re not saying that we can’t change things, just that we draw a line when we do change things. * Jon: Things should try to be backward compatible. * Julius: This isn’t a vboot problem - it’s a coreboot problem in general. * Jon: This is at least a starting point. * Martin: VBOOT is *AN* issue, let’s take issue one by one. * Julius: There are too many issues, and it may be a waste of time to try. * Jon: Let’s try to draw a line - we won’t fix everything, but let’s try to create mechanisms. We can at least try to separate coreboot & vboot. Let’s write a design doc to deal with this. * Julius: We’re already working to encapsulate vboot. It’s a more realistic goal to try to hold any breaking changes to a certain time. Keeping things stable for a year isn’t realistic. * Werner: Has google run into this? How does google handle it? * Julius: We cut a branch and ship any updates from the branch. * Jon: i’m not suggesting an annual roll. Just giving a year to come up with a plan. The current google method is problematic. This change would help both google and the community. * Martin: We can do quarterly releases of breaking changes like we do with toolchain updates. * David: Can we break the build when there’s a backward-compatible breaking changes? Google can create branches for porting features and test all their products, but upstream cannot. Our goal upstream is to avoid breaking boards in the upstream main branch, so it will help to signal to our builder that something is broken so incompatible boards can be removed. * Martin: It’s more of a boot test than a build test. The new RW wouldn’t be backward compatible with the old RO. * Werner: what breaks? * Matt: Basically the structures are no longer compatible. Changes to the major and minor versions will halt the boot. We want to avoid having downstream dependency break upstream coreboot. * Jon: Software versioning is an industry practice. Why can’t we update vboot for backward compatibility? Disable features that aren’t compatible. * Julius: The CAR stack size for intel was incompatible. To be compatible, you have to add asm and move things by the exact amount. This would be very early. For the AMD board, can we just update a new signed verstage? * Matt: Yes, we just got a new update. There was a 2 year period where things were broken. * Martin: we can add a check in the CI to make sure that an update to the vboot version number breaks the build. This would make sure that people are notified and new signed verstages are published. * Martin: Let’s work towards marking all backwards breaking changes. ### [Martin] We had a meeting with the SFC last week. * We currently have over $70K in the bank and our current expenses are around $20K per year for the server infrastructure. * We should again look at how we want to spend this, and who is going to manage the projects spending the money. SFC will help in this process. We’ve agreed that we (the coreboot project) do _not_ want to pay anyone for writing patches. * Some thoughts we’ve had for our needs in the past: * someone to do documentation * someone to help with reviews * a community manager (Mina is doing parts of this job now, but the job could be expanded significantly.) * Update the website SFC will help with a fund-raiser. * Currently, our main supporter is Google, who has donated $50,000 over the past two years. * [Jon Murphy] Google is willing to contribute more, but requires written justification. I can request $25,000 this year, but need to write a one pager on what it’s used for. Can I get help? Can the community take this action and include me [Jon Murphy](jpmurphy(a)google.com) * Martin will write something up as to what we want to use this money for. * If we’re actively spending the money, especially on salaries, the money goes fast, so we should look at * What should our priorities be? * MattD: A website is probably the first item. * Werner: This doesn’t need coreboot expertise. * FelixS: Documentation and a website. * Max: For documentation, we’d really need someone who already knows coreboot * Martin: My thought was that we want a tech writer who can learn the coreboot project. * David: Agree with Max - documentation tasks would have to be scoped to be very high-level for this to work. * Matt: We can separate this into 2 parts: the project documentation and the implementation/developer documentation. * Ron: Documentation needs to be structured as something ongoing. It’s typically out of date as soon as it’s written. * Max: Agreed - we have breaking changes and updates. * Martin: Right - we want to have a writer who keeps updating things. * There’s a stringent process on how to hire people. There’s a bidding process and a lot of rules. * David: We may have legal expenses - there’s a company using the coreboot logo without supporting coreboot, and have a generally terrible reputation. Not sure if legal funds come from SFC's 10% or if that would come from our budget. ### [Werner] Intel asks for feedback from the open source community on how open source is received. * They currently have the opinion that open source isn’t worth it and base it on their experience with EDK II. * Werner: We have meeting with intel, where we ask for more open source. Recently we had meetings where there was friction. Intel tried with edk2 and don’t see that it works. Offered to ask the community about why edk2 isn’t a good example. Why did it fail, and how can things be done better? * Ron: Clearly open source works - they’re a big contributor, but you can’t just dump anything out there and expect it to work. Edk2 is viewed as being a dumpster fire. * Werner: This comes from the firmware group * Nico: Continue the comparison with the linux kernel. Edk2 is completely different. It tries to be internal binary compatible. * Werner: it’s not that the code is bad, but the way it’s run * Matt: Trying to upstream into edk2 is very difficult, moreso than linux. Patches stagnate, hard to get code reviews. Dev process is difficult. Sean has had similar issues. * Ron: There is an open source culture and EDK2 hasn’t adopted it. They don’t accept change well. * Max: posted link to blog post. EDK2 is more closely linked to closed source. coreboot is different because it’s based on open source. We don’t upstream to edk2 because it’s too difficult. * [https://blog.aheymans.xyz/post/uefi-coreboot-comparison/] * Werner: is there a community around the EDK2 project * Max: Yes * Werner: Can I set up a doc to further the discussion? [Feedback on EDK 2 as open source project](https://docs.google.com/document/d/1P3GLpCufykSID1MjhSU47wI7nM-Jgb… * Feel free to add your thoughts on this into this doc and share it with whomever is interested in being part of this discussion. * Max: May accept github PRs now. * FelixS: Did intel give any reasons why it failed from their perspective? * Werner: not yet. * FelixS: My thinking is that theirs is currently an empty statement to prevent any further discussion. * Ron: Big question is what’s in it for you? They failed at open source, it didn’t fail them. * Werner: I don’t want to pass up an opportunity and get blamed for it. ## INFO ### [Martin] Patches Review Meeting Feedback * The 2nd review meeting was Wednesday, August 15th. There was positive feedback again about the usefulness of the time spent. Reviewed ~15 patches. The feeling is that anything that we can review and get moving is to the project’s benefit. ### [Martin] Looking at uncrustify as an alternative to clang-format. * David: Search gerrit for uncrustify. We tried it on flashrom a while back and had some promising results, but it fell somewhat short. I'll be interested to see how you approach it. ### [Martin] Info:coreboot 24.08 Release * Release tag planned for Thursday. * Please mark anything you want to be merged with the hashtag “coreboot_release_2408”. * Mark anything that should be merged after the release with the hashtag “post_coreboot_release_2408”. **Completed Action Items** * [Done] Martin: Work on [clang-format config update](https://review.coreboot.org/c/coreboot/+/7883). * 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 example](https://review.coreboot.org/c/coreboot/+/78833/4/src/drivers/intel… to 78833 * Let’s look at running this just for .c files to start with. * [Done] PatrickG, FelixS, MartinR: Look at improving the responsiveness of gerrit. * This had a number of causes, mostly related to running out of storage, as well as both of the NVMe drives going bad. We’ve reduced the amount of data being saved by jenkins and replaced the NVMe drives # Next Leadership Meeting * September 4, 2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.

1 0

Re: Stable RO/RW ABI discussion
by Julius Werner 22 Aug '24

22 Aug '24

[resent with correct sender address] Hi, I wanted to pick up the discussion from the leadership meeting again here because I think it's easier to show my point with a few examples. If you want an old coreboot RO build to work together with a ToT RW build, then you don't just care about the vboot workbuffer matching... *everything* that is shared in any way between bootblock/verstage and romstage/ramstage/payload needs to be kept in sync or risks introducing dangerous and not necessarily immediately obvious errors. One major issue is the pre-RAM memory layout. Take for example this simple one-line CL: https://review.coreboot.org/83680 . Would most reviewers expect that it makes RW firmware built after that point incompatible with RO firmware built before? Well, it does, because it increases the size of a memory region here https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/src/… which then moves the offsets of all subsequent memory regions downwards accordingly. Some of these regions contain buffers that were passed by the bootblock to later stages (e.g. CBFS_MCACHE, FMAP_CACHE), and when the romstage tries to reuse those buffers it suddenly finds different data at the same offsets. We actually had to figure out how to support this for an RW update to one of our shipped Chromebooks, and it looks like this: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/… . It needs an ugly, complicated assembly hack to copy bytes around from the locations where RO firmware left them into the locations where RW firmware expects them. Since one of these regions is the stack, you can't even do that in C code because you might already be trampling over the data you're still trying to save once you enter a C function. And this patch is just tailored to this one particular case (and platform), it's not a universal solution — if we were resizing a different region, or swapping the order of two regions, that would require a completely different (maybe impossible) workaround. Now, we could try to replace our simple memory region management with something more complicated that comes with a built-in tagged directory (kinda like a second CBMEM in pre-RAM). Then, if every single access to one of those regions went through that directory, it would automatically find the right location. We would need to write the code to parse that directory in assembly for every architecture, since the stack setup is one of the things that uses them. But even then, that doesn't solve the resize problem: if we e.g. find a rare stack overflow in the FSP that requires us to have a bigger romstage stack, then we can't just reuse the directory the bootblock has written, we need to actually change it to fix that bug and move all those regions around to fit the new requirements. And what if migrating from the old to the new layout on the fly is not possible? If we flip the order of two sections, there might not be enough free scratch space to temporarily save the contents of one section while we move the contents of the other into its place. (Note that car.ld is only the shared pre-RAM layout for Intel platforms. Every Arm and (recent) AMD platform has their own separate layout like this, and some of them tend to be very tight. We regularly have to land patches like https://review.coreboot.org/78970 to make some sections larger or smaller so that things still fit on certain platforms. Each of those changes would lead to one of these situations where suddenly the romstage needs to move everything into a different place from where the bootblock left it because it needs space for new things that the older code didn't account for.) There are plenty of other dependencies between RO and RW stages, many of them very abstract and platform specific. For example, on Arm SoCs we often have a clock tree where a few shared top-level PLLs get multiplexed onto many peripheral devices that each have their own pre-divisors. The PLLs are usually set up by bootblock code (because some of them are needed very early), and the peripheral divisors are usually configured by the driver that initializes that peripheral. If you e.g. initialize an I2C controller in ramstage to 400KHz, the I2C driver can calculate what divider to set based on the target frequency and a #define constant of what the top-level PLL was set to. But what if for some reason the top-level PLL frequency needs to change? Today we'd submit a patch to change that #define and all the peripheral driver code will continue to calculate accurate divisor values. But if you then try to combine that RW ramstage with an RO bootblock built before that change, suddenly your divisor will be calculated with an incorrect value and your I2C clock will either be too fast or too slow, resulting in maybe the peripheral not working, or maybe your boot speed just regressing in a way nobody will ever track down, or maybe the bus running slightly too fast so that on 99.9% of devices it will still work but on 0.1% of devices you suddenly start having an awful heisenbug that will be a royal pain to track down. There can be a near-infinite number of scenarios like this on various platforms where code running in a later stage depends on some hardware initialization that code running in an earlier stage did, and I see no practical way to track them all even if we did try to implement explicit backwards-compatibility for all of them. vboot is an optional feature in coreboot and most people aren't even using it. How are we going to get every developer/reviewer to care about whether a change they're about to make could subtly break compatibility for a feature they've never used? And even if we did find a way to perfectly track every possible dependency and wanted to implement backwards-compatibility for all of them, what is the cost for doing so (both the effort of writing it, and the amount of extra romstage code we need to carry around in our binaries)? Not every incompatibility is easy to fix up once you detect it. Let's go back to the vboot workbuffer, for example: the workbuffer contains among other things a couple of data structures that have been read from the TPM and contain information relevant at various points in the boot flow. Right now, two of those (secdata_firmware and secdata_kernel) get loaded in verstage, while the third (secdata_fwmp) only gets loaded in our payload. But we have been discussing that we might want to (for various reasons) change this in the future so that secdata_fwmp is also loaded in verstage. Let's say we make that change, and we want to stay backwards compatible to RO firmware built before it. That means that early in romstage, before any new code that depends on secdata_fwmp runs, we'll need to run some code that checks the workbuffer version and fixes this incompatibility if it is too old. But in order to be able to load secdata_fwmp, we'll need to link the entire TPM driver stack into romstage which otherwise wouldn't be needed there on many platforms. So we are bloating our binary size in a potentially space-restricted pre-RAM stage just to be able to fix an issue that most people are never going to care about. Multiply that by the dozens of possible incompatibilities that will accumulate over the years. I totally understand that it would be great if we could just build a system where you can just run any RO and RW together and have them work it out, but I really don't think that's feasible in practice. vboot was not designed to support that, for good reason. And if we tried to just get started on adding compatibility code for specific issues that people have on a specific platform right now to "see how far we get", I don't think it's going to work out in the long term and it will just lead to disruption and extra code complexity right now that's eventually not going to pay off for anyone. It may work for the one platform you care about for a while but sooner or later there'll be another compatibility break that you can't easily mitigate. And if people start to rely on this working then they may get angry if someone else makes a change that is going to break compatibility on their platform in a way that can't be fixed, which I think would be a bad thing, because we do need to be able to develop new features and fix architectural issues (both in vboot and in other code that can cause RO->RW dependencies) unburdened by legacy code from years ago.

4 5

[announce] flashprog v1.2 is ready!
by Nico Huber 20 Aug '24

20 Aug '24

Hi all, I'm happy to announce the flashprog v1.2 release. This one should be particularly interesting for developers: We have finally added the first bits for multi-i/o fast reads and QPI support. QPI works well with a new driver for programmers based on the FT4222H. Dual- and quad-i/o reads are also implemented for the Dediprog SF600 and its successors. Of the latter, the SF600Plus-G2 is fully tested. Other versions, using the same protocol, should work as well. Dual-i/o is enabled by default for these. With all four i/o lines connected, quad-i/o reads can be enabled with $ flashprog -p dediprog:iomode=quad (don't forget to also set the `spispeed` to go even faster) SF600 models that use older protocol versions should work as well but are untested. For those, `iomode=dual` is necessary for dual- i/o. Test reports are most welcome! See also the full release notes at [1]. The code is available in Git[2] (tag `v1.2') and as tarball[3]. After the release is before the release, and we are currently loo- king for testers of new chipset support: On the Intel side we have patches prepared for Snow Ridge, Meteor Lake, and Emmitsburg (PCH) (newer Xeon-SP systems) [4]. For AMD, everything up to and including Zen 4 is supported as long as the chipset is not too locked down. More testing here would be welcome, though, so we know what configurations vendors ship. Happy flashing, Nico [1] https://flashprog.org/wiki/Flashprog/v1.2 [2] https://github.com/SourceArcade/flashprog [3] https://flashprog.org/releases/flashprog-v1.2.tar.bz2 [4] https://review.sourcearcade.org/q/status:open+topic:moar_ichspi

1 0

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

19 Aug '24

Dear coreboot community, Please be reminded that our upcoming leadership meeting is scheduled for Wednesday, August 21, 2024.[1] Kindly take a moment to review the current agenda and share your thoughts or suggest additional items you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda ### [Martin] coreboot relies on VBOOT, but the ABI isn’t stable. Currently we can’t build coreboot without it at all. How do we want to handle this? * Do we want to fork VBOOT? * Can Google help us to specify and stabilize ABI versions? ### [Martin] Looking at uncrustify as an alternative to clang-format. ### [Martin] We had a meeting with the SFC last week. We currently have over $70K in the bank and our current expenses are around $20K per year for the server infrastructure. ### [Martin] Patch Review Meeting Feedback * The 2nd review meeting was Wednesday, August 15th. There was positive feedback again about the usefulness of the time spent. Reviewed ~15 patches. The feeling is that anything that we can review and get moving is to the project’s benefit. ### [Martin] Info:coreboot 24.08 Release * Release tag planned for Thursday. * Please mark anything you want to be merged with the hashtag “coreboot_release_24.08” * Mark anything that should be merged after the release with the hashtag “post_coreboot_release_24.08” ## Announcements & Events * OSFC will be in Bochum Germany - September 3-5, 2024 https://www.osfc.io * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

[coreboot - Bug #121] T520: Hangs in OS
by Anastasios Koutian 17 Aug '24

17 Aug '24

Issue #121 has been updated by Anastasios Koutian. Have been using this change: https://review.coreboot.org/c/coreboot/+/78609 since it was merged (May 23) and haven't seen any freezes. It's possible that this solves the issue. Can others confirm? ---------------------------------------- Bug #121: T520: Hangs in OS https://ticket.coreboot.org/issues/121#change-1893 * Author: Firstname Lastname * Status: In Progress * Priority: Normal * Category: chipset configuration * Start date: 2017-06-09 * Affected hardware: SNB, IVY * Affected OS: - ---------------------------------------- I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors. Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing. Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs. ---Files-------------------------------- config (20.7 KB) dmesg.txt (57.3 KB) cbmem-raminit.txt (62 KB) lspci.txt (29.6 KB) cpuinfo.txt (3.94 KB) defconfig (1023 Bytes) defconfig (699 Bytes) -- 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 Meetings Announcement And Agenda Call
by mina＠coreboot.org 16 Aug '24

16 Aug '24

Dear community, Please note that our next coreboot leadership meeting is scheduled for Wednesday, August 21, 2024.[1] Kindly take a moment to update the current agenda with matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Assistance Required: MSI PRO Z790-P WiFi DDR4 - No Display Output After Coreboot ROM Update
by William Chen 15 Aug '24

15 Aug '24

*Dear Coreboot Support Team,* I hope this email finds you well. My name is [Your Name], and I am currently working as a BIOS developer. I am reaching out to seek assistance regarding an issue I have encountered while working with Coreboot on an MSI PRO Z790-P WiFi DDR4 motherboard. *Issue Description:* I successfully updated the ROM on the aforementioned motherboard using Coreboot. After flashing the ROM and powering on the system, the motherboard appears to be functioning—fans are spinning, and the board is receiving power—but there is no display output on the monitor. The motherboard has two display outputs: one DisplayPort and one HDMI. Since I do not have a suitable connector for the DisplayPort, I am using the HDMI output for display. Unfortunately, there is no signal on the monitor, and I am unsure whether this is related to the HDMI output, Coreboot configuration, or another issue. *Steps Taken:* - Confirmed the motherboard powers on correctly (fan is spinning). - Verified the HDMI cable and monitor are functional by testing with another system. - Double-checked the ROM update process to ensure there were no errors. *Request for Assistance:* Could you please provide guidance on how to resolve this issue or suggest any troubleshooting steps that I might have overlooked? Any advice or support would be greatly appreciated, as I aim to ensure proper functionality with Coreboot on this specific hardware. Thank you in advance for your time and assistance. I look forward to your response. *Best regards,William*

1 0

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

13 Aug '24

Hello coreboot, Please be reminded we are having a group review session tomorrow: https://meet.google.com/kpu-yozw-gtt. Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html. We’ll be reviewing a few RFC patches together, then switch to reviewing patches individually for a bit, but everyone will be available if you have questions about the patch you’re reviewing. Here’s the link to the list of patches to be reviewed: https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY… If you have patches you’d specifically like the group to review, please add them to the top of the sheet. Given the limited time for the review session, any reviews that are done before the session are highly appreciated. Thank you. Best regards, Mina.

1 0

[coreboot - Support #550] (New) Help with dGPU integration with edk2 on W530
by Simon Dominic 09 Aug '24

09 Aug '24

Issue #550 has been reported by Simon Dominic. ---------------------------------------- Support #550: Help with dGPU integration with edk2 on W530 https://ticket.coreboot.org/issues/550 * Author: Simon Dominic * Status: New * Priority: Normal * Target version: none * Start date: 2024-08-09 * Affected versions: master * Affected hardware: Lenovo ThinkPad W530 ---------------------------------------- I run Debian and Windows 11 on my corebooted Thinkpad W530 with edk2 payload. Until recently I was using SeabBIOS, which in my experience has been a lot simpler to set up and integrate the dGPU via vga bios. The dGPU is necessary to use external displays for the W530. With a lot of [help from Matt DeVillier](https://ticket.coreboot.org/issues/549), I made the switch to edk2 with this defconfig: ``` CONFIG_USE_OPTION_TABLE=y CONFIG_VENDOR_LENOVO=y CONFIG_CBFS_SIZE=0x300000 CONFIG_VGA_BIOS_DGPU_ID="10de,0ffc" CONFIG_VGA_BIOS=y CONFIG_IFD_BIN_PATH="descriptor.bin" CONFIG_ME_BIN_PATH="me.bin" CONFIG_GBE_BIN_PATH="gbe.bin" CONFIG_VGA_BIOS_FILE="vgabios/8086,0166.rom" CONFIG_HAVE_IFD_BIN=y CONFIG_BOARD_LENOVO_W530=y CONFIG_HAVE_ME_BIN=y CONFIG_USE_ME_CLEANER=y CONFIG_HAVE_GBE_BIN=y CONFIG_MAINBOARD_USE_LIBGFXINIT=y CONFIG_VGA_BIOS_DGPU=y CONFIG_VGA_BIOS_DGPU_FILE="vgabios/10de,0ffc.rom" CONFIG_ELOG=y CONFIG_PAYLOAD_EDK2=y CONFIG_EDK2_BOOT_MANAGER_ESCAPE=y CONFIG_EDK2_FOLLOW_BGRT_SPEC=y ``` If I set graphics initialization to "Run VGA Option ROMs", the system completely hangs and I get a white underscore. libgfxinit works. With nvramtool. I can set hybrid_graphics_mode to "Dual Graphics". Interestingly, external displays is working on (Debian) **Linux**, but only detects the Intel iGPU. Specifically, even though I've chosen dual graphics, fastfetch only shows that one GPU, and not "GPU 1" and "GPU 2", and yet I get the functionality of the dGPU of external displays. On **Windows**, external display functionality doesn't work, and Windows Updates does not install Vulkan or Nvidia drivers like it did with the stock bios. When I change hybrid_graphics_mode to "Discrete Only", I get a black screen on boot. This can be reversed by resetting the CMOS settings by disconnecting the CMOS battery, removing the battery and powering on with just the charger plugged in. What can be done to have the dGPU actually properly detected (both Linux and Windows), and not cause black screen when selecting discrete graphics only? -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2024