This series adds device tree overlays for the Toradex Verdin, Aquila,
and SMARC iMX95 SoMs.

The series adds support for:
- NAU8822 Bridge Tied Load configuration on the Verdin Development Board
- UART_4 reservation for Cortex-M7 firmware on Verdin and Aquila
- SER0 reservation for Cortex-M7 firmware on SMARC

The UART overlays mark the port as reserved so Linux does not claim it.
Firmware remains responsible for configuring the UART and its pads.

The Makefile entries build standalone DTBOs and ready-to-use composed
DTBs for the corresponding Development Boards.

Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
---
Ernest Van Hoecke (4):
      arm64: dts: freescale: imx95-verdin: Add NAU8822 Bridge Tied Load
      arm64: dts: freescale: imx95-verdin: Add Cortex-M7 UART_4 overlay
      arm64: dts: freescale: imx95-aquila: Add Cortex-M7 UART_4 overlay
      arm64: dts: freescale: imx95-toradex-smarc: Add Cortex-M7 SER0 overlay

 arch/arm64/boot/dts/freescale/Makefile                    | 15 +++++++++++++++
 arch/arm64/boot/dts/freescale/imx95-aquila-uart4-mcu.dtso | 14 ++++++++++++++
 .../boot/dts/freescale/imx95-toradex-smarc-ser0-mcu.dtso  | 14 ++++++++++++++
 .../boot/dts/freescale/imx95-verdin-dev-nau8822-btl.dtso  | 14 ++++++++++++++
 arch/arm64/boot/dts/freescale/imx95-verdin-uart4-mcu.dtso | 14 ++++++++++++++
 5 files changed, 71 insertions(+)
---
base-commit: 478f68c644732750f8386e4de7c909c5ffb26ab2
change-id: 20260922-v1-imx95-overlays-89b3a9185b93

Best regards,
-- 
Ernest Van Hoecke <ernest.vanhoecke@toradex.com>

On Tue, Sep 22, 2026 at 04:33:45PM +0200, Ernest Van Hoecke wrote:
> This series adds device tree overlays for the Toradex Verdin, Aquila,
> and SMARC iMX95 SoMs.
>
> The series adds support for:
> - NAU8822 Bridge Tied Load configuration on the Verdin Development Board
> - UART_4 reservation for Cortex-M7 firmware on Verdin and Aquila
> - SER0 reservation for Cortex-M7 firmware on SMARC
>
> The UART overlays mark the port as reserved so Linux does not claim it.
> Firmware remains responsible for configuring the UART and its pads.
>
> The Makefile entries build standalone DTBOs and ready-to-use composed
> DTBs for the corresponding Development Boards.
>
> Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> ---
> Ernest Van Hoecke (4):
>       arm64: dts: freescale: imx95-verdin: Add NAU8822 Bridge Tied Load
>       arm64: dts: freescale: imx95-verdin: Add Cortex-M7 UART_4 overlay
>       arm64: dts: freescale: imx95-aquila: Add Cortex-M7 UART_4 overlay

both reserved lpuart2, can you share one dtso?

Frank

>       arm64: dts: freescale: imx95-toradex-smarc: Add Cortex-M7 SER0 overlay
>
>  arch/arm64/boot/dts/freescale/Makefile                    | 15 +++++++++++++++
>  arch/arm64/boot/dts/freescale/imx95-aquila-uart4-mcu.dtso | 14 ++++++++++++++
>  .../boot/dts/freescale/imx95-toradex-smarc-ser0-mcu.dtso  | 14 ++++++++++++++
>  .../boot/dts/freescale/imx95-verdin-dev-nau8822-btl.dtso  | 14 ++++++++++++++
>  arch/arm64/boot/dts/freescale/imx95-verdin-uart4-mcu.dtso | 14 ++++++++++++++
>  5 files changed, 71 insertions(+)
> ---
> base-commit: 478f68c644732750f8386e4de7c909c5ffb26ab2
> change-id: 20260922-v1-imx95-overlays-89b3a9185b93
>
> Best regards,
> --
> Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
>
>

