[PROPOSAL] extended payload handling

[Hendricks David W.]

On Tue, 8 Jun 2004, Frank wrote:
> You missed the point!

Yes, I did miss the point (I should've read more closely).

> at u-boot and you'll find support for just about every PPC  and
> the number of drivers are abundant. I can port u-boot to a new
> PPC based board in about 3 days tops. There is no way I can port
> LinuxBios to a new X86 based board in that amount of time. 

I haven't looked at u-boot code much, so I cannot compare ease of porting 
to a new board. However, LB doesn't seem all bad in that area from where I 
stand. Of course it's going to be difficult if you switch architectures, 
but once the initial work is done it's a piece of cake. I was get an Iwill 
DK8S2 (Dual opteron board) running in less than 3 days simply by 
duplicating the Arima HDAMA (Another dual Opteron board) code and tweaking 
some config files, and I'm just a student working here and not some l33t 
hacker like Eric or Ron. No hacking on assembly code (Or even C code for 
that matter) was required. 

As far as architectures go, LinuxBIOS has run on Alphas, x86, x86-64, 
and now PPC. It's portable. And since freebios2 is took a huge leap in 
reducing the amount of assembly required to do a port, it should be easier 
now than it was before.

On Tue, 8 Jun 2004, Frank wrote:
> not waste time trying to make it work for the PPC. If I wanted a
> bootloader I would use u-boot not LinuxBios. I have heard of
> other people abandoning LinuxBios and going to u-boot in that
> past, just like I did...

You ought to try FILO as a payload for LinuxBIOS. I think it accomplishes 
what you wanted a year ago ( 
http://www.clustermatic.org/pipermail/linuxbios/2003-June/003789.html ).

> --- "Hendricks David W." <dwh at lanl.gov> wrote:
> > IIRC, that's what Greg's addition of FILO for PPC was all
> > about.
> > 
> > On Tue, 8 Jun 2004, Frank wrote:
> > 
> > > Finally, someone has recognized the lack of support with
> > > LinuxBios. About 6 months ago we decide to do an x86 based
> > > project but abandoned it because of the lack of support for
> > this
> > > bootloader. The code is disorganized and in disarray as far
> > as
> > > I'm concerend. We were on a tight schedule and didn't have
> > the
> > > luxury of spending a lot of time trying to understand the
> > code
> > > layout. This was due in part to the lack of badly needed
> > > documentation and code organization. We decided to base our
> > > design on a powerpc and go with u-boot.
> > > Hopefully by the time we decide to do cost reduced version,
> > > LinuxBios will be usable for the masses and not just for an
> > > elite group of people who assume everybody else uses the x86
> > for
> > > everyday use.:-(
> > > 
> > > --- Greg Watson <gwatson at lanl.gov> wrote:
> > > > 
> > > > On Jun 8, 2004, at 7:59 AM, Stefan Reinauer wrote:
> > > > 
> > > > > * Greg Watson <gwatson at lanl.gov> [040608 15:22]:
> > > > >> I think this is a reasonable idea, particularly your
> > > > suggestion of
> > > > >> making linuxbios more modular. One of my main beefs
> > with
> > > > the payload
> > > > >> strategy is that each payload has to provide it's own
> > set
> > > > of,
> > > > >> potentially buggy, driver code. If we have 5 payloads
> > then
> > > > we have 5
> > > > >> sets of drivers that all do the same thing slightly
> > > > differently. If 
> > > > >> the
> > > > >> drivers were modular enough so that a payload could
> > call
> > > > them 
> > > > >> directly,
> > > > >> then this would go a long way to addressing these
> > concerns.
> > > > >
> > > > > As far as I can tell the only drivers involved would be
> > > > output drivers,
> > > > > ie. video output and serial output. There the extensible
> > > > LinuxBIOS 
> > > > > table
> > > > > could come into play. The video driver could store a
> > pointer
> > > > to the
> > > > > framebuffer, the resolution and maybe even a font, to
> > save
> > > > duplicates.
> > > > > Serial is only a kilobyte or so of a driver i think.
> > > > >
> > > > > Have I forgotten something?
> > > > >
> > > > 
> > > > PCI device code and resource information should be
> > available
> > > > for 
> > > > payloads to use. A payload should not have to re-probe for
> > > > devices on 
> > > > the PCI bus.
> > > > 
> > > > Greg
> > > > 
> > > > _______________________________________________
> > > > Linuxbios mailing list
> > > > Linuxbios at clustermatic.org
> > > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > > 
> > > 
> > > 	
> > > 		
> > > __________________________________
> > > Do you Yahoo!?
> > > Friends.  Fun.  Try the all-new Yahoo! Messenger.
> > > http://messenger.yahoo.com/ 
> > > _______________________________________________
> > > Linuxbios mailing list
> > > Linuxbios at clustermatic.org
> > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > > 
> > 
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> Friends.  Fun.  Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/ 
>