Re: [XenPPC] JS21/SLOF net boot commands

[Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>]

> > 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?
There is an OF environment variable ("config variable") called  
"nvramrc".
Those variables are stored in NVRAM, so they survive over rebooting (and
power off sequences).  "nvramrc" is executed as a piece of Forth code at
some point during boot.

As I said though, I'm not sure if we implement this yet.  And, if we do,
I'm 100% sure we don't do it in a _quite_ standard-compliant way yet
(although it might be good enough for your purposes).

If you feel you really need this, please escalate the issue...

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

> > 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.
Hard configured to just take whatever the DHCP and/or TFTP servers want
to give us, or soft-configured through some NVRAM thing, yes.

> 2. Because the downloaded image is not ELF, evaluation of it as
>    attempted as a forth script.
That doesn't happen yet AFAIK, and that's not exactly the correct
mechanism anyway; but, we should do something similar.  Escalate?
I could do this easily pretty soon, at the same time I abstract
out the elf-loader.

> 3. The downloaded script is evaluated, and it uses netboot to download
>    the (multiple) appropriate components.
This is still pretty hackish, due to the way the PowerPC binding handles
load- and run- addresses.  Not _too_ bad though, certainly at least as
good as the stunts yaboot pulls off already.

> 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).
Don't you have a unified build tree for those fragments anyway?  Can I
try to steer you towards linking them together please?  Linker scripts
are hours and hours of fun!  (Whoops, shouldn't have said that) ;-)

> 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.)
kexec?  Don't you have enough pain already?

> > 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.
I always did, so this is an eminently attainable goal.

You wouldn't be interested into building Xen into the boot ROM, are you?

> > 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".
Yes, {\bold{\it<b><i>TEMPORARY</i></b>}}.


Segher


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel