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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 17/11/2025 07:43, Chen-Yu Tsai wrote:
> On Wed, Nov 12, 2025 at 5:49 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 12/11/2025 10:35, Chen-Yu Tsai wrote:
>>> On Wed, Nov 12, 2025 at 4:14 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>
>>>> 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.
>>>
>>> This is part of the discussion I want to have at Plumbers. But I suppose
>>> we can start here.
>>
>> Then the patch should be called RFC as not yet ready for merging. :)
>>
>>>
>>> The Android DTB partition format uses six 32-bit integers for matching,
>>> as opposed to a compatible string used in FIT images. Two of the integers
>>> are the "id" and "rev" numbers in the example above. The remaining four
>>> are custom and left up to the (vendor) bootloader implementation.
>>>
>>> The values for these fields need to be stored somewhere with the .dts.
>>> The compiled DTB is useless if the user cannot build a proper image for
>>> the bootloader to consume, and that involves putting in the right numbers
>>> in these fields. The android "mkdtimg" tool can either take the values
>>> from some known properties within the DTB, or have them fed to it
>>> externally.
>>>
>>> So if we don't want these numbers in the dts itself, then we should come
>>> up with some format to store them beside the dts files.
>>
>> Re-iterating comment from Rob long time ago: adding such new properties
>> is fine, but they must come for more than one user and be universal
>> across these users.
> 
> Is Android universal enough? As mentioned above, Android defines some
> fields that it wants in its DTBO partition header. I am doubtful we
> could generalize further, since each bootloader scheme wants different
> things.

There is no such user of these bindings as "Android".

> 
>> And of course the ABI needs to be documented which did not happen here.
>>
>> I indeed said incorrectly that "properties are not allowed". The
>> properties could be allowed if we document them according to above Rob's
>> comment, but that did not happen.
>>
>> Adding these properties per one SoC vendor is not really allowed, like
>> qcom,board-id and qcom,msm-id, but maybe you intend to make it generic.
> 
> That is indeed not great. I believe this part predates the DTBO partition
> format, and is also related to how vendors split their base DTB and
> overlays, such as the scheme Doug presented.
> 
> Maybe the new Android Generic Boot Loader (GBL) work will provide
> unification. I will reach out to them to see what's happening in that space.
> 
>>> On a similar note, we would have a similar problem with FIT images and
>>> overlays. The FIT image format maps a (series of) compatible string(s)
>>> to one DTB and any number of overlays. If overlays are involved, then
>>> the compatible string cannot come from the DTB itself, and the mapping
>>> must be stored somewhere.
>>
>> I recall, although cannot find now references to, a email talk on the
>> list saying that such overlays should have their own compatible, thus
>> solving this mapping problem.
> 
> Rob provided it in the other thread. The per-overlay compatible allows
> identifying the overlay instead of using the filename, which I think
> is much appreciated. But we still need a mapping of what a final device
> compatible breaks down to.

Who is "we"? Linux does not care about that mapping. For user-space
"google,yoda-sku0" should be good enough.


> 
> For example, say we have the the following:
> 
> - product common base "google,yoda" (DTB)
> - codec option one "google,yoda-codec-rt5682i" (DTBO)
> - codec option two "google,yoda-codec-rt5682s" (DTBO)
> - WWAN module and SAR sensor option "google,yoda,wwan" (DTBO)
> 
> We then have different SKUs that are a combination of the above:
> 
> - product SKU "google,yoda-sku0"
>   combine "google,yoda", "google,yoda-codec-rt5682s", and "google,yoda,wwan"
> 
> - product SKU "google,yoda-sku4"
>   combine "google,yoda", "google,yoda-codec-rt5682i", and "google,yoda,wwan"
> 
> - product SKU "google,yoda-sku16"
>   combine "google,yoda" and "google,yoda-codec-rt5682s"
> 
> This is the mapping we have to put _somewhere_. The bootloader only
> knows about "google,yoda-skuXYZ" and "google,yoda", as described in
> the Chromebook boot flow document [1].
> 

The entire pathset is about Google Pixel so I really do not get how
Chromebook boot flow got here.

Best regards,
Krzysztof