[coreboot] coreboot and U-Boot: a comparison

[ron minnich]

On Fri, Jun 20, 2008 at 4:11 PM,  <Ken.Fuchs at bench.com> wrote:
> Having worked in a non-trivial way with both LinuxBIOS code and
> U-Boot code, I can make a fair comparison of coreboot and U-Boot.
>
> I wish coreboot was as dominant in the x86 market as U-Boot is
> in the non-x86 market.  There appear to be several reasons:
>
> 1) Technical information flows very freely in the non-x86 market.

A really big problem for us, and getting *worse* in some cases.

Also, I've been through all the platforms U-boot supports (admittedly,
a while ago). They are *easy*
to write to compared to the stuff we deal with. That's been a factor
in our ability to ship stable releases.

A big problem is the hostilty that one big x86 mover and shaker has
shown to this project over the last 6 years. It's made life hard, what
with the continuous FUD.

> 2) U-Boot has official stable releases and coreboot doesn't.

What can this even mean? I've looked at the code too and used it. I
don't know if I believe that
for a given stable release, every single platform in the release works
perfectly. We've gone with stable
release per platform, via saying "this svn rev for this platform".
Anything else has proven very hard.

> 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.  More people
>   know about LinuxBIOS that disappeared than know about coreboot.

Let's not talk about the name please. There has been too much on this
already. The change was done, it's over, let's move on. Trust me, I'm
well aware of the brand equity we lost with the name change. It will
take years to get it back. But we had a lot of insistence from many
quarters.

> 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.

Like I said, the non-x86 market is really a good deal easier than ours.

> 6) Much of the U-Boot code, especially its device drivers come
>   from the corresponding device drivers in the Linux kernel.

There's no need for "drivers" in LB, that's the whole point. This is
actually a negative IMHO for
U-boot -- way more software bits than we have.

> 7) There seems to be more active development on U-Boot than on
>   coreboot based on the activity of their respective mailing
>   lists.

Almost certainly true. U-boot is good stuff, and is a de-facto
standard in the ARM and PPC world. They've
done a great job. Why that one company wants UEFI for ARM is totally
baffling. They've got u-boot; why wreck such a a good thing? That has
to be a Pointy-Haired Boss decision.

> 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.

ah, git. Love it or hate it. I know people who have used it and now
stopped. We had a truly terrible experience with LB and arch years
ago, and the SCM question is a sensitive one. I have had people tell
me "move to git" and others tell me "please please DON'T EVER MOVE TO
GIT".

that's a tough one.

ron