From: Brian Norris <briannorris@chromium.org>
To: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Thierry Reding <thierry.reding@kernel.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
Heiko Stuebner <heiko@sntech.de>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>
Cc: devicetree@vger.kernel.org, Doug Anderson <dianders@chromium.org>,
linux-arm-kernel@lists.infradead.org,
Tzung-Bi Shih <tzungbi@kernel.org>,
chrome-platform@lists.linux.dev,
Brian Norris <briannorris@chromium.org>,
linux-rockchip@lists.infradead.org,
Julius Werner <jwerner@chromium.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
cros-qcom-dts-watchers@chromium.org,
linux-arm-msm@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/7] dts: Add /firmware/#{address,size}-cells to Chromium-based DTs
Date: Tue, 28 Apr 2026 13:06:52 -0700 [thread overview]
Message-ID: <20260428200712.2660635-1-briannorris@chromium.org> (raw)
Chromium/Depthcharge bootloaders may dynamically add a few device nodes
to a system's DTB under a /firmware node. A typical DT looks something
like the following:
## From a RK3399 Gru/Kevin Chromebook:
# find /sys/firmware/devicetree/base/firmware
/sys/firmware/devicetree/base/firmware
/sys/firmware/devicetree/base/firmware/coreboot
/sys/firmware/devicetree/base/firmware/coreboot/ram-code
/sys/firmware/devicetree/base/firmware/coreboot/compatible
/sys/firmware/devicetree/base/firmware/coreboot/board-id
/sys/firmware/devicetree/base/firmware/coreboot/reg
/sys/firmware/devicetree/base/firmware/coreboot/name
/sys/firmware/devicetree/base/firmware/chromeos
/sys/firmware/devicetree/base/firmware/chromeos/readonly-firmware-version
/sys/firmware/devicetree/base/firmware/chromeos/active-ec-firmware
/sys/firmware/devicetree/base/firmware/chromeos/firmware-version
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-storage
/sys/firmware/devicetree/base/firmware/chromeos/vboot-shared-data
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-size
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-offset
/sys/firmware/devicetree/base/firmware/chromeos/hardware-id
/sys/firmware/devicetree/base/firmware/chromeos/compatible
/sys/firmware/devicetree/base/firmware/chromeos/firmware-type
/sys/firmware/devicetree/base/firmware/chromeos/fmap-offset
/sys/firmware/devicetree/base/firmware/chromeos/name
/sys/firmware/devicetree/base/firmware/ranges
/sys/firmware/devicetree/base/firmware/name
The /firmware node has an empty 'ranges', but does not have
address/size-cells.
Commit 6e5773d52f4a ("of/address: Fix WARN when attempting translating
non-translatable addresses") started requiring #address-cells for a
device's parent if we want to use the reg resource in a device node.
This leads to errors like the following:
[ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
This series adds appropriate #{address,size}-cells to the device trees
used on Arm Chromebooks to work around the problem.
Note that Google provides bootloader updates for some devices that add
{address,size}-cells [1], but these are only delivered via Google OS
updates. Not all users receive Google software updates, and even if they
do, not all devices still receive bootloader updates from Google.
This problem was first noticed in OpenWrt, where some Chromium-based
routers ran into the same issue:
https://github.com/openwrt/openwrt/issues/21243
Relevant OpenWrt fixes: https://github.com/openwrt/openwrt/pull/22951
There is also discussion at [2].
I've currently only tested:
1) the aforementioned OpenWrt routers (with non-upstream DTS/DTB)
2) RK3399 Gru/Kevin Chromebook (patch 1)
3) Qualcomm SC7280 Herobrine (patch 7)
I assume the others should follow the same pattern. I don't know if I've
covered every relevant Depthcharge-using device, but I've made a good
attempt to identify them all.
I reviewed Depthcharge code history and found that this problematic
bootloader behavior dates back to at least 2014, with the Tegra/Nyan
device. Older devices may have similar DTB structures, but I'm not sure
if they have the same address-cells problems. In any case, these changes
shouldn't hurt even if a device was not affected.
Brian
[1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/
https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
#size-cells for firmware node")
[2] [regression] of: mis-parsing Depthcharge's /firmware
https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
Brian Norris (7):
arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based
/firmware
ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based
/firmware
ARM: dts: nvidia: Add #{address,size}-cells to Chromium-based
/firmware
ARM: dts: samsung: Add #{address,size}-cells to Chromium-based
/firmware
arm64: dts: mediatek: Add #{address,size}-cells to Chromium-based
/firmware
arm64: dts: nvidia: Add #{address,size}-cells to Chromium-based
/firmware
arm64: dts: qcom: Add #{address,size}-cells to Chromium-based
/firmware
arch/arm/boot/dts/nvidia/tegra124-nyan.dtsi | 5 +++++
arch/arm/boot/dts/nvidia/tegra124-venice2.dts | 5 +++++
arch/arm/boot/dts/rockchip/rk3288-veyron.dtsi | 5 +++++
arch/arm/boot/dts/samsung/exynos5250-snow-common.dtsi | 5 +++++
arch/arm/boot/dts/samsung/exynos5250-spring.dts | 5 +++++
arch/arm/boot/dts/samsung/exynos5420-peach-pit.dts | 5 +++++
arch/arm/boot/dts/samsung/exynos5800-peach-pi.dts | 5 +++++
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 5 +++++
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 +++++
arch/arm64/boot/dts/mediatek/mt8186-corsola.dtsi | 5 +++++
arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi | 5 +++++
arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 5 +++++
arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 5 +++++
arch/arm64/boot/dts/nvidia/tegra132-norrin.dts | 5 +++++
arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 5 +++++
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 5 +++++
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 5 +++++
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 5 +++++
18 files changed, 90 insertions(+)
--
2.54.0.545.g6539524ca2-goog
next reply other threads:[~2026-04-28 20:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 20:06 Brian Norris [this message]
2026-04-28 20:06 ` [PATCH 1/7] arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based /firmware Brian Norris
2026-04-29 4:17 ` Chen-Yu Tsai
2026-04-30 23:54 ` Doug Anderson
2026-04-28 20:06 ` [PATCH 2/7] ARM: " Brian Norris
2026-04-30 23:54 ` Doug Anderson
2026-04-28 20:06 ` [PATCH 3/7] ARM: dts: nvidia: " Brian Norris
2026-04-30 23:54 ` Doug Anderson
2026-04-28 20:06 ` [PATCH 4/7] ARM: dts: samsung: " Brian Norris
2026-04-30 23:54 ` Doug Anderson
2026-04-28 20:06 ` [PATCH 5/7] arm64: dts: mediatek: " Brian Norris
2026-04-29 4:17 ` Chen-Yu Tsai
2026-04-30 23:54 ` Doug Anderson
2026-04-28 20:06 ` [PATCH 6/7] arm64: dts: nvidia: " Brian Norris
2026-04-30 23:54 ` Doug Anderson
2026-04-28 20:06 ` [PATCH 7/7] arm64: dts: qcom: " Brian Norris
2026-04-30 23:54 ` Doug Anderson
2026-04-28 21:43 ` [PATCH 0/7] dts: Add /firmware/#{address,size}-cells to Chromium-based DTs Julius Werner
2026-04-28 22:15 ` Brian Norris
2026-05-05 18:19 ` (subset) " Heiko Stuebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260428200712.2660635-1-briannorris@chromium.org \
--to=briannorris@chromium.org \
--cc=alim.akhtar@samsung.com \
--cc=andersson@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chrome-platform@lists.linux.dev \
--cc=conor+dt@kernel.org \
--cc=cros-qcom-dts-watchers@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=heiko@sntech.de \
--cc=jonathanh@nvidia.com \
--cc=jwerner@chromium.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=robh@kernel.org \
--cc=thierry.reding@kernel.org \
--cc=tzungbi@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox