[coreboot] coreboot and U-Boot: a comparison

Segher Boessenkool segher at kernel.crashing.org
Tue Jun 24 18:58:38 CEST 2008

> 3) Das U-Boot had a very early name change from PPCBoot when it
>    added non-PPC processor support.  LinuxBIOS had a recent name
>    change to coreboot, but that was a huge mistake.

Not really.  There were good reasons to change the name.  Yes, of
course not-heavily-involved people have to be educated about the
new name.  There are two main ways to do this: 1) more publicity;
2) when speaking to an audience (on a mailing list, on a website,
whatever) that might not know the name coreboot yet, always mention
it used to be called linuxbios.

> 4) In the non-x86 market, the processor often includes all I/O
>    controllers needed by the application.  Often a designer just
>    needs to pick the processor variant that contains all the
>    I/O controllers he needs.  No chipsets and often no external
>    I/O controllers are required for the design.

Well, not _required_, but many embedded devices have some external
I/O chips connected.  Not many, but still some.

> 5) No IBVs (Independent BIOS Vendors = AMI, Phoenix, Insyde,
>    General Software, etc.) that dominate (monopolize) the market
>    with proprietary firmware/BIOS "solutions".

That's because cost is a more important factor for embedded than
it is for the x86 PC market.  Also, that x86 PC market is largely
forced to use legacy BIOS anyway.

Maybe things will change with the new wave of tiny embedded-style
x86 PCs.

> 8) U-Boot now has architecture specific git repositories for
>    active development available via http protocol that passes
>    through most firewalls transparently.  coreboot has a
>    single SVN repository that seems to be accessible only
>    via the svn protocol which requires that the svn port
>    be open on the firewall which is often impossible to get
>    approved, since it is a "non-standard" port.

I get my coreboot goodness via git-svn.  If people are interested,
I can set up a git mirror (also available via http).

> Whether or not you agree with all of these reasons, something
> can be done about all of them to varying degrees, ranging from
> nothing to completely fixing it.

Any suggestions?  Spotting (perceived) problems is nice, fixing
those problems is double-plus-good :-)


More information about the coreboot mailing list