Implement ofnode_options phandle helper to get an ofnode from a phandle
option in /options/u-boot.
This helper can be useful since new DT yaml usually require to link a
phandle of a node instead of referencing it by name or other indirect
way.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Implement ofnode/tree_parse_phandle() helper as an equivalent of
of_parse_phandle to handle simple single value phandle.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Implement oftree variant of parse_phandle OPs.
There is currently a very hidden and laten BUG with parse_phandle OPs
that doesn't permit the support of multiple DTS in a system. One usage
example if sandbox with the usage of other.dts
The BUG is only present on live scenario where of_... OPs are used and
it's not present when fdt... OPs are used.
This is caused by an assumption made in __of_parse_phandle_with_args,
with the of_find_node_by_phandle call that pass the first arg as NULL.
This makes of_find_node_by_phandle use the default root node of the
system and doesn't permit the usage of alternative tree. This is correct
for normal system and also for the linux kernel where it's assumed a
single device tree.
It's problematic if other device tree needs to be used.
To fix this, introduce __of_root_parse_phandle_with_args to define a
root device tree for of_find_node_by_phandle.
Introduce all the variant OPs for this and in ofnode, the oftree OPs
following how it's done for other OPs with similar task.
For FDT scenario, ofnode_from_fdtdec_phandle_args is reworked to accept
a new variable, node and noffset_to_ofnode is used instead of
offset_to_ofnode. This is required to support multiple FDB blob to
calculate the correct of_offset of the ofnode.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
People complained that enabling (SPL_)DM_WARN was now totally unusable
due to the amount of messages printed on the console.
Let's downgrade the log level of some messages that are clearly not on
the error path.
Note that there's one pr_debug in there, because it is followed by
pr_cont so it made sense to reuse the same family of functions.
Reported-by: Alexander Dahl <ada@thorsis.com>
Fixes: 6afdb15851 ("dm: core: migrate debug() messages to use dm_warn")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
Implement ofnode_options helpers to read options in /options/u-boot to
adapt to the new way to declare options as described in [1].
[1] dtschema/schemas/options/u-boot.yaml
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Until a live tree is used in U-Boot proper after relocation, use of
ofnode_get_parent() will trigger a call to the very expensive
fdt_parent_offset() as detailed by the function documentation:
NOTE: This function is expensive, as it must scan the device tree
structure from the start to nodeoffset, *twice*.
Re-use the returned value from a single call instead of having to make
multiple calls for same node.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Simon Glass <sjg@chromium.org>
Prior to that, seeing the debug() messages required to enable DM_DEBUG
which defines DEBUG (and then _DEBUG) which in turn makes failing
assert() calls reset U-Boot which isn't necessarily what is desired.
Instead, let's migrate to dm_warn which is using log_debug when unset or
log_warn when set.
While at it, reword the DM_DEBUG symbol in Kconfig to explain what it
now actually does.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
outp always point to an unsigned type in ofnode_read_u* functions but
the format specifier is currently always using signed type.
This is an issue since the signed type can only contain half of the
unsigned type values above 0.
However, this now breaks another usecase. Indeed,
ofnode_read_s32_default is actually passing an s32 but it'll be printed
as a u32 instead. But since the function is called u32, it makes more
sense to have it print an unsigned value.
This was discovered because arm,smc-id = <0x82000010>; on RK3588S is
above the max signed value and therefore would return a negative signed
decimal value instead of its proper unsigned one.
Fixes: fa12dfa08a ("dm: core: support reading a single indexed u64 value")
Fixes: 4bb7075c83 ("dm: core: support reading a single indexed u32 value")
Fixes: 7e5196c409 ("dm: core: Add ofnode function to read a 64-bit int")
Fixes: 9e51204527 ("dm: core: Add operations on device tree references")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Check the header before starting to use it, since this could provide
very confusing later, when ofnode calls start to fail.
Signed-off-by: Simon Glass <sjg@chromium.org>
The baudrate configured in .config is taken by default by serial. If
change of baudrate is required then the .config needs to changed and
u-boot recompilation is required or the u-boot environment needs to be
updated.
To avoid this, support is added to fetch the baudrate directly from the
device tree file and update.
The serial, prints the log with the configured baudrate in the dtb.
The commit c4df0f6f31 ("arm: mvebu: Espressobin: Set default value for
$fdtfile env variable") is taken as reference for changing the default
environment variable.
The default environment stores the default baudrate value, When default
baudrate and dtb baudrate are not same glitches are seen on the serial.
So, the environment also needs to be updated with the dtb baudrate to
avoid the glitches on the serial.
Also add test to cover this new function.
Signed-off-by: Algapally Santosh Sagar <santoshsagar.algapally@amd.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20230921112043.3144726-3-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The PCI helpers read only the base address for a PCI region. In some cases
the size is needed as well, e.g. to pass along to a driver which needs to
know the size of its register area.
Update the functions to allow the size to be returned. For serial, record
the information and provided it with the serial_info() call.
A limitation still exists in that the size is not available when OF_LIVE
is enabled, so take account of that in the tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for writing a single 64-bit value into a property.
Repurpose the existing tests to handle this case too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add functions to write a boolean property. This involves deleting it if
the value is false.
Add a new ofnode_has_property() as well. Add a comment about the behaviour
of of_read_property() when the property value is empty.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a way to flatten a devicetree into binary form. For livetree this
involves generating the devicetree using fdt_property() and other calls.
For flattree it simply involves providing the buffer containing the tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a function to copy a node to another place under a new name. This is
useful at least for testing, since copying a test node with existing
properties is easier than writing the code to generate it all afresh.
Signed-off-by: Simon Glass <sjg@chromium.org>
Nodes with bootph-pre-sram/ram props are bound in multiple phases:
1. At TPL (bootph-pre-sram) or SPL (bootph-pre-ram) phase
2. At U-Boot proper pre-relocation phase
3. At U-Boot proper normal phase
However the binding and U-Boot Driver Model documentation indicate that
only nodes marked with bootph-all or bootph-some-ram should be bound in
the U-Boot proper pre-relocation phase.
Change ofnode_pre_reloc to report a node with bootph-pre-ram/sram prop
with a pre-reloc status only after U-Boot proper pre-relocation phase.
Also update the ofnode_pre_reloc documentation to closer reflect the
binding and driver model documentation.
This changes behavior of what nodes are bound in the U-Boot proper
pre-relocation phase. Change to bootph-all or add bootph-some-ram prop
to restore prior behavior.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Simon Glass <sjg@chromium.org>
ofnode_read_bootscript_flash() reads bootscript address from
/options/u-boot DT node. bootscr-flash-offset and bootscr-flash-size
properties are read and values are filled. When bootscr-flash-size is not
defined, bootscr-flash-offset property is unusable that's why cleaned.
Both of these properties should be defined to function properly.
Also add test to cover this new function.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/08a3e6c09cce13287c69ad370e409e7f1766b406.1693465465.git.michal.simek@amd.com
ofnode_read_bootscript_address() reads bootscript address from
/options/u-boot DT node. bootscr-address or bootscr-ram-offset properties
are read and values are filled. bootscr-address has higher priority than
bootscr-ram-offset and the only one should be described in DT.
Also add test to cover this new function.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/23be3838502efef61803c90ef6e8b32bbd6ede41.1693465140.git.michal.simek@amd.com
Add helper function to allow reading a single indexed u64 value from a
device-tree property containing multiple u64 values, that is an array of
u64's.
Co-developed-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/08043c8d204d0068f04c27de86afe78c75c50b69.1692956263.git.michal.simek@amd.com
The "oftree_count" is the number of entries which have been set in
the oftree_list[] array. If all the entries have been initialized then
this off by one would result in reading one element beyond the end
of the array.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present livetree can only be used for the control FDT. It is useful
to be able to use the ofnode API for other FDTs, e.g. those used by
the upcoming configuration editor.
We already have most of the support present, and tests can be marked with
the UT_TESTF_OTHER_FDT flag to use another FDT as a special case. But
with this change, the functionality becomes more generally available.
Plumb in the require support.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present there are various restrictions on the use of livetree:
- It is only available once the tree is unflattened, i.e. after relocation
- It is designed to be used with the control FDT
- It can (in principle) be used with other FDTs, but only if they are
unflattened first; this is not supported
Add a few checks to make sure that any tree that is created is actually
valid. Otherwise it can be confusing when nodes and properties cannot
actually be accessed.
Signed-off-by: Simon Glass <sjg@chromium.org>
In case where a single timing resolution is implemented in the
device-tree, the property is named "panel-timing", as specify
in Linux kernel binding file:
Documentation/devicetree/bindings/display/panel/panel-common.yaml
# Display Timings
panel-timing:
description:
Most display panels are restricted to a single resolution and
require specific display timings. The panel-timing subnode expresses those
timings.
$ref: panel-timing.yaml#
display-timings:
description:
Some display panels support several resolutions with different timings.
The display-timings bindings supports specifying several timings and
optionally specifying which is the native mode.
$ref: display-timings.yaml#
Fixes: 0347cc7732 ("drivers: core: ofnode: Add panel timing decode.")
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
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>
ofnode_decode_display_timing supports reading timing parameters from
subnode of display-timings node, for displays supporting multiple
resolution, in case if a display supports single resolution, it fails
reading directly from display-timings node, to support it
ofnode_decode_panel_timing is added.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use dot instead of comma. The fix doesn't affect anything but it is good to
be aligned with used pattern. The first is used only for string size
calculation and the second change is in the comment.
Fixes: db681d4929 ("net: phy: Add new read ethernet phy id function")
Signed-off-by: Michal Simek <michal.simek@amd.com>
At present ofnode_write_prop() is inconsistent between livetree and
flattree, in that livetree requires the caller to ensure the property
value is stable (e.g. in rodata or allocated) but flattree does not, since
it makes a copy.
This makes the API call a bit painful to use, since the caller must do
different things depending on OF_LIVE.
Add a new 'copy' argument which tells the function to make a copy if
needed. Add some tests to cover this behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
We need to be able to look up phandles in any FDT, not just the control
FDT. Use the 'other' FDT to test this, with a helper function which gets
this as an oftree that can then we used as needed.
Add a few more tests and some comments at the top of the file, to explain
what is going on.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the logic to redirect requests for the device tree through a function
which can look up the tree ID. This works by using the top bits of
ofnode.of_offset to encode a tree.
It is assumed that there will only be a few device trees used at runtime,
typically the control FDT (always tree ID 0) and possibly a separate FDT
to be passed the OS.
The maximum number of device trees supported at runtime is 8, with this
implementation. That would use bits 30:28 of the node-offset value,
meaning that the positive offset range is limited to bits 27:0, versus
30:1 with this feature disabled. That still allows a device tree of up
to 256MB, which should be enough for most FITs. Larger ones can be
supported by using external data with the FIT, or by enabling OF_LIVE.
Update the documentation a little and fix up the comment for
ofnode_valid().
Signed-off-by: Simon Glass <sjg@chromium.org>
This function turns out to be a little confusing since it looks up a path
and also registers the tree. Split it into two, one that gets the root
node and one that looks up a path, so the purpose is clear.
Registering the tree will happen in a function to be added in a later
patch, called oftree_from_fdt().
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases we want to obtain an ofnode in the same tree as a different
ofnode, such as when looking up a subnode. At present this is trivial,
since there is only one tree. When there are multiple trees, this
implementation will change.
Also move the ofnode_to_offset() function up higher in the header file,
since we will need to provide a different implementation with multiple
trees.
Signed-off-by: Simon Glass <sjg@chromium.org>
When we have multiple trees, the ofnode logic needs to be told which one
to use. Create a new function which takes an oftree argument, along with
a helper to obtain the FDT pointer from an oftree.
Signed-off-by: Simon Glass <sjg@chromium.org>
The flat device tree is assumed to be the control FDT but this is not
always the case. Update the ofnode implementation to obtain the node via
an function call so we can eventually add support for selecting different
trees.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current tests do not cover all the behaviour. Add some more.
Tidy up a few inconsistencies between livetree and flattree which come to
light with these tests. Also drop the -ENODATA error since it is never
actually returned.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current implementation creates a 'name' value for every node. This
is not needed for the latest device tree format, which includes a name in
the node header.
Adjust the code to point the name at the node header instead.
Also simplify ofnode_get_name(), now that we can rely on it to set the
name correctly. Update the comment to make it clear what name the root
node has.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current name is quite unwieldy. Change it to use an ofprop_ prefix
and shorten it. Fix the return-value comment while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
