You missed the point! If I wanted a bootloader for the PPC I would use u-boot and that's what I did. But if I wanted a bootloader for the X86 platform I would have liked to use LinuxBios. U-BOOT is synonymous with the PPC. LinuxBios should be synonymous with the X86 just like PMON is with the MIPS platform. Take a long look 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. You should focus your efforts on improving LinuxBios for the X86 and 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... --- "Hendricks David W." dwh@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@lanl.gov wrote:
On Jun 8, 2004, at 7:59 AM, Stefan Reinauer wrote:
- Greg Watson gwatson@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@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@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
__________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/