Hi everyone, I have just recently found out there is a thing like coreboot/libreboot, and I like the concept of it: fast(er), secure, open source, easy to flash and non-brickable process.
I’ve been trying to understand the basics behind it and it’s too difficult for me. I have some basic understanding of what BIOS / EFI is. And as I understand it, the core/libreboot is an open-source replacement for it. Great!
But what I’m interested in is understanding, how it manages to be better than the OEM’s BIOS? I understand that the nature of open-source is better than closed source software, but what I don’t understand is how this project manages to be better for end-user?
As I get it, it’s similar to Custom ROMs on Android. There is an OEM’s rom — say, Samsung — it makes its version of Android, and it’s good (in terms of how it works with the hardware), but usually with tons of bloatware and OEM never updates the phone after a customer bought it. Here we have Custom ROMs, like CyanogenMod / Lineage OS / Pixel Experience / etc. etc. Those ROMs somehow manage to keep the software updated for much longer time-frame, having extra functionality and even working faster. (Frankly, I don’t understand how do they manage to do that as well, and why it’s so difficult for OEMs.)
Is this something similar? I can understand the (ineffective) processes of big corporations, but I cannot understand how the developers manage to keep those things better, lighter, etc. Say, whether the OEM’s firmwares somehow bloated? Why is so then? Why won’t a big company like Gigabyte, Asus, Acer, etc. also use this product, why do they write so-closed-source BIOSes and EFIs then, if they can use something lighter and faster, and in so many ways better? As it’s advertised on the website of coreboot.
I’m not sure I keep the question simple, for others to understand, but if talking about the real hardware. Say, I have Asus MAXIMUS IV GENE-Z motherboard. Can I install coreboot on it (seems like yes, according to the website https://coreboot.org/status/board-status.html#asus/maximus_iv_gene-z), and if I can, will it miss some functionality comparing to its original EFI? I mean not that I need it, but I’m interested whether there’s something special in original firmware or not. There are many things on the website, at ‘ROG Exclusive Features’ and ‘Special Features’ sections, but I’m not aware if it’s something special or it’s just some marketing bullshit, is it located in the firmware, or it’s something entirely different they speak of in that section?
Please pardon me if the question is too newbish and was answered somewhere. I’ve tried to do my search and found no information on my question. I would appreciate any comment on this topic. Thanks!
edit: Found Why use coreboot? (reddit post) And it’s an interesting read itself, but it’s not the question I’m trying to find answer to.
credit: u/walteweiss on Reddit.
original link: https://www.reddit.com/r/coreboot/comments/bgjzth/how_does_coreboot_manage_to_be_better_than/
There are two main aspects to coreboot in my opinion that differentiate it from other firmware ecosystems:
The first is a strong push towards having a single code base for lots of boards (and, these days, architectures). Historically, most firmware is build in a model I like to call “copy&adapt”: The producer of a device picks the closest reference code (probably a board support package), adapts it to work with their device, builds the binary and puts it on the device, then moves to the next device.
Maintenance is hard in such a setup: If you find a bug in common code you’ll have to backport the fix to all these copies of the source code, hope it doesn’t break anything else, and build all these different trees. Building a 5 year old coreboot tree on a modern OS is quite the exercise, but many firmware projects are near impossible to build under such circumstances.
With coreboot, we encourage developers to push their changes to the common tree. We maintain it there, but we also expect the device owner (either the original developer or some interested user) in helping with that, at least with testing but more ideally with code contributions to keep it up to current standards of the surrounding code. A somewhat maintained board is typically brought up to latest standards in less than a day if a new build is required, and that means that everybody has an easy time to do a new build when necessary.
The second aspect is our separation of responsibilities: Where BIOS mandates the OS-facing APIs and not much else (with lots of deviation in how that standard is implemented), UEFI (and other projects like u-boot) tends to go the other extreme: with UEFI you buy into everything from build system, boot drivers, OS APIs and user interface. If you need something that only provides 10% of UEFI you’ll be having a hard time.
With coreboot we split responsibilities between 2 parts: coreboot does the hardware initialization (and comes with its build system for the coreboot part, and drivers, but barely any OS APIs and no user interface). The payload is responsible for providing interfaces to the OS and user (and we can use Tianocore to provide a UEFI experience on top of coreboot’s initialization, or seabios, grub2, u-boot, Linux, or any program you build for the purpose of running as payload).
The interface between coreboot and the payload is pretty minimal: the payload’s entry point is well-defined, and there’s a data table in memory that describes certain system properties. In particular the interface defines no code to call into (including: no drivers), which we found complicates things and paints the firmware architecture into a corner.
To help payload developers, coreboot also provides libpayload, a set of minimal libraries implementing libc, ncurses and various other things we found useful, plus standard drivers. It’s up to each coreboot user/vendor if they want to use that or rather go for whatever else they want.
credit: [deleted] user on Reddit.