In dt_copy_subtree(), the device_tree_node copying
*dst_node = *src_node;
doesn't work correctly for circular linked lists [1], because the 'next'
pointer of the last element isn't modified to point to the dst head.
As the only public caller of dt_copy_subtree() is dt_apply_overlay(),
and the dt_apply_overlay() function comment already explicitly disallows
'overlay' accesses after the call, fix the problem by utilizing
list_move() for copying device tree node properties and children.
Also add a new test case test_dt_apply_overlay.
[1] commit 23c41622a9 ("commonlib/list: Change to circular list")
BUG=b:434080284
TEST=emerge-rauru coreboot libpayload
BRANCH=none
Change-Id: I166ab74c9de67330d52f94e92b5d7ce5ddefa82b
Signed-off-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/91558
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Jakub "Kuba" Czapiga <czapiga@google.com>
Introduce a centralized helper function, dt_add_reserved_memory_region,
to simplify the creation of sub-nodes under /reserved-memory.
Currently, various features (such as pKVM, ramoops, and platform-
specific firmware reservations) manually handle the creation of
reserved memory nodes. This involves repetitive logic for:
- Navigating or creating the /reserved-memory parent path.
- Calculating cell sizes for 'reg' properties.
- Manually adding 'no-map' or 'compatible' properties.
This helper abstracts those steps into a single call, reducing
boilerplate and the risk of cell-size mismatches across the codebase.
The function handles:
- Node creation if the path doesn't exist.
- Optional 'compatible' string assignment.
- Automatic 'reg' property generation using appropriate address/size
cells.
- Optional 'no-map' property assignment via a boolean flag.
Change-Id: Ie58f5fdcfd1863b41c177b63ed9fc25d6d220e3a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90713
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The current code doesn't make much sense. The offset created by the
skipping of NOP tokens is just ignored.
Reorder the lines to skip the NOP tokens first.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I860a57e4a773b634149e84271b8322d78ac20e32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add dt_is_overlay() API to check whether the input devicetree is
actually an overlay DT. Payload will use this API when parsing an input
image which is a collection of base and overlay devicetree blobs.
BUG=b:394980221
TEST=Build firmware image for Rauru/Hylia and boot to OS. Ensure that
the API correctly identifies the base and overlay DTs.
Change-Id: I2fc54e3d9e63ebc993c8ce6a7d4a7224a9251497
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90028
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`dt_add_reg_prop` and the newly introduced `dt_add_iommu_addr_prop`
share identical logic for building the binary data buffer, differing
only in the property name written to the Device Tree. Therefore,
refactor the shared logic into a new static helper function,
`dt_add_addr_and_size_prop`.
The existing `dt_add_reg_prop` is converted to a wrapper around this new
helper.
`dt_add_iommu_addr_prop` is introduced as a separate wrapper to
specifically add the `iommu-addresses` property. This property defines
reserved IOVA ranges or identity-mapped regions, such as a display
framebuffer configured by the bootloader. It is typically utilized
within the `reserved-memory` subsystem.
BUG=b:435289727
TEST=The below translation fault does not occur.
[ 0.171028] arm-smmu-v3 30800000.iommu: TBU_id-2-fault_id:0x2000008(0x8), TF read in NORMAL world, iova:0xa3000000, sid:144, ssid:0, ssidv:0, secsidv:0
Change-Id: Icedcce5681a7b659b11b7e7208663bc1d920ce3b
Signed-off-by: Yidi Lin <yidilin@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89152
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the passed `blob` is not a valid FDT, the memory allocated for
`tree` should be freed. Move the allocation after the fdt_is_valid()
check to avoid the problem.
Also remove the unnecessary cast to 'const struct fdt_header *'.
Change-Id: If591172cd511ae2a1ca9c26f2addef8d67fd0b69
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88948
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Follow the recommendation at
https://review.coreboot.org/c/coreboot/+/84796/comment/21f615a2_99a41147/
and implement support for reading integer properties generically, using
their size to determine how much to read. This will be used for reading
`load`, `entry` and perhaps others.
Change-Id: I02d27eb5e23dfbfc1404d209ee8d60968e22bb80
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85643
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
dt_find_node() looks up nodes specified by the `const char **path`
array, without modifying the strings in the array. Therefore, the char
pointers in the array could be changed to const.
Change-Id: I8d330e78d0977bae54996bb622190f6546fcb59f
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87653
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
dt_find_node() calls dt_read_cell_props() for every node it walks, but
this is only actually necessary when the caller is interested in the
`#address-cells` and `#size-cells` values and passed out-parameters to
receive them. Most callers don't actually do that, and we scan through
all properties needlessly on every node. This patch adds a fast path to
skip that.
Change-Id: I114f824a7d88b0bac4a96aca3f7dced459503b02
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85989
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
This patch wraps `dt_find_node()` in a function that initializes the
addr_cells and size_cells values to the defaults provided in the FDT
specification before potentially updating them from found values, so
that we always return the correct result and remove the burden of
correctly initializing them from the caller.
Change-Id: I39ba2c82d3a0d0b39a2ed5eba2420a04fbccb2f7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85988
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
In Flattened Device Trees, there exist special properties called
`#address-cells` and `#size-cells` that determine how large addresses
and sizes in `reg` properties are. According to the FDT specification,
each `reg` node cares about the `...cells` property in the _parent_ of
its node. Our current implementation looks for those properties in the
node it finds and returns, which would presumably be the node with the
`reg` property itself. Therefore, we're returning the wrong `...cells`
values.
This isn't really a problem in practice because we also allow inheriting
these properties from the parent when they don't exist in the child, and
nodes that contain `reg` properties usually don't contain `...cells`
properties themselves (because those properties would be incorrect and
useless there), so we usually just end up falling back to the (correct)
value we inherited from the parent. But it's still better to just fix
the mistake, and if we ever happen to have a situation where the node
containing the `reg` property still has children that require different
`...cells` values as well, it could make a difference. (The fact that
we're inheriting these properties is also technically incorrect
according to the spec, but we're doing that intentionally to match
behavior in the Linux kernel.)
This issue was already correctly implemented in the recently added
fdt_find_node() from commit 33079b8174 ("lib/device_tree: Add some FDT
helper functions"), and this patch also fixes it in the older
dt_find_node().
Change-Id: I323066477a4d4be17225e0915a81ce2ff39c1e40
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85964
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
According to the FDT specification the FDT_END token is supposed to be
the last token in the structure block, not a free-floating token
immediately outside of it. That means we're supposed to count it in
struct_size. It seems that the kernel never cared about this, but some
FDT parsing utilities like `fdtgrep` do.
Change-Id: Icdeadbeefcafed00dbabefeed1337c0debc86836
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85462
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently a warning is printed even if the maximum amount of nodes is
not exceeded.
Remove the warning, since in most cases the maximum amount of nodes
for a given prefix is usually well known. For example the /cpu nodes
always have a maximum of CONFIG_MAX_CPUS.
One may also just want to read the first X amount of nodes matching a
given prefix.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ic1111e8acb72ea1e9159da0d8386f40cbbdbc63f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add a helper function to read the reg property from an unflattened
device tree.
It also factors out the common code into a new function called
`read_reg_prop`.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I7846eb8af390d709b0757262025cb819e9988699
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Now that the device tree code has been made available in libpayload, we
should reintroduce the node and property allocation optimization for
libpayload's memory allocator that was originally dropped when porting
this code from depthcharge to coreboot.
On a Qualcomm SC7180 unflattening a normal ChromeOS kernel device tree,
this saves roughly ~145ms. The total scratch space used is about ~1350
nodes and ~5200 properties, so we leave a little room to grow with the
constants hardcoded here.
Change-Id: I0f4d80a8b750febfb069b32ef47304ccecdc35af
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
