October 2005 - coreboot - mail.coreboot.org

Re: [LinuxBIOS] BIOS Saver RD1
by Ken Fuchs June 5, 2007

June 5, 2007

> On Wed, Aug 03, 2005 at 11:59:20AM +0900, Jun OKAJIMA wrote: > > Probably, most guys here use BIOS Saver. > > And it works well? > > In mine, RD1 for PLCC gets not being writable suddenly. > > I mean, it seems writable but # flash_rom -v fails. > > I solved this problem by a quick hack. > > > > How about yours? You can write RD1 or W49F002U well? > > Any problem happen? Johnathan McDowell wrote: > Even after that it's sometimes a bit flakey and I have to erase, then > write it. I've put the board's original BIOS in the RD1 and am writing > to the SST 39SF020A instead, which works without problems. I've read posts about the RD1 that suggest its integrated flash device is low quality and it may take 10 or more flash attempts to get a good flash update to the RD1 flash device. As a result, many RD1 BIOS Savior users will flash the commercial BIOS image (or other known good BIOS image) into the RD1 integrated flash device as many times as needed to get an image that boots. Then use the original BIOS device to flash test BIOS image (usually LinuxBIOS images among this group), since the original BIOS device usually flashes OK on the first attempt. I've used the RD1 in the above fashion with great success on the Tyan S2885 mainboard. The same RD1 would not work on the nVidia CK8-04 CRB mainboard. I think the CK8-04 CRB requires a flash device that the RD1 does not support. However, the RD1 worked well as an "do nothing" adapter which allowed swapping the BIOS flash device between my flash burner and the mainboard without any wear to the mainboard's BIOS socket. BTW, my flash burner is an older Enhanced Willem Universal Programmer. I got mine for only $60 US over a year ago. I've seen it for less than $40 on eBay a few weeks ago. The newest model is going for about $50 US. It does a LinuxBIOS flash in about 5 minutes; not bad for a $60 burner. However, it does require changing DIP switches to match an image for each device it can program. Great for the amateur or professional with a small budget. > > BTW, a cable of your RD1 is not broken? > > I needed soldering to fix it. > Mine was fine out of the box. Mine cable and switch worked fine out of the box as well. Sincerely, Ken Fuchs <kfuchs(a)winternet.com> ami-mac-sun

16 47

[LinuxBIOS] x86_64: calibrate_delay_direct and apic id lift for BSP
by Yinghai Lu Jan. 6, 2006

Jan. 6, 2006

andi, I tried to lift apic id in LinuxBIOS for all cpus after 0x10. When using MB with AMD8111, the jiffies was not moving. So it is locked at calibrate_delay_direct... but MB with Nvidia ck804, jiffies is moving. If I don't change BSP apic id ( keep it to 0), It changes.... I have no idea how the jiffies changes, there is another thread change it....? YH Memory: 508000k/524288k available (3146k kernel code, 15900k reserved, 1160k data, 296k init) calibrate_delay_direct i=0 calibrate_delay_direct start_jiffies=fffedb08 calibrate_delay_direct 1 jiffies=fffedb08 calibrate_delay_direct 1 jiffies=fffedb08 calibrate_delay_direct 1 jiffies=fffedb08 calibrate_delay_direct 1 jiffies=fffedb08

3 2

RE: [LinuxBIOS] E7501 Raminit rewrite
by Lu, Yinghai Nov. 1, 2005

Nov. 1, 2005

