Hi Ron, I started looking at building the Via/Epia with the v2, and noticed that your last snapshot said that the mainboard Config.lb should set the ROM_SIZE to 265K.
Here's a little patch that lets the config python use 'default OPTION value' tag in the Mainboard Config.lb overriding the value set in config/Optins.lb (which has ROM_SIZE set to NONE)
or should the command be 'default OPTION=<value>' in which case, alter the line for 'rule default<<C>>: ...' to read rule default<<C>>: DEFAULT ID EQ value {{ if(C): mbdefault(ID,value) }}
Regards Mark Wilkinson.
PS. Hope to burn a V2 epia bios tomorrow morning and test !!
If my understanding is correct, you want to have an option value that has a mainboard specific default value, but that can be overridden in the target configuration file?
If this is the case, then my preference would be to do something like the following in the mainboard file:
if ~ ROM_IMAGE_SIZE option ROM_IMAGE_SIZE = 65536 end
where the '~' operator means "hasn't been set".
It seems to me this would be clearer than changing a default value, possibly after the value has already been set.
Greg
At 3:44 PM +0100 1/10/03, Mark Wilkinson wrote:
Hi Ron, I started looking at building the Via/Epia with the v2, and noticed that your last snapshot said that the mainboard Config.lb should set the ROM_SIZE to 265K.
Here's a little patch that lets the config python use 'default OPTION value' tag in the Mainboard Config.lb overriding the value set in config/Optins.lb (which has ROM_SIZE set to NONE)
or should the command be 'default OPTION=<value>' in which case, alter the line for 'rule default<<C>>: ...' to read rule default<<C>>: DEFAULT ID EQ value {{ if(C): mbdefault(ID,value) }}
Regards Mark Wilkinson.
PS. Hope to burn a V2 epia bios tomorrow morning and test !! Attachment converted: Macintosh HD:config.patch (TEXT/ttxt) (002EE9D4)
Hi Greg,
On Wednesday 01 Oct 2003 16:25, Greg Watson wrote:
If my understanding is correct, you want to have an option value that has a mainboard specific default value, but that can be overridden in the target configuration file?
Not quite, Ron (I assume it was Ron) already added a line like default ROM_SIZE 256*1024 to the src/mainboard/via/epia/Config.lb file (there are similar lines for solo and one other I think) in the CVS snapshot (20031001-1400)
What my patch does is make that line work so that the buildtarget command will work out of the box (or cvs snapshot) in the targets diretory for ./buildtarget via/epia
The solo and other one (hdama) both have 'option ROM_SIZE ....' lines in their target Config.lb files
I think what was trying to be achived is that the mainboard config file has a default rom size for the flash part supplied with that mainboard, and if you want to override it (say you have a larger flash part) you can in the target config file.
If this is the case, then my preference would be to do something like the following in the mainboard file:
if ~ ROM_IMAGE_SIZE option ROM_IMAGE_SIZE = 65536 end
where the '~' operator means "hasn't been set".
It seems to me this would be clearer than changing a default value, possibly after the value has already been set.
Greg
At 3:44 PM +0100 1/10/03, Mark Wilkinson wrote:
Hi Ron, I started looking at building the Via/Epia with the v2, and noticed that your last snapshot said that the mainboard Config.lb should set the ROM_SIZE to 265K.
Here's a little patch that lets the config python use 'default OPTION value' tag in the Mainboard Config.lb overriding the value set in config/Optins.lb (which has ROM_SIZE set to NONE)
or should the command be 'default OPTION=<value>' in which case, alter the line for 'rule default<<C>>: ...' to read rule default<<C>>: DEFAULT ID EQ value {{ if(C): mbdefault(ID,value) }}
Regards Mark Wilkinson.
PS. Hope to burn a V2 epia bios tomorrow morning and test !! Attachment converted: Macintosh HD:config.patch (TEXT/ttxt) (002EE9D4)
Mark,
Understood. The thing I don't like about Ron's solution is that is relies on an option effectively having two values simultaneously - a default value and a set value. Being able to modify both these values independently, then relying on a side effect to determine the actual value seems a recipe for future problems and confusion. My original intention was the that default value would just be the initial value of the option, nothing more than that.
What Ron and you have highlighted is that there is a need for part-specific default values for options (maybe more than just the mainboard.) My suggestion is that these default values be dealt with by either explicitly setting the option value (using the ~ operator) or through some other explicit mechanism.
One possibility would be to add a Default.lb file in the part directory (containing lines like 'ROM_SIZE=65536') then in the target config file saying:
loadoptions loaddefaults mainboard/via/epia loaddefaults cpu/i386
The important thing is that these are loaded in the target config file, before any option values are set.
Greg
At 4:44 PM +0100 1/10/03, Mark Wilkinson wrote:
Hi Greg,
On Wednesday 01 Oct 2003 16:25, Greg Watson wrote:
If my understanding is correct, you want to have an option value that has a mainboard specific default value, but that can be overridden in the target configuration file?
Not quite, Ron (I assume it was Ron) already added a line like default ROM_SIZE 256*1024 to the src/mainboard/via/epia/Config.lb file (there are similar lines for solo and one other I think) in the CVS snapshot (20031001-1400)
What my patch does is make that line work so that the buildtarget command will work out of the box (or cvs snapshot) in the targets diretory for ./buildtarget via/epia
The solo and other one (hdama) both have 'option ROM_SIZE ....' lines in their target Config.lb files
I think what was trying to be achived is that the mainboard config file has a default rom size for the flash part supplied with that mainboard, and if you want to override it (say you have a larger flash part) you can in the target config file.
If this is the case, then my preference would be to do something like the following in the mainboard file:
if ~ ROM_IMAGE_SIZE option ROM_IMAGE_SIZE = 65536 end
where the '~' operator means "hasn't been set".
It seems to me this would be clearer than changing a default value, possibly after the value has already been set.
Greg
At 3:44 PM +0100 1/10/03, Mark Wilkinson wrote:
Hi Ron, I started looking at building the Via/Epia with the v2, and noticed that your last snapshot said that the mainboard Config.lb should set the ROM_SIZE to 265K.
Here's a little patch that lets the config python use 'default OPTION value' tag in the Mainboard Config.lb overriding the value set in config/Optins.lb (which has ROM_SIZE set to NONE)
or should the command be 'default OPTION=<value>' in which case, alter the line for 'rule default<<C>>: ...' to read rule default<<C>>: DEFAULT ID EQ value {{ if(C): mbdefault(ID,value) }}
Regards Mark Wilkinson.
PS. Hope to burn a V2 epia bios tomorrow morning and test !! Attachment converted: Macintosh HD:config.patch (TEXT/ttxt) (002EE9D4)
Greg Watson gwatson@lanl.gov writes:
Mark,
Understood. The thing I don't like about Ron's solution is that is relies on an option effectively having two values simultaneously - a default value and a set value. Being able to modify both these values independently, then relying on a side effect to determine the actual value seems a recipe for future problems and
confusion. My original intention was the that default value would just be the initial value of the option, nothing more than that.
What Ron and you have highlighted is that there is a need for part-specific default values for options (maybe more than just the mainboard.) My suggestion is that these default values be dealt with by either explicitly setting the option value (using the ~ operator) or through some other explicit mechanism.
One possibility would be to add a Default.lb file in the part directory (containing lines like 'ROM_SIZE=65536') then in the target config file saying:
loadoptions loaddefaults mainboard/via/epia loaddefaults cpu/i386
The important thing is that these are loaded in the target config file, before any option values are set.
Greg. This is why the original config tool did this in two passes.
The one pass algorithm of the current config tool, already does not work 100% of the time, the evidence is some options that do not work properly if I move them. So we might as well rework the code so it operates in two passes, a parsing passes and then an option evaluation pass.
With 2 passes we can have default values in configuration values and still ensure that we only ever have 1 default value for an option. If we dnn't modify the code to be a 2 pass algorithm Greg something like your changes for loaddefaults are what is needed.
Eric
On 1 Oct 2003, Eric W. Biederman wrote:
Greg. This is why the original config tool did this in two passes.
not so sure on this. I think Greg and I are iterating to a conclusion.
But if somebody wants to build it as a two-pass tool be my guest. I don't have the time or energy :-)
ron
On Wed, 1 Oct 2003, ron minnich wrote:
On 1 Oct 2003, Eric W. Biederman wrote:
Greg. This is why the original config tool did this in two passes.
one thing about the new tool, and why I thought we might not need two passes.
Default works this way for a variable (or should) 1.if variable is set with a default value, over-ride the value 2. if variable is not set with a value, set it 3. If variable is set via an option command, do not set value 4. If variable has been used, fatal error
option works this way: 1. If variable is set with a default, set it 2. If variable is not set with a default, set it. 3. if variable is set with an option, fatal error 4. If variable has been used, fatal error
Now, I think if I changed the rules for default above, to: Default works this way for a variable (or should) 1. if variable is not set with a value, set it 2. if variable has been set with a default, fatal error 2. If variable is set via an option command, do not set value 3. If variable has been used, fatal error
then default and option statements for a single variable can occur in any order, and the right results will occur. this would eliminate the second pass.
I think?
ron
On 1 Oct 2003, Eric W. Biederman wrote:
The one pass algorithm of the current config tool, already does not work 100% of the time, the evidence is some options that do not work properly if I move them. So we might as well rework the code so it operates in two passes, a parsing passes and then an option evaluation pass.
OK, OK, two passes.
sigh.
Greg?
ron
* ron minnich rminnich@lanl.gov [031002 06:18]:
On 1 Oct 2003, Eric W. Biederman wrote:
The one pass algorithm of the current config tool, already does not work 100% of the time, the evidence is some options that do not work properly if I move them. So we might as well rework the code so it operates in two passes, a parsing passes and then an option evaluation pass.
OK, OK, two passes.
Is this really closer to optimum than the current default..option behaviour? I don't really think that even having default ROM_SIZE in a mainboard config file would cause more mistakes than in the Options.lb file. But I may be wrong...
Stefan
On Thu, 2 Oct 2003, Stefan Reinauer wrote:
Is this really closer to optimum than the current default..option behaviour? I don't really think that even having default ROM_SIZE in a mainboard config file would cause more mistakes than in the Options.lb file. But I may be wrong...
I think I may agree with you. I'm just trying to see what people in general think.
ron
At 10:18 PM -0600 1/10/03, ron minnich wrote:
On 1 Oct 2003, Eric W. Biederman wrote:
The one pass algorithm of the current config tool, already does not work 100% of the time, the evidence is some options that do not work properly if I move them. So we might as well rework the code so it operates in two passes, a parsing passes and then an option evaluation pass.
OK, OK, two passes.
sigh.
Greg?
ron
I look at it.
Greg
On Wed, 1 Oct 2003, Greg Watson wrote:
If my understanding is correct, you want to have an option value that has a mainboard specific default value, but that can be overridden in the target configuration file?
If this is the case, then my preference would be to do something like the following in the mainboard file:
if ~ ROM_IMAGE_SIZE option ROM_IMAGE_SIZE = 65536 end
where the '~' operator means "hasn't been set".
It seems to me this would be clearer than changing a default value, possibly after the value has already been set.
well, guys, here is how it works not.
ROM_IMAGE_SIZE is define in Options.lb (read first) with no default value.
In the config (e.g. targets/via/epia/Config.lb) you can set something like: option ROM_IMAGE_SIZE=512*1024
If there is no setting, then what applies is in the mainboard file:
default ROM_IMAGE_SIZE=256*1024
however, I did not know about this 'hasn't been set' stuff. Sorry. Greg, I have no problem with that.
ron
At 10:20 AM -0600 1/10/03, ron minnich wrote:
On Wed, 1 Oct 2003, Greg Watson wrote:
If my understanding is correct, you want to have an option value that has a mainboard specific default value, but that can be overridden in the target configuration file?
If this is the case, then my preference would be to do something like the following in the mainboard file:
if ~ ROM_IMAGE_SIZE option ROM_IMAGE_SIZE = 65536 end
where the '~' operator means "hasn't been set".
It seems to me this would be clearer than changing a default value, possibly after the value has already been set.
well, guys, here is how it works not.
ROM_IMAGE_SIZE is define in Options.lb (read first) with no default value.
In the config (e.g. targets/via/epia/Config.lb) you can set something like: option ROM_IMAGE_SIZE=512*1024
If there is no setting, then what applies is in the mainboard file:
default ROM_IMAGE_SIZE=256*1024
however, I did not know about this 'hasn't been set' stuff. Sorry. Greg, I have no problem with that.
ron
The problem is you're relying on obscure behavior of an option. You're setting (or not setting) an option in the target config file, then subsequently changing it's default value, then using whichever happens to override the other. See my reply to Mark.
Greg
On Wed, 1 Oct 2003, Greg Watson wrote:
The problem is you're relying on obscure behavior of an option. You're setting (or not setting) an option in the target config file, then subsequently changing it's default value, then using whichever happens to override the other. See my reply to Mark.
the 'default' command was supposed to work as follows:
set value if not set.
default is really equivalent to
if ~ value value = x end
so value is set only if not set at that point.
ron
* Mark Wilkinson mwilkinson@ndirect.co.uk [031001 16:44]:
Here's a little patch that lets the config python use 'default OPTION value' tag in the Mainboard Config.lb overriding the value set
Is that not possible already? I've been using it in some of the opteron builds since a while...?!?
Stefan
On Wed, 1 Oct 2003, Stefan Reinauer wrote:
'default OPTION value' tag in the Mainboard Config.lb overriding the value set
Is that not possible already? I've been using it in some of the opteron builds since a while...?!?
default was not allowed in mainboard files until I added that patch.
ron
Mark, that patch is not needed, there is already code in place to do that.
But thanks for the input, we appreciate it.
I'm impressed that you got that all worked out!
thanks!
ron
-
ebiederman＠lnxi.com -
Greg Watson -
Mark Wilkinson -
ron minnich -
Stefan Reinauer