LinuxBios PPC-support.. U-Boot project

[Frank]

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