On 1/6/06, Sven Luther <sven.luther at wanadoo.fr> wrote: > > > > > > 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.
Correct - NFS works around that. > > > > > 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 ? http://docs.sun.com/app/docs/doc/819-0690 Linker Guide - can be a good start > > > > 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 :) http://svn.genunix.org/repos/opensolaris/trunk for your service ! > > > > 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 ? I am not ready for commitment like that at this time - I think we need to get something working and re-evaluate the situation again. And we need to get community agreement on what is the best thing to implement. Another thing to consider is which partition types are in use on other PowerPC/POWER implementations - we''d better go with something most widely used. -- Regards, Cyril
