Sandbox unit tests in U-Boot proper load a test device tree to have some
devices to work with. In order to do the same in SPL, we must enable
SPL_OF_REAL. However, we already have SPL_OF_PLATDATA enabled. When
generating platdata from a devicetree, it is expected that we will not need
devicetree access functions (even though SPL_OF_CONTROL is enabled). This
expectation does not hold for sandbox, so allow user control of
SPL_OF_REAL.
There are several places in the tree where conditions involving OF_PLATDATA
or OF_REAL no longer function correctly when both of these options can be
selected at the same time. Adjust these conditions accordingly.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a CONFIG option to deal with this automatically, printing a warning
when U-Boot starts up. This can be useful if the device tree comes from
another project.
We will maintain this through the 2023.07 release, providing 6 months
for people to notice.
Signed-off-by: Simon Glass <sjg@chromium.org>
Version 4:
Acked-by: Michal Simek <michal.simek@amd.com>
Tighten up symbol dependencies in a number of places. Ensure that a VPL
specific option has at least a direct dependency on VPL. In places
where it's clear that we depend on something more specific, use that
dependency instead.
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
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 41f59f6853 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>
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>
U-Boot always needs some sort of a device tree in the build. Some boards
never actually use this, at least in production systems, since a prior
firmware stage sets one up and passes it to U-Boot. At present the only
mechanism to do that is with custom function (OF_BOARD), but future work
will include a standard way of doing this ('standard passage').
It can be confusing to see a device tree emitted from the U-Boot build in
this situation. Add an option to drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
When U-Boot is started from another firmware program, not just a prior
phase of U-Boot, special behaviour is typically used. In particular, the
device tree may come from that prior stage.
At present this is sort-of indicated by OF_BOARD, although the
correlation is not 1:1, since that option simply means that the board has
a custom mechanism for obtaining the device tree. For example, sandbox
defines OF_BOARD. Also the board_fdt_blob_setup() function can in fact
make use of the devicetree in U-Boot if it wishes, as used by
dragonboard410c until very recently.
Add an explicit Kconfig for this situation. Update the OF_BOARD option to
more-accurately reflect what it is doing, e.g. for sandbox.
Drop the docs in the README as it is out of date.
Signed-off-by: Simon Glass <sjg@chromium.org>
This was added as a hack to work around not having an in-tree devicetree.
Now that this is fixed it is not needed.
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
This should not be a separate option from OF_SEPARATE. It is a run-time
option to override the devicetree, even if present.
Move the option out of the choice.
Disable BINMAN_FDT for a few boards which don't actually use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
OF_HOSTFILE is used on sandbox configs only. Although it's pretty
unique and not causing any confusions, we are better of having simpler
config options for the DTB.
So let's replace that with the existing OF_BOARD. U-Boot would then
have only three config options for the DTB origin.
- OF_SEPARATE, build separately from U-Boot
- OF_BOARD, board specific way of providing the DTB
- OF_EMBED embedded in the u-boot binary(should not be used in production
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present U-Boot always builds dtc if CONFIG_OF_CONTROL is defined, even
when DTC is provided. The built dtc is not actually used, so this is a
waste of time.
Update the Makefile logic to build dtc only if one is not provided to the
build with the DTC variable. Add documentation to explain this.
This saves about 3.5 seconds of elapsed time on a clean build of
sandbox_spl for me.
Signed-off-by: Simon Glass <sjg@chromium.org>
The previous patches removed OF_PRIOR_STAGE from the last consumers of the
Kconfig option. Cleanup any references to it in documentation, code and
configuration options.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
At some point back in 2018 prior_stage_fdt_address and OF_PRIOR_STAGE got
introduced, in order to support a DTB handed over by an earlier stage boo
loader. However we have another option in the Kconfig (OF_BOARD) which has
identical semantics.
On RISC-V some of the boards pick up the DTB from a1 and copy it in their
private gd_t. Apart from that they copy it to prior_stage_fdt_address, if
the Kconfig option is selected, which is unnecessary.
So let's switch the config option for those boards to OF_BOARD and define
the required board_fdt_blob_setup() for them.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
The condition to indicate whether there is a runtime devicetree available
is OF_CONTROL && !OF_PLATDATA. This is a bit unweidly and is repeated in
a lot of places.
Add a new OF_REAL Kconfig which provides this information directly.
Note: This is similar in effect to LIBFDT. We might consider dropping
LIBFDT and using this instead, but this is left for now as we also have
OF_LIBFDT_OVERLAY which it would not make sense to change.
Signed-off-by: Simon Glass <sjg@chromium.org>
For scenarios like OF_BOARD or OF_PRIOR_STAGE, no device tree blob is
provided in the U-Boot build phase hence the binman node information
is not available. In order to support such use case, a new Kconfig
option BINMAN_STANDALONE_FDT is introduced, to tell the build system
that a device tree blob containing binman node is explicitly required
when using binman to package U-Boot.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present when driver model needs to change a device it simply updates
the struct udevice structure. But with of-platdata-inst most of the fields
are not modified at runtime. In fact, typically only the flags need to
change.
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.
Create a new udevice_rt table, similar to the existing driver_rt. For now
it just holds the flags, although they are not used in this patch.
Add a new Kconfig for the driver_rt data, since this is not needed when
of-platdata-inst is used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Some systems (e.g. x86 APL) run SPL from read-only memory. The device
instances created by dtoc are therefore not writeable. To make things work
we would need to copy the devices to read/write memory.
To avoid this, add an option to use a separate runtime struct for devices,
just as is done for drivers. This can be used to hold information that
changes at runtime, avoiding the need for a copy.
Also add a Kconfig option for read-only SPL, which selects this feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
With OF_PLATDATA_INST devices are bound at build time. We should not need
binding of devices at runtime in most cases. However it is inflexible to
absolutely prohibit it, so add an option to control this.
Update the driver model core so that it does not bind devices. Update
device_bind() to return an error if called.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add Kconfig options to support build-time device instantiation. When
fully implemented, this will allow dtoc to create U-Boot devices (i.e.
struct udevice records) at build time, thus reducing code space in
SPL.
For now this defaults to off, but will be enabled when the rest of
the implementation is in place.
Signed-off-by: Simon Glass <sjg@chromium.org>
lib/of_live.c references the following 2 ofnode APIs:
of_alias_scan() and of_get_property().
These APIs get built only when DM is on. Fix the dependency then.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current macro is a misnomer since it does not declare a device
directly. Instead, it declares driver_info record which U-Boot uses at
runtime to create a device.
The distinction seems somewhat minor most of the time, but is becomes
quite confusing when we actually want to declare a device, with
of-platdata. We are left trying to distinguish between a device which
isn't actually device, and a device that is (perhaps an 'instance'?)
It seems better to rename this macro to describe what it actually is. The
macros is not widely used, since boards should use devicetree to declare
devices.
Rename it to U_BOOT_DRVINFO(), which indicates clearly that this is
declaring a new driver_info record, not a device.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present of-platdata does not provide parent information. But this is
useful for I2C devices, for example, since it allows them to determine
which bus they are on.
Add support for setting the parent correctly, by storing the parent
driver_info index in dtoc and reading this in lists_bind_drivers(). This
needs multiple passes since we must process children after their parents
already have been bound.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present MKIMAGE_DTC_PATH is in the devicetree menu but not within
'devicetree control' since it does not relate to that. As a result it
shows up in the top menu.
It actually relates to the mkimage tool, so create a new tools menu for it
and move it there.
Signed-off-by: Simon Glass <sjg@chromium.org>
This can be used for device tree size reduction similar as
CONFIG_OF_SPL_REMOVE_PROPS option. Some boards must pass the
built-in DTB unchanged to the kernel, thus we may not cut it
down unconditionally. Therefore enable the property removal
list option only if CONFIG_OF_DTB_PROPS_REMOVE is selected.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Some features implicitly depended on MALLOC_F and OF_LIBFDT and would
fail at link-time if these features were not enabled.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
If u-boot.img is a FIT image, CONFIG_OF_OVERLAY_LIST can be used to add
DT overlays to u-boot.img.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This choice is not about SPL for which we have a separate choice.
Fixes: 95f4bbd581 ("lib: fdt: Allow LZO and GZIP DT compression in U-Boot")
Cc: Marek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
As initially this feature was implemented as a negative CONFIG and
later it was redesigned to be positive the help text should be
updated to reflect this change.
This commit updates the help text to match the current implementation.
Signed-off-by: Walter Lozano <wlozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
interrupt-parent property is removed already that's why there is no
reason to keep interrupts property if parent doesn't exist.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add required Kconfig symbols, Makefile bits and macro fixes in a
few places to support LZO and DT compression in U-Boot. This can
save a lot of space with multi-DTB fitImages.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Improve some things in the documentation of OF_PLATDATA that I found
while porting socfgpa_gen5 to it.
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Remove additional trailing whitespaces in prompt reported by kconfiglib:
warning: DM_PMIC_SANDBOX (defined at drivers/power/pmic/Kconfig:133) has
leading or trailing whitespace in its prompt
warning: <choice> (defined at dts/Kconfig:204) has leading or trailing
whitespace in its prompt
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Felix Brack <fb@ltec.ch>
Add support for loading U-Boot on the Broadcom 7445 SoC. This port
assumes Broadcom's BOLT bootloader is acting as the second stage
bootloader, and U-Boot is acting as the third stage bootloader, loaded
as an ELF program by BOLT.
Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org>
Cc: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Currently, pylibfdt is always compiled if swig is installed on your
machine. It is really annoying because most of targets (excepts
x86, sunxi, rockchip) do not use dtoc or binman.
"checkbinman" and "checkdtoc" are wrong. It is odd that the final
build stage checks if we have built necessary tools. If your platform
depends on dtoc/binman, you must be able to build pylibfdt. If swig
is not installed, it should fail immediately.
I added PYLIBFDT, DTOC, BINMAN entries to Kconfig. They should be
property select:ed by platforms that need them. Kbuild will descend
into scripts/dtc/pylibfdt/ only when CONFIG_PYLIBFDT is enabled.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
u-boot can be embedded within a FIT image with multiple DTBs. It then
selects at run-time which one is best suited for the platform.
Use the same principle here for the SPL: put the DTBs in a FIT image,
compress it (LZO, GZIP, or no compression) and append it at the end of the
SPL.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
[trini: Move default y of SPL_MULTI_DTB_FIT_DYN_ALLOC to it being the
default choice if SYS_MALLOC_F, drop spl.h include from lib/fdtdec.c
it's unused.]
Signed-off-by Tom Rini <trini@konsulko.com>
CONFIG_FIT_EMBED might be confused with CONFIG_OF_EMBED, rename it
MULTI_DTB_FIT as it is able to get a DTB from a FIT image containing
multiple DTBs. Also move the option to the Kconfig dedicated to the DTS
options and create a README for this feature.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In some cases, such as FreeBSD, the path to an alternative dtc needs to
be used. Rather than override the one given in the Makefile on the
command line, make this part of the build configuration.
Signed-off-by: Tom Rini <trini@konsulko.com>
This makes us act like the Linux Kernel does and allow for dtc to be
provided externally but otherwise we use the version of dtc that is
included in the sources. This in turn means that we can drop the
checkdtc logic. We select DTC in the cases where we will need the dtc
tool provided.
Signed-off-by: Tom Rini <trini@konsulko.com>
For the RK3368, we want to use OF_PLATDATA in TPL, but full OF_CONTROL
in SPL: this requires the introduction of a new family of
configuration options to decouple SPL_OF_CONTROL and SPL_OF_PLATDATA
from TPL.
Consequently, Makefile.spl needs to be adjusted to test for these
configuration items through the $(SPL_TPL_) macro instead of
hard-coding the SPL variant.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
OF_LIST will be useable by SPL and U-boot. Therefore, update its
dependency to allow it to be enable by either SPL or U-boot specific
config option.
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Add a Kconfig option to enable a live device tree, built at run time from
the flat tree. Also add structure definitions and a root node.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some boards like the Raspberry Pi the initial bootloader will pass
a DT to the kernel. When using U-Boot as such kernel, the board code in
U-Boot should be able to provide U-Boot with this, already assembled
device tree blob.
This patch introduces a new config option CONFIG_OF_BOARD to use instead
of CONFIG_OF_EMBED or CONFIG_OF_SEPARATE which will initialize the DT
from a board-specific funtion instead of bundling one with U-Boot or as
a separated file. This allows boards like the Raspberry Pi to reuse the
device tree passed from the bootcode.bin and start.elf firmware
files, including the run-time selected device tree overlays.
Signed-off-by: Alex Deymo <deymo@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This patch replaces SPL_PINCTRL_FULL with SPL_PINCNTRL. It is to avoid removal
of pin control properties in case of SPL_PINCTRL. No impact in case of
SPL_PINCTRL_FULL as it depends on SPL_PINCTRL.
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
