summaryrefslogtreecommitdiffstats
path: root/Documentation/Kconfig.tex
blob: bac8f2bccd28b37e93ea74aceb5b20b5b37a7c50 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
\documentclass[10pt,letterpaper]{article}
\usepackage[latin1]{inputenc}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\author{Ron Minnich}
\title{Kconfig usage in coreboot v2}
\begin{document}
\section{Introduction}
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.
\section{Kconfig variations}
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.

For variables set by the user, see src/console/Kconfig.

For variables not set by the user, see src/mainboard/amd/serengeti\_cheetah/Kconfig. Users should never set such variables as the cache as RAM base. These are highly mainboard dependent.

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.

\section{Makefile and Makefile.inc}
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.

Make is not recursive. There is only one make process.
\subsection{subdirs usage}
Further includes of Makefile.inc, if needed, are done via subdirs-y commands. As in Linux, the subdirs can be conditional or unconditional. Conditional includes are done via subdirs-\$(CONFIG\_VARIABLE) usage; unconditional are done via subdirs-y.

We define the common rules for which variation to use below.
\subsection{object file specification}
There are several different types of objects specified in the tree. They are:
\begin{description}
\item[obj]objects for the RAM part of the code
\item[driver]drivers for the RAM part. Drivers are not represented in the device tree but do have a driver struct attached in the driver section.
\item[initobj]seperately-compiled code for the ROM section of coreboot
\end{description}
These items are specified via the -y syntax as well. Conditional object inclusion is done via the -\$(CONFIG\_VARIABLE) syntax.

\section{Example: AMD serengeti cheetah}
\subsection{mainboard/Kconfig}
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.
\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.
\input{ mainboardkconfig.tex}
\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}
We define objects in the first part. The mainbard itself is a driver and included unconditionally. Other objects are conditional:
\begin{verbatim}
driver-y +=  mainboard.o

#needed by irq_tables and mptable and acpi_tables
obj-y += get_bus_conf.o
obj-$(CONFIG_HAVE_MP_TABLE) += mptable.o
obj-$(CONFIG_HAVE_PIRQ_TABLE) += irq_tables.o
obj-$(CONFIG_HAVE_ACPI_TABLES) +=  dsdt.o
obj-$(CONFIG_HAVE_ACPI_TABLES) +=  acpi_tables.o
obj-$(CONFIG_HAVE_ACPI_TABLES) +=  fadt.o

#./ssdt.o is in northbridge/amd/amdk8/Config.lb
obj-$(CONFIG_ACPI_SSDTX_NUM) +=  ssdt2.o
obj-$(CONFIG_ACPI_SSDTX_NUM) +=  ssdt3.o
obj-$(CONFIG_HAVE_ACPI_TABLES) +=  ssdt4.o
driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o

# This is part of the conversion to init-obj and away from included code.

initobj-y += crt0.o
\end{verbatim}
\subsubsection{romcc legacy support}
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
crt0-y += ../../../../src/cpu/x86/16bit/reset16.inc
crt0-y += ../../../../src/arch/i386/lib/id.inc
crt0-y += ../../../../src/cpu/amd/car/cache_as_ram.inc
crt0-y += auto.inc

ldscript-y += ../../../../src/arch/i386/init/ldscript_fallback_cbfs.lb
ldscript-y += ../../../../src/cpu/x86/16bit/entry16.lds
ldscript-y += ../../../../src/cpu/x86/16bit/reset16.lds
ldscript-y += ../../../../src/arch/i386/lib/id.lds
ldscript-y += ../../../../src/arch/i386/lib/failover.lds

\end{verbatim}
\subsubsection{POST\_EVALUATION}
POST\_EVALUATION rules should be placed after this section:
\begin{verbatim}
ifdef POST_EVALUATION
\end{verbatim}
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 $@