On Tue, Sep 22, 2026 at 11:07:44AM -0500, Frank Li wrote:
> On Tue, Sep 22, 2026 at 04:33:45PM +0200, Ernest Van Hoecke wrote:
> > This series adds device tree overlays for the Toradex Verdin, Aquila,
> > and SMARC iMX95 SoMs.
> >
> > The series adds support for:
> > - NAU8822 Bridge Tied Load configuration on the Verdin Development Board
> > - UART_4 reservation for Cortex-M7 firmware on Verdin and Aquila
> > - SER0 reservation for Cortex-M7 firmware on SMARC
> >
> > The UART overlays mark the port as reserved so Linux does not claim it.
> > Firmware remains responsible for configuring the UART and its pads.
> >
> > The Makefile entries build standalone DTBOs and ready-to-use composed
> > DTBs for the corresponding Development Boards.
> >
> > Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> > ---
> > Ernest Van Hoecke (4):
> >       arm64: dts: freescale: imx95-verdin: Add NAU8822 Bridge Tied Load
> >       arm64: dts: freescale: imx95-verdin: Add Cortex-M7 UART_4 overlay
> >       arm64: dts: freescale: imx95-aquila: Add Cortex-M7 UART_4 overlay
> 
> both reserved lpuart2, can you share one dtso?

The comment in the DT file must be different because it's important to
reference the actual board it applies to.

So to fulfill this request we would need to add a common dtsi, include
it from two different dtso files.

This to save 2 lines of duplicated code, `&lpuart2 { status = "reserved"; };`.

To me this is just worst than the current proposal.

Francesco

On Tue, Sep 22, 2026 at 06:58:46PM +0200, Francesco Dolcini wrote:
> On Tue, Sep 22, 2026 at 11:07:44AM -0500, Frank Li wrote:
> > On Tue, Sep 22, 2026 at 04:33:45PM +0200, Ernest Van Hoecke wrote:
> > > This series adds device tree overlays for the Toradex Verdin, Aquila,
> > > and SMARC iMX95 SoMs.
> > >
> > > The series adds support for:
> > > - NAU8822 Bridge Tied Load configuration on the Verdin Development Board
> > > - UART_4 reservation for Cortex-M7 firmware on Verdin and Aquila
> > > - SER0 reservation for Cortex-M7 firmware on SMARC
> > >
> > > The UART overlays mark the port as reserved so Linux does not claim it.
> > > Firmware remains responsible for configuring the UART and its pads.
> > >
> > > The Makefile entries build standalone DTBOs and ready-to-use composed
> > > DTBs for the corresponding Development Boards.
> > >
> > > Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> > > ---
> > > Ernest Van Hoecke (4):
> > >       arm64: dts: freescale: imx95-verdin: Add NAU8822 Bridge Tied Load
> > >       arm64: dts: freescale: imx95-verdin: Add Cortex-M7 UART_4 overlay
> > >       arm64: dts: freescale: imx95-aquila: Add Cortex-M7 UART_4 overlay
> >
> > both reserved lpuart2, can you share one dtso?
>
> The comment in the DT file must be different because it's important to
> reference the actual board it applies to.
>
> So to fulfill this request we would need to add a common dtsi, include
> it from two different dtso files.

No, direct use one dtso. see

https://elixir.bootlin.com/linux/v7.3-rc3/source/arch/arm64/boot/dts/freescale/imx-pcie0-ep.dtso

And makefile to check how apply the same dtso for difference boards

Frank

>
> This to save 2 lines of duplicated code, `&lpuart2 { status = "reserved"; };`.
>
> To me this is just worst than the current proposal.
>
> Francesco
>
>

Hello Frank,

