Standard passage provides for a bloblist to be passed from one firmware
phase to the next. That can be used to pass the devicetree along as well.
Add an option to support this.
Tests for this will be added as part of the Universal Payload work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
After some header file cleanups to add missing include files, remove
common.h from all files in the lib directory. This primarily means just
dropping the line but in a few cases we need to add in other header
files now.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Now all linker symbols are declared as type char[]. Though we can
reference the address via both the array name 'var' and its address
'&var'. It's better to unify them to avoid confusing developers.
This patch converts all '&var' linker symbol refrences to the most
commonly used format 'var'.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Please pull the second part of the sunxi pull request for this cycle.
Another bunch of patches that replace old-school U-Boot hacks with
proper DM based code, this time for the raw NAND flash driver, and the
USB PHY VBUS detection code. Plus two smaller patches that were sitting
in my inbox for a while.
Gitlab CI passed. In lack of some supported board with NAND flash I
couldn't really test this part, but apparently this was tested by the
reviewer. I briefly ran the branch on some boards with USB-OTG, and
this still worked.
As a first step toward converting this driver to the driver model, use
the ofnode abstraction to replace direct references to the FDT blob.
Using ofnode_read_u32_index removes an extra pair of loops and makes the
allwinner,rb property optional, matching the devicetree binding.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The fdt_path_offset() function is slow since it must scan the tree.
This substantial overhead now applies to all boards.
The original code may not be ideal but it is fit for purpose and is only
needed on a few boards.
Reverting this reduces time to set up driver model by about 30ms.
Before revert:
Accumulated time:
47,170 dm_r
53,237 dm_spl
572,986 dm_f
Accumulated time:
44,598 dm_r
50,347 dm_spl
549,133 dm_f
This reverts commit 26f981f295.
Signed-off-by: Simon Glass <sjg@chromium.org>
If the FDT overlaps with the data region of the image, or with the stack,
it can become corrupted before relocation. Add a check for this, behind a
debug flag, as it can be very confusing and time-consuming to debug.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function uses gd->fdt_blob a lot and cannot be used to check any
other device tree. Use a parameter instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is a bit messy with several #ifdefs. Convert them to use C
for the conditions.
Rewrite the function comment since most of it is stale.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present there is only one device tree used by the ofnode functions,
except for some esoteric use of live tree. In preparation for supporting
more than one, add a way to reset the list of device trees.
For now this does nothing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Asking if the alias we found actually points at the device tree node
we passed in (in the guise of its offset from blob) can be done simply
by asking if the fdt_path_offset() of the alias' path is identical to
offset.
In fact, the current method suffers from the possibility of false
negatives: dtc does not necessarily emit a phandle property for a node
just because it is referenced in /aliases; it only emits a phandle
property for a node if it is referenced in <angle brackets>
somewhere. So if both the node we passed in and the alias node we're
considering don't have phandles, fdt_get_phandle() returns 0 for both.
Since the proper check is so simple, there's no reason to hide that
behind a config option (and if one really wanted that, it should be
called something else because there's no need to involve phandle in
the check).
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Acked-by: Aswath Govindraju <a-govindraju@ti.com>
As removal of nds32 has been ack'd for the Linux kernel, remove support
here as well.
Cc: Rick Chen <rick@andestech.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Rick Chen <rick@andestech.com>
Commit 690af71850 changed this condition
from an explicit
IS_ENABLED(CONFIG_SPL_SEPARATE_BSS)
to
CONFIG_IS_ENABLED(SEPARATE_BSS)
The documentation for CONFIG_IS_ENABLED() in include/linux/kconfig.h
implies that we will get the correct behaviour, but the actual behaviour
differs such that this condition is now always false.
This stopped TPL being able to load the device tree blob at least on the
ROCKPro64 board (RK3399 SoC), since the wrong device tree location was
chosen.
The issues causing this behaviour with CONFIG_IS_ENABLED() are:
1. The documentation implies that CONFIG_SPL_BUILD =>
CONFIG_SPL_<option> is considered before the TPL equivalent.
Actually, the TPL options have higher priority - see definition of
_CONFIG_PREFIX.
2. The documentation implies a fallthrough, eg. if CONFIG_SPL_BUILD is
defined but the CONFIG_SPL_<option> is not, then it will proceed to
check if CONFIG_TPL_BUILD
Actually, if CONFIG_TPL_BUILD is defined, then it stops there
and CONFIG_SPL_BUILD is not considered - see definition of
_CONFIG_PREFIX.
During TPL build, at least for the ROCKPro64, both CONFIG_TPL_BUILD
and CONFIG_SPL_BUILD are defined, but because of the above, only TPL
options are considered. Since there is no CONFIG_TPL_SEPARATE_BSS,
this fails.
Fixes: 690af71850 ("fdt: Correct condition for SEPARATE_BSS")
Signed-off-by: Andrew Abbott <andrew@mirx.dev>
We don't use an appended tree for sandbox and the required symbols are
not present. Add a condition to avoid a build error.
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>
It can be confusing to figure out where the devicetree came from. It seems
important enough to warrant a message during boot. Add information about
the number of devices and uclasses too since it is helpful to have some
idea what is going on with driver model.
Report the devicetree source in bdinfo too.
This looks something like this, with > marking the new line.
U-Boot 2021.10-00190 (Oct 30 2021 - 09:01:29 -0600)
DRAM: 128 MiB
> Core: 42 devices, 11 uclasses, devicetree: passage
Flash: 64 MiB
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this override function is called even when OF_BOARD is not
enabled. This makes it impossible to disable this feature and in fact
makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between
the appended devicetree and one provided by the board's custom function.
A follower patch adds warnings for this scenario, but for now we don't
have a Kconfig that definitively tells us that OF_BOARD should be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function should only be called when OF_CONTROL is enabled. It
fails in fdtdec_prepare_fdt() anyway, since gd->fdt_blob stays as NULL
if OF_CONTROL is not enabled.
Drop this useless check.
Signed-off-by: Simon Glass <sjg@chromium.org>
This logic is a bit convoluted for one function. Move the mulit-FIT part
into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.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>
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>
Reserved memory nodes can have additional flags. Support reading and
writing these flags to ensure that reserved memory nodes can be properly
parsed and emitted.
This converts support for the existing "no-map" flag to avoid extending
the argument list for fdtdec_add_reserved_memory() to excessive length.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The fdtdec_set_carveout() function's parameters are inconsistent with
the parameters passed to fdtdec_add_reserved_memory(). Fix up the order
to make it more consistent.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reserved memory nodes can have a compatible string list to identify the
type of reserved memory that they represent. Support specifying an
optional compatible string list when creating these nodes.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
When retrieving a given carveout for a device, allow callers to query
the name. This helps differentiating between carveouts when there are
more than one.
This is also useful when copying carveouts to help assign a meaningful
name that cannot always be guessed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
In order make it possible to use fdtdec_get_carveout() in loops, return
FDT_ERR_NOTFOUND when the passed-in index exceeds the number of phandles
present in the given property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The current API is outdated as it requires a devicetree pointer.
Move these functions to use the ofnode API and update this globally. Add
some tests while we are here.
Correct the call in exynos_dsim_config_parse_dt() which is obviously
wrong.
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't need this check anymore since when PCI is enabled, driver model
is always used.
Sadly this doesn't work with nds32 for some reason to do with the
toolchain. Add a work-around for that.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is a pain to have to specify the value 10 in each call. Add a new
dectoul() function and update the code to use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a bus driver for this and use it to configure the bus parameters for
the Ethernet interface. Drop the old pre-driver-model code.
Switch over to use driver model for Ethernet.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Today of_address_to_resource() is called only in
ofnode_read_resource() for livetree support and
fdt_get_resource() is called when livetree is not supported.
The fdt_get_resource() doesn't do the address translation
so when it is required, but the address translation is done
by ofnode_read_resource() caller, for example in
drivers/firmware/scmi/smt.c::scmi_dt_get_smt_buffer() {
...
ret = ofnode_read_resource(args.node, 0, &resource);
if (ret)
return ret;
faddr = cpu_to_fdt32(resource.start);
paddr = ofnode_translate_address(args.node, &faddr);
...
The both behavior should be aligned and the address translation
must be called in fdt_get_resource() and removed for each caller.
Fixes: a44810123f ("dm: core: Add dev_read_resource() to read device resources")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
On Rockchip platforms we need this area of code in TPL, but there is no
TPL_SEPARATE_BSS symbol.
This reverts commit 0a2aaab0b6.
Reported-by: Markus Reichl <m.reichl@fivetechno.de>
Reported-by: Jesper Schmitz Mouridsen <jesper@schmitz.computer>
Reported-by: Peter Robinson <pbrobinson@gmail.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
At present prior_stage_fdt_address is declared as phys_addr_t. On
a 32-bit platform where phys_addr_t can be 64-bit, assigning its
value to gd->fdt_blob which is a pointer, can cause warnings.
Cast it to uintptr_t before the assignment.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
This includes information about sandbox which is not relevant for most
boards. Drop it.
Also add the address to help figure out the problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