Every define have SPD_DDR_ prefix, or with ddr_spd.h and SPD_ prefix.... YH -----Original Message----- From: Steven J. Magnani [mailto:steve@digidescorp.com] Sent: Wednesday, September 14, 2005 11:06 AM To: Lu, Yinghai; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite Can you be more specific about the changes you'd like to see? Steve -----Original Message----- From: Lu, Yinghai [mailto:yinghai.lu@amd.com] Sent: Tuesday, September 13, 2005 10:27 AM To: Steven J. Magnani; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite It's good to have spd.h there. But the name should be changed for support DDR2...etc. YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Steven J. Magnani Sent: Tuesday, September 13, 2005 8:08 AM To: linuxbios(a)openbios.org Subject: [LinuxBIOS] E7501 Raminit rewrite This one ends up being a little more than a "patch". I ended up reorganizing the E7501 raminit code so I could follow it, and fixed some bugs along the way. Significant logical changes: * Added support for "fast" (64-clock) refresh * Added code to support remap window for 3 - 4 GB systems * Fixed premature configuration of true row boundaries that resulted in some sections of DRAM not receiving JEDEC commands (see http://openbios.org/pipermail/linuxbios/2005-June/011752.html) * Redefined RCOMP_MMIO so that RCOMP registers can be configured on systems where A20M# is asserted. * Disabled subsystem (vendor) ID configuration * #ifdef'd out suspicious looking code (see http://openbios.org/pipermail/linuxbios/2005-June/011759.html) * Added optional run-time checking of dual-channel compatibility of installed DIMMs * Move JEDEC SPD and SDRAM definitions into reusable #include files Probably, the rewritten code should be reviewed as if it were new. My hope is that it is now easy enough to follow that this shouldn't be too bad. The original code is, of course, in Subversion. Since I reordered the functions as part of the rewrite, a 'diff' of of the new code against the original won't tell you much. I've attached a reordered copy of the Subversion code that won't compile, but should be a little easier to diff against the new code so you can see what's changed. I will hold off on committing this for awhile to give people time to look at it. I know that radical changes are a pain to review, but IMHO the improvement in maintainability is significant. New files that are part of this 'patch', but not included here (I committed these to Subversion): src/include/spd.h src/include/sdram_mode.h src/include/northbridge/intel/e7501/e7501.h Thanks, Steve ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include <standard.disclaimer>

2 1

[LinuxBIOS] Tyan S2865
by Justin Cormack Oct. 31, 2005

Oct. 31, 2005

Ok, I now have several of these. They shouldnt be very different from the supported Tyan chipsets (unless the nForce 4 Ultra chipset is very different from the nForce 4 Pro - lspci below). WOuld I be best off using ECC memory as all the other Tyan ports do? Any other hints and tips? ANyone looked at this? 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: nVidia Corporation: Unknown device 0050 (rev a3) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:05.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 01:06.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11)

1 0

[LinuxBIOS] New config language
by Josiah England Oct. 29, 2005

Oct. 29, 2005

