[coreboot] coreboot and U-Boot: a comparison
Ken.Fuchs at bench.com
Ken.Fuchs at bench.com
Thu Jun 26 00:52:04 CEST 2008
> Ken Fuchs wrote:
> > 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.
Segher Boessenkool wrote:
> 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.
There's still something wrong with the new naming system or I'm
missing something. coreboot has its well defined name and the
payloads have their well defined names. However, what does one
call a particular combination of payloads used for particular
purpose that encompasses both coreboot and all payloads used?
Some of these combinations are well defines "computer" idioms,
such as the sequence of payloads needed to boot MS Windows "Du
Jour" In other words what is the complete package called that
uses coreboot as the IPL code?
> > 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.
To reduce end product cost, the trend is toward fewer external
controller chips. The x86 market will need to reduce the no.
of dies to complete in the embedded market. Even Intel recognizes
this with their introduction of Atom/Poulsbo (2 chips instead of
the usual 3) and their new System on a Chip processor (single chip
> > 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.
My focus is on the embedded market. There is no need for IBVs here.
No need for either a legacy BIOS or an UEFI BIOS. U-Boot, Redboot,
and other bootloaders work just fine on non-x86 processors. The
dream is coreboot working on a majority of x86 embedded boards just
as well as U-Boot runs on many ARM, MIPS, and PPC based boards.
> Maybe things will change with the new wave of tiny embedded-style
> x86 PCs.
A few controllers are being put on the processor die in x86 embedded.
A well known example is the AMD Geode with its on-die DRAM controller.
x86 embedded solutions will usually have to be single chip and not
depend on either Legacy or UEFI BIOS. They will also need coreboot
or something similar to initialize the board prior to OS boot.
> > 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).
This sounds great! Is there a web site that describes how to set
up git to use a Subversion repository (via an SVN server)? The
git-svn man page is not particularly helpful in this regard.
Please set up a git mirror via http. People using your git
mirror would not need to learn/use git-svn directly, right?
More information about the coreboot