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] [day] [month] [year] [list]

Message-Id: <80d0fb36-17d8-44c9-8941-0bac9f3b3ef2@app.fastmail.com>
Date: Thu, 30 Oct 2025 10:19:15 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Ryan Chen" <ryan_chen@...eedtech.com>,
 "Geert Uytterhoeven" <geert@...ux-m68k.org>
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

On Thu, Oct 30, 2025, at 03:30, Ryan Chen wrote:
>> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
>> tree
>> 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
>
> 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.

This still looks like the simplest case to me, where you'd have
a dtsi file describing the @soc0 and @soc1 devices using their
local addresses such as uart0@...000, and a ranges property
to map it into the CPU specific physical address space, one of

	ranges = <0x0 0x0 0x0 0x14000000 0x0 0x1000000>;
	ranges = <0x0 0x0 0x0 0x74000000 0x0 0x1000000>;

to remap 0x1000000 bytes (16MB) of address space from local
bus addresses to one of the two clusters. This is almost
what you have, except you map an entire 256MB (0x10000000)
range. The exact size you want should be available in your
hardware documentation.

         Arnd