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

Hi Ryan,

On Wed, 29 Oct 2025 at 03:38, Ryan Chen [off-list ref] wrote:

quoted

Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
On Mon, 27 Oct 2025 at 13:01, Andrew Lunn [off-list ref] wrote:

quoted

On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:

quoted

quoted

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

quoted

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.

quoted

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.

quoted

quoted

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";?

"reserved" is the appropriate status value for that.

Thanks for the clarification.

Since the SoC-level .dtsi is shared by all users (potentially other platforms),
I don’t actually know in advance which peripherals will be assigned to
which CPU. For this reason, marking nodes as `status = "reserved"` in the
.dtsi might be misleading.

Sure, not in the SoC-specific .dtsi.

I think it’s more appropriate to keep all peripherals as
`status = "disabled"` in the common .dtsi, and let each board-level .dts or
firmware-specific DT decide whether a device should be `okay` or `reserved`
depending on the actual resource assignment.

Correct.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds