Re: [XenPPC] JS21/SLOF net boot commands

[Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>]

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



> 
> 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
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel