Re: [XenPPC] JS21/SLOF net boot commands

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

I posted these "hacks", because people were asking me how I loaded  
images separately on this machine.
There is no architected design, just another hack for a insufficient  
loading environment for a specific development environment.
Except for the "load anywhere" argument, which I would like to see  
eventually, you guys are FOS.
There is a Xen work-a-round for every single issue you guys raise,  
I'm just describing a way that accelerate the boot process over a  
network on a specific piece of HW.
In a production environment with SLOF, a bootloader will obtain n  
images (2 for yaboot, N for grub) from the disk, which is a runtime  
IO method SLOF supports.
On Jun 19, 2006, at 7:05 PM, Segher Boessenkool wrote:

> > > When its made a SLOF word you just type "xen" :)
> > By whom?  If it is by the user then the definition is lost once you
> > reboot (it is as far as I can tell with the current images I have).
> You can store the commands in nvramrc.  Not sure if that works right
> now though ;-)
>
> > The boot-loader requirements for xen should be no different than  
> > those
> > for Linux.  If Linux tolerates being loaded at an arbitrary  
> > address, so
> > should Xen.
> Yes.
>
> > Any FW/bootloader config that can load Linux image "X", should  
> > work if X
> > magically becomes a Xen image.
> Yes.
>
> > You must be able to switch back and forth between booting xen and  
> > Linux,
> > without anything more than simply telling FW/bootloader to load a
> > different image.
> Yes.
>
> > If you're using netboot, then any netboot invocation that boots Linux
> > should boot Xen if a Xen image is substituted for the Linux image  
> > on the
> > tftp server.
> Yes.
>
> > These may seem like trivialities or not important to some, but to me
> > this is very important.
> x2.
>
> > The amount of developer time that will be
> > wasted due to a) manually targeting FW on every boot  b) debugging
> > misconfiguration/typos will very quickly recoup any investment in
> > getting this right.
> > If you need to re-type this stuff on every boot, then it is not a
> > reasonable solution.
> It's better than nothing...  for now.  Developers _should_ feel the
> pain, that's what makes them create better solutions ;-)
>
>
> That said...  It seems to me that the main problem here is that you
> need to load _two_ images, something OF was never designed for.
>
> You could try putting the second image in through the same cheesy
> mechanism that yaboot uses for the initrd (GPR4, GPR5 iirc).  That's
> the path of least resistance.  Much better would be to use your own
> wrapper, similar to the more modern Linux "built-in ramdisk" thing.
>
>
> Segher
>
>
> p.s.  And no, I'm not downplaying the fact that SLOF doesn't have  
> proper
> network "laod" support yet.  That's a completely separate issue, and
> not likely to be resolved _too_ soon, anyway.
>
> My point is that you guys should design _your_ stuff to be as non- 
> fragile
> as possible, too :-)
>
> Jimi's hack is fine as a temporary thing during development, of  
> course.
> It sounds like it is generating complaints already though ;-)
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel