i2c: Add a ir35221 device

Simple model of a PSU device of the witherspoon.

TODO:
- generate "real" values
- implement property visitors to generate faults.

Signed-off-by: Cédric Le Goater <c

i2c: Add a ir35221 device

Simple model of a PSU device of the witherspoon.

TODO:
- generate "real" values
- implement property visitors to generate faults.

Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

i2c: Add a IBM CFF Power Supply device

Simple model of a PSU device of the witherspoon.

TODO:
- generate "real" values
- implement property visitors to generate faults.

Signed-off-by: Cédric

i2c: Add a IBM CFF Power Supply device

Simple model of a PSU device of the witherspoon.

TODO:
- generate "real" values
- implement property visitors to generate faults.

Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

hw/misc: Add an iBT device model

Implement an IPMI BT interface model using a chardev backend to
communicate with an external PowerNV machine. It uses the OpenIPMI
simulator protocol for virtual mac

hw/misc: Add an iBT device model

Implement an IPMI BT interface model using a chardev backend to
communicate with an external PowerNV machine. It uses the OpenIPMI
simulator protocol for virtual machines described in :

https://github.com/cminyard/openipmi/blob/master/lanserv/README.vm

and implemented by the 'ipmi-bmc-extern' model on the host side.

To use, start the Aspeed BMC machine with :

-chardev socket,id=ipmi0,host=localhost,port=9002,ipv4,server,nowait \
-global driver=aspeed.ibt,property=chardev,value=ipmi0

and the PowerNV machine with :

-chardev socket,id=ipmi0,host=localhost,port=9002,reconnect=10 \
-device ipmi-bmc-extern,id=bmc0,chardev=ipmi0 \
-device isa-ipmi-bt,bmc=bmc0,irq=10 -nodefaults

Cc: Hao Wu <wuhaotsh@google.com>
Cc: Corey Minyard <cminyard@mvista.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

hw/misc: Add basic Aspeed PWM model

Just enough to quiet down the output when running with the logs.

Signed-off-by: Cédric Le Goater <clg@kaod.org>

hw/misc: Add basic Aspeed GFX model

Enough model to capture the pinmux writes to enable correct operation of
the parts of pinmux that depend on GFX registers.

Signed-off-by: Joel Stanley <joel@jms.

hw/misc: Add basic Aspeed GFX model

Enough model to capture the pinmux writes to enable correct operation of
the parts of pinmux that depend on GFX registers.

Signed-off-by: Joel Stanley <joel@jms.id.au>

show more ...

hw/arm/aspeed: Build with I3C_DEVICES

Allows us to attach the mock I3C target

Signed-off-by: Joe Komlodi <komlodi@google.com>
Link: https://lore.kernel.org/qemu-devel/20250613000411.1516521-19-koml

hw/arm/aspeed: Build with I3C_DEVICES

Allows us to attach the mock I3C target

Signed-off-by: Joe Komlodi <komlodi@google.com>
Link: https://lore.kernel.org/qemu-devel/20250613000411.1516521-19-komlodi@google.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/i3c: Split DesignWare I3C out of Aspeed I3C

The Aspeed I3C IP block is technically an Aspeed IP block that manages
6 DW I3C controllers.

To help reflect this better and to make it easier for oth

hw/i3c: Split DesignWare I3C out of Aspeed I3C

The Aspeed I3C IP block is technically an Aspeed IP block that manages
6 DW I3C controllers.

To help reflect this better and to make it easier for other SoCs to use
the DW I3C model, we'll split out the DW portion from the Aspeed
portion.

Signed-off-by: Joe Komlodi <komlodi@google.com>
Link: https://lore.kernel.org/qemu-devel/20250613000411.1516521-4-komlodi@google.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/misc/aspeed_i3c: Move to i3c directory

Moves the Aspeed I3C model and traces into hw/i3c and creates I3C build
files.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Ventur

hw/misc/aspeed_i3c: Move to i3c directory

Moves the Aspeed I3C model and traces into hw/i3c and creates I3C build
files.

Signed-off-by: Joe Komlodi <komlodi@google.com>

Reviewed-by: Patrick Venture <venture@google.com>
Reviewed-by: Titus Rwantare <titusr@google.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250613000411.1516521-2-komlodi@google.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/aspeed_ast27x0: Introduce 3 PCIe RCs for AST2700

Add PCIe Root Complex support to the AST2700 SoC model.

The AST2700 A1 silicon revision provides three PCIe Root Complexes:

PCIe0 with its P

hw/arm/aspeed_ast27x0: Introduce 3 PCIe RCs for AST2700

