[PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Ryan Chen]

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> Hi Arnd,
> 
> On Wed, 29 Oct 2025 at 08:26, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Wed, Oct 29, 2025, at 03:31, Ryan Chen wrote:
> > >> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700
> > >> SoC device tree
> > >>
> > >> On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:
> > >> > > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial
> > >> > > AST2700 SoC device tree
> > >> > >
> > >> > > > SoC0, referred to as the CPU die, contains a dual-core
> > >> > > > Cortex-A35 cluster and two Cortex-M4 cores, along with its
> > >> > > > own clock/reset domains and high-speed peripheral set.
> > >> > >
> > >> > > > SoC1, referred to as the I/O die, contains the Boot MCU and
> > >> > > > its own clock/reset domains and low-speed peripheral set, and
> > >> > > > is responsible for system boot and control functions.
> > >> > >
> > >> > > So is the same .dtsi file shared by both systems?
> > >> >
> > >> > This .dtsi represents the Cortex-A35 view only and is not shared
> > >> > with the Cortex-M4 or the Boot MCU side, since they are separate
> > >> > 32-bit and 64-bit systems running independent firmware.
> > >>
> > >> DT describes the hardware. The .dtsi file could be shared, you just
> > >> need different status = <>; lines in the dtb blob.
> > >
> > > Could you please share an example of a .dtsi that is shared between
> > > different CPU architectures?
> >
> > I can think of three that are shared between arm and riscv, with both
> > able to boot Linux using a variation of the same device tree, with the
> > .dtsi file being included from the respective other side:
> >
> > arch/riscv/boot/dts/renesas/r9a07g043f.dtsi
> > arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
> > arch/arm64/boot/dts/sophgo/sg2000.dtsi
> >
> > All of these however use the same basic physical address layout as
> > seen from the two CPUs, with only the set of on-chip devices being
> > slightly different, such as using the native irqchip instance per CPU.
> 
> I can't speak for the last two ones, but the first one is not what Ryan is looking
> for, as r9a07g043 has either an ARM (r9a07g043u) or a RISC-V (r9a07g043f)
> CPU core, not both.
> 
> > In the AST2700 design, even though we have both Cortex-A35 (64-bit)
> > > and Cortex-M4 (32-bit) cores, each runs in a distinct address space
> > > and sees a different memory map.
> >
> > This is similar to the Cortex-M4 on i.MX7D. This is supported by the
> > Linux code, but I don't see the corresponding dts file for it now, it
> > may have never been merged.
> 
> The keyword here is "System DT", where you have a single file describing the
> whole SoC. From this, separate DTS files are generated that describe the view
> for the application CPU core, real-time CPU core, control CPU core, etc...
> 
> Gr{oetje,eeting}s,
> 
>                         Geert

Thanks for pointing me in the right direction.

After checking the TI K3 example
(https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-common.dtsi#L75),
I see that all processing domains in that SoC share the same physical
address decoding, which makes a System-DT-style structure possible.

However, in the AST2700 design, the Cortex-A35 (64-bit) and Cortex-M4
(32-bit) cores each run in a distinct address space with different memory
maps, so they do not share the same decode view.  
Because of that, a single unified .dtsi cannot directly represent both sides
without additional translation or “ranges” mapping logic.
For example, in ca35 view uart0 at 14c33000, cm4 view uart0 at 74c33000
From ca35 do have 0x7xxxxxxx is another peripheral decode address.

> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert at linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds