GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

brush up language, unify terms, correct some urls. 

git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1588 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This commit is contained in:
Stefan Reinauer 2004-06-02 11:25:31 +00:00
parent 5a78bd03a6
commit 2c83b27c91
1 changed files with 78 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

144
documentation/LinuxBIOS-AMD64.tex
View File

@ -32,7 +32,7 @@
\title{LinuxBIOS on AMD64} \title{LinuxBIOS on AMD64}
\author{Stefan Reinauer $<$stepan@openbios.org$>$} \author{Stefan Reinauer $<$stepan@openbios.org$>$}
\date{February 10th, 2004} \date{June 2nd, 2004}
\begin{document} \begin{document}
@ -50,7 +50,7 @@
\section{Abstract} \section{Abstract}
This document targets porting LinuxBIOS to new Motherboards and creating This document targets porting LinuxBIOS to new mainboards and creating
custom firmware images using LinuxBIOS. It describes how to build custom firmware images using LinuxBIOS. It describes how to build
LinuxBIOS images for the AMD64 platform, including hypertransport LinuxBIOS images for the AMD64 platform, including hypertransport
configuration and pertinent utilities. If you are missing information or configuration and pertinent utilities. If you are missing information or
@ -64,8 +64,9 @@ find errors in the following descriptions, contact
\section{Changes} \section{Changes}
\begin{itemize} \begin{itemize}
\item 2003/11/18 initial release \item 2004/06/02 url and language fixes from Ken Fuchs $<$kfuchs@winternet.com$>$
\item 2004/02/10 acpi and option rom updates \item 2004/02/10 acpi and option rom updates
\item 2003/11/18 initial release
\end{itemize} \end{itemize}
@ -116,12 +117,21 @@ The following toolchain is recommended:
\section{Getting the Sources} \section{Getting the Sources}
The latest LinuxBIOS sources are available via CVS. The CVS repository The latest LinuxBIOS sources are available via CVS. The CVS repository
is maintained at SourceForge.net (the project name is \emph{FreeBIOS}). You is maintained at SourceForge.net (the project name is \emph{FreeBIOS}).
can get the entire source tree via CVS: First you should create a directory for your LinuxBIOS trees:
{ \small { \small
\begin{verbatim} \begin{verbatim}
% cvs -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios login $ mkdir linuxbios
$ cd linuxbios
\end{verbatim}
}
You can get the entire source tree via CVS:
{ \small
\begin{verbatim}
$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/freebios login
\end{verbatim} \end{verbatim}
} }
@ -130,7 +140,7 @@ the freebios source tree as follows:
{ \small { \small
\begin{verbatim} \begin{verbatim}
% cvs -z3 -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios co freebios2 $ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/freebios co freebios2
\end{verbatim} \end{verbatim}
} }
@ -163,18 +173,18 @@ lot of configuration options that can be tweaked in several ways:
\item \item
Firmware image specific configuration options can be set in the image Firmware image specific configuration options can be set in the image
configuration file which is usually found in configuration file which is usually found in
\texttt{freebios2/targets/$<$vendor$>$/$<$motherboard$>$/}. Such \texttt{freebios2/targets/$<$vendor$>$/$<$mainboard$>$/}. Such
options are the default amount of output verbosity during bootup, image options are the default amount of output verbosity during bootup, image
size, use of fallback mechanisms, firmware image size and payloads size, use of fallback mechanisms, firmware image size and payloads
(Linux Kernel, Bootloader...) The default configuration file name is (Linux Kernel, Bootloader...) The default configuration file name is
\texttt{Config.lb}, but LinuxBIOS allows multiple configurations to \texttt{Config.lb}, but LinuxBIOS allows multiple configurations to
reside in that directory. reside in that directory.
\item Motherboard specific configuration options can be set in the \item Mainboard specific configuration options can be set in the
motherboard configuration file placed in mainboard configuration file placed in
\texttt{freebios2/src/mainboard/$<$vendor$>$/$<$motherboard$>$}. The \texttt{freebios2/src/mainboard/$<$vendor$>$/$<$mainboard$>$}. The
motherboard configuration file is always called \texttt{Config.lb}. It mainboard configuration file is always called \texttt{Config.lb}. It
contains information on the onboard components of the motherboard like contains information on the onboard components of the mainboard like
CPU type, northbridge, southbridge, hypertransport configuration and CPU type, northbridge, southbridge, hypertransport configuration and
SuperIO configuration. This configuration file also allows to include SuperIO configuration. This configuration file also allows to include
addon code to hook into the LinuxBIOS initialization mechanism at addon code to hook into the LinuxBIOS initialization mechanism at
@ -191,8 +201,8 @@ LinuxBIOS source tree when building for AMD64.
\section{Building LinuxBIOS} \section{Building LinuxBIOS}
One of the design goals for building LinuxBIOS was to keep object files One of the design goals for building LinuxBIOS was to keep object files
out of the source tree in a seperate place. This is mandatory for out of the source tree in a separate place. This is mandatory for
building parallel LinuxBIOS images for several distinct motherboards building parallel LinuxBIOS images for several distinct mainboards
and/or platforms. Therefore building LinuxBIOS consists of two steps: and/or platforms. Therefore building LinuxBIOS consists of two steps:
\begin{itemize} \begin{itemize}
\item \item
@ -204,7 +214,7 @@ compiling the LinuxBIOS code and creating a flashable firmware image.
The first of these two steps is accomplished by the \texttt{buildtarget} The first of these two steps is accomplished by the \texttt{buildtarget}
script found in \texttt{freebios2/targets/}. To build LinuxBIOS for script found in \texttt{freebios2/targets/}. To build LinuxBIOS for
instance for the AMD Solo Athlon64 motherboard enter: instance for the AMD Solo Athlon64 mainboard enter:
\begin{verbatim} \begin{verbatim}
% cd freebios2/targets % cd freebios2/targets
@ -214,7 +224,7 @@ instance for the AMD Solo Athlon64 motherboard enter:
This will create a directory containing a Makefile and other software This will create a directory containing a Makefile and other software
components needed for this build. The directory name is defined in the components needed for this build. The directory name is defined in the
firmware image specific configuration file. In the case of AMD's Solo firmware image specific configuration file. In the case of AMD's Solo
motherboard the default directory resides in mainboard the default directory resides in
\texttt{freebios2/targets/amd/solo/solo}. To build the LinuxBIOS image, do \texttt{freebios2/targets/amd/solo/solo}. To build the LinuxBIOS image, do
\begin{verbatim} \begin{verbatim}
@ -223,7 +233,7 @@ motherboard the default directory resides in
\end{verbatim} \end{verbatim}
The LinuxBIOS image filename is specified in the firmware image specific The LinuxBIOS image filename is specified in the firmware image specific
configuration file. The default filename for AMD's Solo motherboard is configuration file. The default filename for AMD's Solo mainboard is
\texttt{solo.rom}. \texttt{solo.rom}.
% %
@ -239,7 +249,7 @@ software flash programming, find detailed information:
\begin{itemize} \begin{itemize}
\item \url{http://www.openbios.org/development/devbios.html} (/dev/bios) \item \url{http://www.openbios.org/development/devbios.html} (/dev/bios)
\item \url{http://www.linuxmtd.infradead.org/} (Memory Technology Device Subsystem MTD) \item \url{http://www.linux-mtd.infradead.org/} (Memory Technology Device Subsystem MTD)
\end{itemize} \end{itemize}
\newpage \newpage
@ -265,7 +275,7 @@ LinuxBIOS distinguishes between statements and options. Statements cause
the LinuxBIOS configuration mechanism to act, whereas options set the LinuxBIOS configuration mechanism to act, whereas options set
variables that are used by the build scripts or source code. variables that are used by the build scripts or source code.
\item \item
Default configuration values can be set in the motherboard configuration Default configuration values can be set in the mainboard configuration
files (keyword default) files (keyword default)
\item \item
Option overrides to the default configuration can only be specified in Option overrides to the default configuration can only be specified in
@ -294,7 +304,7 @@ variable is known.
\item \begin{verbatim}default\end{verbatim} \item \begin{verbatim}default\end{verbatim}
The \texttt{default} statement is used to set a configuration variable The \texttt{default} statement is used to set a configuration variable
with an overridable default value. It is commonly used in motherboard with an overridable default value. It is commonly used in mainboard
configuration files. configuration files.
Example: Example:
@ -330,7 +340,7 @@ The \texttt{option} statement basically behaves identically to the
build target configuration files build target configuration files
(\texttt{freebios2/targets/$<$vendor$>$/$<$mainboard$>$}). The option (\texttt{freebios2/targets/$<$vendor$>$/$<$mainboard$>$}). The option
statement allows either to set new options or to override default values statement allows either to set new options or to override default values
set with the default statement in a motherboard configuration file. set with the default statement in a mainboard configuration file.
Syntax and application are the same as with default. Syntax and application are the same as with default.
\end{itemize} \end{itemize}
@ -340,8 +350,8 @@ LinuxBIOS allows to create different firmware images for the same
hardware. Such images can differ in the amount of output they produce, hardware. Such images can differ in the amount of output they produce,
the payload, the number of subimages they consist of etc. the payload, the number of subimages they consist of etc.
The firmware image specific configuration file can be found in The firmware image specific configuration file can be found in \\
\texttt{freebios2/targets/$<$vendor$>$/<motherboard$>$}. \texttt{freebios2/targets/$<$vendor$>$/<mainboard$>$}.
\subsubsection{Firmware image specific keywords} \subsubsection{Firmware image specific keywords}
In addition to the above described keywords the following statements are In addition to the above described keywords the following statements are
@ -389,7 +399,7 @@ the images and the final image size:
In addition to the definitions described above there are a number of In addition to the definitions described above there are a number of
commonly used options. Configuration options set in the firmware image commonly used options. Configuration options set in the firmware image
specific configuration file can override default selections from the specific configuration file can override default selections from the
Motherboard specific configuration. See above examples about Mainboard specific configuration. See above examples about
option on how to set them. option on how to set them.
\begin{itemize} \begin{itemize}
@ -403,7 +413,7 @@ machine.
\item \begin{verbatim}CONFIG_CHIP_CONFIGURE \end{verbatim} \item \begin{verbatim}CONFIG_CHIP_CONFIGURE \end{verbatim}
Use new \textit{chip\_configure} method for configuring (nonpci) Use new \textit{chip\_configure} method for configuring (nonpci)
devices. Set to \texttt{1} for all AMD64 motherboards. devices. Set to \texttt{1} for all AMD64 mainboards.
\item \begin{verbatim}MAXIMUM_CONSOLE_LOGLEVEL\end{verbatim} \item \begin{verbatim}MAXIMUM_CONSOLE_LOGLEVEL\end{verbatim}
@ -433,7 +443,7 @@ This does not include the fallback payload.
\item \begin{verbatim}HAVE_OPTION_TABLE\end{verbatim} \item \begin{verbatim}HAVE_OPTION_TABLE\end{verbatim}
Export CMOS option table. Default is \texttt{0}. Set to \texttt{1} if Export CMOS option table. Default is \texttt{0}. Set to \texttt{1} if
your motherboard has CMOS memory and you want to use it to store your mainboard has CMOS memory and you want to use it to store
LinuxBIOS parameters (Loglevel, serial line speed, ...) LinuxBIOS parameters (Loglevel, serial line speed, ...)
\item \begin{verbatim}CONFIG_ROM_STREAM\end{verbatim} \item \begin{verbatim}CONFIG_ROM_STREAM\end{verbatim}
@ -470,29 +480,29 @@ to any string to add an extra version string to your LinuxBIOS build.
\newpage \newpage
\subsection{Motherboard specific configuration} \subsection{Mainboard specific configuration}
Motherboard specific configuration files describe the onboard Mainboard specific configuration files describe the onboard
motherboard components, i.e. bridges, number and type of CPUs. They also mainboard components, i.e. bridges, number and type of CPUs. They also
contain rules for building the low level start code which is translated contain rules for building the low level start code which is translated
using romcc and/or the GNU assembler. This code enables caches and using romcc and/or the GNU assembler. This code enables caches and
registers, early mtrr settings, fallback mechanisms, dram init and registers, early mtrr settings, fallback mechanisms, dram init and
possibly more. possibly more.
\textbf{NOTE:} The option keyword can not be used in motherboard specific \textbf{NOTE:} The \texttt{option} keyword can not be used in mainboard
configuration files. Options shall instead be set using the default specific configuration files. Options shall instead be set using the
keyword so that they can be overridden by the image specific \texttt{default} keyword so that they can be overridden by the image
configuration files if needed. specific configuration files if needed.
\subsubsection{Motherboard specific keywords} \subsubsection{Mainboard specific keywords}
The following statements are used in motherboard specific configuration The following statements are used in mainboard specific configuration
files: files:
\begin{itemize} \begin{itemize}
\item \begin{verbatim}arch\end{verbatim} \item \begin{verbatim}arch\end{verbatim}
Sets the CPU architecture. This should be \texttt{i386} for AMD64 boards. Sets the CPU architecture. This should be \texttt{i386} for AMD64 boards.\\
Example: Example:
\begin{verbatim} \begin{verbatim}
@ -551,9 +561,9 @@ makerule ./auto.inc
end end
\end{verbatim} \end{verbatim}
Each makerule section contains file dependencies (using the depend Each \texttt{makerule} section contains file dependencies (using the
keyword) and an action that is taken when the dependencies are satisfied texttt{depends} keyword) and an action that is taken when the dependencies
(using the action keyword). are satisfied (using the \texttt{action} keyword).
\item \begin{verbatim}mainboardinit\end{verbatim} \item \begin{verbatim}mainboardinit\end{verbatim}
@ -583,8 +593,8 @@ creation. Example:
\item \begin{verbatim}dir\end{verbatim} \item \begin{verbatim}dir\end{verbatim}
LinuxBIOS reuses as much code between the different ports as possible. LinuxBIOS reuses as much code between the different ports as possible.
To achieve this, commonly used code can be stored in a seperate To achieve this, commonly used code can be stored in a separate
directory. For a new motherboard, it is enough to know that the code in directory. For a new mainboard, it is enough to know that the code in
that directory can be used as is. that directory can be used as is.
LinuxBIOS will also read a \texttt{Config.lb} file stored in that LinuxBIOS will also read a \texttt{Config.lb} file stored in that
@ -606,7 +616,8 @@ used as:
\item \begin{verbatim}register\end{verbatim} \item \begin{verbatim}register\end{verbatim}
The \texttt{register} keyword can occur in any section, passing The \texttt{register} keyword can occur in any section, passing
additional parameters to the code handling the according device. additional \\
parameters to the code handling the associated device.
Example: Example:
\begin{verbatim} \begin{verbatim}
@ -619,7 +630,8 @@ The \texttt{northbridge} keyword describes a system northbridge. Some
systems, like AMD64, can have more than one northbridge, i.e. one per systems, like AMD64, can have more than one northbridge, i.e. one per
CPU node. Each northbridge is described by the path to the northbridge CPU node. Each northbridge is described by the path to the northbridge
code in LinuxBIOS (relative to \texttt{freebios2/src/northbridge}), i.e. code in LinuxBIOS (relative to \texttt{freebios2/src/northbridge}), i.e.
\texttt{amd/amdk8} and a unique name (i.e ´mc0' ) Example: \texttt{amd/amdk8} and a unique name (i.e \texttt{mc0}) \\
Example:
\begin{verbatim} \begin{verbatim}
northbridge amd/amdk8 "mc0" northbridge amd/amdk8 "mc0"
@ -732,9 +744,9 @@ end
\newpage \newpage
\subsubsection{Motherboard specific configuration options} \subsubsection{Mainboard specific configuration options}
The following options are commonly used in motherboard specific The following options are commonly used in mainboard specific
configuration files. configuration files.
They should be set using the \texttt{default} keyword: They should be set using the \texttt{default} keyword:
@ -818,9 +830,9 @@ decompression is needed).
\section{Tweaking the source code} \section{Tweaking the source code}
Besides configuring the existing code it is sometimes necessary or Besides configuring the existing code it is sometimes necessary or
wished to tweak certain parts of LinuxBIOS by direct changes to the desirable to tweak certain parts of LinuxBIOS by direct changes to the
code. This chapter covers some possible enhancements and changes that code. This chapter covers some possible enhancements and changes that
are needed when porting LinuxBIOS to a new motherboard or just come are needed when porting LinuxBIOS to a new mainboard or just come
handy now and then. handy now and then.
\subsection{Hypertransport configuration} \subsection{Hypertransport configuration}
@ -829,9 +841,9 @@ attached to these CPUs (and thus, see all devices attached to the
system) it has to initialize the coherent hypertransport devices. system) it has to initialize the coherent hypertransport devices.
The current algorithms to do coherent hypertransport initialization are The current algorithms to do coherent hypertransport initialization are
not fully automatically evaluating the hypertransport chain graph. not fully, automatically evaluating the hypertransport chain graph.
Therefore the code needs to be adapted when porting LinuxBIOS to a new Therefore the code needs to be adapted when porting LinuxBIOS to a new
AMD64 motherboard. An example arrangement of hypertransport devices AMD64 mainboard. An example arrangement of hypertransport devices
looks like this: looks like this:
\begin{figure}[htb] \begin{figure}[htb]
@ -989,7 +1001,7 @@ timings, size and other properties. The SPD data is usually read
utilizing the I2C SMBUS interface of the southbridge. utilizing the I2C SMBUS interface of the southbridge.
There is one central data structure that describes the RAM controllers There is one central data structure that describes the RAM controllers
available on an AMD64 system and the concerned devices: available on an AMD64 system and the associated devices:
\begin{verbatim} \begin{verbatim}
struct mem_controller { struct mem_controller {
@ -1000,15 +1012,15 @@ struct mem_controller {
}; };
\end{verbatim} \end{verbatim}
Available motherboard implementations and CPUs create the need to add Available mainboard implementations and CPUs create the need to add
special setup code to RAM initialization in a number of places. special setup code to RAM initialization in a number of places.
LinuxBIOS provides hooks to easily add code in these places without LinuxBIOS provides hooks to easily add code in these places without
having to change the generic code. Whether these hooks have to be used having to change the generic code. Whether these hooks have to be used
depends on the motherboard design. In many cases the functions executed depends on the mainboard design. In many cases the functions executed
by the hooks just carry out trivial default settings or they are even by the hooks just carry out trivial default settings or they are even
empty. empty.
Some motherboard/CPU combinations need to trigger an additional memory Some mainboard/CPU combinations need to trigger an additional memory
controller reset before the memory can be initialized properly. This is, controller reset before the memory can be initialized properly. This is,
for example, used to get memory working on preC stepping AMD64 for example, used to get memory working on preC stepping AMD64
processors. LinuxBIOS provides two hooks for triggering onboard memory processors. LinuxBIOS provides two hooks for triggering onboard memory
@ -1020,7 +1032,7 @@ reset logic:
mem_controller *ctrl)\end{verbatim} mem_controller *ctrl)\end{verbatim}
\end{itemize} \end{itemize}
Some motherboards utilize an SMBUS hub or possibly other mechanisms to Some mainboards utilize an SMBUS hub or possibly other mechanisms to
allow using a large number of SPDROMs and thus ram sockets. The result allow using a large number of SPDROMs and thus ram sockets. The result
is that only the SPDROM information of one cpu node is visible at a is that only the SPDROM information of one cpu node is visible at a
time. The following function, defined in \texttt{auto.c}, is called every time time. The following function, defined in \texttt{auto.c}, is called every time
@ -1032,13 +1044,13 @@ static inline void activate_spd_rom (const struct mem_controller *ctrl)
\end{verbatim} \end{verbatim}
The way SMBUS hub information is coded into the \texttt{mem\_controller} The way SMBUS hub information is coded into the \texttt{mem\_controller}
structure is motherboard implementation specific and not closer structure is mainboard implementation specific and not
described here. See \texttt{freebios2/src/mainboard/amd/quartet/auto.c} described here. See \texttt{freebios2/src/mainboard/amd/quartet/auto.c}
for an example. for an example.
LinuxBIOS folks have agreed on SPD data being the central information LinuxBIOS folks have agreed on SPD data being the central information
source for RAM specific information. But not all motherboards/RAM source for RAM specific information. But not all mainboards/RAM
modules feature a physical SPD ROM. To still allow an easytouse SPD modules feature a physical SPD ROM. To still allow an easy to use SPD
driven setup, there is a hook that abstracts reading the SPD ROM driven setup, there is a hook that abstracts reading the SPD ROM
ingredients that are used by the memory initialization mechanism: ingredients that are used by the memory initialization mechanism:
@ -1065,7 +1077,7 @@ as indices to this array.
\subsection {IRQ Tables} \subsection {IRQ Tables}
Motherboards that provide an IRQ table should have the following two Mainboards that provide an IRQ table should have the following two
variables set in their \texttt{Config.lb} file: variables set in their \texttt{Config.lb} file:
\begin{verbatim} \begin{verbatim}
@ -1073,8 +1085,8 @@ default HAVE_PIRQ_TABLE=1
default IRQ_SLOT_COUNT=7 default IRQ_SLOT_COUNT=7
\end{verbatim} \end{verbatim}
This will make LinuxBIOS look for the file This will make LinuxBIOS look for the file \\
\texttt{freebios2/src/mainboard/<vendor>/<motherboard>/irq\_tables.c} which \texttt{freebios2/src/mainboard/<vendor>/<mainboard>/irq\_tables.c} which
contains the source code definition of the IRQ table. LinuxBIOS corrects contains the source code definition of the IRQ table. LinuxBIOS corrects
small inconsistencies in the IRQ table during startup (checksum and small inconsistencies in the IRQ table during startup (checksum and
number of entries), but it is not yet writing IRQ tables in a completely number of entries), but it is not yet writing IRQ tables in a completely
@ -1208,7 +1220,7 @@ initialize and operate the device:
By separating the two structures above, M:N relations between compatible By separating the two structures above, M:N relations between compatible
devices and drivers can be described. The driver source code containing devices and drivers can be described. The driver source code containing
above data structures and code have to be added to a LinuxBIOS image above data structures and code have to be added to a LinuxBIOS image
using the driver keyword in the motherboard specific configuration file using the driver keyword in the mainboard specific configuration file \\
\texttt{freebios2/src/mainboard/<vendor>/<mainboard>/Config.lb}: \texttt{freebios2/src/mainboard/<vendor>/<mainboard>/Config.lb}:
\begin{verbatim} \begin{verbatim}
@ -1309,7 +1321,7 @@ initialization can be factored and reused more easily among mainboards
and platforms. and platforms.
Since no memory is available during this early initialization point, Since no memory is available during this early initialization point,
romcc has to map all used variables in registers for their time being. romcc has to map all used variables in registers for the time being.
Same applies for their stack usage. Generally the less registers are Same applies for their stack usage. Generally the less registers are
used up by the algorithms, the better code can be factored, resulting in used up by the algorithms, the better code can be factored, resulting in
a smaller object size. Since getting the best register usage is an NP a smaller object size. Since getting the best register usage is an NP
@ -1318,7 +1330,7 @@ time. If you run out of registers during compilation, try to refactor
your code. your code.
\subsection{CMOS handling} \subsection{CMOS handling}
LinuxBIOS can use the motherboard's CMOS memory to store information LinuxBIOS can use the mainboard's CMOS memory to store information
defined in a data structure called the CMOS table . This information defined in a data structure called the CMOS table . This information
contains serial line speed, fallback boot control, output verbosity, contains serial line speed, fallback boot control, output verbosity,
default boot device, ECC control, and more. It can be easily enhanced by default boot device, ECC control, and more. It can be easily enhanced by
@ -1401,7 +1413,7 @@ the following line in \texttt{/etc/inetd.conf}:
tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
\end{verbatim} \end{verbatim}
Then put your kernel image \texttt{vmlinuz.elf} to \texttt{/tftpboot} on Then put your kernel image \texttt{vmlinuz.elf} in \texttt{/tftpboot} on
the \texttt{tftp} server. the \texttt{tftp} server.
@ -1415,7 +1427,7 @@ the \texttt{tftp} server.
Like software, today's hardware is getting more and more complex. To Like software, today's hardware is getting more and more complex. To
stay flexible many hardware vendors start breaking hardware stay flexible many hardware vendors start breaking hardware
compatibility to old standards as VGA. Thus, VGA is still supported by compatibility to old standards like VGA. Thus, VGA is still supported by
most cards, but emulation has to be enabled by the firmware for the most cards, but emulation has to be enabled by the firmware for the
device to operate properly. Also, many expansion cards are small device to operate properly. Also, many expansion cards are small
discrete systems that have to initialize attached ram, download discrete systems that have to initialize attached ram, download