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:
 <TY2PPF5CB9A1BE6A90EB3EE01B924744957F2C5A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Wed, 5 Nov 2025 00:35:22 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Arnd Bergmann <arnd@...db.de>, 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

> 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.

Thanks the direction.
I will separate the aspeed-g7.dtsi file to be aspeed-g7-a35.dtsi and aspeed-g7-common.dts.
aspeed-g7-a35.dtsi will descript soc0/1 ranges
    soc0: bus@...00000 {
        compatible = "simple-bus";
        #address-cells = <2>;
        #size-cells = <2>;

        ranges = <0x0 0x0 0x0 0x0 0x0 0x10000000>;
    };

    soc1: bus@...00000 {
        compatible = "simple-bus";
        #address-cells = <2>;
        #size-cells = <2>;

        ranges = <0x0 0x0 0x0 0x14000000 0x0 0x10000000>; 
    };
aspeed-g7-common.dts will descript soc0/1 peripheral offset. 

> 
>          Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