there was, but not available everywhere and not anymore.
sadly, not availeble where I can buy them. maybe second hand.
I refrain from further comments untill someone makes some coreboot progress or FW themselves. unless pm/dm/discord.
Stupid Boot Guard. We have a known working coreboot for a very similar board, it would be trivial to fill out the little bits that a non-Chromebook Intel 12th gen board would need, and jump from there to 11th/13th+. Any plans for an Intel motherboard without Boot Guard someday, Framework? You could sell it at a premium, no support needed for the firmware.
1 Like
Apparently it’s non-trivial as those that received boards without boot guard have failed to deliver a port of Coreboot nor has Framework themselves invested in this.
3 Likes
Couple of things. The unlocked laptops got sent to “some people”, unknown to the larger Coreboot development group and community. We literally have no idea what was done, FW isn’t commenting, no one in the Coreboot community heard anything, I’m not saying it didn’t happen, but it didn’t happen in a helpful and supported way. Those laptops were later reported to be bricked, again without any information about what that means or who tried what to recover them. No Framework hardware, support, or documentation has been provided to anyone publicly associated with Coreboot to my knowledge. (Edit: There is one Youtube video. Didn’t find that on my initial search.)
That’s also not the point I was making. We HAVE an existing Coreboot port that’s fully functional on the Intel 12th gen board. It’s every Framework Chromebook ever shipped. This means that if Boot Guard wasn’t a big problem (it is), we could start with the Chromebook firmware today and have something that boots right away. I’d hazard a guess that full FW 12th gen support would only take a week. Backporting to the 11th gen would likely be equally simple, since the hardware is very similar.
Porting forward to the 13th gen and up would be more difficult, but all we lack is some way to disable Boot Guard, and a little bit of support from Framework, who understandably aren’t very interested.
There’s an unofficial Coreboot proof of concept build on AMD, and there’s a shipping and supported Coreboot on the 12th gen hardware, via the Chromebook. Framework is clearly not interested in supporting/advancing these, and THAT’S OKAY, but it still makes those of us who would like Coreboot sad. That’s all!
3 Likes
Took that quite personally, didn’t you? Here’s a link to a bunch of folks on the Coreboot ticketing system saying pretty much the same things. Also, I never once said that anyone lied. I said that Framework claimed to work with some people, and they won’t identify any of them (fair), but that the larger community around Coreboot remains un-engaged (which is true, as far as I can tell).
The plain truth remains this: Framework made an overture, it didn’t work out, and the answer given is that board level documentation is provided only to authorized repair agencies, under NDA. Between this and the lack of any new developments on the three one-off laptops three years ago, it looks like Coreboot on Intel Frameworks is pretty dead. I was just lamenting that, not casting any aspersions or lambasting anyone. Framework isn’t obligated to support Coreboot, or anyone else.
3 Likes
Yeah, I agree that Framework isn’t obligated to provide a Coreboot port or Coreboot support. Yeah, this is lamentable. Given how long people have been asking for this, I seriously doubt this effort is going anywhere. At any time Framework could have said “We won’t invest engineering time/budget into backporting our older platforms but going forward we will be using Coreboot”. They have not. Skilled devs were handed hardware and it got bricked. We can assume Framework wasn’t handing out hardware to any idiot that asked for it and only those that could demonstrate an ability to do the work were given hardware. Matthew Garrett is such an individual.
I’ll cautiously say that Frameworks track record is improving on Firmware but it’s been historically atrocious. At this point, be satisfied with the proprietary firmware or purchase a laptop that uses Coreboot out the gate.
Maybe OpenSIL will change this. I’m waiting on the sidelines to find out.
A Coreboot dev (I think it was Martin) also said “ I think we all would like a framework coreboot port, and would be excited to see it happen, but it takes quite a bit of work to get an initial port done and maintained” so the work cannot both be “trivial” and “quite a bit of work”.
I have ranted and raved plenty in this thread pleading for Framework to get this in gear but to no avail. If Framework the corporation does not aid in getting Coreboot ported in a substantial way (assigning devs/paying for the port) then it’s dead. Especially since the Chromebox variant hasn’t received a hardware refresh…ever. MrChromeBox created a Coreboot “distribution” so that Linux could be run on that board. That’s the state of things today and I don’t see anything to change that status quo in the next year or so.
2 Likes
I would say that there are a number of things that need to be in place to advance coreboot on FW:
- make the FW laptop unbrickable. All this means is, if the bios, pd, ec firmware is corrupted, the is always a simple, non-expensive, no-resoldering way to recover.
- allow anyone to write their own BIOS, and not need special versions of the hardware.
- full documentation of the AMD chips, together with AMDs detailed description of what the boot process is. I.e. which registers need to be set to what, during the boot process.
- able to replace AMD proprietary firmware blobs with their own.
- FW full schematics.
Those 5 items are not in place, and unlikely to be for a long time, so coreboot is a long way away.
If 5 items did exist, anyone, even me could dabble in helping coreboot work.
For example, intel laptops can display the BIOS screens to both laptop display and external monitor. AMD cannot. The FW AMD laptop can only display BIOS screens to the laptop display. It would need a AMD firmware blob change to fix it. So no one from FW or coreboot could ever fix that. If you are wondering why displaying to both is useful:
- user using their laptop with external displays and the lid closed.
- diagnosis, maybe the laptop display is faulty, so proving that would have the BIOS display on an external monitor.
Summary:
I don’t think coreboot is going to get very far with the current lack of open documentation from all parties.
I personally would like something like uboot ported to FW laptops but you need an exposed serial port for that.
9 Likes
My current understanding of the situation is as follows:
- Intel devices with Boot Guard are virtually impossible, barring expoits.
- Intel devices without Boot Guard are challenging but possible, and in my opinion a device such as the Framework laptop will be supported relatively quickly, provided devices without Boot Guard are provided to the community. It is also easier if a similar device exists (e.g. the Chromebook version)
- AMD has Platform Secure Boot (Platform Secure Boot). This is done at the CPU level rather than the PCH level. This means if you bring your own CPU in a device with PSB it is effectively vendor locked for the rest of its life!
- AMD PSB seems to be rare on laptops and consumer devices in general, with a focus on servers/workstations. Evidently, the Framework AMD version does not have it enabled, which allowed the coreboot port.
- Current AMD CPUs use AGESA, which is proprietary and interfaces with EFI. This is the equivalent to the Intel Firmware Support Package.
- My understanding is porting coreboot to current gen AMD devices is extremely difficult but technically possible because AGESA is designed for UEFI, and it is challenging to interface with it from non-UEFI firmware like coreboot to do things like sleep.
- OpenSIL is the replacement of AGESA. It is fully open source (!) and not specific to UEFI.
- Provided OpenSIL releases in CPU used in a Framework laptop, and framework does not enable PSB, I believe we will finally have a device where anyone can do development of a practical and eventually feature-complete coreboot port, even with continued lack of involvement by framework.
Tangentially, another point against Boot Guard being enabled is that Framework cannot support a device with FW updates for ever, so if a security issue is discovered, there may be no way for the community to fix it.
8 Likes
That’s what I was curious about, the AMD framework doesn’t have PSB then? Nothing stops you from installing Coreboot? Since there doesn’t seem to be any updates since last time they showed it, too
1 Like
Well maybe Risc-V will become an option… someday. A blobless one.
2 Likes
If you mean a RISC-V board for Framework, thats exists today. If you are talking about the gulf in performance between RISC-V and x86, yeah, I hope that delta gets smaller too, substantially so.
6 Likes
I am talking about something that can compete with the intel N200 minimum.
for average linux users.
1 Like
I wanted to (repeat) a big picture question: what is the barrier to a full linux kernel running from BIOS? In my limited understanding, the original barrier was ROM size, but that hasn’t been a practical issue for a decade. The old “ROM sends the BIOS code to a chip on the Northbridge and then fires everything up” model hasn’t been standard since maybe 2010? So in a world where memory is cheap and plentiful, why isn’t COREBOOT running from a microSD card plugged into the motherboard which initiates the kernel for the OS (not just a mini kernel to initialize, but the kernel) the ideal path forward? Linux is already well adapted to flexibility wtih storage spaces and a very clear division between user and root space, while BIOS updates from within the OS are now common. ASUS had a mini OS that would run from BIOS with a browser as a failsafe in their motherboards back in the early 2010s, and you know what, it worked alright. I guess that since the death of the separate Northbridge/Southbridge and the steady decline of HDDs in favor of extremely cheap and plentiful solid state memory, the separation of the OS kernel from the coreboot mini kernel (or the analagous American Megatrends blurb) hasn’t made much sense from an 80000’ view (at least to me).
1 Like
@Adam_Schindler, for that theoretical SD card to function as the firmware, embedded motherboard firmware must first enumerate it. What you describe is already significantly more feasible than what this thread proposes, and is fulfilled by EDKII, loaded as an EFI shell. [1]
BTW, modern motherboard firmware doesn’t attempt to comply with “BIOS” norms. It adheres to the [U]EFI standard. They’re not interchangeable. The superordinate term is “motherboard firmware”, to my knowledge.
3 Likes
To be fair, I didn’t come up with this….as soon as the ROM had barely enough space, folks at Coreboot were running mini kernels on it. The coreboot payloads page doesn’t even try to enumerate the Linux-as-a-payload options….which I assume means that there were too many to list. And I appreciate the clarification of terms…I’m not a dev, if that weren’t already apparent.
2 Likes
Linux kernel as a payload, within the “bios” is a thing yes. Sadly, with framework being forced by big Intel to enable bootguard, we cant flash/run our own variation of the “bios” or firmware (a combination of actual uefi firmware, the network firmware, amoung this would allow network boot) and possibly firmware blobs for other hardware (and the awful intel ME portion, csme these days?). If possible, strip or make minimally small, sign with FW key a coreboot image or shim, and we can boot a very small kernel, with a initramfs that could pull or detect a newer larger initramfs for us to chainloud. The kernel can even be swapped to a more fully kernel.
All this magic and awesomeness stopped by sadly a Intel imposed requirement to sign firmware to check upon boot (and flashing too, but we can hardware flash the storage device. Yes, we could swap it for a larger eeprom/flashrom if needed. SPI, in theory, it could take a SD card… if the chipset understands it, can talk to it, can copy data from it, into ram)
Originally coreboot was called LinuxBIOS, and its main purpose was to start a linux kernel way more earlier then to do hardware checks and boot device enumeration. Kinda neat to look what old hardware they tried to support
4 Likes
Right, I’ve been following coreboot as a layman for many years. I remember when Intel dropped the IMEon us, but have been a long time AMD user even when it wasn’t great. That’s why I’ve been following AMD’s rumored shift to OpenSIL so closely: it’s an opportunity to revisit a cool and pretty foundational reorganization of software, and maybe there’s finally a critical mass of hardware, EFI, kernel and user interest to do it.
I wonder how ThinkPads have hardware diagnostics built into the BIOS(?)…is that some kind of a light linux kernel?
1 Like
Modern x86 firmware follows (with varying success) the UEFI standard, whose purpose in life nominally is to specify the programming interface between the firmware (partially) ceding control of the machine and the OS acquiring that control in those early moments when the OS is not yet aware enough to fully drive the hardware all by itself, but still wants to do things with it. This covers the OS loading files from disk, reporting boot progress on screen, but also the firmware finding the OS in the first place (on the “EFI system partition”) and the OS getting a vague idea of what hardware there is to drive at all.
That essential and unavoidable task is UEFI’s purpose. Nominally. In practice, as you can guess from the name of Unified Extensible Firmware Interface, they (Intel under a great deal of influence from Microsoft) just couldn’t resist adding more stuff. In particular, the “OS”, or more properly the UEFI executable, does have a way to tell the firmware it’s taking over, but it doesn’t actually have to do that. It can just do some things, call some UEFI APIs, and return, whereupon UEFI is free to execute something else. Given the fairly extensive nature of those APIs, this is beginning to look like a single-tasking OS in its own right.
Given the sucky nature of some of those APIs, the single-tasking OS in question is not, generally speaking, good. (For example, you can place pixels on screen, but you can’t learn when vertical blanking happens, so if you try to animate anything the picture is doomed to tear, pun absolutely intended. This is literally worse than the VESA BIOS extensions from the late 1990s.) But people still use it.
Motherboard vendors use it to write their firmware configuration (“BIOS setup”) utilities, because they need some set of APIs to do that, they have to implement the UEFI ones anyway, and they’re hardly going to invent, implement, and test a second completely separate one for the sole use of the setup utility. Much easier to reuse what already has to be there.
Other enterprising people use it to do diagnostics in situations when the full OS might be too picky and the hardware too broken to boot; also just because they can. For example, the “EFI shell” is a cmd.exe-lookalike interactive command interpreter that’s an optional part of the UEFI specification, but you can also just drop a copy of it into your ESP yourself. Many Linux distributions will install an OS picker called systemd-boot (ex gummiboot), because while the UEFI specification requires the motherboard manufacturer to provide one, too often their horrible code quality (cough) means it’s completely broken. And some Linux distributions will also install an UEFI port of memtest86+, a RAM tester application, because somebody already wrote it and it can be useful when your OS fails to boot.
So most probably what you’re talking about here is a mix of these two options: additional goodies in the form of UEFI executables, but written and shipped by Lenovo themselves.
(Of course UEFI can run DOOM. Also a JavaScript interpreter.)
TL;DR: If you can display a setup menu and load Windows from a FAT-formatted partition, you probably have enough tools to write a diagnostic utility as well.
3 Likes
There are two versions of the Lenovo Diagnostics UEFI, “Bootable” and “Embedded”. The embedded version is baked into the BIOS.
Hope we get something like this from Framework.
1 Like