It has come to the awareness of many (apparently *after* I did my talk at the summit) that the mini-config-language is quite useful and indeed necessary unless we want a bunch of really ugly, duplicated makefile code scattered through our codebase, and (most) people have come to the realization that they don't want to handwrite static C initialization structures unnecessarily. So, by request, I've modified the old pseudo-BNF for the config language and appended it to this message with the (initial) changes to include in the "new" language. This is by no means complete nor formal (yet hopefully it is relatively accurate ;). Most of the language description matches what we currently have, but I've also added many of the changes I deem necessary (mostly from common sense). There are a few notes and suggestions on which I'd like some feedback. Feel free to rant or rave on anything and furthermore share your ideas. Said changes are mostly small and include, but are not limited to: - Removing unnecessary "end" statements to commands that needn't be blocks (like 'arch') - Combined the function of 'define' (as found in src/config/Options.lb) as an optional part of the 'default' statement - Limited the widespread used of 'default' for setting options - Changed 'dir' to 'config' and 'config' to 'static' (maybe) - Removing necessity of double-quotes surrounding strings (which may happen to include double-quotes of their own) - etc... ------------------------------------------------------------------------------- New config language for LinuxBIOS This document defines the new configuration language for LinuxBIOS. The goals of the new language are these: - Move from the python based configuration tool to something more easily extensible and flexible - Simplify parser so people can see and alter what is done - Detail output so people can visualize the configuration tree during the parsing process - Implement capability for viewing and altering configuration with Kconfig Here is the new language. It is very similar to the old one, differing in only a few aspects. Furthermore, effort has been put forth to make the new configuration tool capable of parsing the syntax of the old language. This capability may be phased out in the near future, and replaced with warning/error statements for configuration files not conforming to the new language. Pseudo-BNF extensions key: Elements in angled brackets (<>) are nonterminal symbols; items within braces ({}) are for clarification and do not represent grammar, double-quotes ("") denote literal strings required in the text, elements in single-quotes ('') are keywords picked up by the parser, and a postfixed asterisk (*) denotes optionally repeatable blocks. # Expressions are composed of terms acted upon by operators # (unary or binary). # They may optionally be surrounded by parentheses. # (Preferably, surrounding parentheses may soon be required syntax - ?) expr ::= ["("] ( unary-op term ) | ( term (binary-op term)* ) [")"] # term is a number (dec or hex with '0x' notation), ID, or expression. # An ID remains as an unexpanded reference until it is used or exported. term ::= NUM | ID | expr unary-op ::= "+" | "-" | "!" binary-op ::= "+" | "-" | "*" | "/" | "^" | "&&" | "||" # Default command: Define and set an ID to its initial value. # Defaults may only be set in Options.lb files. # Attempts to assign defaults elsewhere are treated as like 'option'. # It is OK to set an ID's default value after it has already been set. # Default assignments may optionally be followed on subsequent lines # with 'export', 'type', and/or 'comment' commands in any order. # A comment will be displayed in generated Kconfig menus. # Values are re-evaluated from component statements when referenced # (ie, are delayed-evaluate, or recursively expanded variables). default ::= 'default' ID "=" value [ type ::= ("number" | "bool" | "string") # (Hex vs. Dec ???) export ::= ("always" | "used" | "never") comment ::= 'comment' [<newline> <comment>]* "end" ] # Option command: Re-sets ID to new value. # Options are used in Config files (in expressions and 'if' statements) # and are also passed to the C compiler when building rom images. # Options always over-ride defaults. # It is an error to have an option command define the value of an ID # after the ID has been referenced (i.e. 'set after used' is an error). option ::= 'option' ID "=" value # Values are treated differently depending on their declared type. # A string is taken literally and doesn't need surrounding quotes. # A numeric type is always evaluated mathematically, as an expression. # An expr containing at least 1 one hex term results in a hex answer. value ::= string | term # Before any option may be referenced in a Config, it must be "used". uses ::= 'uses' ID # The 'chip' command causes sourcing of Config files as in the old # config tool. As parts are sourced, a device tree is built. # The 'device' command also works just as it has in the past. # Note that the 'device' command is used exclusively for describing the # device tree and it does not source any configuration files. # The structure of the tree is determined by the structure of the # components. # Example of structure: ... chip southbridge/via/vt8231 register "enable_native_ide" = "0" device pci 11.0 on # Southbrdge chip superio/winbond/w83627hf device pnp 2e.0 on # Floppy io 0x60 = 0x3f0 end ... # Static initializers are auto-generated from this hierarchy (static.c). # Order does not matter for statements in the same block (for instance, # in the above example, the device block may go before 'register' as # long as it ends). chip ::= 'chip' PATH ['register' """<register_name>""" "=" """<register_value>"""]* [<embedded_chip_or_device_statement>]* "end" # NOTE: Quotes may (preferably) become unneccessary in 'register' # clause. device ::= 'device' device_path_type device_path ("on" | "off") [device_resource <resource_index> "=" <resource_base>]* device_path_type ::= ("pci_domain" | "pci" | "pnp" | "apic" | "apic_cluster" | "i2c") device_path ::= <port_on_path_type>"."<device_number_on_path_type> # NOTE: The two numbers composing the path are implied hex (without the "0x") device_resource ::= "io" | "irq" | "drq" | "mem" # Except as otherwise noted (in 'mainboard' and 'arch'), # PATH is to a file's location in relation to the LinuxBIOS src dir. PATH ::= {path_to_Config_file/}<filename> # Files to include in static.c (Can this command have a better name?) static ::= 'static' PATH # Add C code to the current component (motherboard, etc.) # to initialise the component-INDEPENDENT structure members. # (Only used for src/arch/<arch>/init/crt0.S, so may become implicit) init ::= 'init' PATH # Add C code to the current component (motherboard, etc.) # to initialise the component-DEPENDENT structure members. register ::= 'register' <CODE> # mainboard command specifies where (from src/mainboard directory) # to find the board's root-level Config file with device tree. mainboard ::= 'mainboard' {src/mainboard/}PATH # Specify where (from within src/arch directory) to find the # architecture-specific Config file. arch ::= 'arch' {src/arch/}PATH # Target build directory target ::= 'target' PATH # Payload to include in image; existence is checked before compilation payload ::= 'payload' PATH # Files for building linuxbios: # Include a file in crt0.S mainboardinit ::= 'mainboardinit' PATH # Include an object for initialization initobject ::= 'initobject' PATH # Object file object ::= 'object' PATH # Driver objects are built into the image in a different way driver ::= 'driver' PATH # Use the Config file in the PATH config ::= 'config' PATH # Add a file to the set of ldscript files. ldscript ::= 'ldscript' PATH # Set up a makerule makerule ::= 'makerule' "<rule_name>" ("""[depends]""")* ("""[action]""")* "end" # NOTE: Again, quotes may become unneccessary # Dependencies or actions for the makerule command depends ::= 'depends' <raw_make_syntax(prerequisites)> action ::= 'action' <raw_make_syntax(commands)> # Add an action to an existing make rule. addaction ::= 'addaction' "<rule_name>" <raw_make_syntax(commands)> # Addition definitions used in generated image makefiles. makedefine ::= 'makedefine' <raw_make_syntax> # statements statement ::= option | default | uses | arch | target | chip | device | driver | object | makerule | makedefine | addaction | init | mainboardinit | initobject | if | config | static | ldscript statements ::= (statement)*

