Coreboot 4.11 | Hacker News Reader

Coreboot 4.11

blogs.coreboot.org

100 pointsgautamcgoel26 comments

"Ron Minnich is a Software Engineer at Google. He has been writing firmware for 40 years, starting with the z80 and 6800. He's also a long time contributor in the Unix, BSD, Plan 9, and Linux communities. He started the LinuxBIOS project in 1999, which was renamed to coreboot in 2008 and is now used in tens of millions of Chromebooks. His most recent effort, LinuxBoot, is now part of the Linux Foundation and aims to bring the benefits of a full Linux kernel to several firmware environments, including coreboot, u-boot, and UEFI." https://www.opencompute.org/blog/ronald-minnich-google-and-g...

As someone who doesn't know what Coreboot does, not having this information in the first paragraph of this post isn't super useful. Add to the problem that clicking on the Coreboot logo only takes me to the front page of the blog - and there are no links to the actual homepage...

It's a CORE part of your system that you could use to BOOT you computer

haha, I nominate you for the HN comment of the day.

The about page of blog has 1 paragraph description of coreboot.

"coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology." https://coreboot.org/

Which means nothing other than its open source and doesn't follow any standards.

If google put 1/2 the effort into edk2 the world would be a lot closer to a general purpose opensource firmware that actually works with things like option roms, and booting on random boards instead of some tiny subset of boards that google has beaten people into porting it onto.

> Which means nothing other than its open source and doesn't follow any standards.

I think you missed the first sentence.

? Which of those aren't provided by edk2? Have you see how fast it is on small embedded boards? Its basically instant boot the same way as uboot is, it also supports the secure boot standard, capsule update, and most of what one expects out of a modern BIOS.

So, yah, if you turn on boot debugging, and enable a pile of drivers for USB/PCIe/etc it gets slower because it can actually probe and boot from random USB & PCIe devices, and display a graphical boot menu using a random GPU. Still, the longest delay tends to be the boot prompt sleep/delay which can be shortened/removed.

> ? Which of those aren't provided by edk2?

What does that have to do with anything?

Your argument was that the description was not descriptive but it was. So your point was wrong and made no sense.

Then you start ranting about coreboot. So clearly your argument was not about the description, you just wanted to shit on coreboot.

And just btw, building a whole new OS to put under your OS is nonsense from pretty much every perspective.

No, my argument was that the description was market-speak and doesn't actually tell you anything useful. Faster than what? More secure than what, how? Its not class leading in either of those cases.

Further the project is yet another CADT model project which further fragments a problematic portion of the ecosystem while bringing little to the table technically.

And while I picked edk2/uefi, there are a dozen other firmware projects including one that actually does put a full blown OS in the firmware. So, if your augment is trying to be technical by saying edk2 does to much, that doesn't address boot loaders like uboot, while simultaneously failing to understand the why's of standardized boot-loaders.

> Its basically instant boot the same way as uboot is

We regularly run into issues where coreboot boots so fast that the peripherals can't catch up and we're the first to notice. So yes, our boot process is pretty quick compared to other stuff.

> it also supports the secure boot standard, capsule update, and most of what one expects out of a modern BIOS.

Absence of runtime services (while still doing a secure boot flow and firmware updates). UEFI doesn't do that.

Also, coreboot provides these things since ~2005 (the verified boot flow was a bit late) while EDK2 started out around 2007 and only gained secure boot in 2012.

From my perspective EDK2 is the also-ran.

The edk2 project is a branch of edk, which itself is a branch. According to their about page the original tiano project was started in 2004 as the opensource fork of intel's internal uefi implementation. This did create some problems early on, but the code is basically BSD licensed at this point since AFAIK, they are dropping the bsd+patent restriction. So technically you could probably work on it without ever looking at the UEFI specifications these days as much of the platform code/etc is actually in a different repo. Given that its mostly a plugin API that isn't really a problem, its a matter of flipping a few switches in the config files to enable functionality on top of whatever platform init is necessary.

https://www.tianocore.org/

I might be able to work on it (and indeed, I sometimes do), but your argument was in favor of implementing a spec.

Any change that modifies the resulting binary might have my copy deviate from the spec and I have little way of knowing. How useful is that when trying to "implement PEI"?

Coreboot is laser focused on early initialization and leaves everything like option roms and disks and OS launching to the payload… which can be EDK2.

Coreboot is actually the easiest way to get pure EDK2 (without anything from vendor UEFI builds) running on any random Intel mainboard :)

Yes I know it can "chainload" edk, people have done similar things with uboot in the past. The point being that the low level init code could conform to the PE spec, which would be a lot cleaner implementation.

> The point being that the low level init code could conform to the PE spec

The spec that is available under "read only, but don't implement" terms[0] unless you manage to join a club that may or may not let you in[1] and can kick you out at any time with 30 days notice[2]? Not sure that's a good base for an open source project.

[0] https://uefi.org/specifications "By downloading any of the UEFI Specifications, you acknowledge that no license, express or implied, is granted to you to distribute, additionally reproduce, implement or otherwise use for any purpose (other than to read only) the UEFI Specifications"

[1] Section 2.1 in the "UEFI Adopter's Agreement" (https://uefi.org/sites/default/files/resources/UEFI_Adopters...): "This Agreement shall become effective only: (a) if executed by the Secretary (or another authorized representative of the Forum) and the Adopter"

[2] Section 2.2 of the same agreement: "shall continue until [...] terminated by either the Forum or the Adopter on 30 days’ written notice."

Open source replacement for BIOS, basically

That's a very nice summary. I found the Wiki article[1] most helpful, too.

[1] https://en.wikipedia.org/wiki/Coreboot

I was always interested in using Coreboot for "retro" machines that have buggy old vendor BIOSes, and may not even have updates available anymore (or easily found)

Is there anywhere I can find out about the actual status of things like Coreboot on Pentium III (Slot 1 or Socket 370) motherboards? I know they maintain a "compatibility list" but I'm not sure if these boards have been tested or if they'd have been lost to code churn

The lifeblood of FOSS drivers, or coreboot in this case, is developers who are using/interested in the machine. Unfortunately, I don't see many Pentium-III fans in the coreboot community. And there was a major refactor in the coreboot codebase since 4.0, the support of many old platforms have been killed.

https://coreboot.org/status/board-status.html

I wish they had more support for consumer desktop motherboards, so I could flash my Asus board. Somehow coreboot seems to focus on laptops and server boards.

For a successful port: the hardware must attract the interest of a team of developers, so this hardware platform...

(1) must be available globally.

(2) must be valued by developers as worthwhile, i.e. for a specific propose.

(3) must be relatively easy to reverse engineer, e.g. platform is not too new.

Thinkpad laptops are already popular among developers and hackers, and used machines and motherboards can be obtained cheaply for a low price, each generation often uses a pretty standard design, only with a newer chipset. As a result, it became the "reference machine" for a lot of developers, including developers working on security and privacy projects. The server motherboard is a thing because there are hardware hackers who are interested in FOSS-friendly and secure server platforms.

On the other hand, there are huge numbers of consumer desktop motherboards with a lot of variations, every single one needs to be reverse-engineered independently. We don't see a platform to gain the critical mass yet.

Reply on news.ycombinator.com