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(+)
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
(Trim address list)
Hi Bjorn, AngeloGioacchino,
On Tue, Apr 28, 2026 at 01:06:52PM -0700, Brian Norris wrote:
...
> 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.
...
> 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
Patch 1 and 2 (Rockchip) and 3 and 6 (Nvidia) are applied to linux-next.
Patch 4 is obsolete / unnecessary. That leaves patch 5 (Mediatek) and 7
(Qualcomm).
Bjorn (Qualcomm) and AngeloGioacchino (Mediatek), any thoughts? I can
resend them separately if that helps somehow.
Regards,
Brian
> 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. I can confirm that Nyan was the first Arm device shipping with depthcharge. Note that the Exynos devices are all older and shipped with an old fork of U-Boot that probably handled this very differently (I believe they had `/firmware/chromeos` but not `/firmware/coreboot`, so they wouldn't have had a `reg` node and should need no `ranges`).
On Tue, Apr 28, 2026 at 02:43:21PM -0700, Julius Werner wrote:
> > 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.
>
> I can confirm that Nyan was the first Arm device shipping with
> depthcharge. Note that the Exynos devices are all older and shipped
> with an old fork of U-Boot that probably handled this very differently
> (I believe they had `/firmware/chromeos` but not `/firmware/coreboot`,
> so they wouldn't have had a `reg` node and should need no `ranges`).
OK, so that makes patch 4 unnecessary:
[PATCH 4/7] ARM: dts: samsung: Add #{address,size}-cells to Chromium-based /firmware
If I respin this, I can drop it. Or if it otherwise looks good,
presumably folks can just skip patch 4.
Thanks,
Brian
On Tue, 28 Apr 2026 13:06:52 -0700, Brian Norris wrote:
> 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
>
> [...]
Applied, thanks!
[1/7] arm64: dts: rockchip: Add #{address,size}-cells to Chromium-based /firmware
commit: 0b74f1a037672980c477bbe6b3848fb5341eb4f1
[2/7] ARM: dts: rockchip: Add #{address,size}-cells to Chromium-based /firmware
commit: 98461edf564a35ee00a97a64f5463eaece586546
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
From: Thierry Reding <treding@nvidia.com>
On Tue, 28 Apr 2026 13:06:52 -0700, Brian Norris wrote:
> 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
>
> [...]
Applied, thanks!
[3/7] ARM: dts: nvidia: Add #{address,size}-cells to Chromium-based /firmware
commit: e6d097f575338738ba597b1d836e7fe655babd7c
Best regards,
--
Thierry Reding <treding@nvidia.com>
© 2016 - 2026 Red Hat, Inc.