1 1

[LinuxBIOS] Epia-M patch
by Nick Barker Oct. 29, 2005

Oct. 29, 2005

I attach a patch file for the Via Epia-m target which makes this target now compile and work. I have tried to keep all changes local to the directories relevent to this target i.e. - mainboard/via/epia-m - northbridge/via/vt8623 - southbridge/via/vt8623 - southbridge/ricoh - superio/via/vt1211 - targets/via/epia-m However there are 4 files which are modified elsewhere in the sources: - devices/cardbus_device.c - which needed another io resource probing - comments suggest no-one else is using this anyway - include/device/cardbus.h - to include another function definition - cpu/via/model_centaur/model_centaur.c - to add more processor id codes and to get it to set up mtrr's - arch/i386/lib/cpu.c - to conditionally test for SMP & IOAPIC systems - this board/processor has no APIC's and would otherwise fail on the call to lapicid() In addition to making it work again, I have added the following functionality: - Dynamic memory sizing - which has been tested so far with: - - 256Mb 1 bank (i.e. single sided) - - 256Mb 2 bank (i.e. double sided) - - 512Mb 2 bank (i.e. double sided) - A minimalist ACPI dsdt table free of any intellectual property and can thus be distributed with sources. - Compact Flash boot working. - I have also written an EPIA-M howto which I have attached seperately. Maybe that can get onto the web site. Things still not resolved: I spent a great deal of time trying to get the vga to initialise through the emulator, but I have failed. I feel that I now know the workings of the emulator inside out, but it would take a good deal more effort to resolve the issues. As an interim solution, therefore, I have re-implemented the old real mode vga-bios.c which works a treat on this board. To keep the main source tree clean of this, it is implemented locally within the mainboard/via/epia-m directory, and in a way which does not require any changes to the main source tree (e.g. it implements its own temporary gdt's and idt's). Maybe one day I shall return to this problem. Whilst attempting to get the emulator to work, I had to start using a fallback only image for sizing reasons, and this is how the patch is configured. Without both real-mode vga and the emulator it may be possible to go back to a dual image. My original epia-m port set up 2 mtrr's over the vga framebuffer and agp bridge as per the Award bios, and this makes a noticeable difference in performance. Without changing the current mtrr stuff I see no way of making a request for these to be set up, and so this version doesn't attempt to. It would be nice to see this sort of functionality return into the core if anyone is interested - perhaps as another type of memory resource different to main memory and non contiguous from main memory. The type of these mtrr's is write combining rather than write back as used for main memory. Nick Barker

4 5

[LinuxBIOS] RE: x86_64: calibrate_delay_direct and apic id lift for BSP
by Lu, Yinghai Oct. 28, 2005

Oct. 28, 2005

I have tried latest code..., except that, it works well. YH -----Original Message----- From: Andi Kleen [mailto:ak@suse.de] Sent: Friday, October 28, 2005 11:53 AM To: Lu, Yinghai Cc: discuss(a)x86-64.org; linux-kernel(a)vger.kernel.org; linuxbios(a)openbios.org Subject: Re: x86_64: calibrate_delay_direct and apic id lift for BSP On Friday 28 October 2005 20:42, Yinghai Lu wrote: > andi, > > I tried to lift apic id in LinuxBIOS for all cpus after 0x10. > > When using MB with AMD8111, the jiffies was not moving. So it is > locked at calibrate_delay_direct... Have you tried it with 2.6.14? It has some new code to handle high apic ids better > but MB with Nvidia ck804, jiffies is moving. The timer is wired different on nvidia than on 8111. They can go either through the 8259 or through the IOAPIC. There is still some code that falls back to the 8259 if IOAPIC doesn't work, which may make it appear working on Nvidia. As a warning I'm about to remove that code so don't rely on it. > If I don't change BSP apic id ( keep it to 0), It changes.... > > I have no idea how the jiffies changes, there is another thread change it....? They change when interrupt 0 fires. So it's probably misrouted or similar. -Andi

3 2

[LinuxBIOS] Proposed change to amdk8 memory controller code
by San Mehat Oct. 28, 2005

Oct. 28, 2005

Greets, I've made some modifications locally here to the amdk8 memory code and wanted to just chuck them out there to see what you guys think: 1 - Renamed DIMM_SOCKETS define to DIMM_SOCKETS_PER_CHANNEL since thats what it actually is. 2 - Added 'channel0_pop' and 'channel1_pop' to 'struct mem_controller' and modified 'raminit.c' to fill this in with the physical DIMM population map. For us knowing the detected DIMM population map *at the mainboard level* is very usefull. Fire away ;) -San

