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:
 <TY2PPF5CB9A1BE665D988A413B8BCD5CA27F2FAA@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Wed, 29 Oct 2025 02:31:48 +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
> 
> 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?
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.

Therefore, the dtsi view for each side needs to be separate rather than
shared.

> 
> > > How do you partition devices
> > > so each CPU cluster knows it has exclusive access to which peripherals?
> >
> > Before the system is fully brought up, Boot MCU configure hardware
> > controllers handle the resource partitioning to ensure exclusive access.
> 
> Are you saying it modifies the .dtb blob and changes some status = "okay"; to
> "disabled";?

no, the Boot MCU does not modify the .dtb blob. 
During early boot, it only configures the SCU and property
bus controllers to partition peripheral access, ensuring exclusive
ownership before others system bring up.

> 
> 	Andrew