I can’t say I speak for the entire thread, but I think OpenCollective seems like a great choice. Also if framework (@nrp) would be willing to embrace this and even match contributions as suggested by @Kent_Brockman 
, we could really get the ball rolling. I also think targeting the latest generation mainboard possible is probably the best idea (edit: [concensus]). It is also optimal to have a scaleable solution such as the one suggested by @Matthew_Garrett, albeit I think that a signed release by framework is currently the most realistic strategy.
Would you be able to speculate on how much overlap in work there would be between the coreboot porting efforts for 11th, 12th and 13th Intel generations?
I think if only one is chosen (to start with), it ought to be the 11th gen. Not because that’s the one I personally own, either! 
Rather, I would assume this is the one with the most units already out in the wild (although if that’s not the case, and if someone from the Framework team could share which generation has had the most units shipped, that would certainly be useful!).
1 Like
I think the effort should be started on whichever generation would be easiest to port to coreboot.
2 Likes
Don’t think they will disclose that information as that would give an indication of the health of the company and could affect investors.
1 Like
Hmm, not sure I agree with that. To be clear I’m not asking for specific sale numbers.
If Framework were to officially state “the 11th gen is our most sold SKU, followed by the 12th gen, followed by the 13th gen” that would mostly make logical sense - the 11th gen has been around the longest. If they were to note that the 12th gen has outsold the 11th gen, that would actually point to an increase in sales demand since originally launching the 11th gen, which could only buoy investor confidence, right?
I wonder how easy such a thing would be to ascertain? I can imagine newer generations being more difficult, since things like newer USB4 controllers and such have only gotten more complicated…
I understand your reasoning @samcday, but in the (hypothetical) case we lose momentum in the future and coreboot never becomes the standard on framework laptops. I would like to have a laptop with coreboot that is usable as a modern laptop (and to a large extent repairable and up-gradable barring the mainboard) for longer. That being said I would be more than willing to contribute to an effort at porting coreboot to any framework mainboard. I think reaching a consensus would be beneficial to this effort.
EDIT: I also think starting with the latest possible mainboard provides more of a direct path to port newer ones.
2 Likes
This information could be positive or negative. The point being is that that kind of information can affect the company in some way and as a startup, you’d want to instill and maintain investor confidence. For example, if they said 12th gen was the best selling, an investor could negatively interpret that information. Why isn’t 13th gen outselling 12th gen? Is demand at the same point after launch lower for 13th gen versus 12th? Point is it can be sensitive company information and we don’t know what information Framework releases to its investors. Another way to get the info you want would be to do a community poll to see which gen has the most number of people interested in coreboot and/or willing to fund development.
1 Like
I am daily driving my 11th gen (i7-1165G7) Framework laptop today. In fact I’m writing you this message from that very laptop. I use this laptop for most everything, and I’m a software engineer that likes to do compile-y and Rust-y things on a regular basis. This laptop is absolutely usable as a “modern laptop”, at least by my definition of a “modern laptop”, which I appreciate could be considered a rather subjective term 
I expect this laptop to remain “modern” for at least another 2-3 years by most peoples’ standards, and probably another 2-3 years beyond that.
I see your point and concern though, and this is why I think it’d be great to get some kind of temperature test from Framework officially. If 11th gen is in fact their most sold unit (which I suspect to be the case), then ensuring that coreboot is available for that generation ensures that it’s available for the most number of potential candidates.
There’s lots of different ways to view this whole thing, though. You might care about coreboot because you’re buying a new laptop. You might care about coreboot because you’re buying an old laptop.
For example, let’s say 2 years from now 11th gen is well and truly out of manufacture and Framework (the company) have their hands full supporting 2-3 generations of Framework 16, and 5+ generations (both Intel and AMD) of Framework 13. It seems less likely that Framework will have the appetite or bandwidth to ensure security updates and further QoL improvements are made available (in a timely fashion) for the older generations.
3 Likes
I say this because I don’t want people suffering burnout going for the most complicated task and then getting frustrated. It’s important to get the base stuff first before diving into the harder stuff; also I wonder if the people in oreboot (coreboot but rewritten in Rust practically) can help? GitHub - oreboot/oreboot: oreboot is a fork of coreboot, with C removed, written in Rust.
2 Likes
I’m not proposing that kind of information be made public, though. That would only be known if specific numbers were provided, with rate of change. There’s no way 13th gen mainboards have outsold 11th gen already! Those have only been available for a few months, the 11th gen has been sold (and also re-sold as refurb) for a couple of years now!
This is an excellent idea.
One thing I’m absolutely certain of: getting coreboot working on any Framework generation is not a good idea for someone currently suffering, or recently recovering from, burnout. 
Modern x86 platforms are horrifyingly complex, they are comprised of 30+ years of standards and technologies layered on top of each other. It’s a miracle anything even works at all.
The only reasonable candidates to be working on such a project are extremely knowledgeable and experienced hardware hackers who grew up with this sort of thing, or folks who are commercially involved and have a monetary interest to do such work.
Take a look at the technical blog for Asahi Linux, for an example of what I mean. The project lead and founder, marcan, is the same fella who was doing stuff like this 10+ years ago: Search for person "marcan" - media.ccc.de …
1 Like
A vote on this isn’t productive and would only lead to more stress on the coreboot maintainers, I think they should decide what generation they should focus on if this happens at all tbh.
2 Likes
I agree, something is better than nothing. I think going for whatever generation is easiest is a good compromise and probably beneficial towards the general attempt at achieving a port.
ooof, another one of those “rust” projects. anyway, looking at their page, an Alwinner D1, awesome RISCV so they did a good choice, but no other support for anthing else but qemu. so nope, not in a while. we need x86_64 atleast (and coreboot does it with i386 anyway at first, due to system bringup). well see where this will go, but i guess if we want a shot at this, it be coreboot (or maybe libre)
1 Like
Maybe there should be a channel in Framework Discord? Or can we create a Matrix or Discord channel? To talk more efficiently.
1 Like
This brings me a lot of hope for the future of Coreboot, MSI Z790-P is a modern motherboard!
4 Likes
Was randomly trawling the Framework forums this morning and stumbled across this thread about enabling Resizable BAR. It was originally opened about a year ago. Whilst the participants in there have found some workarounds to enable ReBAR, there’s never been any official Framework assistance or response to this matter.
I think this is a great example of why we need something like coreboot. ReBAR didn’t matter so much a couple of years ago (though I do remember messing with it years ago whilst trying to get GPU passthrough working under Xen…), but it matters more today with the mainstream release of Arc GPUs.
Looks like coreboot supports ReBAR enablement: https://github.com/coreboot/coreboot/blob/master/src/device/Kconfig#L668
So, pretending that we already had coreboot firmware shipped when this thread was first opened, I can imagine a scenario where someone from the community says “huh, let me try a build of coreboot with PCIEXP_SUPPORT_RESIZABLE_BARS enabled…”, produces said build, and it’s available for testing the next day, and in a stable release the next week/month.
3 Likes
It’s great that coreboot now has official targets for the absolute latest chipsets, but FWIW we were already at the point that it could be considered to run on “modern motherboards” last year: https://www.phoronix.com/review/coreboot-adl-dream
I’d be curious how much work from that Z690 enablement was useful for the Z790 bring-up. If the answer is “alot” then likely we’d see the same re-use if the bring-up is done for 11th gen and then that work is carried forwards for 12th gen + 13th gen bring-up.
2 Likes
Are there different implementations of Coreboot?
As a System 76 GALP5 owner, I’m not all that fond of Coreboot’s options. Granted I’m not a developer so maybe you need to be one to be able to configure it to your heart’s content. But from my POV, the firmware is stripped down and doesn’t give me access to settings I’d need from something like Phoenix.
To this day, no idea how to switch to legacy mode (it doesn’t seem to have that), configure TPM, memory timing/speeds, edit boot entries (requires knowledge of bcdedit or efi cmd line tools), etc.
Again, probably have OS-level config tools, but System76 doesn’t have an all-in-one firmware settings app (nothing like a GUI that exposes traditional firmware/BIOS settings). They have command line packages for various things like power management, battery charging limitation setting, etc.
Coreboot is amazing for some people who has a handle on that kind of access, but not everyone does. There are still people who complain about System76 use of Coreboot. Yes it’s faster because it’s stripped down, but not everyone wants it stripped down. Most people are just used to a traditional firmware.
If Framework can offer two different firmwares you can swap between easily, then sure.
System76 offers a way to get the proprietary firmware back on the laptop but I believe it requires special tools most people don’t have.
I’m personally having issues with dual booting PopOS and Windows 11 on my GALP5 and Coreboot left a very nasty taste in my mouth right now. Waiting on System76 to fix the issues turned it into a Linux only laptop for me (which isnfine for those whomuust want Linux) . They didn’t release a new firmware until my laptop was 2 generations old. And it still didn’t fix the issue.
I don’t want this to happen to my Framework laptop.
Here’s a video of mine showing System76 Coreboot.
3 Likes
Are there different implementations of Coreboot?
Coreboot is kinda like the Linux kernel. It’s a low level codebase that handles the super early initialization (from cold power-on) of the various bits of silicon in your computer. It’s the software that is initializing your DDR memory controllers, pulling the CPU up from 16bit real mode thru to 64 bit, etc.
I think the Linux kernel analogy is especially apt when you think about something like a BIOS configuration screen. You wouldn’t expect the Linux kernel to present a GUI on a screen. It provides the low level DRI stuff. But then you need something like Mesa to implement 2D/3D rasterization APIs, a Wayland display server implementation (e.g Weston), and then finally a window manager (like Mutter) to handle drawing pretty UI elements and such.
So yeah, coreboot isn’t really for someone who just wants to press F1 and configure some settings graphically before booting into Windows or a vanilla Ubuntu installation. It’s for power users, system integrators, and such. Of course, there’s nothing stopping someone from implementing a fancy GUI payload on top of coreboot that functions similar to what you typically expect from a proprietary BIOS blob.
To this day, no idea how to switch to legacy mode
Someone with more experience can speak specifically to this, but if you’re referring to CSM mode I dunno if coreboot would ever bother supporting that.
As mentioned, Coreboot is very low level. It configures memory controllers, uploads FSP blob to your Intel CPU, and then it hands over to a “payload”. The typical payloads you’d be using are either SeaBIOS (for the legacy BIOS you’re probably looking for) or TianoCore (for a UEFI boot environment).
Coreboot is very niche. As noted in this thread, you can count the number of standard mainstream ATX/ITX mainboards produced in the last decade supported by coreboot on one hand. It has a lot more adoption in the netbook world because Google chose it for Chromebooks. But Google doesn’t want you to configure a Chromebook any further than the cart customization you do every 3 months in their checkout page so that we can all drown in e-waste.
I can imagine that coreboot gains a lot more traction over the next few years, which attracts more vendor interest and demand for end-user-friendly GUI configuration tools, either at F1 on boot, or from userland in a booted OS.
In summary, I wouldn’t expect Framework to completely drop the current InsydeH2O payload shipping on their laptops today. In fact, I would expect a consumer-focused company like Framework to continue shipping that BIOS (or something like it) by default indefinitely.
As I’ve noted earlier, it’s more about what happens 5 years from now when Framework stop supporting their old 11th gen laptops. It’s also about enabling folks to do whatever they want to do with their Framework mainboards once a laptop has reached its end of life. Or put differently, preventing an item from ending up as e-waste.
10 Likes