[RFC] arm64: dts: freescale: Supporting Variscite SoM and carrier revisions

[RFC] arm64: dts: freescale: Supporting Variscite SoM and carrier revisions

[Stefano Radaelli]

Hi all,

At Variscite, we are starting to look at how best to maintain upstream
Linux support for multiple hardware revisions of our SoMs and carrier
boards. We would appreciate guidance before settling on an approach.
Our goal is to support new revisions while allowing customers to keep
using current kernels on older hardware.

Our platforms are typically described by a SoM .dtsi and a carrier-board
.dts, for example imx8mm-var-som.dtsi and imx8mm-var-som-symphony.dts.
Both the SoM and the carrier can evolve independently. Some revisions
require changes to the hardware description, while others may work with
the same DT. Over time, this leaves us with several combinations to
support, without wanting to duplicate complete device trees for each one.

What would be the recommended upstream approach to organizing and
maintaining these revisions and their supported combinations?

One possibility we have considered is keeping the common SoM and carrier
descriptions in .dtsi files, with revision-specific .dtsi files extending
or overriding them, and small top-level .dts files selecting the required
combination. Would this be a suitable structure? Are there established
patterns or existing platforms we should follow, particularly to keep
changes for newer revisions from affecting older ones?

We are also wondering how to handle revisions that can share the same
description. As a concrete example, we have discussed the following
possible grouping for DART-MX8M Mini and Sonata:

  imx8mm-var-dart-2.0-sonata-1.0.dtb
    DART-MX8M Mini v2.0-v2.1 on Sonata v1.0-v1.3

  imx8mm-var-dart-2.2-sonata-1.4.dtb
    DART-MX8M Mini v2.2 on Sonata v1.4

These are proposed names, assuming that the same DT correctly describes
all the hardware combinations covered by each entry.

Would it be acceptable to keep updating the first DTS to support a
compatible revision such as v2.1, retaining the v2.0 filename, as long as
it remains correct for all previously supported hardware? In this scheme,
we would add a separate DTS/DTB for v2.2 only if a different description
were needed.

This is an initial idea rather than a settled design, so suggestions for
a different approach would be very welcome.

Thanks,
Best Regards,
Stefano

Re: [RFC] arm64: dts: freescale: Supporting Variscite SoM and carrier revisions

[Frank Li]

On Fri, Oct 23, 2026 at 01:52:41PM +0200, Stefano Radaelli wrote:
> Hi all,
>
> At Variscite, we are starting to look at how best to maintain upstream
> Linux support for multiple hardware revisions of our SoMs and carrier
> boards. We would appreciate guidance before settling on an approach.
> Our goal is to support new revisions while allowing customers to keep
> using current kernels on older hardware.
>
> Our platforms are typically described by a SoM .dtsi and a carrier-board
> .dts, for example imx8mm-var-som.dtsi and imx8mm-var-som-symphony.dts.
> Both the SoM and the carrier can evolve independently. Some revisions
> require changes to the hardware description, while others may work with
> the same DT. Over time, this leaves us with several combinations to
> support,> without wanting to duplicate complete device trees for each.
>
> What would be the recommended upstream approach to organizing and
> maintaining these revisions and their supported combinations?
>
> One possibility we have considered is keeping the common SoM and carrier
> descriptions in .dtsi files, with revision-specific .dtsi files extending
> or overriding them, and small top-level .dts files selecting the required
> combination. Would this be a suitable structure? Are there established
> patterns or existing platforms we should follow, particularly to keep
> changes for newer revisions from affecting older ones?

It is quite depend on how much difference. maybe choose overlay to update.
but some change is quite big. Have to rename to .dtsi and use difference
dts to include dtsi.

>
> We are also wondering how to handle revisions that can share the same
> description. As a concrete example, we have discussed the following
> possible grouping for DART-MX8M Mini and Sonata:
>
>   imx8mm-var-dart-2.0-sonata-1.0.dtb
>     DART-MX8M Mini v2.0-v2.1 on Sonata v1.0-v1.3

How about use boards compatible string? You add new compatible for new
boards, so user know this dts cover which boards.

>
>   imx8mm-var-dart-2.2-sonata-1.4.dtb
>     DART-MX8M Mini v2.2 on Sonata v1.4
>
> These are proposed names, assuming that the same DT correctly describes
> all the hardware combinations covered by each entry.

If new boards 2.3 appear, do you plan change to
imx8mm-var-dart-2.2-sonata-1.4-2.3.dtb?

Rename affect addtional problem or efforts when back port.

>
> Would it be acceptable to keep updating the first DTS to support a
> compatible revision such as v2.1, retaining the v2.0 filename, as long as
> it remains correct for all previously supported hardware?

I think it is fine.

Frank

> In this scheme,
> we would add a separate DTS/DTB for v2.2 only if a different description
> were needed.
>
> This is an initial idea rather than a settled design, so suggestions for
> a different approach would be very welcome.
>
> Thanks,
> Best Regards,
> Stefano
>

Re: [RFC] arm64: dts: freescale: Supporting Variscite SoM and carrier revisions

[Stefano Radaelli]

Hi Frank,

