Most of the changes here are trivial, but the white space changes would be harder to undo than to do over.

I changed all groups of 8 spaces to tabs, then all tabs to two spaces so more of the device tree fits on the page.  It could have been three or possibly four, but the largest indents I found were 6 tabs, so 4 is a lot of the space on the page.

Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>



git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4543 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This commit is contained in:
Myles Watson 2009-08-13 16:02:24 +00:00 committed by Ronald G. Minnich
parent fabde37cb8
commit 10c41fa008
1 changed files with 302 additions and 302 deletions

View File

@ -41,17 +41,17 @@ Sources all Kconfig files in the vendor directories.
\input{ mainboardkconfig.tex}
\subsection{mainboard/Makefile.inc}
There is none at this time.
\subsection{mainboard/<vendor>/Kconfig}
\subsection{mainboard/$<$vendor$>$/Kconfig}
We use the amd as a model. The only action currently taken is to source all Kconfig's in the
subdirectories.
\subsection{mainboard/<vendor>/Makefile.inc}
\subsection{mainboard/$<$vendor$>$/Makefile.inc}
We use amd as a model. There is currently no Makefile.inc at this level.
\subsection{mainboard/<vendor>/<board>/Kconfig}
\subsection{mainboard/$<$vendor$>$/$<$board$>$/Kconfig}
The mainboard Kconfig and Makefile.inc are designed to be the heart of the build. The defines
and rules in here determine everything about how a mainboard target is built.
We will use serengeti\_cheetah as a model. It defines these variables.
\input{ mainboardkconfig.tex}
\subsection{mainboard/<vendor>/<board>/Makefile.inc}
\subsection{mainboard/$<$vendor$>$/$<$board$>$/Makefile.inc}
This is a fairly complex Makefile.inc. Because this is such a critical component, we are going to excerpt and take it piece by piece.
Note that this is the mainboard as of August, 2009, and it may change over time.
\subsubsection{objects}
@ -101,9 +101,9 @@ There are variables that should never be definable by users, as changing them wi
in MAINBOARD\_OPTIONS.
\begin{verbatim}
MAINBOARD_OPTIONS=\
-DCONFIG_AP_IN_SIPI_WAIT=0 \
-DCONFIG_USE_PRINTK_IN_CAR=1 \
-DCONFIG_HAVE_HIGH_TABLES=1
-DCONFIG_AP_IN_SIPI_WAIT=0 \
-DCONFIG_USE_PRINTK_IN_CAR=1 \
-DCONFIG_HAVE_HIGH_TABLES=1
\end{verbatim}
\subsubsection{POST\_EVALUATION}
POST\_EVALUATION rules should be placed after this section:
@ -114,31 +114,31 @@ to ensure that the values of variables are correct.
Here are the post-evaluation rules for this mainboard:
\begin{verbatim}
$(obj)/dsdt.c: $(src)/mainboard/$(MAINBOARDDIR)/dsdt.asl
iasl -p dsdt -tc $(src)/mainboard/$(MAINBOARDDIR)/dsdt.asl
mv dsdt.hex $@
iasl -p dsdt -tc $(src)/mainboard/$(MAINBOARDDIR)/dsdt.asl
mv dsdt.hex $@
$(obj)/mainboard/$(MAINBOARDDIR)/dsdt.o: $(obj)/dsdt.c
$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) $(DEBUG_CFLAGS) -I$(src) -I. -c $< -o $@
$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) $(DEBUG_CFLAGS) -I$(src) -I. -c $< -o $@
$(obj)/ssdt2.c: $(src)/mainboard/$(MAINBOARDDIR)/dx/pci2.asl
iasl -p $(CURDIR)/pci2 -tc $(CONFIG_MAINBOARD)/dx/pci2.asl
perl -pi -e 's/AmlCode/AmlCode_ssdt2/g' pci2.hex
mv pci2.hex ssdt2.c
iasl -p $(CURDIR)/pci2 -tc $(CONFIG_MAINBOARD)/dx/pci2.asl
perl -pi -e 's/AmlCode/AmlCode_ssdt2/g' pci2.hex
mv pci2.hex ssdt2.c
$(obj)/ssdt3.c: $(src)/mainboard/$(MAINBOARDDIR)/dx/pci3.asl"
iasl -p $(CURDIR)/pci3 -tc $(CONFIG_MAINBOARD)/
perl -pi -e 's/AmlCode/AmlCode_ssdt3/g' pci3.hex
mv pci3.hex ssdt3.c
iasl -p $(CURDIR)/pci3 -tc $(CONFIG_MAINBOARD)/
perl -pi -e 's/AmlCode/AmlCode_ssdt3/g' pci3.hex
mv pci3.hex ssdt3.c
$(obj)/ssdt4.c: $(src)/mainboard/$(MAINBOARDDIR)/dx/pci4.asl"
iasl -p $(CURDIR)/pci4 -tc $(CONFIG_MAINBOARD)/dx/pci4.asl
perl -pi -e 's/AmlCode/AmlCode_ssdt4/g' pci4.hex
mv pci4.hex ssdt4.c
iasl -p $(CURDIR)/pci4 -tc $(CONFIG_MAINBOARD)/dx/pci4.asl
perl -pi -e 's/AmlCode/AmlCode_ssdt4/g' pci4.hex
mv pci4.hex ssdt4.c
$(obj)/mainboard/$(MAINBOARDDIR)/auto.inc: $(src)/mainboard/$(MAINBOARDDIR)/rom.c $(obj)/option_table.h
$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) $(DEBUG_CFLAGS) -I$(src) -I. -c -S $(src)/mainboard/$(MAINBOARDDIR)/rom.c -o $@
perl -e 's/\.rodata/.rom.data/g' -pi $@
perl -e 's/\.text/.section .rom.text/g' -pi $@
$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) $(DEBUG_CFLAGS) -I$(src) -I. -c -S $(src)/mainboard/$(MAINBOARDDIR)/rom.c -o $@
perl -e 's/\.rodata/.rom.data/g' -pi $@
perl -e 's/\.text/.section .rom.text/g' -pi $@
\end{verbatim}
The last rule is for romcc, and, again, we hope to eliminate romcc usage and this rule soon. The first set of rules concern ACPI tables.
@ -148,11 +148,11 @@ properly, as it defines topology and chips that can be defined no other way.
Let's go through the tree.
\begin{verbatim}
chip northbridge/amd/amdk8/root_complex
device apic_cluster 0 on
chip cpu/amd/socket_F
device apic 0 on end
end
end
device apic_cluster 0 on
chip cpu/amd/socket_F
device apic 0 on end
end
end
\end{verbatim}
This topology is always somewhat confusing to newcomers, and even to coreboot veterans.
@ -164,7 +164,7 @@ somewhere, since it runs memory.
What is the APIC? Northbridges always have an Advanced Programmable Interrupt Controller, and that {\it APIC cluster} is a topological connection to the
CPU socket. So the tree is rooted at the northbridge, which has a link to an apic cluster, and then the CPU. The CPU contains
its own APIC, and will define any parameters needed. In this case, we have a northbridge of type
{\it northbridge/amd/amdk8/root\_complex}, with its won apic\_cluster device which we turn on,
{\it northbridge/amd/amdk8/root\_complex}, with its own apic\_cluster device which we turn on,
which connects to a {\it cpu/amd/socket\_F},
which has an apic, which is on.
@ -172,191 +172,191 @@ Note that we do not enumerate all CPUs, even on this SMP mainboard. The reason i
is the so-called Boot Strap Processor, or BSP; the other CPUs will come along later, as the are discovered. We do not require (unlike many
BIOSes) that the BSP be CPU 0; any CPU will do.
\begin{verbatim}
device pci_domain 0 on
chip northbridge/amd/amdk8
device pci 18.0 on # northbridge
# devices on link 0, link 0 == LDT 0
device pci_domain 0 on
chip northbridge/amd/amdk8
device pci 18.0 on # northbridge
# devices on link 0, link 0 == LDT 0
\end{verbatim}
Here begins the pci domain, which usually starts with 0. Then there is the northbridge, which bridges to the PCI bus. On
Opterons, certain CPU control registers are managed in PCI config space in device 18.0 (BSP), 19.0 (AP), and up.
\begin{verbatim}
chip southbridge/amd/amd8132
# the on/off keyword is mandatory
device pci 0.0 on end
device pci 0.1 on end
device pci 1.0 on end
device pci 1.1 on end
end
chip southbridge/amd/amd8132
# the on/off keyword is mandatory
device pci 0.0 on end
device pci 0.1 on end
device pci 1.0 on end
device pci 1.1 on end
end
\end{verbatim}
This is the 8132, a bridge to a secondary PCI bus.
\begin{verbatim}
chip southbridge/amd/amd8111
# this "device pci 0.0" is the parent the next one
# PCI bridge
device pci 0.0 on
device pci 0.0 on end
device pci 0.1 on end
device pci 0.2 off end
device pci 1.0 off end
end
chip southbridge/amd/amd8111
# this "device pci 0.0" is the parent the next one
# PCI bridge
device pci 0.0 on
device pci 0.0 on end
device pci 0.1 on end
device pci 0.2 off end
device pci 1.0 off end
end
\end{verbatim}
The 8111 is a bridge to other busses and to the legacy ISA devices such as superio.
\begin{verbatim}
device pci 1.0 on
chip superio/winbond/w83627hf
device pnp 2e.0 off # Floppy
io 0x60 = 0x3f0
irq 0x70 = 6
drq 0x74 = 2
end
device pnp 2e.1 off # Parallel Port
io 0x60 = 0x378
irq 0x70 = 7
end
device pnp 2e.2 on # Com1
io 0x60 = 0x3f8
irq 0x70 = 4
end
device pnp 2e.3 off # Com2
io 0x60 = 0x2f8
irq 0x70 = 3
end
device pnp 2e.5 on # Keyboard
io 0x60 = 0x60
io 0x62 = 0x64
irq 0x70 = 1
irq 0x72 = 12
end
device pnp 2e.6 off # CIR
io 0x60 = 0x100
end
device pnp 2e.7 off # GAME_MIDI_GIPO1
io 0x60 = 0x220
io 0x62 = 0x300
irq 0x70 = 9
end
device pnp 2e.8 off end # GPIO2
device pnp 2e.9 off end # GPIO3
device pnp 2e.a off end # ACPI
device pnp 2e.b on # HW Monitor
io 0x60 = 0x290
irq 0x70 = 5
end
end
end
device pci 1.0 on
chip superio/winbond/w83627hf
device pnp 2e.0 off # Floppy
io 0x60 = 0x3f0
irq 0x70 = 6
drq 0x74 = 2
end
device pnp 2e.1 off # Parallel Port
io 0x60 = 0x378
irq 0x70 = 7
end
device pnp 2e.2 on # Com1
io 0x60 = 0x3f8
irq 0x70 = 4
end
device pnp 2e.3 off # Com2
io 0x60 = 0x2f8
irq 0x70 = 3
end
device pnp 2e.5 on # Keyboard
io 0x60 = 0x60
io 0x62 = 0x64
irq 0x70 = 1
irq 0x72 = 12
end
device pnp 2e.6 off # CIR
io 0x60 = 0x100
end
device pnp 2e.7 off # GAME_MIDI_GIPO1
io 0x60 = 0x220
io 0x62 = 0x300
irq 0x70 = 9
end
device pnp 2e.8 off end # GPIO2
device pnp 2e.9 off end # GPIO3
device pnp 2e.a off end # ACPI
device pnp 2e.b on # HW Monitor
io 0x60 = 0x290
irq 0x70 = 5
end
end
end
\end{verbatim}
The pnp refers to the many Plug N Play devices on a superio. 2e refers to the base I/O address of the superio, and the number following the
2e (i.e. 2e.1) is the Logical Device Number, or LDN. Each LDN has a common configuration (base, irq, etc.) and these are set by the statements under the LDN.
\begin{verbatim}
device pci 1.1 on end
device pci 1.2 on end
device pci 1.1 on end
device pci 1.2 on end
\end{verbatim}
More devices. These statements set up placeholders in the device tree.
\begin{verbatim}
device pci 1.3 on
chip drivers/i2c/i2cmux # pca9556 smbus mux
device i2c 18 on #0 pca9516 1
chip drivers/generic/generic #dimm 0-0-0
device i2c 50 on end
end
chip drivers/generic/generic #dimm 0-0-1
device i2c 51 on end
end
chip drivers/generic/generic #dimm 0-1-0
device i2c 52 on end
end
chip drivers/generic/generic #dimm 0-1-1
device i2c 53 on end
end
end
device i2c 18 on #1 pca9516 2
chip drivers/generic/generic #dimm 1-0-0
device i2c 50 on end
end
chip drivers/generic/generic #dimm 1-0-1
device i2c 51 on end
end
chip drivers/generic/generic #dimm 1-1-0
device i2c 52 on end
end
chip drivers/generic/generic #dimm 1-1-1
device i2c 53 on end
end
chip drivers/generic/generic #dimm 1-2-0
device i2c 54 on end
end
chip drivers/generic/generic #dimm 1-2-1
device i2c 55 on end
end
chip drivers/generic/generic #dimm 1-3-0
device i2c 56 on end
end
chip drivers/generic/generic #dimm 1-3-1
device i2c 57 on end
end
end
end
end # acpi
device pci 1.3 on
chip drivers/i2c/i2cmux # pca9556 smbus mux
device i2c 18 on #0 pca9516 1
chip drivers/generic/generic #dimm 0-0-0
device i2c 50 on end
end
chip drivers/generic/generic #dimm 0-0-1
device i2c 51 on end
end
chip drivers/generic/generic #dimm 0-1-0
device i2c 52 on end
end
chip drivers/generic/generic #dimm 0-1-1
device i2c 53 on end
end
end
device i2c 18 on #1 pca9516 2
chip drivers/generic/generic #dimm 1-0-0
device i2c 50 on end
end
chip drivers/generic/generic #dimm 1-0-1
device i2c 51 on end
end
chip drivers/generic/generic #dimm 1-1-0
device i2c 52 on end
end
chip drivers/generic/generic #dimm 1-1-1
device i2c 53 on end
end
chip drivers/generic/generic #dimm 1-2-0
device i2c 54 on end
end
chip drivers/generic/generic #dimm 1-2-1
device i2c 55 on end
end
chip drivers/generic/generic #dimm 1-3-0
device i2c 56 on end
end
chip drivers/generic/generic #dimm 1-3-1
device i2c 57 on end
end
end
end
end # acpi
\end{verbatim}
These are the i2c devices.
\begin{verbatim}
device pci 1.5 off end
device pci 1.6 off end
device pci 1.5 off end
device pci 1.6 off end
\end{verbatim}
More placeholders.
\begin{verbatim}
register "ide0_enable" = "1"
register "ide1_enable" = "1"
end
end # device pci 18.0
register "ide0_enable" = "1"
register "ide1_enable" = "1"
end
end # device pci 18.0
\end{verbatim}
These "register" commands set controls in the southbridge.
\begin{verbatim}
device pci 18.0 on end
device pci 18.0 on end
device pci 18.0 on end
device pci 18.0 on end
\end{verbatim}
These are the other two hypertransport links.
\begin{verbatim}
device pci 18.1 on end
device pci 18.2 on end
device pci 18.3 on end
device pci 18.1 on end
device pci 18.2 on end
device pci 18.3 on end
\end{verbatim}
The 18.1 devices are, again, northbridge control for various k8 functions.
\begin{verbatim}
end
end
\end{verbatim}
That's it for the BSP I/O and HT busses. Now we begin the AP busses. Not much here.
\begin{verbatim}
chip northbridge/amd/amdk8
device pci 19.0 on # northbridge
chip southbridge/amd/amd8151
# the on/off keyword is mandatory
device pci 0.0 on end
device pci 1.0 on end
end
end # device pci 19.0
chip northbridge/amd/amdk8
device pci 19.0 on # northbridge
chip southbridge/amd/amd8151
# the on/off keyword is mandatory
device pci 0.0 on end
device pci 1.0 on end
end
end # device pci 19.0
device pci 19.0 on end
device pci 19.0 on end
device pci 19.1 on end
device pci 19.2 on end
device pci 19.3 on end
end
device pci 19.0 on end
device pci 19.0 on end
device pci 19.1 on end
device pci 19.2 on end
device pci 19.3 on end
end
\end{verbatim}
\begin{verbatim}
end #pci_domain
# chip drivers/generic/debug
# device pnp 0.0 off end # chip name
# device pnp 0.1 on end # pci_regs_all
# device pnp 0.2 off end # mem
# device pnp 0.3 off end # cpuid
# device pnp 0.4 off end # smbus_regs_all
# device pnp 0.5 off end # dual core msr
# device pnp 0.6 off end # cache size
# device pnp 0.7 off end # tsc
end #pci_domain
# chip drivers/generic/debug
# device pnp 0.0 off end # chip name
# device pnp 0.1 on end # pci_regs_all
# device pnp 0.2 off end # mem
# device pnp 0.3 off end # cpuid
# device pnp 0.4 off end # smbus_regs_all
# device pnp 0.5 off end # dual core msr
# device pnp 0.6 off end # cache size
# device pnp 0.7 off end # tsc
# end
end
@ -368,17 +368,17 @@ The CPU socket is the key link from mainboard to its CPUs. Since many models of
the socket, and the socket, in turn, references the various model CPUs which can be plugged into it. The socket is thus the focus
of all defines and Makefile controls for building the CPU components of a board.
\subsubsection{ /cpu/Kconfig}
\subsubsection{ cpu/Kconfig}
Defines variables. Current variables are:
\input{cpukconfig.tex}
Sources all Kconfig files in the vendor directories.
\subsubsection{ /cpu/Makefile.inc}
\subsubsection{ cpu/Makefile.inc}
Unconditionally sources all Makefile.inc in the vendor directories.
\subsection{cpu/<vendor>/Kconfig}
\subsection{cpu/$<$vendor$>$/Kconfig}
The only action currently taken is to source all Kconfig's in the
subdirectories.
\subsection{cpu/<vendor>/Makefile.inc}
\subsection{cpu/$<$vendor$>$/Makefile.inc}
{\em Conditionally} source the socket directories.
Example:
\begin{verbatim}
@ -387,7 +387,7 @@ subdirs-$(CONFIG_CPU_AMD_SOCKET_F) += socket_F
.
CONFIG\_CPU\_AMD\_SOCKET\_F is set in a mainboard file.
\subsection{cpu/<vendor>/<socket>/Kconfig}
\subsection{cpu/$<$vendor$>$/$<$socket$>$/Kconfig}
Set variables that relate to this {\em socket}, and {\em any models that plug into this socket}. Note that
the socket, as much as possible, should control the models, because the models may plug into many sockets.
Socket\_F currently sets:
@ -395,10 +395,10 @@ Socket\_F currently sets:
It sources only those Kconfigs that relate to this particular socket, i.e. not all possible models are sourced.
\subsection{cpu/<vendor>/<model>/Kconfig}
\subsection{cpu/$<$vendor$>$/$<$model$>$/Kconfig}
CPU Model Kconfigs only set variables, We do not expect that they will source any other Kconfig. The socket Kconfig should do that
if needed.
\subsection{cpu/<vendor>/<model>/Makefile.inc}
\subsection{cpu/$<$vendor$>$/$<$model$>$/Makefile.inc}
The Makefile.inc {\em unconditionally} specifies drivers and objects to be included in the build. There is no conditional
compilation at this point. IF a socket is included, it includes the models. If a model is included, it should include {em all}
objects, because it is not possible to determine at build time what options may be needed for a given model CPU.
@ -407,34 +407,34 @@ This Makefile.inc includes no other Makefile.inc files; any inclusion should be
\subsection{northbridge}
\subsubsection{northbridge/Kconfig}
No variables. Source all vendor directory Kconfigs.
\subsubsection{northbridge/Kconfig}
\subsubsection{northbridge/Makefile.inc}
No variables. unconditionally include all vendor Makefile.inc
\subsubsection{northbridge/<vendor>/Kconfig}
\subsubsection{northbridge/$<$vendor$>$/Kconfig}
No variables. Source all chip directory Kconfigs.
\subsubsection{northbridge/<vendor>/Makefile.inc}
\subsubsection{northbridge/$<$vendor$>$/Makefile.inc}
No variables. {\em Conditionally} include all chipset Makefile.inc. The variable
is the name of the part, e.g.
\begin{verbatim}
subdirs-$(CONFIG_NORTHBRIDGE_AMD_AMDK8) += amdk8
\end{verbatim}
.
\subsubsection{northbridge/<vendor>/<chip>/Kconfig}
\subsubsection{northbridge/$<$vendor$>$/$<$chip$>$/Kconfig}
Typically a small number of variables. One defines the part name. Here is an example
of the variables defined for the K8.
\begin{verbatim}
config NORTHBRIDGE_AMD_AMDK8
bool
default n
bool
default n
config AGP_APERTURE_SIZE
hex
default 0x4000000
hex
default 0x4000000
config HAVE_HIGH_TABLES
int
default 1
int
default 1
\end{verbatim}
\subsubsection{northbridge/<vendor>/<chip>/Makefile.inc}
\subsubsection{northbridge/$<$vendor$>$/$<$chip$>$/Makefile.inc}
Typically very small set of rules, and very simple.
Since this file is already conditionally included,
we don't need to test for the chipset CONFIG variable. We
@ -459,7 +459,7 @@ obj-$(CONFIG_HAVE_ACPI_TABLES) += amdk8_acpi.o
\subsubsection{vendor and part}
\subsection{superio}
\subsection{drivers/i2c}
This is a rather special case. There are no Kconfig files or Makefile.inc files here. They are notneeed.
This is a rather special case. There are no Kconfig files or Makefile.inc files here. They are not needed.
To compile in one of these files, name the .o directory. E.g. in serengeti\_cheetah we have:
\begin{verbatim}
\end{verbatim}