Add PCIe Root Complex support to the AST2700 SoC model.

The AST2700 A1 silicon revision provides three PCIe Root Complexes:

PCIe0 with its PHY at 0x12C15000, config (H2X) block at 0x120E0000,
MMIO window at 0x60000000, and GIC IRQ 56.

PCIe1 with its PHY at 0x12C15800, config (H2X) block at 0x120F0000,
MMIO window at 0x80000000, and GIC IRQ 57.

PCIe2 with its PHY at 0x14C1C000, config (H2X) block at 0x140D0000,
MMIO window at 0xA0000000, and IRQ routed through INTC4 bit 31
mapped to GIC IRQ 196.

Each RC instantiates a PHY device, a PCIe config (H2X) bridge, and an MMIO
alias region. The per-RC MMIO alias size is 0x20000000. The AST2700 A0
silicon revision does not support PCIe Root Complexes, so pcie_num is set
to 0 in that variant.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250819090141.3949136-11-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/aspeed_ast2600: Add PCIe RC support (RC_H only)

Wire up the PCIe Root Complex in the AST2600 SoC model.

According to the AST2600 firmware driver, only the RC_H controller is
supported. RC_H

hw/arm/aspeed_ast2600: Add PCIe RC support (RC_H only)

Wire up the PCIe Root Complex in the AST2600 SoC model.

According to the AST2600 firmware driver, only the RC_H controller is
supported. RC_H uses PCIe PHY1 at 0x1e6ed200 and the PCIe config (H2X)
register block at 0x1e770000. The RC_H MMIO window is mapped at
0x70000000–0x80000000. RC_L is not modeled. The RC_H interrupt is
wired to IRQ 168. Only RC_H is realized and connected to the SoC
interrupt controller.

The SoC integration initializes PCIe PHY1, instantiates a single RC
instance, wires its MMIO regions, and connects its interrupt. An alias
region is added to map the RC MMIO space into the guest physical address
space.

This provides enough functionality for firmware and guest drivers to
discover and use the AST2600 RC_H Root Complex while leaving RC_L
unimplemented.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250819090141.3949136-7-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/pci-host/aspeed: Add AST2600 PCIe PHY model

This patch introduces an initial ASPEED PCIe PHY/host controller model to
support the AST2600 SoC. It provides a simple register block with MMIO
read/w

hw/pci-host/aspeed: Add AST2600 PCIe PHY model

This patch introduces an initial ASPEED PCIe PHY/host controller model to
support the AST2600 SoC. It provides a simple register block with MMIO
read/write callbacks, integration into the build system, and trace events
for debugging.

Key changes:

1. PCIe PHY MMIO read/write callbacks
Implemented aspeed_pcie_phy_read() and aspeed_pcie_phy_write() to
handle 32-bit register accesses.

2. Build system and Kconfig integration
Added CONFIG_PCI_EXPRESS_ASPEED in hw/pci-host/Kconfig and meson
rules.
Updated ASPEED_SOC in hw/arm/Kconfig to imply PCI_DEVICES and select
PCI_EXPRESS_ASPEED.

3. Trace events for debug
New tracepoints aspeed_pcie_phy_read and aspeed_pcie_phy_write allow
monitoring MMIO accesses.

4. Register space and defaults (AST2600 reference)
Expose a 0x100 register space, as documented in the AST2600 datasheet.
On reset, set default values:
PEHR_ID: Vendor ID = ASPEED, Device ID = 0x1150
PEHR_CLASS_CODE = 0x06040006
PEHR_DATALINK = 0xD7040022
PEHR_LINK: bit[5] set to 1 to indicate link up.

This provides a skeleton device for the AST2600 platform. It enables
firmware to detect the PCIe link as up by default and allows future
extension.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250819090141.3949136-3-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm: Integrate ASPEED OTP memory support into AST1030 SoCs

The has_otp attribute is enabled in the SBC subclasses for AST1030 to
control the presence of OTP support per SoC type.

Signed-off-by:

hw/arm: Integrate ASPEED OTP memory support into AST1030 SoCs

The has_otp attribute is enabled in the SBC subclasses for AST1030 to
control the presence of OTP support per SoC type.

Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250812094011.2617526-7-kane_chen@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm: Integrate ASPEED OTP memory support into AST2600 SoCs

The has_otp attribute is enabled in the SBC subclasses for AST2600 to
control the presence of OTP support per SoC type.

Signed-off-by:

hw/arm: Integrate ASPEED OTP memory support into AST2600 SoCs

