2014-09-22 10:59:05 +00:00
|
|
|
#
|
|
|
|
# Device Tree Control
|
|
|
|
#
|
|
|
|
|
|
|
|
config SUPPORT_OF_CONTROL
|
|
|
|
bool
|
|
|
|
|
2017-10-17 04:42:44 +00:00
|
|
|
config PYLIBFDT
|
|
|
|
bool
|
|
|
|
|
|
|
|
config DTOC
|
|
|
|
bool
|
|
|
|
select PYLIBFDT
|
|
|
|
|
|
|
|
config BINMAN
|
|
|
|
bool
|
|
|
|
select DTOC
|
|
|
|
|
2014-09-22 10:59:05 +00:00
|
|
|
menu "Device Tree Control"
|
|
|
|
depends on SUPPORT_OF_CONTROL
|
|
|
|
|
|
|
|
config OF_CONTROL
|
|
|
|
bool "Run-time configuration via Device Tree"
|
2019-12-18 02:40:09 +00:00
|
|
|
select OF_LIBFDT if !OF_PLATDATA
|
2021-08-07 13:24:03 +00:00
|
|
|
select OF_REAL if !OF_PLATDATA
|
2014-09-22 10:59:05 +00:00
|
|
|
help
|
|
|
|
This feature provides for run-time configuration of U-Boot
|
|
|
|
via a flattened device tree.
|
|
|
|
|
2021-08-07 13:24:02 +00:00
|
|
|
config OF_REAL
|
2021-08-07 13:24:03 +00:00
|
|
|
bool
|
2021-08-07 13:24:02 +00:00
|
|
|
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.
|
|
|
|
|
dm: Add callback to modify the device tree
Certain boards come in different variations by way of utilizing daughter
boards, for example. These boards might contain additional chips, which
are added to the main board's busses, e.g. I2C.
The device tree support for such boards would either, quite naturally,
employ the overlay mechanism to add such chips to the tree, or would use
one large default device tree, and delete the devices that are actually
not present.
Regardless of approach, even on the U-Boot level, a modification of the
device tree is a prerequisite to have such modular families of boards
supported properly.
Therefore, we add an option to make the U-Boot device tree (the actual
copy later used by the driver model) writeable, and add a callback
method that allows boards to modify the device tree at an early stage,
at which, hopefully, also the application of device tree overlays will
be possible.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>
2017-02-22 15:07:22 +00:00
|
|
|
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.
|
|
|
|
|
2015-08-11 22:31:54 +00:00
|
|
|
config SPL_OF_CONTROL
|
|
|
|
bool "Enable run-time configuration via Device Tree in SPL"
|
|
|
|
depends on SPL && OF_CONTROL
|
2019-12-18 02:40:09 +00:00
|
|
|
select SPL_OF_LIBFDT if !SPL_OF_PLATDATA
|
2021-08-07 13:24:02 +00:00
|
|
|
select SPL_OF_REAL if !SPL_OF_PLATDATA
|
2015-02-28 05:06:38 +00:00
|
|
|
help
|
|
|
|
Some boards use device tree in U-Boot but only have 4KB of SRAM
|
2019-10-22 14:50:19 +00:00
|
|
|
which is not enough to support device tree. Disable this option to
|
2015-02-28 05:06:38 +00:00
|
|
|
allow such boards to be supported by U-Boot SPL.
|
|
|
|
|
2017-06-29 09:11:21 +00:00
|
|
|
config TPL_OF_CONTROL
|
|
|
|
bool "Enable run-time configuration via Device Tree in TPL"
|
|
|
|
depends on TPL && OF_CONTROL
|
2019-12-18 02:40:09 +00:00
|
|
|
select TPL_OF_LIBFDT if !TPL_OF_PLATDATA
|
2021-08-07 13:24:02 +00:00
|
|
|
select TPL_OF_REAL if !TPL_OF_PLATDATA
|
2017-06-29 09:11:21 +00:00
|
|
|
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.
|
|
|
|
|
2022-04-30 06:56:53 +00:00
|
|
|
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.
|
|
|
|
|
2017-05-19 02:08:53 +00:00
|
|
|
config OF_LIVE
|
|
|
|
bool "Enable use of a live tree"
|
2021-02-03 13:20:03 +00:00
|
|
|
depends on DM && OF_CONTROL
|
2017-05-19 02:08:53 +00:00
|
|
|
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
|
2018-08-17 08:16:36 +00:00
|
|
|
tree does not support modification from within U-Boot since it
|
2017-05-19 02:08:53 +00:00
|
|
|
can invalidate driver-model device tree offsets. This option
|
|
|
|
enables a live tree which is available after relocation,
|
|
|
|
and can be adjusted as needed.
|
|
|
|
|
2014-09-22 10:59:05 +00:00
|
|
|
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
|
2015-09-01 00:47:52 +00:00
|
|
|
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.
|
2014-09-22 10:59:05 +00:00
|
|
|
|
2021-12-17 03:59:21 +00:00
|
|
|
endchoice
|
|
|
|
|
2017-04-02 08:25:20 +00:00
|
|
|
config OF_BOARD
|
2021-10-11 21:00:13 +00:00
|
|
|
bool "Provided by the board (e.g a previous loader) at runtime"
|
2021-12-17 03:59:35 +00:00
|
|
|
default y if SANDBOX || OF_HAS_PRIOR_STAGE
|
2017-04-02 08:25:20 +00:00
|
|
|
help
|
2021-12-17 03:59:35 +00:00
|
|
|
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.
|
2017-04-02 08:25:20 +00:00
|
|
|
|
2021-12-17 03:59:35 +00:00
|
|
|
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.
|
2014-09-22 10:59:05 +00:00
|
|
|
|
2021-12-17 03:59:38 +00:00
|
|
|
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.
|
|
|
|
|
2014-09-22 10:59:06 +00:00
|
|
|
config DEFAULT_DEVICE_TREE
|
|
|
|
string "Default Device Tree for DT control"
|
2016-02-23 05:55:44 +00:00
|
|
|
depends on OF_CONTROL
|
2014-09-22 10:59:06 +00:00
|
|
|
help
|
|
|
|
This option specifies the default Device Tree used for DT control.
|
2014-10-21 20:44:32 +00:00
|
|
|
It can be overridden from the command line:
|
2014-09-22 10:59:06 +00:00
|
|
|
$ 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.
|
|
|
|
|
2016-02-23 05:55:57 +00:00
|
|
|
config OF_LIST
|
dts: automatically build necessary .dtb files
When building for a custom board, it is quite common to maintain a
private branch which include some defconfig and .dts files. But to
hook up those .dts files requires modifying a file "belonging" to
upstream U-Boot, the arch/*/dts/Makefile. Forward-porting that branch
to a newer upstream then often results in a conflict which, while it
is trivial to resolve by hand, makes it harder to have a CI do "try to
build our board against latest upstream".
The .config usually includes information on precisely what .dtb(s) are
needed, so to avoid having to modify the Makefile, simply add the
files in (SPL_)OF_LIST to dtb-y.
A technicality is that (SPL_)OF_LIST is not always defined, so rework
the Kconfig symbols so that (SPL_)OF_LIST is always defined (when
(SPL_)OF_CONTROL), but only prompted for in the cases which used to be
their "depends on".
nios2 and microblaze already have something like this in their
dts/Makefile, and the rationale in commit 41f59f68539 is similar to
the above. So this simply generalizes existing practice. Followup
patches could remove the logic in those two makefiles, just as there's
potential for moving some common boilerplate from all the
arch/*/dts/Makefile files to the new scripts/Makefile.dts.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
2022-01-10 13:34:41 +00:00
|
|
|
string "List of device tree files to include for DT control" if SPL_LOAD_FIT || MULTI_DTB_FIT
|
|
|
|
depends on OF_CONTROL
|
2016-05-04 13:14:11 +00:00
|
|
|
default DEFAULT_DEVICE_TREE
|
2016-02-23 05:55:57 +00:00
|
|
|
help
|
|
|
|
This option specifies a list of device tree files to use for DT
|
2017-06-16 22:25:09 +00:00
|
|
|
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>.
|
2016-02-23 05:55:57 +00:00
|
|
|
|
2019-10-22 14:39:21 +00:00
|
|
|
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.
|
|
|
|
|
2019-03-08 15:06:55 +00:00
|
|
|
choice
|
2019-10-07 12:05:47 +00:00
|
|
|
prompt "OF LIST compression"
|
2019-03-08 15:06:55 +00:00
|
|
|
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.
|
2017-09-15 10:57:24 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2017-09-15 10:57:32 +00:00
|
|
|
|
|
|
|
config SPL_MULTI_DTB_FIT
|
2021-08-07 13:24:02 +00:00
|
|
|
depends on SPL_LOAD_FIT && SPL_OF_REAL
|
2017-09-15 10:57:32 +00:00
|
|
|
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
|
dts: automatically build necessary .dtb files
When building for a custom board, it is quite common to maintain a
private branch which include some defconfig and .dts files. But to
hook up those .dts files requires modifying a file "belonging" to
upstream U-Boot, the arch/*/dts/Makefile. Forward-porting that branch
to a newer upstream then often results in a conflict which, while it
is trivial to resolve by hand, makes it harder to have a CI do "try to
build our board against latest upstream".
The .config usually includes information on precisely what .dtb(s) are
needed, so to avoid having to modify the Makefile, simply add the
files in (SPL_)OF_LIST to dtb-y.
A technicality is that (SPL_)OF_LIST is not always defined, so rework
the Kconfig symbols so that (SPL_)OF_LIST is always defined (when
(SPL_)OF_CONTROL), but only prompted for in the cases which used to be
their "depends on".
nios2 and microblaze already have something like this in their
dts/Makefile, and the rationale in commit 41f59f68539 is similar to
the above. So this simply generalizes existing practice. Followup
patches could remove the logic in those two makefiles, just as there's
potential for moving some common boilerplate from all the
arch/*/dts/Makefile files to the new scripts/Makefile.dts.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
2022-01-10 13:34:41 +00:00
|
|
|
string "List of device tree files to include for DT control in SPL" if SPL_MULTI_DTB_FIT
|
|
|
|
depends on SPL_OF_CONTROL
|
2017-09-15 10:57:32 +00:00
|
|
|
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
|
2018-07-23 06:38:56 +00:00
|
|
|
prompt "Location of uncompressed DTBs"
|
2017-09-15 10:57:32 +00:00
|
|
|
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.
|
|
|
|
|
2015-06-23 21:38:29 +00:00
|
|
|
config OF_SPL_REMOVE_PROPS
|
|
|
|
string "List of device tree properties to drop for SPL"
|
2015-08-28 11:28:42 +00:00
|
|
|
depends on SPL_OF_CONTROL
|
2019-02-22 09:50:23 +00:00
|
|
|
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"
|
2015-06-23 21:38:29 +00:00
|
|
|
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.
|
|
|
|
|
2020-01-12 14:57:42 +00:00
|
|
|
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.
|
|
|
|
|
2016-07-04 17:58:06 +00:00
|
|
|
config SPL_OF_PLATDATA
|
|
|
|
bool "Generate platform data for use in SPL"
|
|
|
|
depends on SPL_OF_CONTROL
|
2017-10-17 04:42:44 +00:00
|
|
|
select DTOC
|
2021-03-15 04:25:36 +00:00
|
|
|
select SPL_OF_PLATDATA_DRIVER_RT if !SPL_OF_PLATDATA_INST
|
2016-07-04 17:58:06 +00:00
|
|
|
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
|
2020-12-29 03:34:54 +00:00
|
|
|
tree as C code. This code creates devices using U_BOOT_DRVINFO()
|
2016-07-04 17:58:06 +00:00
|
|
|
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
|
2020-12-29 03:34:54 +00:00
|
|
|
compatible string, then adding platform data and U_BOOT_DRVINFO
|
2019-01-16 19:40:18 +00:00
|
|
|
declarations for each node. See of-plat.txt for more information.
|
2016-07-04 17:58:06 +00:00
|
|
|
|
2021-08-07 13:24:02 +00:00
|
|
|
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
|
|
|
|
|
2021-02-03 13:01:13 +00:00
|
|
|
if SPL_OF_PLATDATA
|
|
|
|
|
2020-10-03 17:31:35 +00:00
|
|
|
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;
|
|
|
|
|
2021-02-03 13:01:13 +00:00
|
|
|
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.
|
|
|
|
|
2021-03-15 04:25:15 +00:00
|
|
|
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.
|
|
|
|
|
2021-03-15 04:25:35 +00:00
|
|
|
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.
|
|
|
|
|
2021-03-15 04:25:36 +00:00
|
|
|
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.
|
|
|
|
|
2021-02-03 13:01:13 +00:00
|
|
|
endif
|
|
|
|
|
2021-08-07 13:24:02 +00:00
|
|
|
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
|
|
|
|
|
2017-06-29 09:11:21 +00:00
|
|
|
config TPL_OF_PLATDATA
|
|
|
|
bool "Generate platform data for use in TPL"
|
|
|
|
depends on TPL_OF_CONTROL
|
2017-10-17 04:42:44 +00:00
|
|
|
select DTOC
|
2021-03-15 04:25:36 +00:00
|
|
|
select TPL_OF_PLATDATA_DRIVER_RT if !TPL_OF_PLATDATA_INST
|
2017-06-29 09:11:21 +00:00
|
|
|
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
|
2020-12-29 03:34:54 +00:00
|
|
|
tree as C code. This code creates devices using U_BOOT_DRVINFO()
|
2017-06-29 09:11:21 +00:00
|
|
|
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
|
2020-12-29 03:34:54 +00:00
|
|
|
compatible string, then adding platform data and U_BOOT_DRVINFO
|
2019-01-16 19:40:18 +00:00
|
|
|
declarations for each node. See of-plat.txt for more information.
|
2017-06-29 09:11:21 +00:00
|
|
|
|
2021-02-03 13:01:13 +00:00
|
|
|
if TPL_OF_PLATDATA
|
|
|
|
|
2020-10-03 17:31:35 +00:00
|
|
|
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;
|
|
|
|
|
2021-02-03 13:01:13 +00:00
|
|
|
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.
|
|
|
|
|
2021-03-15 04:25:15 +00:00
|
|
|
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.
|
|
|
|
|
2021-03-15 04:25:35 +00:00
|
|
|
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.
|
|
|
|
|
2021-03-15 04:25:36 +00:00
|
|
|
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.
|
|
|
|
|
2021-02-03 13:01:13 +00:00
|
|
|
endif
|
|
|
|
|
2022-04-30 06:56:53 +00:00
|
|
|
config VPL_OF_REAL
|
|
|
|
def_bool y
|
2022-06-08 12:24:40 +00:00
|
|
|
depends on VPL
|
2022-04-30 06:56:53 +00:00
|
|
|
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
|
|
|
|
|
2014-09-22 10:59:05 +00:00
|
|
|
endmenu
|