5 8

RE: [LinuxBIOS] Config file dependencies
by Lu, Yinghai Oct. 28, 2005

Oct. 28, 2005

No 1. CONFIG_USE_INIT==0 is very useful for debug. 2. CONFIG_USE_INIT==1 is something ppc car using... Auto.c and cache_as_ram_auto.c is very different 1. cache_as_ram_auto include failover.c 2. later cache_as_ram_auto will have struct sys_info sysinfox, and it will include every info include dimm.....and we don't need to keep read smbus and pci conf space for.... YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Thursday, October 27, 2005 1:22 PM To: Lu, Yinghai Cc: Stefan Reinauer; LinuxBIOS Subject: RE: [LinuxBIOS] Config file dependencies On Thu, 2005-10-27 at 11:11 -0700, Lu, Yinghai wrote: > If CONFIG_USE_INIT == 0, the cache_as_ram_auto.c will be compiled to > auto.inc. ---> part of crt0.s---> part of linuxbios_rom > > If CONFIG_USE_INIF == 1, the cache_as_ram_auto.c will be compiled to > auto.o and be linked with memcpy.o....and auto.o and memcpy.o ---> > init.o > And init.o ---> part of linuxbios_rom... > Is there any reason we need two different ways to do it? If both of them are as good, can we drop one and support just the other? BTW, after reading your patch, I found there is very little difference between auto.c and cache_as_ram_auto.c. Most of the differences are in the included files, can we merge auto.c and cache_as_ram_auto.c? > > YH > > -----Original Message----- > From: linuxbios-bounces(a)openbios.org > [mailto:linuxbios-bounces@openbios.org] On Behalf Of Li-Ta Lo > Sent: Thursday, October 27, 2005 10:31 AM > To: Stefan Reinauer > Cc: LinuxBIOS > Subject: Re: [LinuxBIOS] Config file dependencies > > On Thu, 2005-10-27 at 09:26 +0200, Stefan Reinauer wrote: > > Hi, > > > > > @@ -130,10 +130,10 @@ > > > ## > > > ## enable CACHE_AS_RAM specifics > > > ## > > > -default USE_DCACHE_RAM=1 > > > +default USE_DCACHE_RAM=0 > > > default DCACHE_RAM_BASE=0xcf000 > > > default DCACHE_RAM_SIZE=0x1000 > > > -default CONFIG_USE_INIT=1 > > > +default CONFIG_USE_INIT=0 > > > > > > The config files have a number of dependencies like the above. > > USE_DCACHE_RAM needs CONFIG_USE_INIT otherwise it won't work. > > > > That's something I try to figure out. If DCACHE_RAM needs USE_INIT, > why we still have > > #if CONFIG_USE_INIT == 0 > #include "lib/memcpy.c" > #endif > > in the src/mainboard/tyan/s2895/cache_as_ram_auto.c ? > > > Should we put this dependency in another place? Keeping such > > things in mind should be part of the LinuxBIOS configuration, > > not the LinuxBIOS (mainboard) developer.. > > > > Stefan > > > > > -- > Li-Ta Lo <ollie(a)lanl.gov> > Los Alamos National Lab > > -- Li-Ta Lo <ollie(a)lanl.gov> Los Alamos National Lab

3 2

RE: [LinuxBIOS] Config file dependencies
by Lu, Yinghai Oct. 28, 2005

Oct. 28, 2005

Yes. -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Thursday, October 27, 2005 3:34 PM To: Lu, Yinghai Cc: Ronald G Minnich; LinuxBIOS Subject: RE: [LinuxBIOS] Config file dependencies On Thu, 2005-10-27 at 15:28 -0700, Lu, Yinghai wrote: > Great, create LinuxBIOS v3 for CAR only? > If you are trying to pass data structure from pre-sdram stage to post-sdram stage, CAR is the only option isn't it? > YH > > -----Original Message----- > From: Ronald G Minnich [mailto:rminnich@lanl.gov] > Sent: Thursday, October 27, 2005 2:24 PM > To: Lu, Yinghai > Cc: Li-Ta Lo; LinuxBIOS > Subject: Re: [LinuxBIOS] Config file dependencies > > Lu, Yinghai wrote: > > You want CAR only or make them coexist? > > my opinion is, that in the long term, we want CAR only. > > For every target in which CAR can be turned on, it should be turned on > and always left on. If you have CAR, you should use it always. > > ron > > -- Li-Ta Lo <ollie(a)lanl.gov> Los Alamos National Lab

1 0