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