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

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.


Any FW/bootloader config that can load Linux image "X", should work if X
magically becomes a Xen image.


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.


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.


These may seem like trivialities or not important to some, but to me
this is very important.


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.


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