The has_otp attribute is enabled in the SBC subclasses for AST2600 to
control the presence of OTP support per SoC type.

Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250812094011.2617526-4-kane_chen@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/misc/aspeed_scu: Add SCU support for TSP SDRAM remap

This commit adds SCU register support for TSP SDRAM remap control and runtime
activation. Unlike SSP, the TSP does not support configurable ta

hw/misc/aspeed_scu: Add SCU support for TSP SDRAM remap

This commit adds SCU register support for TSP SDRAM remap control and runtime
activation. Unlike SSP, the TSP does not support configurable target address remapping
through SCU registers. It only supports setting the PSP DRAM base and size, which
are then aliased into the TSP-visible SDRAM window.

One MemoryRegion alias is attached to the SCU via QOM property link:
- tsp-sdram-remap: maps PSP DRAM at 0x42E000000 (size: 32MB) to TSP SDRAM
offset 0x0

The SCU registers AST2700_SCU_TSP_CTRL_1 and
AST2700_SCU_TSP_REMAP_SIZE_2 allow runtime reconfiguration of the DRAM base (alias offset)
and mapping size.

|------------------------------------------| |----------------------------|
| PSP DRAM | | TSP SDRAM |
|------------------------------------------| |----------------------------|
| 0x42E0_0000_0 (SCU_168 << 4) | | 0x0000_0000 |
| remap base |------> | - fixed target addr |
| size: 32MB (SCU_194) | | |
|------------------------------------------| |----------------------------|

SCU VMState version remains at 3, as it was already bumped in a previous commit.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-17-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/misc/aspeed_scu: Add SCU support for SSP SDRAM remap

This commit adds SCU register support for SSP SDRAM remap control and runtime
activation. It introduces logic for the PSP to dynamically confi

hw/misc/aspeed_scu: Add SCU support for SSP SDRAM remap

This commit adds SCU register support for SSP SDRAM remap control and runtime
activation. It introduces logic for the PSP to dynamically configure the mapping
of its own DRAM windows into SSP-visible SDRAM space, enabling shared memory
communication via memory region aliases.

Two MemoryRegion aliases are attached to the SCU via QOM property links:
- ssp-sdram-remap1: maps PSP DRAM at 0x400000000 (size: 32MB) to SSP SDRAM
offset 0x2000000
- ssp-sdram-remap2: maps PSP DRAM at 0x42c000000 (size: 32MB) to SSP SDRAM
offset 0x0

The SCU registers AST2700_SCU_SSP_CTRL_1/2 and
AST2700_SCU_SSP_REMAP_ADDR_{1,2} / REMAP_SIZE_{1,2} allow runtime reconfiguration
of alias offset, base, and size.

Bumps the SCU VMState version to 3.

|------------------------------------------| |----------------------------|
| PSP DRAM | | SSP SDRAM |
|------------------------------------------| |----------------------------|
| 0x4_0000_0000 (SCU_124 << 4) | --> | 0x0000_0000 |
| remap1 base |---| | | - SCU_150: target addr |
| size: 32MB (SCU_14C) | | | | remap2 |
|------------------------------------------| | | |----------------------------|
| | | | | |
| 0x4_2C00_0000 (SCU_128 << 4) |-----| | 0x0200_0000 |
| remap2 base | | | - SCU_148: target addr |
| size: 32MB (SCU_154) | |---> | remap1 |
|------------------------------------------| |----------------------------|

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-16-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Start TSP in powered-off state to match hardware behavior

In the previous design, both the PSP and TSP were started together during
SoC initialization. However, on real hardware, the

hw/arm/ast27x0: Start TSP in powered-off state to match hardware behavior

In the previous design, both the PSP and TSP were started together during
SoC initialization. However, on real hardware, the TSP begins in a powered-off
state. The typical boot sequence involves the PSP powering up first, loading
the TSP firmware binary into shared memory via DRAM remap, and then releasing
the TSP reset and enabling it through SCU control registers.

To more accurately model this behavior in QEMU, this commit sets the
"start-powered-off" property for the TSP's ARMv7M core. This change ensures
the TSP remains off until explicitly enabled via the SCU, simulating the
real-world flow where the PSP controls TSP boot through SCU interaction.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-15-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Start SSP in powered-off state to match hardware behavior

In the previous design, both the PSP and SSP were started together during
SoC initialization. However, on real hardware, the

hw/arm/ast27x0: Start SSP in powered-off state to match hardware behavior

