Murray.Jensen at csiro.au wrote:
> On Thu, 27 Oct 2005 16:04:09 +0200, Sven Luther writes:
> A port? of what? CHRP?
I believe the port was of GRUB2.
I really think it's disingenuous to call anything about the platforms CHRP
at this point, given CHRP was intended to be a standard and its one to
which huge swaths of it no longer apply (I previously mentioned ADB device
support and support for MacOS ROMs.)
Rather I think it's better to think in terms of more or less generic
PowerPC-based platforms that generally have some common factors, the most
common being their use of OpenFirmware for boot purposes.
> OK, so someone at some point will need to write/port the bits of chrp/OF
> required by OpenSolaris, if they want to support non-chrp/OF hardware (as
> in my case with a barebones embedded board running U-Boot).
The thing is that GRUB2 already knows how to interface with OpenFirmware; to
support your board someone will in theory need to make GRUB2 talk to it. I
suspect this wouldn't be difficult work, as GRUB2 isn't going to make
extensive use of OF and already knows how to talk to PC BIOSes.
Meanwhile, U-Boot doesn't use OF at all, relying instead on compile-time
#defines to determine things like RAM size, what devices are present, etc.
Great for an embedded board, not so great for a general purpose OS.
> It seems to me in this case that grub2 would just be extra work - might as
> well just add the required bits to U-Boot.
That's tricky for a couple different reasons, notably that U-Boot just
isn't set up for a general purpose OS. If you need more memory on your
embedded board, it's no big deal to recompile U-Boot. Add RAM to say a
Pegasos machine and you really shouldn't have to recompile the boot loader
to see it.
> The real question is, what does OpenSolaris require? I haven't actually
> gone and looked at the source (yet), but is it (or will it be) clear? Maybe
> it is even documented somewhere?
Basically, like most operating systems, OpenSolaris needs the booter to load
the kernel executable and provide basic services (console I/O, memory mapping,
device access, etc.) until the kernel is able to fend for itself.
So for example, on SPARC and early OpenSolaris, the booter is expected to not
only do this but also to provide callbacks to do things like map memory (both
RAM and devices), allocate memory, etc. With the coming of the GRUB-based
newboot to Solaris, the x86 boot process looks much more like the boot
process with U-Boot where the booter loads an initial RAM disk
image that turns around and loads the kernel and other supporting features.
> I don't want to write a complete OF implementation for U-Boot - just enough
> to boot OpenSolaris, but maybe OpenSolaris uses so much of OF that you pretty
> much have to have a complete OF implementation. Does anyone have a feel for
> how much of OF is required by Solaris, and whether the U-Boot idea is
> feasible? (keep in mind U-Boot is really lean - used to fit in 64Kb)
You REALLY don't want to take that approach.
There are two obvious approaches _to_ take here:
1) Add support for your board type to GRUB2, if it isn't already present
2) Modify U-Boot to know how to deal with the initial RAM disk image that
GRUB2 would normally load
I can't say which would be easier as frankly I don't have experience with
either booter, but since both know how to boot Linux now, the difficulty
of (2) would depend largely on how intimate U-Boot's knowledge of Linux
is (likely deep given it originally arose from some Linux boot code
according to the U-Boot README files.)
William Kucharski
william.kucharski at sun.com
