u-boot's weakness is that it primarily supports arm and ppc processors. There is only one x86 board in the source tree and it won't even compile! If u-boot had more support for x86 platforms, it would give linuxbios a serious run for it's money.
--- Bari Ari bari@onelabs.com wrote:
Gregg C Levine wrote:
Hello again from Gregg C Levine I agree in principle Ron, but I am curious as to why they
thought
that. After all, Linux BIOS does more for a system then
U-Boot. It's
my guess that after seeing the appropriate demonstrations
that group
will change their minds, collectively or otherwise.
There was quite a bit of bickering on the U-Boot list at the time. Things seem to have settled down since last fall and theU-Boot list seems to be getting along now. Here are some snippets from last falls discussion about this:
LinuxBIOS was designed to use Linux to boot the OS of choice.
So was PPCBoot, but without excluding the resto of the
world.
So was LinuxBIOS, it currently also boots Plan9 and WinCE.
Bragging about each other's feats won't take us anywhere....
>It uses some assembly to do some basic init and config
and then jumps to
>Linux to fully configure the rest of the system, after
that LinuxBIOS
>jumps to whatever OS kernel is wanted.
So your boot sequence is LinuxBIOS => Linux => LinuxBIOS
=> Target OS?
LinuxBIOS (a few lines of assembly and then a Linux kernel)
=> TargetOS
That means in order to use LinuxBIOS on a platform, you first need to have at least a basic Linux Kernel that runs on that platform. Thus, if you want to port to a new platform, you have to struggle with interrupts, MMU initialization, caches, possibly DMA before you get *anything* to run. This approach makes perfect sense when the kernel is already there, but to *begin* porting at this level -- no thanks!
it also supports this boot sequence:
LinuxBIOS (few lines of assembly and no Linux kernel)=>
EtherBoot =>
TargetOS. Linux itself is basically not needed.
So where is the gain over e.g. Etherboot without LinuxBIOS ?
I believe it's safe to say that a _merge_ of PPCboot/ARMboot/Blob and LinuxBIOS is not going to happen. And rightly so IMHO since they are (valid) tools to solve different problems. Even an x86 port of PPCboot would make a lot of sense because nothing of this kind exists in the x86 world (at least not under GPL). This has been discussed here before (BTW: what's the status of the PPCboot/x86 project ?).
Of course the bootloaders contain code which the LinuxBIOS people might find useful to rip^H^H^Hre-use (and vice versa). This shouldn't be a problem since they are license compatible.
LinuxBIOS was designed to use Linux to boot the OS of choice.
So was PPCBoot, but without excluding the resto of the
world.
this is not the forum for PPCBoot vs. LinuxBIOS arguments. I Just Don't Care. I am sure PPCBoot is wonderful software!
So your boot sequence is LinuxBIOS => Linux => LinuxBIOS =>
Target OS?
no. The boot sequence is:
- LinuxBIOS -> Linux -> OS (i.e. on Pink)
- LinuxBIOS -> 9load -> Plan 9
- LinuxBIOS -> Etherboot built in to linuxbios -> OS of choice
- LinuxBios -> Etherboot (external ) -> OS of choice
In other words, we have lots of boot sequences depending on the target system and OS.
The issue of *BSD is not that we can't boot it. We can. The issue is that *BSD wants to make BIOS calls we don't support.
Seems a bit overkill to me. Especially in systems
where (flash)
memory is tight it might be a PITA to have to reserve
space for a
Linux kernel just to initialize the hardware.
We Have Our Reasons. And, we don't always load linux in flash.
The current version of PPCBoot boots Linux, VxWorks, QNX,
and NetBSD.
terrific! I'm happy for you. But this is not a competition.
It seems you do not know much about PPCBoot.
funny, as it seem syou don't know much about linuxbios. So we all need to read more :-)
PPCBoot also provides powerful scripting capabilties;
busybox' "hush"
shell has been integrated, so you can write standard shell
scripts or
run conditional command sequences using
"if...then...else...fi",
"for...do...done", "while...do...done",
"until...do...done", or using
shortcuts like "cmd1 && cmd2" or "cmd1 || cmd2".
I really don't much like firmware that starts taking on the attributes of an OS, but to each his own. If you're going to put an OS in firmware, just make it an OS, not a pseudo-OS. But that's just my opinion.
anyway, I am sure PPCBoot is wonderful, and we should be sharing code, not getting out our rulers to see whose BIOS is bigger.
-Bari
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com