Re: V2 VIA EPIA
ron minnich [EMAIL PROTECTED] writes: OK, for VGA, here we go again. Here is my plan. I will combine vgabios + idt into one file, put it in pc80, make it a standard device, have it turn itself on with the standard static configuration techniques, and we'll have vga. The understanding here is that this is code that we hope to deprecate in favor of the emulation that Stefan is working on. But the pressure to do something in the short term is getting irresistable, this code works, so I think we take a short term focus to help the user community. I'll try to get this in this week. Ok. That sounds like a plan. As long as it does not require special cases in the configuration it should impose no extra support burden. Adam Agnew has pointed me at a frame buffer driver for the ATI Rage XL that should be capable of initializing the card without bios support. If that works we have an even better solution. So that would make an even more elegant driver for the cards that have on board VGA support. And given that the ATI Rage XL is the most common chip I have seen on motherboards with LinuxBIOS it should be a big help. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Level 2 cache activation code?
Ron, Thank you for your reply. Maybe there is hope after all. On Wed, 2003-10-01 at 01:34, ron minnich wrote: On Tue, 30 Sep 2003, Svante Signell wrote: i) Does this code work for 440BX motherboards? it's processor-dependent, 440bx or not is not an issue. Thanks for the info. To clarify I'll split the question into three: i) Does LinuxBIOS work for 440BX-based mother-boards, single and dual? Downloading the code from CVS shows support for Intel L440GX+ and a patch for linux-2.4.13, not 440BX or kernels later than 2.4.13. Also, I did not find anything about MSI mainboards. ii) Does the cache activation code work for Mendocino, Coppermine, Tualatin and newer Intel processors? Will it work for the VIA C3 Nehemiah? iii) How much of the boot process in GNU/Linux the BIOS responsible for? I thought that the kernel was only dependent on the BIOS for a few functions, such as different HW initialisations: CPU, memory, disks, etc compared to Windows 9x etc. Any pointers? ii) Is it possible to extract this code and try out after the kernel has booted (slowly), to verify my assumption? yes, we tested it that way. You can try it. I will try. Which files do I need in addition to src/cpu/p6/l2_cache.c? iii) Is there some other tool available for cache activation? Not sure. iv) One interesting continuation would be to try to replace the MSI (AMI) BIOS with linuxbios, but as a first step I think this would be a little risky. well, so far, given the track record of many of these BIOSes, I'm not sure how risky that is ... With risks I meant the chance of being left with a dead motherboard... I'm always nervous when flashing the BIOS that something will happen, for example a sudden power loss, regardless of where the BIOS originates from. ron BTW: Why is this work called LinuxBIOS (except maybe for historical reasons). Will other OSes (eg GNU/Hurd) boot with LinuxBIOS now or in the future? Maybe then something like FreeBIOS should be used instead. Thanks, Svante ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Level 2 cache activation code?
On Wed, 1 Oct 2003, Svante Signell wrote: i) Does LinuxBIOS work for 440BX-based mother-boards, single and dual? Downloading the code from CVS shows support for Intel L440GX+ and a patch for linux-2.4.13, not 440BX or kernels later than 2.4.13. Also, I did not find anything about MSI mainboards. single are tested. Dual I don't know. ii) Does the cache activation code work for Mendocino, Coppermine, Tualatin and newer Intel processors? Will it work for the VIA C3 Nehemiah? It was only needed for PII. Coppermine and later -- Just works. It is extremely cpu-dependent. iii) How much of the boot process in GNU/Linux the BIOS responsible for? I thought that the kernel was only dependent on the BIOS for a few functions, such as different HW initialisations: CPU, memory, disks, etc compared to Windows 9x etc. Any pointers? that's about right. I will try. Which files do I need in addition to src/cpu/p6/l2_cache.c? none. You have to turn that back into a main() but it should be fine. With risks I meant the chance of being left with a dead motherboard... I'm always nervous when flashing the BIOS that something will happen, for example a sudden power loss, regardless of where the BIOS originates from. never do this kind of work without a spare bios part. Never. BTW: Why is this work called LinuxBIOS (except maybe for historical reasons). Will other OSes (eg GNU/Hurd) boot with LinuxBIOS now or in the future? Maybe then something like FreeBIOS should be used instead. It was called linuxbios for a simple reason: linux was going to be the bios. linux would be in flash, linux would boot the oses. Small flashes have caused changes in course in some cases, but the name has stuck anyway. Now that vendors have joined in, changing the name would be hard. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: V2 VIA EPIA
Oh, I can see what is going to happen to buildrom now that Ron has discovered it... :-) Greg At 11:44 PM -0600 30/9/03, ron minnich wrote: Changes: new epia target for 512k: targets/via/epia/Config.512kflash.lb epia defaults to 256k flash buildtarget now takes either a directory, and uses directory/Config.lb, or takes a file e.g. buildtarget via/epia will use via/epia/Config.lb, and buildtarget via/epia/Config.512kflash.lb will use that file. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Patch for V2 new config
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 defaultC: ...' to read
rule defaultC: DEFAULT ID EQ value {{ if(C): mbdefault(ID,value) }}
Regards
Mark Wilkinson.
PS. Hope to burn a V2 epia bios tomorrow morning and test !!diff -ur freebios2-1400/util/newconfig/config.g freebios2/util/newconfig/config.g
--- freebios2-1400/util/newconfig/config.g 2003-09-26 12:40:05.0 +0100
+++ freebios2/util/newconfig/config.g 2003-10-01 15:26:10.0 +0100
@@ -521,6 +521,15 @@
self.default = 1
self.loc = loc
+ def altdefault(self, value, loc):
+ global global_option_values
+ if (self.default):
+ warning(default value for %s already set % self.name)
+ setdict(global_option_values, self.name, value)
+ self.defined = 1
+ self.default = 1
+ self.loc = loc
+
def setnodefault(self, loc):
self.default = 1
self.defined = 0
@@ -872,6 +881,16 @@
v = option_value(value)
o.setdefault(v, loc)
+def mbdefault(name, value):
+ global loc, global_options
+ o = getdict(global_options, name)
+ if (not o):
+ return
+ if (o.default):
+ print setdefault: modifing default for %s % name
+ v = option_value(value)
+ o.altdefault(v, loc)
+
def setnodefault(name):
global loc, global_options
o = getdict(global_options, name)
@@ -1488,7 +1507,7 @@
#mainboard config files are special, in that they can also have
# default values.
rule mainboard_cfgfile: (uses1)*
-(defstmts1)*
+(default1)*
(stmt1)*
EOF {{ return 1 }}
@@ -1550,6 +1569,9 @@
# ENTRY for parsing a delayed value
rule delexpr: { expr } EOF {{ return expr }}
+
+rule defaultC: DEFAULT ID value {{ if(C): mbdefault(ID, value) }}
+
rule defstmtsID: {{ d = 0 }}
( DEFAULT
( value {{ setdefault(ID, value) }}
Re: Patch for V2 new config
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 defaultC: ...' to read
rule defaultC: 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)
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Patch for V2 new config
* Mark Wilkinson [EMAIL PROTECTED] [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 -- Architecture Team SuSE Linux AG ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Patch for V2 new config
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Patch for V2 new config
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Patch for V2 new config
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 defaultC: ...' to read
rule defaultC: 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)
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Patch for V2 new config
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Patch for V2 new config
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Patch for V2 new config
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 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
