On 1/1/10 8:47 PM, Mark Cave-Ayland wrote:
Mark Cave-Ayland wrote:
Stepping through with the debugger shows that it is now dying in the very last line of exec-file which reads:
" to load-base init-program" evaluate
So it looks as if we're very nearly there. My guess would be that OpenBIOS is dying somewhere within init-program. Does anyone know anything about what init-program should be doing under SPARC64? Has it ever been tested before?
Hmmmm now I see what the problem is - load-base is actually a special configuration word and not a variable. Hence when the Fcode executes "to load-base" it overwrites the first part of the load-base word causing the crash.
Reading the OF specification in section 7.4.4.1 it seems that OpenBIOS violates the Fundamental Data Type property of configuration variables since they are stored in a special configuration word format. I think the only way to solve this is rework the NVRAM code so that it respects the fundamental data types when creating the configuration variables. Does everyone agree that this is the way forward?
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".
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.
Stefan