On Fri, Jan 06, 2006 at 04:55:05PM +0200, Cyril Plisko wrote: > On 1/6/06, Sven Luther <sven.luther at wanadoo.fr> wrote: > > On Fri, Jan 06, 2006 at 03:28:21PM +0200, Cyril Plisko wrote: > > > > > > > > What is important is that the OF client interface is still active and > > > > can be > > > > used from the client program (namely OpenSolaris here). This is the way > > > > the > > > > linux kernel early startup does it, in his prom.c code, and the way both > > > > yaboot and grub2 access the disk underneath. > > > > > > > > grub2 really only provides OF-like capabilities to hardware lacking > > > > such, and > > > > in the OF implementation case, it mostly just passes down his read > > > > accesses to > > > > the lower level. > > > > > > What makes the GRUB2 so attractive is that it makes us independent from > > > ufsboot. > > > > Indeed, i understand that. But if the pegasos OF had an ufs driver of the > > level of the ufsboot one, this would also free you from the ufsboot thingy, > > no ? > > Yes, and at the same time will require us to implement ATA driver (in any > form) > right away.
No, because we can simply use the OF ATA driver for now, which at 5/6MB/s i, altough not fast, very usable for this early development stage. You need to have the MMU and interrupt controller working in order to be able to worry about fast ATA drivers, and in the meantime you have NFS. > > > It fetches the ramdisk image into the memory and runs from there. Which > > > let us > > > > The OF has also the ability to load and execute elf binaries. > > That is true and very useful. Having more than one way of booting system is > good. Indeed. I am not sure the OF elf loader has the ability to do the special linking step of dependent module Joerg spoke about, is this one documented, or part of the official elf spec or something ? > > Nope, probably not, but it would be interesting to have good quality ufs > > drivers in the pegasos OF implementation, of the same level of those found > > in > > usfboot. > > Have a look at > usr/src/psm/stand/bootblks/ufs/common/boot_1275.fth and > usr/src/psm/stand/bootblks/ufs/common/boot_obp.fth Ok. will have a look. I need to get hands on a copy of the source code first though :) > > > Today Pegasos firmware supports Amiga and FDISK types, right ? > > > > There is support for amiga RDBs, msdos FDISK, and bsd disklabels, and > > filesystem support for (v)fat, ext2/3, bsd ufs, and amiga ffs, pfs and sfs. > > > > Currently all pegasos favour the amiga RDB partition table (basically a > > linked > > list of partition, each partition can be upto 32bit of cylinder value size, > > and each cylinder size being defined by the multiplication of two 32bit > > values > > (sectors and heads they are traditionally called), and one 32bit value for > > sector size i believe, and you can have any number of partitions in the > > linked > > list. Also, of interest to you, there is a 32bit value usable as partition > > type marker, which you would use for zfs, which is something similar to > > linux's raid/md/lvm thingy. The RDB disklabel also has support for carying > > filesystem drivers, a bit like Solaris uses, and now also incorporates space > > for a boot program. The RDB itself can be an arbitrary number in size, upto > > 32bit of sectors i think. > > > > Either a OpenSolaris driver can be written for this, which makes > > cohabitation > > with other operating systems easier, and yes, i am ready to write and > > maintain > > That is important consideration. Yes, especially as i had the (bad) experience of the suse installer assuming MBR because they didn't want to do the added work to support the RDBs, and thus cause full data loss for one users when their installer just forgot to recognize the existing partition table and overwrote it with an MBR. They fixed it since, rihgt ? > > said code, having implemented it for both libparted and yaboot. The other > > solution would be for the OF to implement whatever partition table is chosen > > and prefered, provided you provide us with a clear specification of the > > format > > in question. > > The GPT label is described in EFI spec (http://www.intel.com/technology/efi) > and parted supports it too. I know, but not well, i have seen patches and bug reports concerning the GPT stuff these past months or so. But the real question is, are you ready to officially require the GPT/EFI and make it the default, or would another existing format do ? Friendly, Sven Luther