On Tue, Sep 22, 2026 at 01:31:51PM -0500, Frank Li wrote:
> On Tue, Sep 22, 2026 at 06:58:46PM +0200, Francesco Dolcini wrote:
> > On Tue, Sep 22, 2026 at 11:07:44AM -0500, Frank Li wrote:
> > > On Tue, Sep 22, 2026 at 04:33:45PM +0200, Ernest Van Hoecke wrote:
> > > > This series adds device tree overlays for the Toradex Verdin, Aquila,
> > > > and SMARC iMX95 SoMs.
> > > >
> > > > The series adds support for:
> > > > - NAU8822 Bridge Tied Load configuration on the Verdin Development Board
> > > > - UART_4 reservation for Cortex-M7 firmware on Verdin and Aquila
> > > > - SER0 reservation for Cortex-M7 firmware on SMARC
> > > >
> > > > The UART overlays mark the port as reserved so Linux does not claim it.
> > > > Firmware remains responsible for configuring the UART and its pads.
> > > >
> > > > The Makefile entries build standalone DTBOs and ready-to-use composed
> > > > DTBs for the corresponding Development Boards.
> > > >
> > > > Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> > > > ---
> > > > Ernest Van Hoecke (4):
> > > >       arm64: dts: freescale: imx95-verdin: Add NAU8822 Bridge Tied Load
> > > >       arm64: dts: freescale: imx95-verdin: Add Cortex-M7 UART_4 overlay
> > > >       arm64: dts: freescale: imx95-aquila: Add Cortex-M7 UART_4 overlay
> > >
> > > both reserved lpuart2, can you share one dtso?
> >
> > The comment in the DT file must be different because it's important to
> > reference the actual board it applies to.
> >
> > So to fulfill this request we would need to add a common dtsi, include
> > it from two different dtso files.
> 
> No, direct use one dtso. see
> 
> https://elixir.bootlin.com/linux/v7.3-rc3/source/arch/arm64/boot/dts/freescale/imx-pcie0-ep.dtso
> 
> And makefile to check how apply the same dtso for difference boards

imx-pcie0-ep.dtso works as a single shared file because its content is
generic, there is no board name anywhere in it, and nobody needs to
apply that specific dtbo by hand to know what it is for.

These overlays are different: they are meant to be picked up and applied
directly by the end user, in addition to also being combined in-tree
into a ready DTB. Put yourself in that user's shoes: they have a Verdin
board, they want to free up UART_4 for their Cortex-M7 firmware, and
they go looking in arch/arm64/boot/dts/freescale/ for the overlay that
does that for their board. What they need at that point is a file name
that says "this is for Verdin" and "this is the UART_4 one", and once
they open it, a comment that confirms both: which board and which
specific UART. That is the whole point of shipping the overlay
separately from a combined DTB: it is meant to be readable and
applicable on its own by someone who is not a DT expert.

There is also a second, even more constrained user: the one who never
looks at the kernel sources at all, and only gets the compiled .dtbo as
deployed on their distribution, e.g. under /boot/overlays/ on the
target, or the more generic paths used by distributions like Debian
(/boot/firmware/overlays/) or Armbian (user_overlays= in
armbianEnv.txt), picking it by name from an overlay list or a U-Boot
env variable. Comments do not survive dtc compilation, so for that user
the file name is the only information available, there is no comment to
fall back on.

A single dtso shared between Verdin and Aquila fails that on both
counts: the name has to become something generic like
imx95-verdin-aquila-uart4-mcu.dtso (immediately confusing: which board
is it really for? can I use it on either?), and the comment inside can
no longer say which board it targets either. That is worse for the
person using it, for the sake of avoiding 2 lines of duplication:

  &lpuart2 {
  	status = "reserved";
  };

It also does not reduce the Makefile churn: we need the same number of
Makefile lines/combos either way, one dtso reused for two boards or two
dedicated ones. And this file will not change once merged, so there is
no maintenance overhead from keeping it per board.