In the previous design, both the PSP and SSP were started together during
SoC initialization. However, on real hardware, the SSP begins in a powered-off
state. The typical boot sequence involves the PSP powering up first, loading
the SSP firmware binary into shared memory via DRAM remap, and then releasing
the SSP reset and enabling it through SCU control registers.

To more accurately model this behavior in QEMU, this commit sets the
"start-powered-off" property for the SSP's ARMv7M core. This change ensures
the SSP remains off until explicitly enabled via the SCU, simulating the
real-world flow where the PSP controls SSP boot through SCU interaction.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-14-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add DRAM alias for TSP SDRAM remap and update realization order

This commit adds a MemoryRegion alias to support PSP access to
TSP SDRAM through shared memory remapping, as defined b

hw/arm/ast27x0: Add DRAM alias for TSP SDRAM remap and update realization order

This commit adds a MemoryRegion alias to support PSP access to
TSP SDRAM through shared memory remapping, as defined by the default SCU
configuration.

The TSP coprocessor exposes one DRAM alias:
- remap maps PSP DRAM at 0x42e000000 (32MB) to TSP SDRAM offset 0x0

This region corresponds to the default SCU register value, which controls
the mapping between PSP and coprocessor memory windows.

To ensure correctness, the alias is initialized early in
aspeed_soc_ast2700_realize(), before SCU and coprocessor realization.
This allows TSP to reference the alias region during its SDRAM setup.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-13-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add DRAM alias for SSP SDRAM remap and update realization order

This commit adds two MemoryRegion aliases to support PSP access to
SSP SDRAM through shared memory remapping, as defin

hw/arm/ast27x0: Add DRAM alias for SSP SDRAM remap and update realization order

This commit adds two MemoryRegion aliases to support PSP access to
SSP SDRAM through shared memory remapping, as defined by the default SCU
configuration.

The SSP coprocessor exposes two DRAM aliases:
- remap1 maps PSP DRAM at 0x400000000 (32MB) to SSP SDRAM offset 0x2000000
- remap2 maps PSP DRAM at 0x42c000000 (32MB) to SSP SDRAM offset 0x0

These regions correspond to the default SCU register values, which control
the mapping between PSP and coprocessor memory windows.

To ensure correctness, the aliases are initialized early in
aspeed_soc_ast2700_realize(), before SCU and coprocessor realization.
This allows SSP to reference the alias regions during its SDRAM setup.

Additionally, the realization order comment has been updated to reflect
the new DRAM dependency: coprocessors must now be realized after DRAM,
SRAM, and SCU are all initialized.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-12-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Move DRAM and SDMC initialization earlier to support memory aliasing

