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