LinuxBios PPC-support.. U-Boot project

[Bari Ari]

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