[PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

[Arnd Bergmann]

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 at arndb.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 at 14c33000, cm4 view uart0 at 74c33000
> 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 at c33000, 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