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. 2) U-Boot has official stable releases and coreboot doesn't. 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. 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. 5) No IBVs (Independent BIOS Vendors = AMI, Phoenix, Insyde, General Software, etc.) that dominate (monopolize) the market with proprietary firmware/BIOS "solutions". 6) Much of the U-Boot code, especially its device drivers come from the corresponding device drivers in the Linux kernel. 7) There seems to be more active development on U-Boot than on coreboot based on the activity of their respective mailing lists. 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.
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.
Sincerely,
Ken Fuchs
On Fri, Jun 20, 2008 at 4:11 PM, Ken.Fuchs@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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
ron minnich schrieb:
- 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".
I think, the main request here is to have the repo available over a "standard port" (yay, it's PHBs and BOFHs ruining the party again).
We already provide the cbv2 repo over https (as documented on http://www.coreboot.org/Download_coreboot ), and it should be easy to provide the other repos as well. It should be easy to map them into the http namespace on coreboot.org, if that's truly necessary.
Regards, Patrick
On Sat, Jun 21, 2008 at 12:14 PM, Patrick Georgi patrick@georgi-clan.de wrote:
We already provide the cbv2 repo over https (as documented on http://www.coreboot.org/Download_coreboot ), and it should be easy to provide the other repos as well. It should be easy to map them into the http namespace on coreboot.org, if that's truly necessary.
yes you and Ken are right and we should set this up. I just don't know how :-)
thanks
ron
Ken Fuchs wrote:
- 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.
ron minnich schrieb:
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".
Patrick Georgi wrote:
I think, the main request here is to have the repo available over a "standard port" (yay, it's PHBs and BOFHs ruining the party again).
We already provide the cbv2 repo over https (as documented on http://www.coreboot.org/Download_coreboot ), and it should be easy to provide the other repos as well. It should be easy to map them into the http namespace on coreboot.org, if that's truly necessary.
Yes, all source available from the Subversion repository via http/https is what I'm mainly looking for. Read only access would allow update of a developer's current tree.
I actually advocated Subversion when arch was chosen a few years ago. Subversion is a good SCM, but a lot of open source projects have moved to git. However, if Subversion is adequate, I see no pressing reason to switch to git. There are some nice tools to track source code at a high level via git though.
Sincerely,
Ken Fuchs
On Mon, Jun 23, 2008 at 06:27:21PM -0500, Ken.Fuchs@bench.com wrote:
Yes, all source available from the Subversion repository via http/https is what I'm mainly looking for.
Per http://www.coreboot.org/Download_coreboot
* svn://coreboot.org/repos/trunk/coreboot-v1 * https://coreboot.org/svn/trunk/coreboot-v1
* svn://coreboot.org/repos/trunk/coreboot-v2 * https://coreboot.org/svn/trunk/coreboot-v2
* svn://coreboot.org/repository/coreboot-v3 * https://coreboot.org/v3-svn/coreboot-v3
* svn://coreboot.org/filo/ * https://coreboot.org/filo-svn/
* svn://coreboot.org/buildrom/ * https://coreboot.org/buildrom-svn/
* svn://coreboot.org/testsystem * https://coreboot.org/testsystem-svn/
I only use the svn URLs though.
//Peter
- 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.
Well, you need minimal drivers for your boot devices. You can put them in a separate payload file, which is likely a good design even, but you still need them _somewhere_.
This is actually a negative IMHO for U-boot -- way more software bits than we have.
I tend to agree with this. "Keep it simple".
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.
One of the nice things about most distributed SCMs, and git in particular, is that even if the "central" repo is SVN, you can still use something else locally.
Segher
- 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.
- 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.
- 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.
- 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 :-)
Segher
Ken Fuchs wrote:
- 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?
- 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 solution).
- 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.
- 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?
Sincerely,
Ken Fuchs
-
Ken.Fuchs＠bench.com -
Patrick Georgi -
Peter Stuge -
ron minnich -
Segher Boessenkool