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:
 <TY2PPF5CB9A1BE6F3E95C7FD61CF4F90ECAF2FEA@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Sat, 25 Oct 2025 03:08:52 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Arnd Bergmann <arnd@...db.de>, 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>,
	Geert Uytterhoeven <geert@...ux-m68k.org>, 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
> 
> > > >> This probably needs some explanation: why are there two 'soc@...'
> > > >> devices? Is this literally two chips in the system, or are you
> > > >> describing two buses inside of the same SoC?
> > > >
> > > > The AST2700 is two soc connection with a property bus.
> > > > Sharing some decode registers. Each have it own ahb bus.
> > >
> > > I don't understand your explanation,
> >
> > Let me clarify more clearly:
> > The AST2700 is a dual-SoC architecture, consisting of two
> > interconnected SoCs, referred to as SoC0 and SoC1. Each SoC has its own
> clock/reset domains.
> > They are connected through an internal "property bus", which is
> > Aspeed's internal interconnect providing shared address decoding and
> > communication between the two SoCs.
> 
> By SoC are you just referring to peripherals? Or are there two sets of CPUs as
> well?
> 
> If it is just peripherals, this has been done before by Marvell.
> 
> See armada-cp11x.dtsi. Marvell calls it a CP, they are identical, so there is one
> description of it, which then gets included twice.
> 
Hi Andrew,

Thanks for asking - yes, the AST2700 is indeed a dual-SoC device, not just a split peripheral domain.

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.

The two SoCs are interconnected through Aspeed's internal "property bus", which provides shared address decoding and inter-SoC communication between the CPU and I/O dies.

This makes the AST2700 closer to a dual-die / dual-SoC configuration, rather than the Marvell CP model you mentioned, which only duplicates peripheral blocks under a single CPU domain.

I'll add this clarification in the commit message and DTS comments in the next revision to make the relationship between the two SoCs explicit.

Best regards,
Ryan