# WARNING - OLD ARCHIVES

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

# xen-ppc-devel

## Re: [XenPPC] JS21/SLOF net boot commands

 To: Michal Ostrowski Re: [XenPPC] JS21/SLOF net boot commands Segher Boessenkool Tue, 20 Jun 2006 01:56:24 +0200 Jimi Xenidis , xen-ppc-devel Mon, 19 Jun 2006 16:56:38 -0700 www-data@xxxxxxxxxxxxxxxxxx <1150758898.3713.194.camel@brick> Xen PPC development , , <6E9F9F82-224C-4378-B64A-B5497F244D99@xxxxxxxxxxxxxx> <1150751852.3713.168.camel@brick> <102B20EC-47DA-4ED2-9162-5BA1BEE1582B@xxxxxxxxxxxxxx> <1150757258.3713.183.camel@brick> <2BD9DC5A-5E98-47D9-B0A9-9E11B3B96258@xxxxxxxxxxxxxxxxxxx> <1150758898.3713.194.camel@brick> xen-ppc-devel-bounces@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{\itTEMPORARY}}. Segher _______________________________________________ Xen-ppc-devel mailing list Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ppc-devel 
 Current Thread [XenPPC] JS21/SLOF net boot commands, Jimi Xenidis Re: [XenPPC] JS21/SLOF net boot commands, Michal Ostrowski Re: [XenPPC] JS21/SLOF net boot commands, Jimi Xenidis Re: [XenPPC] JS21/SLOF net boot commands, Segher Boessenkool Re: [XenPPC] JS21/SLOF net boot commands, Michal Ostrowski Re: [XenPPC] JS21/SLOF net boot commands, Segher Boessenkool Re: [XenPPC] JS21/SLOF net boot commands, Segher Boessenkool Re: [XenPPC] JS21/SLOF net boot commands, Michal Ostrowski Re: [XenPPC] JS21/SLOF net boot commands, Segher Boessenkool <= Re: [XenPPC] JS21/SLOF net boot commands, Jimi Xenidis Re: [XenPPC] JS21/SLOF net boot commands, Segher Boessenkool Re: [XenPPC] JS21/SLOF net boot commands, Michal Ostrowski Re: [XenPPC] JS21/SLOF net boot commands, Segher Boessenkool Re: [XenPPC] JS21/SLOF net boot commands, Jimi Xenidis Re: [XenPPC] JS21/SLOF net boot commands, Hollis Blanchard Re: [XenPPC] JS21/SLOF net boot commands, Michal Ostrowski Re: [XenPPC] JS21/SLOF net boot commands, Segher Boessenkool Re: [XenPPC] JS21/SLOF net boot commands, Jimi Xenidis