On Fri, Oct 23, 2026 at 10:15:36AM -0500, Frank Li wrote:
> >
> >   imx8mm-var-dart-2.2-sonata-1.4.dtb
> >     DART-MX8M Mini v2.2 on Sonata v1.4
> >
> > These are proposed names, assuming that the same DT correctly describes
> > all the hardware combinations covered by each entry.
> 
> If new boards 2.3 appear, do you plan change to
> imx8mm-var-dart-2.2-sonata-1.4-2.3.dtb?
> 
> Rename affect addtional problem or efforts when back port.

No, our intention is to keep the filename unchanged. For example,
imx8mm-var-dart-2.0-sonata-1.0.dtb would retain that name even if it
also supports later revisions, provided that the same description
remains correct for all previously supported hardware.

Regarding the filename itself, would it be acceptable to include both
the SoM and carrier hardware revisions, as in the example above?
Or is there a preferred upstream naming convention for distinguishing
these combinations? I have not found a clear example to follow where
both revisions are included in the filename.

We would introduce a separate DTS/DTB only when the hardware requires
a different description, sharing the common parts through .dtsi files.
Our preference is to distribute complete DTBs that the bootloader
can load directly.

> How about use boards compatible string? You add new compatible for new
> boards, so user know this dts cover which boards.

Could you give an example of how you would handle the root compatible
property when the same DTB is used unchanged on multiple revisions?

For instance, if SoM v2.0 and v2.1 on the same carrier can share exactly
the same DT, would you retain the existing board compatible, or
introduce revision-specific strings? How would those be represented
in the shared DTS?

Thanks,
Stefano

Re: [RFC] arm64: dts: freescale: Supporting Variscite SoM and carrier revisions

[Frank Li]

On Mon, Oct 26, 2026 at 09:29:39AM +0100, Stefano Radaelli wrote:
> Hi Frank,
>
> On Fri, Oct 23, 2026 at 10:15:36AM -0500, Frank Li wrote:
> > >
> > >   imx8mm-var-dart-2.2-sonata-1.4.dtb
> > >     DART-MX8M Mini v2.2 on Sonata v1.4
> > >
> > > These are proposed names, assuming that the same DT correctly describes
> > > all the hardware combinations covered by each entry.
> >
> > If new boards 2.3 appear, do you plan change to
> > imx8mm-var-dart-2.2-sonata-1.4-2.3.dtb?
> >
> > Rename affect addtional problem or efforts when back port.
>
> No, our intention is to keep the filename unchanged. For example,
> imx8mm-var-dart-2.0-sonata-1.0.dtb would retain that name even if it
> also supports later revisions, provided that the same description
> remains correct for all previously supported hardware.
>
> Regarding the filename itself, would it be acceptable to include both
> the SoM and carrier hardware revisions, as in the example above?

Is it for created dtb file? We generally doesn't finial results.

> Or is there a preferred upstream naming convention for distinguishing
> these combinations? I have not found a clear example to follow where
> both revisions are included in the filename.
>
> We would introduce a separate DTS/DTB only when the hardware requires
> a different description, sharing the common parts through .dtsi files.
> Our preference is to distribute complete DTBs that the bootloader
> can load directly.

It should be fine only if dts can be shared. It is okay to generate differe
combination dtb file by using makefile.

>
> > How about use boards compatible string? You add new compatible for new
> > boards, so user know this dts cover which boards.
>
> Could you give an example of how you would handle the root compatible
> property when the same DTB is used unchanged on multiple revisions?
>
> For instance, if SoM v2.0 and v2.1 on the same carrier can share exactly
> the same DT, would you retain the existing board compatible, or
> introduce revision-specific strings? How would those be represented
> in the shared DTS?

Yes, need revision-specific compatible string.

compatible = "SoM2.1-carrier-0.1", "SoMv2.0-carrier-0.2", ....

Frank

>
> Thanks,
> Stefano

Re: [RFC] arm64: dts: freescale: Supporting Variscite SoM and carrier revisions

[Stefano Radaelli]

On Mon, Oct 26, 2026 at 11:37:04AM -0500, Frank Li wrote:
> 
> Is it for created dtb file? We generally doesn't finial results.
> 

I meant the source .dts filenames committed to the kernel tree,
as well as the resulting .dtb filenames.

Would a name such as imx8mm-var-dart-2.0-sonata-1.0.dts be acceptable
upstream, including both the SoM and carrier hardware revisions?
We would keep that filename unchanged when later compatible
revisions can use the same description.

> 
> It should be fine only if dts can be shared. It is okay to generate differe
> combination dtb file by using makefile.
> 

Thanks. Our proposed approach is to share the common and
revision-specific descriptions through .dtsi files, with small
top-level .dts files selecting the appropriate SoM/carrier
combination through includes. We would then list the corresponding
.dtb targets in the Makefile and compile them into complete DTBs
that the bootloader can load directly.

> 
> Yes, need revision-specific compatible string.
> 
> compatible = "SoM2.1-carrier-0.1", "SoMv2.0-carrier-0.2", ....
> 

Understood. When a new revision can share the existing description,
we would add its revision-specific compatible to the same DTS,
retain the existing strings, and update the corresponding binding.

For example, if SoM v2.1 on Sonata v1.0 can use the same description
as SoM v2.0 on Sonata v1.0, we would add the new compatible to the
existing DTS. The resulting DTB would continue to serve both
revisions under the same filename, provided that the description
and all declared compatibilities remain correct for both.

Thanks,
Stefano