1.. _setting_configuration_values: 2 3Setting Kconfig configuration values 4#################################### 5 6The :ref:`menuconfig and guiconfig interfaces <menuconfig>` can be used to test 7out configurations during application development. This page explains how to 8make settings permanent. 9 10All Kconfig options can be searched in the :ref:`Kconfig search page 11<kconfig-search>`. 12 13.. note:: 14 15 Before making changes to Kconfig files, it's a good idea to also go through 16 the :ref:`kconfig_tips_and_tricks` page. 17 18 19Visible and invisible Kconfig symbols 20************************************* 21 22When making Kconfig changes, it's important to understand the difference 23between *visible* and *invisible* symbols. 24 25- A visible symbol is a symbol defined with a prompt. Visible symbols show 26 up in the interactive configuration interfaces (hence *visible*), and can be 27 set in configuration files. 28 29 Here's an example of a visible symbol: 30 31 .. code-block:: kconfig 32 33 config FPU 34 bool "Support floating point operations" 35 depends on HAS_FPU 36 37 The symbol is shown like this in ``menuconfig``, where it can be toggled: 38 39 .. code-block:: none 40 41 [ ] Support floating point operations 42 43- An *invisible* symbol is a symbol without a prompt. Invisible symbols are 44 not shown in the interactive configuration interfaces, and users have no 45 direct control over their value. They instead get their value from defaults 46 or from other symbols. 47 48 Here's an example of an invisible symbol: 49 50 .. code-block:: kconfig 51 52 config CPU_HAS_FPU 53 bool 54 help 55 This symbol is y if the CPU has a hardware floating point unit. 56 57 In this case, ``CPU_HAS_FPU`` is enabled through other symbols having 58 ``select CPU_HAS_FPU``. 59 60 61Setting symbols in configuration files 62************************************** 63 64Visible symbols can be configured by setting them in configuration files. The 65initial configuration is produced by merging a :file:`*_defconfig` file for the 66board with application settings, usually from :file:`prj.conf`. See 67:ref:`initial-conf` below for more details. 68 69Assignments in configuration files use this syntax: 70 71.. code-block:: cfg 72 73 CONFIG_<symbol name>=<value> 74 75There should be no spaces around the equals sign. 76 77``bool`` symbols can be enabled or disabled by setting them to ``y`` or ``n``, 78respectively. The ``FPU`` symbol from the example above could be enabled like 79this: 80 81.. code-block:: cfg 82 83 CONFIG_FPU=y 84 85.. note:: 86 87 A boolean symbol can also be set to ``n`` with a comment formatted like 88 this: 89 90 .. code-block:: cfg 91 92 # CONFIG_SOME_OTHER_BOOL is not set 93 94 This is the format you will see in the merged configuration in 95 :file:`zephyr/.config`. 96 97 This style is accepted for historical reasons: Kconfig configuration files 98 can be parsed as makefiles (though Zephyr doesn't use this). Having 99 ``n``-valued symbols correspond to unset variables simplifies tests in Make. 100 101Other symbol types are assigned like this: 102 103.. code-block:: cfg 104 105 CONFIG_SOME_STRING="cool value" 106 CONFIG_SOME_INT=123 107 108Comments use a #: 109 110.. code-block:: cfg 111 112 # This is a comment 113 114Assignments in configuration files are only respected if the dependencies for 115the symbol are satisfied. A warning is printed otherwise. To figure out what 116the dependencies of a symbol are, use one of the :ref:`interactive 117configuration interfaces <menuconfig>` (you can jump directly to a symbol with 118:kbd:`/`), or look up the symbol in the :ref:`Kconfig search page 119<kconfig-search>`. 120 121 122.. _initial-conf: 123 124The Initial Configuration 125************************* 126 127The initial configuration for an application comes from merging configuration 128settings from three sources: 129 1301. A ``BOARD``-specific configuration file stored in 131 :file:`boards/<architecture>/<BOARD>/<BOARD>_defconfig` 132 1332. Any CMake cache entries prefix with ``CONFIG_`` 134 1353. The application configuration 136 137The application configuration can come from the sources below (each file is 138known as a Kconfig fragment, which are then merged to get the final 139configuration used for a particular build). By default, :file:`prj.conf` is 140used. 141 142#. If ``CONF_FILE`` is set, the configuration file(s) specified in it are 143 merged and used as the application configuration. ``CONF_FILE`` can be set 144 in various ways: 145 146 1. In :file:`CMakeLists.txt`, before calling ``find_package(Zephyr)`` 147 148 2. By passing ``-DCONF_FILE=<conf file(s)>``, either directly or via ``west`` 149 150 3. From the CMake variable cache 151 152 Furthermore if ``CONF_FILE`` is set as single configuration file of the 153 form :file:`prj_<build>.conf` and if file 154 :file:`boards/<BOARD>_<build>.conf` exists in same folder as file 155 :file:`prj_<build>.conf`, the result of merging :file:`prj_<build>.conf` and 156 :file:`boards/<BOARD>_<build>.conf` is used. 157 158#. Otherwise, :file:`prj_<BOARD>.conf` is used if it exists in the application 159 configuration directory. 160 161#. Otherwise, if :file:`boards/<BOARD>.conf` exists in the application 162 configuration directory, the result of merging it with :file:`prj.conf` is 163 used. 164 165#. Otherwise, if board revisions are used and 166 :file:`boards/<BOARD>_<revision>.conf` exists in the application 167 configuration directory, the result of merging it with :file:`prj.conf` and 168 :file:`boards/<BOARD>.conf` is used. 169 170#. Otherwise, :file:`prj.conf` is used from the application configuration 171 directory. If it does not exist then a fatal error will be emitted. 172 173All configuration files will be taken from the application's configuration 174directory except for files with an absolute path that are given with the 175``CONF_FILE``, ``EXTRA_CONF_FILE``, ``DTC_OVERLAY_FILE``, and 176``EXTRA_DTC_OVERLAY_FILE`` arguments. For these, 177a file in a Zephyr module can be referred by escaping the Zephyr module dir 178variable like this ``\${ZEPHYR_<module>_MODULE_DIR}/<path-to>/<file>`` 179when setting any of said variables in the application's :file:`CMakeLists.txt`. 180 181See :ref:`Application Configuration Directory <application-configuration-directory>` 182on how the application configuration directory is defined. 183 184If a symbol is assigned both in :file:`<BOARD>_defconfig` and in the 185application configuration, the value set in the application configuration takes 186precedence. 187 188The merged configuration is saved to :file:`zephyr/.config` in the build 189directory. 190 191As long as :file:`zephyr/.config` exists and is up-to-date (is newer than any 192``BOARD`` and application configuration files), it will be used in preference 193to producing a new merged configuration. :file:`zephyr/.config` is also the 194configuration that gets modified when making changes in the :ref:`interactive 195configuration interfaces <menuconfig>`. 196 197 198Configuring invisible Kconfig symbols 199************************************* 200 201When making changes to the default configuration for a board, you might have to 202configure invisible symbols. This is done in 203:file:`boards/<architecture>/<BOARD>/Kconfig.defconfig`, which is a regular 204:file:`Kconfig` file. 205 206.. note:: 207 208 Assignments in :file:`.config` files have no effect on invisible symbols, 209 so this scheme is not just an organizational issue. 210 211Assigning values in :file:`Kconfig.defconfig` relies on defining a Kconfig 212symbol in multiple locations. As an example, say we want to set ``FOO_WIDTH`` 213below to 32: 214 215.. code-block:: kconfig 216 217 config FOO_WIDTH 218 int 219 220To do this, we extend the definition of ``FOO_WIDTH`` as follows, in 221:file:`Kconfig.defconfig`: 222 223.. code-block:: kconfig 224 225 if BOARD_MY_BOARD 226 227 config FOO_WIDTH 228 default 32 229 230 endif 231 232.. note:: 233 234 Since the type of the symbol (``int``) has already been given at the first 235 definition location, it does not need to be repeated here. Only giving the 236 type once at the "base" definition of the symbol is a good idea for reasons 237 explained in :ref:`kconfig_shorthands`. 238 239``default`` values in :file:`Kconfig.defconfig` files have priority over 240``default`` values given on the "base" definition of a symbol. Internally, this 241is implemented by including the :file:`Kconfig.defconfig` files first. Kconfig 242uses the first ``default`` with a satisfied condition, where an empty condition 243corresponds to ``if y`` (is always satisfied). 244 245Note that conditions from surrounding top-level ``if``\ s are propagated to 246symbol properties, so the above ``default`` is equivalent to 247``default 32 if BOARD_MY_BOARD``. 248 249.. warning:: 250 251 When defining a symbol in multiple locations, dependencies are ORed together 252 rather than ANDed together. It is not possible to make the dependencies of a 253 symbol more restrictive by defining it in multiple locations. 254 255 For example, the direct dependencies of the symbol below becomes 256 ``DEP1 || DEP2``: 257 258 .. code-block:: kconfig 259 260 config FOO 261 ... 262 depends on DEP1 263 264 config FOO 265 ... 266 depends on DEP2 267 268 When making changes to :file:`Kconfig.defconfig` files, always check the 269 symbol's direct dependencies in one of the :ref:`interactive configuration 270 interfaces <menuconfig>` afterwards. It is often necessary to repeat 271 dependencies from the base definition of the symbol to avoid weakening a 272 symbol's dependencies. 273 274 275Motivation for Kconfig.defconfig files 276-------------------------------------- 277 278One motivation for this configuration scheme is to avoid making fixed 279``BOARD``-specific settings configurable in the interactive configuration 280interfaces. If all board configuration were done via :file:`<BOARD>_defconfig`, 281all symbols would have to be visible, as values given in 282:file:`<BOARD>_defconfig` have no effect on invisible symbols. 283 284Having fixed settings be user-configurable would clutter up the configuration 285interfaces and make them harder to understand, and would make it easier to 286accidentally create broken configurations. 287 288When dealing with fixed board-specific settings, also consider whether they 289should be handled via :ref:`devicetree <dt-guide>` instead. 290 291 292Configuring choices 293------------------- 294 295There are two ways to configure a Kconfig ``choice``: 296 2971. By setting one of the choice symbols to ``y`` in a configuration file. 298 299 Setting one choice symbol to ``y`` automatically gives all other choice 300 symbols the value ``n``. 301 302 If multiple choice symbols are set to ``y``, only the last one set to ``y`` 303 will be honored (the rest will get the value ``n``). This allows a choice 304 selection from a board :file:`defconfig` file to be overridden from an 305 application :file:`prj.conf` file. 306 3072. By changing the ``default`` of the choice in :file:`Kconfig.defconfig`. 308 309 As with symbols, changing the default for a choice is done by defining the 310 choice in multiple locations. For this to work, the choice must have a name. 311 312 As an example, assume that a choice has the following base definition (here, 313 the name of the choice is ``FOO``): 314 315 .. code-block:: kconfig 316 317 choice FOO 318 bool "Foo choice" 319 default B 320 321 config A 322 bool "A" 323 324 config B 325 bool "B" 326 327 endchoice 328 329 To change the default symbol of ``FOO`` to ``A``, you would add the 330 following definition to :file:`Kconfig.defconfig`: 331 332 .. code-block:: kconfig 333 334 choice FOO 335 default A 336 endchoice 337 338The :file:`Kconfig.defconfig` method should be used when the dependencies of 339the choice might not be satisfied. In that case, you're setting the default 340selection whenever the user makes the choice visible. 341 342 343More Kconfig resources 344====================== 345 346The :ref:`kconfig_tips_and_tricks` page has some tips for writing Kconfig 347files. 348 349The :zephyr_file:`kconfiglib.py <scripts/kconfig/kconfiglib.py>` docstring 350docstring (at the top of the file) goes over how symbol values are calculated 351in detail. 352