On Wed, Aug 17, 2005 at 10:43:51PM +0300, Cyril Plisko wrote: > On 8/17/05, Sven Luther <sven.luther at wanadoo.fr> wrote: > > On Wed, Aug 17, 2005 at 09:20:23PM +0300, Cyril Plisko wrote: > > > On 8/17/05, Sven Luther <sven.luther at wanadoo.fr> wrote: > > > > On Wed, Aug 17, 2005 at 04:56:37PM +0200, Joerg Schilling wrote: > > > > > Cyril Plisko <cyril.plisko at gmail.com> wrote: > > > > > > > > > > > let me disagree with you. Since we have nothing working right now > > > > > > we have quite a load of code to write and test even _before_ we get > > > > > > to crypto and ATA subsystem. Of course in a sense that we still > > > > > > will not have a fully pledged distribution you are right and lack > > > > > > of the basic stuff like the one you mentioned will prevent us > > > > > > from declaring the job is done. But still one have to start walking > > > > > > in order to get somewhere. > > > > > > > > > > The PPC hardware we use depends on an ATA disk and we need an ATA > > > > > driver in order to boot. > > > > > > > > Can't you netboot with a ramdisk image like linux dies ? > > > > > > I guess that should be possible too. Can you describe the Linux > > > netboot process in more details ? I am quite familiar with how > > > Solaris does netboot on SPARC and x86, but have to admit > > > I amnot sure how similar or different Linux netboot is on PPC > > > > Another why would be a NFS root system, this would probably work nicely in > > the > > solaris framework. > > Should be. In fact Solaris SPARC has it working very nice - that is > what I originally planned to start from. Still it has a drawback of having > to implement complete NFS stack in order to load kernel modules > (Solaris kernel is highly modularized).
Well, you already have the sparc NFS stack, should be easily portable, as i don't see many arch-specific stuff in that, but then i may be wrong. > > For the ramdisk method, yaboot or grub2 copies the (compressed) initrd in > > ram, > > and passes to the booting kernel the address of said ramdisk in r4 or > > something such. the kernel then accesses this ramdisk, it knows its size, or > > the end of it, don't remember, and then mapps a filesystem on it. compressed > > ext2 in a loop (cloop) device, or cramfs usually. > > > > Right, that is what so appealing about GRUB - you can have your kernel > boot archive built on cross system and then load it from disk/network > into RAM and have it running even without network/disk drivers. > Should be a gift for early kernel work, when even core functionaly > is barely present. The other way is to append the initrd to the kernel elf file, in a separate elf sectrion, and have a mini wrapper program which uncompresses the kernel and moves the intird into place. this is what is done on pegasos right now, and the code is in arch/ppc/boot/openfirmware/chrp_main.c if i remember well. friendly, Sven Luther