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>
While assigning the sequence number to subsystem instances by reading the
aliases property, only DT nodes names are compared and not the complete
path. This causes a problem when there are two DT nodes with same name but
have different paths.
In arch/arm/dts/k3-am65-main.dtsi there are two USB controllers with the
same device tree node name but different path. When aliases are defined for
these USB controllers then fdtdec_get_alias_seq() fails to pick the correct
instance for a given index.
fdt_path_offset() function is slow and this would effect the U-Boot
startup. To avert the time penalty on all boards, apply this extra check
only when required by using a config option.
Fix it by comparing the phandles of DT nodes after the node names match,
under a config option.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Fix whitespace error in Kconfig:
Signed-off-by: Simon Glass <sjg@chromium.org>
The result of fdt_node_offset_by_phandle is negative for error,
so this patch corrects the check of this result in
fdtdec_parse_phandle_with_args.
This patch allows to have the same behavior with or without OF_LIVE
for the function dev_read_phandle_with_args with cell_name = NULL and
with invalid phandle.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add boolean input argument @no_map to helper function
fdtdec_add_reserved_memory() to add or not "no-map" property
for an added reserved memory node.
Property no-map is used by the Linux kernel to not not map memory
in its static memory mapping. It is needed for example for the|
consistency of system non-cached memory and to prevent speculative
accesses to some firewalled memory.
No functional change. A later change will update to OPTEE library to
add no-map property to OP-TEE reserved memory nodes.
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Repair incorrectly negated condition in the original patch which broke
DT memory node parsing on everything which has more than one DT memory
node, e.g. R-Car3.
In case multiple valid memory nodes are present in the DT, the original
patch would complete parsing cycle for the first memory node, then move
on to the next one, identify it as a valid, and end the parsing. The fix
is to invert the condition, to make the code behave as it did before the
livetree conversion, so it would continue parsing the subsequent memory
nodes as well.
Fixes: c2f0950c33 ("lib: fdt: Convert fdtdes_setup_mem..() to livetree API")
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Tested-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Since commit 86cf1c8285 ("configs: Migrate CONFIG_NR_DRAM_BANKS") &
commit 999a772d9f ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
It makes no sense to still carry code that is guarded with
"#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
all these unreferenced code paths.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Convert fdtdec_setup_mem_size_base(), get_next_memory_node(),
fdtdec_setup_memory_banksize() and fdtdec_setup_mem_size_base_lowest() to
livetree API.
Tested on ZynqMP zcu104 board.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
New function should be called from board dram_init() because it initialized
gd->ram_base/ram_size. It finds the lowest available memory.
On systems with multiple memory nodes finding out the first memory node by
fdtdec_setup_mem_size_base() is not enough because this memory can be above
actual U-Boot VA mapping. Currently only mapping till 39bit is supported
(Full 44bit mapping was removed by commit 7985cdf74b ("arm64: Remove
non-full-va map code")).
If DT starts with the first memory node above 39bit address then system can
be unpredictable.
The function is available only when multiple memory bank support is
enabled.
Calling fdtdec_setup_memory_banksize() from dram_init() is not possible
because fdtdec_setup_memory_banksize() is saving dram information to bd
structure which is placed on stack but not initialized at this time. Also
stack is placed at location setup in dram_init().
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This reverts commit 3ebe09d09a.
There is no user of this split function that's why remove it.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This reverts commit 118f4d4559.
There is no user of this split function that's why remove it.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This reverts commit 3ebe09d09a.
There is no user of this split function that's why remove it.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This reverts commit 118f4d4559.
There is no user of this split function that's why remove it.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The Linux coding style guide (Documentation/process/coding-style.rst)
clearly says:
It's a **mistake** to use typedef for structures and pointers.
Besides, using typedef for structures is annoying when you try to make
headers self-contained.
Let's say you have the following function declaration in a header:
void foo(bd_t *bd);
This is not self-contained since bd_t is not defined.
To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h>
#include <asm/u-boot.h>
void foo(bd_t *bd);
Then, the include direcective pulls in more bloat needlessly.
If you use 'struct bd_info' instead, it is enough to put a forward
declaration as follows:
struct bd_info;
void foo(struct bd_info *bd);
Right, typedef'ing bd_t is a mistake.
I used coccinelle to generate this commit.
The semantic patch that makes this change is as follows:
<smpl>
@@
typedef bd_t;
@@
-bd_t
+struct bd_info
</smpl>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
