Stefan Reinauer wrote:
I don't think that's the right approach, because the code in Milax seems to be what's not standard conform here. It relies on an implementation specific detail of SUN's OFW.
IEEE 1275-1994 says:
Thus, they cannot be accessed at fixed locations, but instead must be
accessed by name. Users can access them by name using printenv and setenv.
Note there is no mentioning of any specific data type for configuration variables anywhere in 7.4.4.1. Milax assumes that load-base is a value (not a variable), hence the "to".
Alas it seems this is still present in OpenSolaris too :( I'm guessing they should be using "printenv", right?
I suggest as a workaround for this particular bug in Milax to add something like the following code at the end of nvram.fs:
load-base value load-base
This will leave the environment variable "load-base" intact for the use in the standard conform way and create a shadow value that will be used by Milax. This shadow value will be initialized with the initial value of load-base.
Nice hack ;) At least now the Fcode finishes execution, but it doesn't seem to load anything from the ramdisk.
ATB,
Mark.