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>

Make it more obvious what .dts file was expected by the build system.

When adding support for a new board, I kept getting this error message,
assuming I passed a wrong DEVICE_TREE parameter.

However, what was really the mistake was that the entry in
`arch/arm/dts/Makefile` was missing, and u-boot didn't like not being
able to find the .dtb file that should have been produced.

Simply logging the expected .dtb file name should make it easier to spot
such mistakes.

Signed-off-by: Florian Klink <flokli@flokli.de>

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>

Use the SPL_NAME variable to simplify the rules. Drop the SPL targets
clean-files since the SPL and TPL dts/ directories are removed by
existing rules. Move the SPL rules into a new spl_dtbs to avoid the
complicated $(if) construct.

Also drop unused pieces from the 'targets' variable.

With this, SPL and TPL have separate dtbs which respect the various
u-boot,dm-spl / u-boot,dm-tpl tags.

Signed-off-by: Simon Glass <sjg@chromium.org>

Rather than putting these in the top-level dts/ directory (which is
intended for U-Boot proper), put them in the correct subdirectory for
SPL (either spl/ or tpl/). This is where other SPL targets are kept,
so this is more consistent.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present both SPL and TPL use the same devicetree binary. While there
is logic to run fdtgrep separately on each one, it does not actually
happen.

Add a new TPL rule and use that instead. Make this rule conditional on
there actually being a TPL. Do the same for SPL for consistency.

Note that the SPL and TPL dtbs are build by a Makefule rule used for
U-Boot proper. This is the 'dtbs' target in dts/Makefile. So the check
for CONFIG_TPL_BUILD in cmd_fdtgrep never actually works at present.

We don't support CONFIG_OF_EMBED for TPL at present.

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>