We agree that avoiding duplication is generally the right call. When
there is real, growing duplication across dtso files, the right fix is
a shared dtsi included by the dtso files, not merging them into one. In
this case the duplication is 2 lines that will not change, so it does
not meet that bar either way.

We would like to keep the two dedicated dtso files.

Francesco

On Wed, Sep 23, 2026 at 10:41:11AM +0200, Francesco Dolcini wrote:
> Hello Frank,
>
> On Tue, Sep 22, 2026 at 01:31:51PM -0500, Frank Li wrote:
> > On Tue, Sep 22, 2026 at 06:58:46PM +0200, Francesco Dolcini wrote:
> > > On Tue, Sep 22, 2026 at 11:07:44AM -0500, Frank Li wrote:
> > > > On Tue, Sep 22, 2026 at 04:33:45PM +0200, Ernest Van Hoecke wrote:
> > > > > This series adds device tree overlays for the Toradex Verdin, Aquila,
> > > > > and SMARC iMX95 SoMs.
> > > > >
> > > > > The series adds support for:
> > > > > - NAU8822 Bridge Tied Load configuration on the Verdin Development Board
> > > > > - UART_4 reservation for Cortex-M7 firmware on Verdin and Aquila
> > > > > - SER0 reservation for Cortex-M7 firmware on SMARC
> > > > >
> > > > > The UART overlays mark the port as reserved so Linux does not claim it.
> > > > > Firmware remains responsible for configuring the UART and its pads.
> > > > >
> > > > > The Makefile entries build standalone DTBOs and ready-to-use composed
> > > > > DTBs for the corresponding Development Boards.
> > > > >
> > > > > Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> > > > > ---
> > > > > Ernest Van Hoecke (4):
> > > > >       arm64: dts: freescale: imx95-verdin: Add NAU8822 Bridge Tied Load
> > > > >       arm64: dts: freescale: imx95-verdin: Add Cortex-M7 UART_4 overlay
> > > > >       arm64: dts: freescale: imx95-aquila: Add Cortex-M7 UART_4 overlay
> > > >
> > > > both reserved lpuart2, can you share one dtso?
> > >
> > > The comment in the DT file must be different because it's important to
> > > reference the actual board it applies to.
> > >
> > > So to fulfill this request we would need to add a common dtsi, include
> > > it from two different dtso files.
> >
> > No, direct use one dtso. see
> >
> > https://elixir.bootlin.com/linux/v7.3-rc3/source/arch/arm64/boot/dts/freescale/imx-pcie0-ep.dtso
> >
> > And makefile to check how apply the same dtso for difference boards
>
> imx-pcie0-ep.dtso works as a single shared file because its content is
> generic, there is no board name anywhere in it, and nobody needs to
> apply that specific dtbo by hand to know what it is for.
>
> These overlays are different: they are meant to be picked up and applied
> directly by the end user, in addition to also being combined in-tree
> into a ready DTB. Put yourself in that user's shoes: they have a Verdin
> board, they want to free up UART_4 for their Cortex-M7 firmware, and
> they go looking in arch/arm64/boot/dts/freescale/ for the overlay that
> does that for their board. What they need at that point is a file name
> that says "this is for Verdin" and "this is the UART_4 one", and once
> they open it, a comment that confirms both: which board and which
> specific UART. That is the whole point of shipping the overlay
> separately from a combined DTB: it is meant to be readable and
> applicable on its own by someone who is not a DT expert.

If someone is not DT expert, most likely direct use your prebuild dtbs,
not apply dtso theyself.

