-This document describes how to use Kconfig in v2. We describe our usage of Kconfig files, Makefile.inc files, when and where to use them, how to use them, and, interestingly, when and where not to use them.
+This document describes how to use Kconfig in v2. We describe our usage of Kconfig files, Makefile.inc files, when and where to use them, how to use them, and, interestingly, when and where not to use them.
-Most Kconfig files set variables, which can be set as part of the Kconfig dialog. Not all Kconfig variables are set by the user, however; some are too dangerous. These are merely enabled by the mainboard.
+Most Kconfig files set variables, which can be set as part of the Kconfig dialog. Not all Kconfig variables are set by the user, however; some are too dangerous. These are merely enabled by the mainboard.
-Kconfig files use the source command to include subdirectories. In most cases, save for limited cases described below, subdirectories have Kconfig files. They are always sourced unconditionally.
+Kconfig files use the source command to include subdirectories. In most cases, save for limited cases described below, subdirectories have Kconfig files. They are always sourced unconditionally.
-There is only one Makefile, at the top level. All other makefiles are included as Makefile.inc. All the next-level Makefile.inc files are selected in the top level Makefile. Directories that are platform-independent are in BUILD-y; platform-dependent (e.g. Makefile.inc's that depend on architecture) are included in PLATFORM-y.
+There is only one Makefile, at the top level. All other makefiles are included as Makefile.inc. All the next-level Makefile.inc files are selected in the top level Makefile. Directories that are platform-independent are in BUILD-y; platform-dependent (e.g. Makefile.inc's that depend on architecture) are included in PLATFORM-y.
-Further includes of Makefile.inc, if needed, are done via subdir-y commands. As in Linux, the subdir can be conditional or unconditional. Conditional includes are done via subdir-\$(CONFIG\_VARIABLE) usage; unconditional are done via subdir-y.
+Further includes of Makefile.inc, if needed, are done via subdir-y commands. As in Linux, the subdir can be conditional or unconditional. Conditional includes are done via subdir-\$(CONFIG\_VARIABLE) usage; unconditional are done via subdir-y.
-Defines Vendor variables. Currently defined variables are:
-Sources all Kconfig files in the vendor directories.
+Defines Vendor variables. Currently defined variables are:
+Sources all Kconfig files in the vendor directories.
\input{ mainboardkconfig.tex}
\subsection{mainboard/Makefile.inc}
There is none at this time.
\input{ mainboardkconfig.tex}
\subsection{mainboard/Makefile.inc}
There is none at this time.
-\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}
-We use amd as a model. There is currently no Makefile.inc at this level.
-\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.
+\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}
+We use amd as a model. There is currently no Makefile.inc at this level.
+\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.
-\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.
+\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.
-We hope to move away from romcc soon, but for now, if one is using romcc, the Makefile.inc must define
-crt0 include files (assembly code for startup, usually); and several ldscripts. These are taken directly from the
-old Config.lb. Note that these use the -y syntax and can use the ability to be included conditionally.
+We hope to move away from romcc soon, but for now, if one is using romcc, the Makefile.inc must define
+crt0 include files (assembly code for startup, usually); and several ldscripts. These are taken directly from the
+old Config.lb. Note that these use the -y syntax and can use the ability to be included conditionally.
\begin{verbatim}
crt0-y += ../../../../src/cpu/x86/16bit/entry16.inc
crt0-y += ../../../../src/cpu/x86/32bit/entry32.inc
\begin{verbatim}
crt0-y += ../../../../src/cpu/x86/16bit/entry16.inc
crt0-y += ../../../../src/cpu/x86/32bit/entry32.inc
- -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
-to ensure that the values of variables are correct.
-Here are the post-evaluation rules for this mainboard:
+to ensure that the values of variables are correct.
+Here are the post-evaluation rules for this mainboard:
- 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
- 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
- $(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 $@
-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.
+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.
\subsubsection{devicetree.cb}
Most of the old Config.lb is gone, but one piece remains: the device tree specification. This tree is still required to build a mainboard
\subsubsection{devicetree.cb}
Most of the old Config.lb is gone, but one piece remains: the device tree specification. This tree is still required to build a mainboard
-properly, as it defines topology and chips that can be defined no other way.
-Let's go through the tree.
+properly, as it defines topology and chips that can be defined no other way.
+Let's go through the tree.
-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,
-which connects to a {\it cpu/amd/socket\_F},
-which has an apic, which is on.
+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 own apic\_cluster device which we turn on,
+which connects to a {\it cpu/amd/socket\_F},
+which has an apic, which is on.
-Note that we do not enumerate all CPUs, even on this SMP mainboard. The reason is they may not all be there. The CPU we define here
-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.
+Note that we do not enumerate all CPUs, even on this SMP mainboard. The reason is they may not all be there. The CPU we define here
+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.
- 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
-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.
+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.
- 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
-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.
+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.
- 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
- 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
+ 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
- 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
-The CPU socket is the key link from mainboard to its CPUs. Since many models of CPU can go in a socket, the mainboard mentions only
-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.
+The CPU socket is the key link from mainboard to its CPUs. Since many models of CPU can go in a socket, the mainboard mentions only
+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.
-Sources all Kconfig files in the vendor directories.
-\subsubsection{ /cpu/Makefile.inc}
-Unconditionally sources all Makefile.inc in the vendor directories.
-
-\subsection{cpu/<vendor>/Kconfig}
-The only action currently taken is to source all Kconfig's in the
-subdirectories.
-\subsection{cpu/<vendor>/Makefile.inc}
-{\em Conditionally} source the socket directories.
-Example:
+Sources all Kconfig files in the vendor directories.
+\subsubsection{ cpu/Makefile.inc}
+Unconditionally sources all Makefile.inc in the vendor directories.
+
+\subsection{cpu/$<$vendor$>$/Kconfig}
+The only action currently taken is to source all Kconfig's in the
+subdirectories.
+\subsection{cpu/$<$vendor$>$/Makefile.inc}
+{\em Conditionally} source the socket directories.
+Example:
-\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:
+\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:
-if needed.
-\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.
+if needed.
+\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.
This Makefile.inc includes no other Makefile.inc files; any inclusion should be done in the socket Makefile.inc.
\subsection{northbridge}
\subsubsection{northbridge/Kconfig}
This Makefile.inc includes no other Makefile.inc files; any inclusion should be done in the socket Makefile.inc.
\subsection{northbridge}
\subsubsection{northbridge/Kconfig}
-\subsubsection{northbridge/<vendor>/Kconfig}
-No variables. Source all chip directory Kconfigs.
-\subsubsection{northbridge/<vendor>/Makefile.inc}
-No variables. {\em Conditionally} include all chipset Makefile.inc. The variable
-is the name of the part, e.g.
+\subsubsection{northbridge/$<$vendor$>$/Kconfig}
+No variables. Source all chip directory Kconfigs.
+\subsubsection{northbridge/$<$vendor$>$/Makefile.inc}
+No variables. {\em Conditionally} include all chipset Makefile.inc. The variable
+is the name of the part, e.g.
-\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.
+\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.
-\subsubsection{northbridge/<vendor>/<chip>/Makefile.inc}
-Typically very small set of rules, and very simple.
-Since this file is already conditionally included,
+\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
can therefore test other variables (which is part of the reason
we set up conditional inclusion of this file, instead
of unconditionally including it). Here is an example from AMD K8.
we don't need to test for the chipset CONFIG variable. We
can therefore test other variables (which is part of the reason
we set up conditional inclusion of this file, instead
of unconditionally including it). Here is an example from AMD K8.
-This is a rather special case. There are no Kconfig files or Makefile.inc files here. They are notneeed.
-To compile in one of these files, name the .o directory. E.g. in serengeti\_cheetah we have:
+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: