aboutsummaryrefslogtreecommitdiffstats log msg author committer range
path: root/documentation/Kconfig.tex
blob: eb77fa9778265fbdfbccf99cfece7019f7a83939 (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  pre { line-height: 125%; } td.linenos .normal { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; } span.linenos { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; } td.linenos .special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; } span.linenos.special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; } .highlight .hll { background-color: #ffffcc } .highlight .c { color: #888888 } /* Comment */ .highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */ .highlight .k { color: #008800; font-weight: bold } /* Keyword */ .highlight .ch { color: #888888 } /* Comment.Hashbang */ .highlight .cm { color: #888888 } /* Comment.Multiline */ .highlight .cp { color: #cc0000; font-weight: bold } /* Comment.Preproc */ .highlight .cpf { color: #888888 } /* Comment.PreprocFile */ .highlight .c1 { color: #888888 } /* Comment.Single */ .highlight .cs { color: #cc0000; font-weight: bold; background-color: #fff0f0 } /* Comment.Special */ .highlight .gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */ .highlight .ge { font-style: italic } /* Generic.Emph */ .highlight .gr { color: #aa0000 } /* Generic.Error */ .highlight .gh { color: #333333 } /* Generic.Heading */ .highlight .gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */ .highlight .go { color: #888888 } /* Generic.Output */ .highlight .gp { color: #555555 } /* Generic.Prompt */ .highlight .gs { font-weight: bold } /* Generic.Strong */ .highlight .gu { color: #666666 } /* Generic.Subheading */ .highlight .gt { color: #aa0000 } /* Generic.Traceback */ .highlight .kc { color: #008800; font-weight: bold } /* Keyword.Constant */ .highlight .kd { color: #008800; font-weight: bold } /* Keyword.Declaration */ .highlight .kn { color: #008800; font-weight: bold } /* Keyword.Namespace */ .highlight .kp { color: #008800 } /* Keyword.Pseudo */ .highlight .kr { color: #008800; font-weight: bold } /* Keyword.Reserved */ .highlight .kt { color: #888888; font-weight: bold } /* Keyword.Type */ .highlight .m { color: #0000DD; font-weight: bold } /* Literal.Number */ .highlight .s { color: #dd2200; background-color: #fff0f0 } /* Literal.String */ .highlight .na { color: #336699 } /* Name.Attribute */ .highlight .nb { color: #003388 } /* Name.Builtin */ .highlight .nc { color: #bb0066; font-weight: bold } /* Name.Class */ .highlight .no { color: #003366; font-weight: bold } /* Name.Constant */ .highlight .nd { color: #555555 } /* Name.Decorator */ .highlight .ne { color: #bb0066; font-weight: bold } /* Name.Exception */ .highlight .nf { color: #0066bb; font-weight: bold } /* Name.Function */ .highlight .nl { color: #336699; font-style: italic } /* Name.Label */ .highlight .nn { color: #bb0066; font-weight: bold } /* Name.Namespace */ .highlight .py { color: #336699; font-weight: bold } /* Name.Property */ .highlight .nt { color: #bb0066; font-weight: bold } /* Name.Tag */ .highlight .nv { color: #336699 } /* Name.Variable */ .highlight .ow { color: #008800 } /* Operator.Word */ .highlight .w { color: #bbbbbb } /* Text.Whitespace */ .highlight .mb { color: #0000DD; font-weight: bold } /* Literal.Number.Bin */ .highlight .mf { color: #0000DD; font-weight: bold } /* Literal.Number.Float */ .highlight .mh { color: #0000DD; font-weight: bold } /* Literal.Number.Hex */ .highlight .mi { color: #0000DD; font-weight: bold } /* Literal.Number.Integer */ .highlight .mo { color: #0000DD; font-weight: bold } /* Literal.Number.Oct */ .highlight .sa { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Affix */ .highlight .sb { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Backtick */ .highlight .sc { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Char */ .highlight .dl { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Delimiter */ .highlight .sd { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Doc */ .highlight .s2 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Double */ .highlight .se { color: #0044dd; background-color: #fff0f0 } /* Literal.String.Escape */ .highlight .sh { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Heredoc */ .highlight .si { color: #3333bb; background-color: #fff0f0 } /* Literal.String.Interpol */ .highlight .sx { color: #22bb22; background-color: #f0fff0 } /* Literal.String.Other */ .highlight .sr { color: #008800; background-color: #fff0ff } /* Literal.String.Regex */ .highlight .s1 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Single */ .highlight .ss { color: #aa6600; background-color: #fff0f0 } /* Literal.String.Symbol */ .highlight .bp { color: #003388 } /* Name.Builtin.Pseudo */ .highlight .fm { color: #0066bb; font-weight: bold } /* Name.Function.Magic */ .highlight .vc { color: #336699 } /* Name.Variable.Class */ .highlight .vg { color: #dd7700 } /* Name.Variable.Global */ .highlight .vi { color: #3333bb } /* Name.Variable.Instance */ .highlight .vm { color: #336699 } /* Name.Variable.Magic */ .highlight .il { color: #0000DD; font-weight: bold } /* Literal.Number.Integer.Long */\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{subdir usage} 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. 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//Kconfig} We use the amd as a model. The only action currently taken is to source all Kconfig's in the subdirectories. \subsection{mainboard//Makefile.inc} We use amd as a model. There is currently no Makefile.inc at this level. \subsection{mainboard///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///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{defines} There are variables that should never be definable by users, as changing them will break the build or the image. These are set in MAINBOARD\_OPTIONS. \begin{verbatim} MAINBOARD_OPTIONS=\ -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: \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 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. 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 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. 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 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 \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} \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 end \end{verbatim} This is a trick used to debug by creating entries in the device tree. \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//Kconfig} The only action currently taken is to source all Kconfig's in the subdirectories. \subsection{cpu//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///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///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///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/Kconfig} No variables. unconditionally include all vendor Makefile.inc \subsubsection{northbridge//Kconfig} No variables. Source all chip directory Kconfigs. \subsubsection{northbridge//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///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 config HAVE_HIGH_TABLES int default 1 \end{verbatim} \subsubsection{northbridge///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} \subsubsection{northbridge/Kconfig} \subsubsection{vendor and part} \subsection{southbridge} \subsubsection{vendor and part} \subsection{superio} \subsection{i2cmux} \subsubsection{vendor and part} \end{document}