>
> There is also a second, even more constrained user: the one who never
> looks at the kernel sources at all, and only gets the compiled .dtbo as
> deployed on their distribution, e.g. under /boot/overlays/ on the
> target, or the more generic paths used by distributions like Debian
> (/boot/firmware/overlays/) or Armbian (user_overlays= in
> armbianEnv.txt), picking it by name from an overlay list or a U-Boot
> env variable. Comments do not survive dtc compilation, so for that user
> the file name is the only information available, there is no comment to
> fall back on.
>
> A single dtso shared between Verdin and Aquila fails that on both
> counts: the name has to become something generic like
> imx95-verdin-aquila-uart4-mcu.dtso (immediately confusing: which board
> is it really for? can I use it on either?), and the comment inside can
> no longer say which board it targets either. That is worse for the
> person using it, for the sake of avoiding 2 lines of duplication:
>
>   &lpuart2 {
>   	status = "reserved";
>   };
>
> It also does not reduce the Makefile churn: we need the same number of
> Makefile lines/combos either way, one dtso reused for two boards or two
> dedicated ones. And this file will not change once merged, so there is
> no maintenance overhead from keeping it per board.
>
> We agree that avoiding duplication is generally the right call. When
> there is real, growing duplication across dtso files, the right fix is
> a shared dtsi included by the dtso files, not merging them into one. In
> this case the duplication is 2 lines that will not change, so it does
> not meet that bar either way.

It is not exactly true. include dtsi only one method. Basic there are two
kind type overy all files

- one is for addtional boards.
- change configuration.

You provide difference configuration, basically it is developping boards.
The real productions is fixed.

Your uboot scripts or other manually should hide complex. like PC grub
menu, just choose 1,2,3...

If someone like advance, he need know more knowledge.

Makefile show how to apply dtso to correct dtb.  filename rule can't
resolve problems without know detail.

The put lpuart2 as reserved also used by other boards, not only verdin
and aquila.

Frank

>
> We would like to keep the two dedicated dtso files.
>
> Francesco

Hello Frank,

