u-boot/dts/Kconfig

545 lines
19 KiB
Text
Raw Normal View History

#
# Device Tree Control
#
config SUPPORT_OF_CONTROL
bool
config PYLIBFDT
bool
config DTOC
bool
select PYLIBFDT
config BINMAN
bool
select DTOC
menu "Device Tree Control"
depends on SUPPORT_OF_CONTROL
config OF_CONTROL
bool "Run-time configuration via Device Tree"
select OF_LIBFDT
select OF_REAL
help
This feature provides for run-time configuration of U-Boot
via a flattened device tree.
config OF_REAL
bool
help
Indicates that a real devicetree is available which can be accessed
at runtime. This means that dev_read_...() functions can be used to
read data from the devicetree for each device. This is true if
OF_CONTROL is enabled in U-Boot proper.
config OF_BOARD_FIXUP
bool "Board-specific manipulation of Device Tree"
help
In certain circumstances it is necessary to be able to modify
U-Boot's device tree (e.g. to delete device from it). This option
make the Device Tree writeable and provides a board-specific
"board_fix_fdt" callback (called during pre-relocation time), which
enables the board initialization to modifiy the Device Tree. The
modified copy is subsequently used by U-Boot after relocation.
config SPL_OF_CONTROL
bool "Enable run-time configuration via Device Tree in SPL"
depends on SPL && OF_CONTROL
select SPL_OF_LIBFDT if !SPL_OF_PLATDATA
select SPL_OF_REAL if !SPL_OF_PLATDATA
help
Some boards use device tree in U-Boot but only have 4KB of SRAM
which is not enough to support device tree. Disable this option to
allow such boards to be supported by U-Boot SPL.
config TPL_OF_CONTROL
bool "Enable run-time configuration via Device Tree in TPL"
depends on TPL && OF_CONTROL
select TPL_OF_LIBFDT if !TPL_OF_PLATDATA
select TPL_OF_REAL if !TPL_OF_PLATDATA
help
Some boards use device tree in U-Boot but only have 4KB of SRAM
which is not enough to support device tree. Enable this option to
allow such boards to be supported by U-Boot TPL.
config VPL_OF_CONTROL
bool "Enable run-time configuration via Device Tree in VPL"
depends on VPL && OF_CONTROL
default y if SPL_OF_CONTROL
help
Some boards use device tree in U-Boot but only have 4KB of SRAM
which is not enough to support device tree. Enable this option to
allow such boards to be supported by U-Boot VPL.
config OF_LIVE
bool "Enable use of a live tree"
depends on DM && OF_CONTROL
help
Normally U-Boot uses a flat device tree which saves space and
avoids the need to unpack the tree before use. However a flat
tree does not support modification from within U-Boot since it
can invalidate driver-model device tree offsets. This option
enables a live tree which is available after relocation,
and can be adjusted as needed.
choice
prompt "Provider of DTB for DT control"
depends on OF_CONTROL
config OF_SEPARATE
bool "Separate DTB for DT control"
help
If this option is enabled, the device tree will be built and
placed as a separate u-boot.dtb file alongside the U-Boot image.
config OF_EMBED
bool "Embedded DTB for DT control"
help
If this option is enabled, the device tree will be picked up and
built into the U-Boot image. This is suitable for local debugging
and development only and is not recommended for production devices.
Boards in the mainline U-Boot tree should not use it.
endchoice
config OF_BOARD
bool "Provided by the board (e.g a previous loader) at runtime"
default y if SANDBOX || OF_HAS_PRIOR_STAGE
help
If this option is enabled, the device tree is provided at runtime by
a custom function called board_fdt_blob_setup(). The board must
implement this function if it wishes to provide special behaviour.
With this option, the device tree build by U-Boot may be overridden or
ignored. See OF_HAS_PRIOR_STAGE.
Note: Boards which use this to handle a device tree passed from an
earlier stage should enable OF_HAS_PRIOR_STAGE.
config OF_HAS_PRIOR_STAGE
bool
help
Indicates that a prior stage of the firmware (before U-Boot proper)
makes use of device tree and this board normally boots with that prior
stage, that provides a devicetree to U-Boot.
This means that the device tree built in U-Boot should not be packaged
in the firmware image. Instead, the prior stage's device tree should
be so packaged. At runtime, the prior stage reads this, does any
necessary fix-ups, then passes it to U-Boot. See OF_BOARD.
This option does not preclude using the U-Boot device tree, e.g. for
development purposes, but it is not recommended, and likely will not
even work, for production systems.
Note: This option must be set in Kconfig and cannot be enabled or
disabled in the board's defconfig file.
config OF_OMIT_DTB
bool "Omit the device tree output when building"
default y if OF_HAS_PRIOR_STAGE && !BINMAN
help
As a special case, avoid writing a device tree file u-boot.dtb when
building. Also don't include that file in u-boot.bin
This is used for boards which normally provide a devicetree via a
runtime mechanism (such as OF_BOARD), to avoid confusion.
config DEFAULT_DEVICE_TREE
string "Default Device Tree for DT control"
depends on OF_CONTROL
help
This option specifies the default Device Tree used for DT control.
It can be overridden from the command line:
$ make DEVICE_TREE=<device-tree-name>
introduce CONFIG_DEVICE_TREE_INCLUDES The build system already automatically looks for and includes an in-tree *-u-boot.dtsi when building the control .dtb. However, there are some things that are awkward to maintain in such an in-tree file, most notably the metadata associated to public keys used for verified boot. The only "official" API to get that metadata into the .dtb is via mkimage, as a side effect of building an actual signed image. But there are multiple problems with that. First of all, the final U-Boot (be it U-Boot proper or an SPL) image is built based on a binary image, the .dtb, and possibly some other binary artifacts. So modifying the .dtb after the build requires the meta-buildsystem (Yocto, buildroot, whatnot) to know about and repeat some of the steps that are already known to and handled by U-Boot's build system, resulting in needless duplication of code. It's also somewhat annoying and inconsistent to have a .dtb file in the build folder which is not generated by the command listed in the corresponding .cmd file (that of course applies to any generated file). So the contents of the /signature node really needs to be baked into the .dtb file when it is first created, which means providing the relevant data in the form of a .dtsi file. One could in theory put that data into the *-u-boot.dtsi file, but it's more convenient to be able to provide it externally: For example, when developing for a customer, it's common to use a set of dummy keys for development, while the consultants do not (and should not) have access to the actual keys used in production. For such a setup, it's easier if the keys used are chosen via the meta-buildsystem and the path(s) patched in during the configure step. And of course, nothing prevents anybody from having DEVICE_TREE_INCLUDES point at files maintained in git, or for that matter from including the public key metadata in the *-u-boot.dtsi directly and ignore this feature. There are other uses for this, e.g. in combination with ENV_IMPORT_FDT it can be used for providing the contents of the /config/environment node, so I don't want to tie this exclusively to use for verified boot. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Fix doc formatting error (make htmldocs) Signed-off-by: Simon Glass <sjg@chromium.org>
2021-11-21 13:52:51 +00:00
config DEVICE_TREE_INCLUDES
string "Extra .dtsi files to include when building DT control"
depends on OF_CONTROL
help
U-Boot's control .dtb is usually built from an in-tree .dts
file, plus (if available) an in-tree U-Boot-specific .dtsi
file. This option specifies a space-separated list of extra
.dtsi files that will also be used.
config OF_LIST
string "List of device tree files to include for DT control" if SPL_LOAD_FIT || MULTI_DTB_FIT
depends on OF_CONTROL
default DEFAULT_DEVICE_TREE
help
This option specifies a list of device tree files to use for DT
control. These will be packaged into a FIT. At run-time, U-boot
or SPL will select the correct DT to use by examining the
hardware (e.g. reading a board ID value). This is a list of
device tree files (without the directory or .dtb suffix)
separated by <space>.
config OF_OVERLAY_LIST
string "List of device tree overlays to include for DT control"
depends on SPL_LOAD_FIT_APPLY_OVERLAY
help
This option specifies a list of device tree overlays to use for DT
control. This option can then be used by a FIT generator to include
the overlays in the FIT image.
choice
prompt "OF LIST compression"
depends on MULTI_DTB_FIT
default MULTI_DTB_FIT_NO_COMPRESSION
config MULTI_DTB_FIT_LZO
bool "LZO"
depends on SYS_MALLOC_F
select LZO
help
Compress the FIT image containing the DTBs available for the SPL
using LZO compression. (requires lzop on host).
config MULTI_DTB_FIT_GZIP
bool "GZIP"
depends on SYS_MALLOC_F
select GZIP
help
Compress the FIT image containing the DTBs available for the SPL
using GZIP compression. (requires gzip on host)
config MULTI_DTB_FIT_NO_COMPRESSION
bool "No compression"
help
Do not compress the FIT image containing the DTBs available for the SPL.
Use this options only if LZO is not available and the DTBs are very small.
endchoice
choice
prompt "Location of uncompressed DTBs"
depends on (MULTI_DTB_FIT_GZIP || MULTI_DTB_FIT_LZO)
default MULTI_DTB_FIT_DYN_ALLOC if SYS_MALLOC_F
config MULTI_DTB_FIT_DYN_ALLOC
bool "Dynamically allocate the memory"
depends on SYS_MALLOC_F
config MULTI_DTB_FIT_USER_DEFINED_AREA
bool "User-defined location"
endchoice
config MULTI_DTB_FIT_UNCOMPRESS_SZ
hex "Size of memory reserved to uncompress the DTBs"
default 0x8000
help
This is the size of this area where the DTBs are uncompressed.
If this area is dynamically allocated, make sure that
SYS_MALLOC_F_LEN is big enough to contain it.
config MULTI_DTB_FIT_USER_DEF_ADDR
hex "Address of memory where dtbs are uncompressed"
depends on MULTI_DTB_FIT_USER_DEFINED_AREA
help
the FIT image containing the DTBs is uncompressed in an area defined
at compilation time. This is the address of this area. It must be
aligned on 2-byte boundary.
config DTB_RESELECT
bool "Support swapping dtbs at a later point in boot"
depends on MULTI_DTB_FIT
help
It is possible during initial boot you may need to use a generic
dtb until you can fully determine the board your running on. This
config allows boards to implement a function at a later point
during boot to switch to the "correct" dtb.
config MULTI_DTB_FIT
bool "Support embedding several DTBs in a FIT image for u-boot"
help
This option provides hooks to allow U-boot to parse an
appended FIT image and enable board specific code to then select
the correct DTB to be used. Use this if you need to support
multiple DTBs but don't use the SPL.
config SPL_MULTI_DTB_FIT
depends on SPL_LOAD_FIT && SPL_OF_REAL
bool "Support embedding several DTBs in a FIT image for the SPL"
help
This option provides the SPL with the ability to select its own
DTB at runtime from an appended FIT image containing several DTBs.
This allows using the same SPL binary on multiple platforms.
The primary purpose is to handle different versions of
the same platform without tweaking the platform code if the
differences can be expressed in the DTBs (common examples are: bus
capabilities, pad configurations).
config SPL_OF_LIST
string "List of device tree files to include for DT control in SPL" if SPL_MULTI_DTB_FIT
depends on SPL_OF_CONTROL
default OF_LIST
help
This option specifies a list of device tree files to use for DT
control in the SPL. These will be packaged into a FIT. At run-time,
the SPL will select the correct DT to use by examining the
hardware (e.g. reading a board ID value). This is a list of
device tree files (without the directory or .dtb suffix)
separated by <space>.
choice
prompt "SPL OF LIST compression"
depends on SPL_MULTI_DTB_FIT
default SPL_MULTI_DTB_FIT_LZO
config SPL_MULTI_DTB_FIT_LZO
bool "LZO"
depends on SYS_MALLOC_F
select SPL_LZO
help
Compress the FIT image containing the DTBs available for the SPL
using LZO compression. (requires lzop on host).
config SPL_MULTI_DTB_FIT_GZIP
bool "GZIP"
depends on SYS_MALLOC_F
select SPL_GZIP
help
Compress the FIT image containing the DTBs available for the SPL
using GZIP compression. (requires gzip on host)
config SPL_MULTI_DTB_FIT_NO_COMPRESSION
bool "No compression"
help
Do not compress the FIT image containing the DTBs available for the SPL.
Use this options only if LZO is not available and the DTBs are very small.
endchoice
choice
prompt "Location of uncompressed DTBs"
depends on (SPL_MULTI_DTB_FIT_GZIP || SPL_MULTI_DTB_FIT_LZO)
default SPL_MULTI_DTB_FIT_DYN_ALLOC if SYS_MALLOC_F
config SPL_MULTI_DTB_FIT_DYN_ALLOC
bool "Dynamically allocate the memory"
depends on SYS_MALLOC_F
config SPL_MULTI_DTB_FIT_USER_DEFINED_AREA
bool "User-defined location"
endchoice
config SPL_MULTI_DTB_FIT_UNCOMPRESS_SZ
hex "Size of memory reserved to uncompress the DTBs"
depends on (SPL_MULTI_DTB_FIT_GZIP || SPL_MULTI_DTB_FIT_LZO)
default 0x8000
help
This is the size of this area where the DTBs are uncompressed.
If this area is dynamically allocated, make sure that
SPL_SYS_MALLOC_F_LEN is big enough to contain it.
config SPL_MULTI_DTB_FIT_USER_DEF_ADDR
hex "Address of memory where dtbs are uncompressed"
depends on SPL_MULTI_DTB_FIT_USER_DEFINED_AREA
help
the FIT image containing the DTBs is uncompressed in an area defined
at compilation time. This is the address of this area. It must be
aligned on 2-byte boundary.
config OF_SPL_REMOVE_PROPS
string "List of device tree properties to drop for SPL"
depends on SPL_OF_CONTROL
default "interrupt-parent interrupts" if SPL_PINCTRL && SPL_CLK
default "clocks clock-names interrupt-parent interrupts" if SPL_PINCTRL
default "pinctrl-0 pinctrl-names interrupt-parent interrupts" if SPL_CLK
default "pinctrl-0 pinctrl-names clocks clock-names interrupt-parent interrupts"
help
Since SPL normally runs in a reduced memory space, the device tree
is cut down to only what is needed to load and start U-Boot. Only
nodes marked with the property "u-boot,dm-pre-reloc" will be
included. In addition, some properties are not used by U-Boot and
can be discarded. This option defines the list of properties to
discard.
config OF_DTB_PROPS_REMOVE
bool "Enable removal of device tree properties"
depends on OF_CONTROL
help
Some boards have restricted amount of storage for U-Boot image.
If the generated binary doesn't fit into available image storage,
the built-in device tree could probably be cut down by removing
some not required device tree properties to reduce the image size.
Enable this option and define the properties to be removed in the
CONFIG_OF_REMOVE_PROPS list. Do not enable this option if you must
pass the built-in DTB directly to the kernel!
config OF_REMOVE_PROPS
string "List of device tree properties to drop"
depends on OF_DTB_PROPS_REMOVE
default "interrupt-parent interrupts" if PINCTRL
help
Some properties are not used by U-Boot and can be discarded.
This option defines the list of properties to discard.
config SPL_OF_PLATDATA
bool "Generate platform data for use in SPL"
depends on SPL_OF_CONTROL
select DTOC
select SPL_OF_PLATDATA_DRIVER_RT if !SPL_OF_PLATDATA_INST
help
For very constrained SPL environments the overhead of decoding
device tree nodes and converting their contents into platform data
is too large. This overhead includes libfdt code as well as the
device tree contents itself. The latter is fairly compact, but the
former can add 3KB or more to a Thumb 2 Image.
This option enables generation of platform data from the device
tree as C code. This code creates devices using U_BOOT_DRVINFO()
declarations. The benefit is that it allows driver code to access
the platform data directly in C structures, avoidin the libfdt
overhead.
This option works by generating C structure declarations for each
compatible string, then adding platform data and U_BOOT_DRVINFO
declarations for each node. See of-plat.txt for more information.
config SPL_OF_REAL
bool
help
Indicates that a real devicetree is available which can be accessed
at runtime. This means that dev_read_...() functions can be used to
read data from the devicetree for each device. This is true if
SPL_OF_CONTROL is enabled and not SPL_OF_PLATDATA
if SPL_OF_PLATDATA
config SPL_OF_PLATDATA_PARENT
bool "Support parent information in devices"
default y
help
Generally it is useful to be able to access the parent of a device
with of-platdata. To save space this can be disabled, but in that
case dev_get_parent() will always return NULL;
config SPL_OF_PLATDATA_INST
bool "Declare devices at build time"
help
Declare devices as udevice instances so that they do not need to be
bound when U-Boot starts. This can save time and code space.
config SPL_OF_PLATDATA_NO_BIND
bool "Don't allow run-time binding of devices"
depends on SPL_OF_PLATDATA_INST
default y
help
This removes the ability to bind devices at run time, thus saving
some code space in U-Boot. This can be disabled if binding is needed,
at the code of some code size increase.
config SPL_OF_PLATDATA_RT
bool "Use a separate struct for device runtime data"
depends on SPL_OF_PLATDATA_INST
default y
help
For systems running SPL from read-only memory it is convenient to
separate out the runtime information, so that the devices don't need
to be copied before being used. This moves the read-write parts of
struct udevice (at present just the flags) into a separate struct,
which is allocated at runtime.
config SPL_OF_PLATDATA_DRIVER_RT
bool
help
Use a separate struct for driver runtime data.
This enables the driver_rt information, used with of-platdata when
of-platdata-inst is not used. It allows finding devices by their
driver data.
endif
config TPL_OF_REAL
bool
help
Indicates that a real devicetree is available which can be accessed
at runtime. This means that dev_read_...() functions can be used to
read data from the devicetree for each device. This is true if
TPL_OF_CONTROL is enabled and not TPL_OF_PLATDATA
config TPL_OF_PLATDATA
bool "Generate platform data for use in TPL"
depends on TPL_OF_CONTROL
select DTOC
select TPL_OF_PLATDATA_DRIVER_RT if !TPL_OF_PLATDATA_INST
help
For very constrained SPL environments the overhead of decoding
device tree nodes and converting their contents into platform data
is too large. This overhead includes libfdt code as well as the
device tree contents itself. The latter is fairly compact, but the
former can add 3KB or more to a Thumb 2 Image.
This option enables generation of platform data from the device
tree as C code. This code creates devices using U_BOOT_DRVINFO()
declarations. The benefit is that it allows driver code to access
the platform data directly in C structures, avoidin the libfdt
overhead.
This option works by generating C structure declarations for each
compatible string, then adding platform data and U_BOOT_DRVINFO
declarations for each node. See of-plat.txt for more information.
if TPL_OF_PLATDATA
config TPL_OF_PLATDATA_PARENT
bool "Support parent information in devices"
default y
help
Generally it is useful to be able to access the parent of a device
with of-platdata. To save space this can be disabled, but in that
case dev_get_parent() will always return NULL;
config TPL_OF_PLATDATA_INST
bool "Declare devices at build time"
help
Declare devices as udevice instances so that they do not need to be
bound when U-Boot starts. This can save time and code space.
config TPL_OF_PLATDATA_NO_BIND
bool "Don't allow run-time binding of devices"
depends on TPL_OF_PLATDATA_INST
default y
help
This removes the ability to bind devices at run time, thus saving
some code space in U-Boot. This can be disabled if binding is needed,
at the code of some code size increase.
config TPL_OF_PLATDATA_RT
bool "Use a separate struct for device runtime data"
depends on TPL_OF_PLATDATA_INST
default y
help
For systems running TPL from read-only memory it is convenient to
separate out the runtime information, so that the devices don't need
to be copied before being used. This moves the read-write parts of
struct udevice (at present just the flags) into a separate struct,
which is allocated at runtime.
config TPL_OF_PLATDATA_DRIVER_RT
bool
help
Use a separate struct for driver runtime data.
This enables the driver_rt information, used with of-platdata when
of-platdata-inst is not used. It allows finding devices by their
driver data.
endif
config VPL_OF_REAL
def_bool y
depends on VPL
help
Indicates that a real devicetree is available which can be accessed
at runtime. This means that dev_read_...() functions can be used to
read data from the devicetree for each device. This is true if
TPL_OF_CONTROL is enabled and not TPL_OF_PLATDATA
endmenu