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: <7c0c966b-c45f-47ad-9243-b945036a9bd2@app.fastmail.com>
Date: Wed, 29 Oct 2025 08:26:11 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Ryan Chen" <ryan_chen@...eedtech.com>, "Andrew Lunn" <andrew@...n.ch>
Cc: 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

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.

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

If you want to share the devicetree source files but have different
physical addresses, you'll need to set up 'ranges' properties in
the top-level .dtsi files that map the child buses into the CPU space
as needed. arch/arm64/boot/dts/apple/t6002.dtsi has a rather
sophisticated way of doing this where &die0 and &die1 set up the
ranges for including the same child die multiple times at different
addresses. You should be able to use similar method but make it
a lot simpler for your case.

      Arnd