Re: [LinuxBIOS] BIOS Saver RD1
by Ken Fuchs
> 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
11 years, 7 months
[LinuxBIOS] x86_64: calibrate_delay_direct and apic id lift for BSP
by Yinghai Lu
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
13 years
RE: [LinuxBIOS] E7501 Raminit rewrite
by Lu, Yinghai
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>
13 years, 2 months
[LinuxBIOS] Tyan S2865
by Justin Cormack
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)
13 years, 2 months
[LinuxBIOS] New config language
by Josiah England
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)*
13 years, 2 months
[LinuxBIOS] Epia-M patch
by Nick Barker
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
13 years, 2 months
[LinuxBIOS] RE: x86_64: calibrate_delay_direct and apic id lift for BSP
by Lu, Yinghai
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
13 years, 2 months
[LinuxBIOS] Proposed change to amdk8 memory controller code
by San Mehat
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
13 years, 2 months
RE: [LinuxBIOS] Config file dependencies
by Lu, Yinghai
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
13 years, 2 months
RE: [LinuxBIOS] Config file dependencies
by Lu, Yinghai
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
13 years, 2 months