On Wed, Sep 23, 2026 at 10:06:55AM -0500, Frank Li wrote:
> On Wed, Sep 23, 2026 at 10:41:11AM +0200, Francesco Dolcini wrote:
> > On Tue, Sep 22, 2026 at 01:31:51PM -0500, Frank Li wrote:
> > > On Tue, Sep 22, 2026 at 06:58:46PM +0200, Francesco Dolcini wrote:
> > > > On Tue, Sep 22, 2026 at 11:07:44AM -0500, Frank Li wrote:
> > > > > On Tue, Sep 22, 2026 at 04:33:45PM +0200, Ernest Van Hoecke wrote:
> > > > > > This series adds device tree overlays for the Toradex Verdin, Aquila,
> > > > > > and SMARC iMX95 SoMs.
> > > > > >
> > > > > > The series adds support for:
> > > > > > - NAU8822 Bridge Tied Load configuration on the Verdin Development Board
> > > > > > - UART_4 reservation for Cortex-M7 firmware on Verdin and Aquila
> > > > > > - SER0 reservation for Cortex-M7 firmware on SMARC
> > > > > >
> > > > > > The UART overlays mark the port as reserved so Linux does not claim it.
> > > > > > Firmware remains responsible for configuring the UART and its pads.
> > > > > >
> > > > > > The Makefile entries build standalone DTBOs and ready-to-use composed
> > > > > > DTBs for the corresponding Development Boards.
> > > > > >
> > > > > > Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> > > > > > ---
> > > > > > Ernest Van Hoecke (4):
> > > > > >       arm64: dts: freescale: imx95-verdin: Add NAU8822 Bridge Tied Load
> > > > > >       arm64: dts: freescale: imx95-verdin: Add Cortex-M7 UART_4 overlay
> > > > > >       arm64: dts: freescale: imx95-aquila: Add Cortex-M7 UART_4 overlay
> > > > >
> > > > > both reserved lpuart2, can you share one dtso?
> > > >
> > > > The comment in the DT file must be different because it's important to
> > > > reference the actual board it applies to.
> > > >
> > > > So to fulfill this request we would need to add a common dtsi, include
> > > > it from two different dtso files.
> > >
> > > No, direct use one dtso. see
> > >
> > > https://elixir.bootlin.com/linux/v7.3-rc3/source/arch/arm64/boot/dts/freescale/imx-pcie0-ep.dtso
> > >
> > > And makefile to check how apply the same dtso for difference boards
> >
> > imx-pcie0-ep.dtso works as a single shared file because its content is
> > generic, there is no board name anywhere in it, and nobody needs to
> > apply that specific dtbo by hand to know what it is for.
> >
> > These overlays are different: they are meant to be picked up and applied
> > directly by the end user, in addition to also being combined in-tree
> > into a ready DTB. Put yourself in that user's shoes: they have a Verdin
> > board, they want to free up UART_4 for their Cortex-M7 firmware, and
> > they go looking in arch/arm64/boot/dts/freescale/ for the overlay that
> > does that for their board. What they need at that point is a file name
> > that says "this is for Verdin" and "this is the UART_4 one", and once
> > they open it, a comment that confirms both: which board and which
> > specific UART. That is the whole point of shipping the overlay
> > separately from a combined DTB: it is meant to be readable and
> > applicable on its own by someone who is not a DT expert.
> 
> If someone is not DT expert, most likely direct use your prebuild dtbs,
> not apply dtso theyself.
> 
> >
> > There is also a second, even more constrained user: the one who never
> > looks at the kernel sources at all, and only gets the compiled .dtbo as
> > deployed on their distribution, e.g. under /boot/overlays/ on the
> > target, or the more generic paths used by distributions like Debian
> > (/boot/firmware/overlays/) or Armbian (user_overlays= in
> > armbianEnv.txt), picking it by name from an overlay list or a U-Boot
> > env variable. Comments do not survive dtc compilation, so for that user
> > the file name is the only information available, there is no comment to
> > fall back on.
> >
> > A single dtso shared between Verdin and Aquila fails that on both
> > counts: the name has to become something generic like
> > imx95-verdin-aquila-uart4-mcu.dtso (immediately confusing: which board
> > is it really for? can I use it on either?), and the comment inside can
> > no longer say which board it targets either. That is worse for the
> > person using it, for the sake of avoiding 2 lines of duplication:
> >
> >   &lpuart2 {
> >   	status = "reserved";
> >   };
> >
> > It also does not reduce the Makefile churn: we need the same number of
> > Makefile lines/combos either way, one dtso reused for two boards or two
> > dedicated ones. And this file will not change once merged, so there is
> > no maintenance overhead from keeping it per board.
> >
> > We agree that avoiding duplication is generally the right call. When
> > there is real, growing duplication across dtso files, the right fix is
> > a shared dtsi included by the dtso files, not merging them into one. In
> > this case the duplication is 2 lines that will not change, so it does
> > not meet that bar either way.
> 
> It is not exactly true. include dtsi only one method. Basic there are two
> kind type overy all files
> 
> - one is for addtional boards.
> - change configuration.
> 
> You provide difference configuration, basically it is developping boards.
> The real productions is fixed.
> 
> Your uboot scripts or other manually should hide complex. like PC grub
> menu, just choose 1,2,3...
> 
> If someone like advance, he need know more knowledge.

I, myself, and us as Toradex, care way more of our users/developer than
just pretending them to know more.

> Makefile show how to apply dtso to correct dtb.  filename rule can't
> resolve problems without know detail.
> 
> The put lpuart2 as reserved also used by other boards, not only verdin
> and aquila.

And I also disagree on this.

Having consistent and correct file names is important, we have the same
naming scheme for SoM using non-NXP SoC, and there is a clear benefit
from this for the users that has the information complete and correct
just from the file name.

With that said, considering our disagreement, let's try to get to a
point:

 1. is it a requirement to have this changed to have it merged?
 2. if the answer is yes, is imx95-verdin-aquila-uart4-mcu.dtso fine?

Thanks,
Francesco