Re: [PATCH 4/4] arm64: dts: google: Add initial dts for frankel, blazer, and mustang

[Krzysztof Kozlowski <krzk@kernel.org>]

On 11/11/2025 20:22, Douglas Anderson wrote:
> Add barebones device trees for frankel (Pixel 10), blazer (Pixel 10
> Pro), and mustang (Pixel 10 Pro XL). These device trees are enough to
> boot to a serial prompt using an initramfs.
> 
> Many things can be noted about these device trees:
> 
> 1. They are organized as "dts" files for the main SoC and "dtso"
>    overlays for the boards. There is discussion about this in the
>    bindings patch ("dt-bindings: arm: google: Add bindings for
>    frankel/blazer/mustang").
> 2. They won't boot with the currently shipping bootloader. The current
>    bootloader hardcodes several paths to nodes that it wants to update
>    and considers it a fatal error if it can't find these nodes.
>    Interested parties will need to wait for fixes to land and a new
>    bootloader to be rolled out before attempting to use these.
> 3. They only add one revision (MP1) of each of frankel, blazer, and
>    mustang. With this simple barebones device tree, there doesn't
>    appear to be any difference between the revisions. More revisions
>    will be added as needed in the future. The heuristics in the
>    bootloader will pick the MP1 device tree if there are not any
>    better matches.
> 4. They only add the dts for the B0 SoC for now. The A0 SoC support
>    can be added later if we find the need.
> 5. Even newer versions of the bootloader will still error out if they
>    don't find a UFS node to add calibration data to. Until UFS is
>    supported, we provide a bogus UFS node for the bootloader. While
>    the bootloader could be changed, there is no long-term benefit
>    since eventually the device tree will have a UFS node.
> 6. They purposely choose to use the full 64-bit address and size cells
>    for the root node and the `soc@0` node. Although I haven't tested
>    the need for this, I presume the arguments made in commit
>    bede7d2dc8f3 ("arm64: dts: qcom: sdm845: Increase address and size
>    cells for soc") would apply here.
> 7. Though it looks as if the UART is never enabled, the bootloader
>    knows to enable the UART when the console is turned on. Baud rate
>    is configurable in the bootloader so is never hardcoded in the
>    device tree.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> To avoid fragmenting the discussion, IMO:
> * Let's have the discussion about using the "dts" for SoC and the
>   "dtso" for the boards in response to the bindings (patch #1).

That's discussion here, bindings are irrelevant to this.

> * If we want to have a discussion about putting "board-id" and
>   "model-id" at the root of the board overlays, we can have it
>   here. I'll preemptively note that the "board-id" and "model-id"
>   won't show up in the final combined device tree and they are just
>   used by the tool (mkdtimg). We could change mkdtimg to parse the
>   "compatible" strings of the overlays files (since I've put the IDs
>   there too), but official the docs [1] seem to indicate that
>   top-level properties like this are OK.
> 
> In order for these device trees to pass validation without warnings,
> it's assumed you have my dtc patches:
> * https://lore.kernel.org/r/20251110204529.2838248-1-dianders@chromium.org
> * https://lore.kernel.org/r/20251110204529.2838248-2-dianders@chromium.org
> 
> [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt?h=main
> 
>  arch/arm64/boot/dts/google/Makefile           |   9 +
>  arch/arm64/boot/dts/google/lga-b0.dts         | 391 ++++++++++++++++++
>  .../arm64/boot/dts/google/lga-blazer-mp1.dtso |  22 +
>  .../boot/dts/google/lga-frankel-mp1.dtso      |  22 +
>  .../boot/dts/google/lga-mustang-mp1.dtso      |  22 +
>  .../boot/dts/google/lga-muzel-common.dtsi     |  17 +
>  6 files changed, 483 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/google/lga-b0.dts
>  create mode 100644 arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
>  create mode 100644 arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
>  create mode 100644 arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
>  create mode 100644 arch/arm64/boot/dts/google/lga-muzel-common.dtsi
> 
> diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
> index a6b187e2d631..276001e91632 100644
> --- a/arch/arm64/boot/dts/google/Makefile
> +++ b/arch/arm64/boot/dts/google/Makefile
> @@ -1 +1,10 @@
>  # SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +
> +dtb-$(CONFIG_ARCH_GOOGLE) += \
> +	lga-blazer-mp1.dtb \
> +	lga-frankel-mp1.dtb \
> +	lga-mustang-mp1.dtb
> +
> +lga-blazer-mp1-dtbs		:= lga-b0.dtb lga-blazer-mp1.dtbo
> +lga-frankel-mp1-dtbs		:= lga-b0.dtb lga-frankel-mp1.dtbo
> +lga-mustang-mp1-dtbs		:= lga-b0.dtb lga-mustang-mp1.dtbo
> diff --git a/arch/arm64/boot/dts/google/lga-b0.dts b/arch/arm64/boot/dts/google/lga-b0.dts
> new file mode 100644
> index 000000000000..83c2db4f20ef
> --- /dev/null
> +++ b/arch/arm64/boot/dts/google/lga-b0.dts
> @@ -0,0 +1,391 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +/*
> + * Google Tensor G5 (laguna) SoC rev B0
> + *
> + * Copyright 2024-2025 Google LLC.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> +	model = "Google Tensor G5 rev B0";
> +	compatible = "google,soc-id-0005-rev-10", "google,lga";

So that's SoC, thus must not be a DTS file, but DTSI.

...


...


> diff --git a/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
> new file mode 100644
> index 000000000000..133494de7a9b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso

And that's a board, so DTS.

> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +/*
> + * Google Pixel 10 (frankel) MP 1
> + *
> + * Copyright 2024-2025 Google LLC.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include "lga-muzel-common.dtsi"
> +
> +/ {
> +	board-id = <0x070306>;
> +	board-rev = <0x010000>;

Undocumented ABI, which you cannot document because these properties are
not allowed. You cannot have them.

Best regards,
Krzysztof