$(obj)/mainboard/$(MAINBOARDDIR)/dsdt.o: $(obj)/dsdt.c
  $(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

$(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

$(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

$(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 $@

\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.
\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.
\begin{verbatim}
chip northbridge/amd/amdk8/root_complex
  device cpu_cluster 0 on
    chip cpu/amd/socket_F
      device lapic 0 on end
    end
  end
\end{verbatim}
This topology is always somewhat confusing to newcomers, and even to coreboot veterans.

We root the tree at the pci-e {\it root complex}. There is always the question of how and where to root the tree. Over the years we
have found that the one part that never goes away is the root complex. CPU sockets may be empty or full; but there is always a northbridge
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 a CPU 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 cpu\_cluster device which we turn on,
which connects to a {\it cpu/amd/socket\_F},
which has a local 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.
\begin{verbatim}
  device 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
\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
\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
\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
\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
\end{verbatim}
These are the i2c devices.
\begin{verbatim}
          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

\end{verbatim}
These "register" commands set controls in the southbridge.
\begin{verbatim}
           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
\end{verbatim}
The 18.1 devices are, again, northbridge control for various k8 functions.
\begin{verbatim}
    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

      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}

\subsection{cpu socket}
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.

\subsubsection{ cpu/Kconfig}
Defines variables. Current variables are:
\input{cpukconfig.tex}
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:
\begin{verbatim}
subdirs-$(CONFIG_CPU_AMD_SOCKET_F) += socket_F
\end{verbatim}
.
CONFIG\_CPU\_AMD\_SOCKET\_F is set in a mainboard file.

\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:
\input{socketfkconfig.tex}

It sources only those Kconfigs that relate to this particular socket, i.e. not all possible models are sourced.

\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}
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}
No variables. Source all vendor directory Kconfigs.
\subsubsection{northbridge/Makefile.inc}
No variables. unconditionally include all vendor Makefile.inc
\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.
\begin{verbatim}
subdirs-$(CONFIG_NORTHBRIDGE_AMD_AMDK8) += amdk8
\end{verbatim}
.
\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

config AGP_APERTURE_SIZE
  hex
  default 0x4000000
\end{verbatim}
\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.
Note that we can make a variable conditional on the ACPI tables.
\begin{verbatim}
driver-y += northbridge.o
driver-y += misc_control.o
obj-y +=  get_sblk_pci1234.o
obj-$(CONFIG_HAVE_ACPI_TABLES) +=  amdk8_acpi.o
\end{verbatim}

\subsection{southbridge}
\subsubsection{southbridge/Kconfig}
No variables. Source all vendor directory Kconfigs.
\subsubsection{southbridge/Makefile.inc}
No variables. {\em Unconditionally} include all vendor Makefile.inc
\subsubsection{southbridge/$<$vendor$>$/Kconfig}
No variables. Source all chip directory Kconfigs.
\subsubsection{southbridge/$<$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_SOUTHBRIDGE_AMD_AMD8111) += amd8111
\end{verbatim}
.
\subsubsection{southbridge/$<$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 SOUTHBRIDGE_AMD_AMD8111
	bool
	default n

\end{verbatim}
\subsubsection{southbridge/$<$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 8111.
No conditionals in this one yet.
\begin{verbatim}
driver-y += amd8111.o
driver-y += amd8111_usb.o
driver-y += amd8111_lpc.o
driver-y += amd8111_ide.o
driver-y += amd8111_acpi.o
driver-y += amd8111_usb2.o
driver-y += amd8111_ac97.o
driver-y += amd8111_nic.o
driver-y += amd8111_pci.o
driver-y += amd8111_smbus.o
obj-y += amd8111_reset.o
\end{verbatim}

\subsubsection{vendor and part}
\subsection{southbridge}
\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 not needed.
To compile in one of these files, name the .o directory. E.g. in serengeti\_cheetah we have:
\begin{verbatim}
\end{verbatim}

\subsubsection{vendor and part}

\end{document}