To support DRAM aliasing for coprocessors (SSP/TSP), this commit moves the
initialization of the SDMC (SDRAM cont

hw/arm/ast27x0: Move DRAM and SDMC initialization earlier to support memory aliasing

To support DRAM aliasing for coprocessors (SSP/TSP), this commit moves the
initialization of the SDMC (SDRAM controller) and DRAM models earlier in
the device realization order.

In the upcoming changes, the PSP will expose a portion of its DRAM as shared
memory by creating a memory region alias at a specific offset. This alias is
mapped into the coprocessor's SDRAM address space, allowing both PSP and the
coprocessor (SSP/TSP) to access the same physical memory through their respective
views — PSP via its DRAM, and the coprocessor via its SDRAM.

The remapping is configured through SCU registers and enables shared memory
communication between PSP and the coprocessors.

Therefore, the DRAM and SDMC devices must be realized before:
- the SCU, which configures the alias offset and size
- the coprocessors, which access the alias through their SDRAM window

No functional change.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-11-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add SCU alias for TSP and ensure correct device realization order

AST2700 has a single SCU hardware block, memory-mapped at 0x12C02000–0x12C03FFF
from the perspective of the main CA3

hw/arm/ast27x0: Add SCU alias for TSP and ensure correct device realization order

AST2700 has a single SCU hardware block, memory-mapped at 0x12C02000–0x12C03FFF
from the perspective of the main CA35 processor (PSP). The TSP coprocessor accesses
this same SCU block at a different address: 0x72C02000–0x72C03FFF.

To support this shared SCU model, this commit introduces "tsp.scu_mr_alias",
a "MemoryRegion" alias of the original SCU region ("s->scu.iomem"). The alias is
realized during TSP SoC setup and mapped into the TSP's SoC memory map.

Additionally, because the SCU must be realized before the TSP can create an alias
to it, the device realization order is explicitly managed:
"aspeed_soc_ast2700_tsp_realize()" is invoked after the SCU is initialized.

This ensures that PSP and TSP access a consistent SCU state, as expected by hardware.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-10-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add SCU alias for SSP and ensure correct device realization order

AST2700 has a single SCU hardware block, memory-mapped at 0x12C02000–0x12C03FFF
from the perspective of the main CA3

hw/arm/ast27x0: Add SCU alias for SSP and ensure correct device realization order

AST2700 has a single SCU hardware block, memory-mapped at 0x12C02000–0x12C03FFF
from the perspective of the main CA35 processor (PSP). The SSP coprocessor accesses
this same SCU block at a different address: 0x72C02000–0x72C03FFF.

To support this shared SCU model, this commit introduces "ssp.scu_mr_alias",
a "MemoryRegion" alias of the original SCU region ("s->scu.iomem"). The alias is
realized during SSP SoC setup and mapped into the SSP's SoC memory map.

Additionally, because the SCU must be realized before the SSP can create an alias
to it, the device realization order is explicitly managed:
"aspeed_soc_ast2700_ssp_realize()" is invoked after the SCU is initialized.

This ensures that PSP and SSP access a consistent SCU state, as expected by hardware.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-9-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add SRAM alias for TSP and ensure correct device realization order

AST2700 has a 128KB SRAM, physically mapped at 0x10000000–0x1001FFFF for the
main CA35 processor. The TSP coprocess

hw/arm/ast27x0: Add SRAM alias for TSP and ensure correct device realization order

AST2700 has a 128KB SRAM, physically mapped at 0x10000000–0x1001FFFF for the
main CA35 processor. The TSP coprocessor accesses this same memory at a
different memory address: 0x70000000–0x7001FFFF.

To support this shared memory model, this commit introduces "tsp.sram_mr_alias",
a "MemoryRegion" alias of the original SRAM region ("s->sram"). The alias is
realized during TSP SoC setup and mapped into the TSP's SoC memory map.

Additionally, because the SRAM must be realized before the TSP can create an
alias to it, the device realization order is explicitly managed:
"aspeed_soc_ast2700_tsp_realize()" is invoked after SRAM is initialized.

This ensures that TSP’s access to shared SRAM functions correctly.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-8-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/ast27x0: Add SRAM alias for SSP and ensure correct device realization order

AST2700 has a 128KB SRAM, physically mapped at 0x10000000–0x1001FFFF for the
main CA35 processor. The SSP coprocess

hw/arm/ast27x0: Add SRAM alias for SSP and ensure correct device realization order

AST2700 has a 128KB SRAM, physically mapped at 0x10000000–0x1001FFFF for the
main CA35 processor. The SSP coprocessor accesses this same memory at a
different memory address: 0x70000000–0x7001FFFF.

To support this shared memory model, this commit introduces "ssp.sram_mr_alias",
a "MemoryRegion" alias of the original SRAM region ("s->sram"). The alias is
realized during SSP SoC setup and mapped into the SSP's SoC memory map.

Additionally, because the SRAM must be realized before the SSP can create an
alias to it, the device realization order is explicitly managed:
"aspeed_soc_ast2700_ssp_realize()" is invoked after SRAM is initialized.

This ensures that SSP’s access to shared SRAM functions correctly.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-7-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...

hw/arm/aspeed_ast27x0-tsp: Switch TSP memory to SDRAM and use dram_container for remap support

According to the AST2700 design, the TSP coprocessor uses its own SDRAM
instead of SRAM. Additionally,

hw/arm/aspeed_ast27x0-tsp: Switch TSP memory to SDRAM and use dram_container for remap support

According to the AST2700 design, the TSP coprocessor uses its own SDRAM
instead of SRAM. Additionally, all three coprocessors—SSP, TSP, and PSP—share
a common SRAM block. In the previous implementation, the TSP memory region
was labeled and sized as "SRAM", but in practice it was being used as TSP's
local SDRAM.

This commit updates the TSP memory mapping to reflect the correct hardware
design:

- Replace the SRAM region with a 512MB SDRAM region starting at 0x0.
- Rename the internal variable from `sram` to `dram_container` for clarity.
- Use "AST2700_TSP_SDRAM_SIZE" (512MB) instead of the previous 32MB SRAM size.
- Map the new region using "ASPEED_DEV_SDRAM" instead of "ASPEED_DEV_SRAM".

This change also prepares for future enhancements where PSP DRAM will be
remapped into this TSP SDRAM container using subregions at specific offsets.
Using "dram_container" makes it easier to manage aliases and remap logic.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Link: https://lore.kernel.org/qemu-devel/20250717034054.1903991-6-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>

show more ...