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 <[EMAIL PROTECTED]> 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 _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
