This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [XenPPC] JS21/SLOF net boot commands

On Tue, 2006-06-20 at 01:05 +0200, 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 ;-)

What do you mean by this?  Can you please provide examples of how you
expect this to work?

> > 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 ;-)

We should know these steps manually for the sake of being able to
articulate the requirements for a proper solution.

> 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.

I agree with this.  

The current "netboot" client IMO can be acceptable provided:

1. SLOF is configured to always download a known forth fragment/script.
2. Because the downloaded image is not ELF, evaluation of it as
   attempted as a forth script.
3. The downloaded script is evaluated, and it uses netboot to download 
   the (multiple) appropriate components.

The use of this multiple-image-download script is merely a convenience
for developers (to avoid the need to link all fragments at build time).

The "built-in ramdisk" mechanism must be supported as well.  I actually
think Xen should use the existing (though perhaps modified) Linux zImage
code, and probably the prom_init code.  (Hence Xen could be a kexec

> 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.

We can live without this, provided we have the mechanisms that allow us
to set up a blade to boot Linux or Xen without user interaction.

> 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 ;-)

Emphasis on the "temporary".

Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>

Xen-ppc-devel mailing list