Hmm… but then how does google prevent users from leaving chromeos on many chrome devices?
They don’t. In fact, they have pretty good developer documentation and have long supported a “developer mode” where you can do whatever you wish to your system.
There are usually restrictions if I recall correctly in escaping chromebooks. Or am I wrong?
If the system belongs to your workplace or school, they may disable developer mode.
But anywho, you are saying google supports coreboot devices and puts it on the official coreboot website?
Correct.
I am not a chromebook expert btw. Is it possible to run fully free software distros on chromebooks then without blobs?
Most modern CPUs cannot function without blobs. If you’re interested in a blob-free or blob-lite experience, you might be interested in playing with ARM devices. I think some older Rockchip chromebooks do not require any blobs at all.
Also, wondering what the difference is between chromebook intel and framework intel regarding linux support.
All frameworks run Linux just fine, including the Chromebook models.
almost anything is possible if you know how or capable of doing so.
Coreboot works on the chromebook edition of framework, you may be able to get rid of certain blobs and use the libreboot automated build tools. I do not know what benefit for now libreboot would have over coreboot. I havent ported coreboot onto anything, so cannot tell if its much or not much trouble. but first step would be to compile your own coreboot image and see if it boots.
me.bin is a 5mb binary blob to initialize Intel ME. Purism have managed to boot their laptops for years “sort-of” without ME. You might be able to use me_cleaner to neuter ME on a Chromebook. But there will need to be some amount of ME-crap running for the CPU to actually … be a CPU. AFAIU.
vbt.bin is 8.5KB of VBIOS. That’s the thing that is uploaded to the iGPU to make it be a GPU. Without it I think you won’t have a GPU, and thus won’t have any functional display output. I might be wrong on this, though.
cpu_microcode.bin is 213kb of … well, CPU microcode. Here is a great talk about CPU microcode. This might just be an updated CPU microcode that coreboot initializes to patch hardware errata in the shipped silicon. Or maybe the CPU won’t work without it. I dunno.
ec.RW.flat is, I’m guessing, the Embedded Controller, which is responsible for controlling all the embedded things (true story). I know Framework has open sourced their EC code for their x86 lappies, but I don’t see any mention of their Chromebooks in that README. Maybe the code can be found elsewhere? But if so, I wouldn’t expect to see a binary blob there, and a submodule/subtree for the appropriate code…
TL;DR - running a Framework Chromebook without the blobs that ship in MrChromebox’s coreboot fork would get you a long way, but you’d probably have a laptop with no functional display, keyboard, touchpad, battery management, LEDs, etc.
ec.RW.flat is, I’m guessing, the Embedded Controller, which is responsible for controlling all the embedded things (true story). I know Framework has open sourced their EC code for their x86 lappies, but I don’t see any mention of their Chromebooks in that README. Maybe the code can be found elsewhere? But if so, I wouldn’t expect to see a binary blob there, and a submodule/subtree for the appropriate code…
A little funny/weird that the official Framework EC repo, which itself is just a fork of cros/ec, isn’t synced with upstream and thus doesn’t have the brya/banshee board code
I just stumbled on this Reddit thread where MrChromebox themselves indicate you don’t need ec.RW.flat to produce a firmware image, which is interesting.
(Someone in that thread was also specifically trying to get coreboot working on their Lenovo Gaming Chromebook or somesuch, and specifically mentioned trying the coolstar.org Windows drivers for Framework Chromebooks, lol)
Yeah, ec.RW.flat is just used for software sync. So if you’re fine with the version currently on your EC’s internal flash, there’s no reason to include the blob (provided you set the kconfigs right to not include software sync).
Unlike most Windows devices, chromebooks generally use ECs with integrated flash, whereas Windows devices tend to load the EC from the AP’s SPI flash. Thus, you don’t actually need the EC firmware in the BIOS image.
So, seeing as how in a couple minutes/hours from now depending on timezone, it will no longer be march, I’m assuming he did not give another talk at the march conference?
No, there was no presentation about coreboot on Framework during Dasharo User Group and Dasharo Developers vPub. I asked Felix on 23rd February but didn’t get a response. I guess he was busy. I will let you know if anything regarding the Framework hardware is planned for DUG or vPub.
As a larger question, I have often wondered if coreboot’s flexibility might ultimately allow a change in the distribution of software on a machine. The very first coreboot payload was a cut down linux kernel, stripped down to fit into a tiny ROM space before replacement with a variety of bootloaders. The dramatic decline in the cost of solid state memory provoked a few small bespoke OS like linux payloads that ran from the ROM, but that was a sort of alternate pathway that didn’t get much traction.
My question since discovering coreboot has always been “why not have the OS kernel load at POST, initiliaze everything exactly once, and then leave everything else in userspace?”. Kernel updates would require “flashing ROM” but mishaps are a lot less scary if swapping a ROM out doesn’t involve soldering. The separation wouldn’t have been possible in the days of X, but the extent to which Wayland has made userspace separate from the kernel opens up possibilities. I think that perhaps the most intriguing is that from a security perspective, the kernel now occupies a separate physical address, such that any request to change it involves a more detailed pathway that other software updates. The system can treat all efforts to modify the kernel as malicious unless they follow that protocol, which should allow an additional ring of security.
Anyway, I am glad that Framework is following this and for the first time I have hope that I’ll have a coreboot system that isn’t a hackjob.
Yeah, people who build proprietary hardware usually do shady stuff.
If its possible to port libreboot to a google device, I would be more willing to trust it though.
I think that the 4th or 5th post in this thread was a member of the Framework team explaining that while Framework is currently focused on easier solutions, coreboot aligns with their mission and is something that they would explore in the future (dated to late 2021). I accept that priorities change, but the “our core mission and their core mission mesh well” sentiment hasn’t gone anywhere, though I assume that implementation issues have kept it on the back burner.
openSIL is EXPLICITLY built to use coreboot, to the extent that it even has one fewer compatibility layer than even UEFI. To me, that looks like “closed source/vendor obstacles to coreboot implementation being removed at the source”. Big picture, I think that means that the obstacles which have prevented coreboot implementation are improving in a meaningful way.
Yeah, I don’t give much water to any of Frameworks statements in the arena for a variety of reasons at this point but I’m not getting into it as I’ve said it all before at this point in numerous threads. Believe what you will, I hope you enjoy the product.
