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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <TY2PPF5CB9A1BE68F47D7F3DBA2CDA2429EF2FBA@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Thu, 30 Oct 2025 02:30:44 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>, Arnd Bergmann <arnd@...db.de>
CC: Andrew Lunn <andrew@...n.ch>, BMC-SW <BMC-SW@...eedtech.com>, Rob Herring
	<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
	<conor+dt@...nel.org>, Joel Stanley <joel@....id.au>, Andrew Jeffery
	<andrew@...econstruct.com.au>, Jeremy Kerr <jk@...econstruct.com.au>, Lee
 Jones <lee@...nel.org>, Catalin Marinas <catalin.marinas@....com>, Will
 Deacon <will@...nel.org>, Bjorn Andersson <bjorn.andersson@....qualcomm.com>,
	Nishanth Menon <nm@...com>, Nícolas F. R. A. Prado
	<nfraprado@...labora.com>, Taniya Das <quic_tdas@...cinc.com>, "Lad,
 Prabhakar" <prabhakar.mahadev-lad.rj@...renesas.com>, Kuninori Morimoto
	<kuninori.morimoto.gx@...esas.com>, Eric Biggers <ebiggers@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
 tree

> 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@...db.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@...33000, cm4 view uart0@...33000
From ca35 do have 0x7xxxxxxx is another peripheral decode address.

> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert@...ux-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