On 5/2/25 04:06, Steven Lee wrote:
Hi Cédric,

-----Original Message-----
From: Cédric Le Goater <c...@kaod.org>
Sent: Wednesday, April 30, 2025 5:46 PM
To: Steven Lee <steven_...@aspeedtech.com>; Peter Maydell
<peter.mayd...@linaro.org>; Troy Lee <leet...@gmail.com>; Jamin Lin
<jamin_...@aspeedtech.com>; Andrew Jeffery
<and...@codeconstruct.com.au>; Joel Stanley <j...@jms.id.au>; open
list:ASPEED BMCs <qemu-...@nongnu.org>; open list:All patches CC here
<qemu-devel@nongnu.org>
Cc: Troy Lee <troy_...@aspeedtech.com>; long...@lenovo.com; Yunlin Tang
<yunlin.t...@aspeedtech.com>
Subject: Re: [PATCH v3 5/9] hw/arm/aspeed_ast27x0-ssp: Introduce AST27x0
A1 SSP SoC

On 4/29/25 11:18, Steven Lee wrote:
The AST2700 SSP (Secondary Service Processor) is a Cortex-M4 coprocessor.
This patch adds support for A1 SSP with the following updates:

- Introduce Aspeed27x0SSPSoCState structure in aspeed_soc.h
- Define memory map and IRQ map for AST27x0 A1 SSP SoC
- Implement initialization and realization functions
- Add support for UART, INTC, and SCU devices
- Map unimplemented devices for IPC and SCUIO

The IRQ mapping is similar to AST2700 CA35 SoC, featuring a two-level
interrupt controller.

Difference from AST2700:

      - AST2700
        - Support GICINT128 to GICINT136 in INTC
        - The INTCIO GIC_192_201 has 10 output pins, mapped as follows:
            Bit 0 -> GIC 192
            Bit 1 -> GIC 193
            Bit 2 -> GIC 194
            Bit 3 -> GIC 195
            Bit 4 -> GIC 196

      - AST2700-ssp
        - Support SSPINT128 to SSPINT136 in INTC
        - The INTCIO SSPINT_160_169 has 10 output pins, mapped as
follows:
            Bit 0 -> SSPINT 160
            Bit 1 -> SSPINT 161
            Bit 2 -> SSPINT 162
            Bit 3 -> SSPINT 163
            Bit 4 -> SSPINT 164

Signed-off-by: Steven Lee <steven_...@aspeedtech.com>
Change-Id: I924bf1a657f1e83f9e16d6673713f4a06ecdb496
---
   include/hw/arm/aspeed_soc.h |  14 ++
   hw/arm/aspeed_ast27x0-ssp.c | 309
++++++++++++++++++++++++++++++++++++
   hw/arm/meson.build          |   1 +
   3 files changed, 324 insertions(+)
   create mode 100644 hw/arm/aspeed_ast27x0-ssp.c

diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index dd5fb731e2..7c65324801 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -145,6 +145,18 @@ struct Aspeed10x0SoCState {
       ARMv7MState armv7m;
   };

+struct Aspeed27x0SSPSoCState {
+    AspeedSoCState parent;
+    AspeedINTCState intc[2];
+    UnimplementedDeviceState ipc[2];
+    UnimplementedDeviceState scuio;
+
+    ARMv7MState armv7m;
+};
+
+
+static void aspeed_soc_ast27x0ssp_class_init(ObjectClass *klass, void
+*data) {
+    static const char * const valid_cpu_types[] = {
+        ARM_CPU_TYPE_NAME("cortex-m4"), /* TODO: cortex-m4f */

So no FPU ?  I wonder what "cortex-m4" CPU model in QEMU implements.
Something to check.


The SSP core on the AST2700 is based on a Cortex-M4 with FPU (M4F).
However, QEMU only provides cortex-m4 at the moment, so I'm using that for now.

Yes. I checked and the cortex-m4 doesn't have FPU support.


+        NULL
+    };
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    AspeedSoCClass *sc = ASPEED_SOC_CLASS(dc);
+
+    /* Reason: The Aspeed SoC can only be instantiated from a board */
+    dc->user_creatable = false;
+    dc->realize = aspeed_soc_ast27x0ssp_realize;
+
+    sc->valid_cpu_types = valid_cpu_types;
+    sc->silicon_rev = AST2700_A1_SILICON_REV;
+    sc->sram_size = AST2700_SSP_RAM_SIZE;
+    sc->spis_num = 0;
+    sc->ehcis_num = 0;
+    sc->wdts_num = 0;
+    sc->macs_num = 0;
+    sc->uarts_num = 13;
+    sc->uarts_base = ASPEED_DEV_UART0;
+    sc->irqmap = aspeed_soc_ast27x0ssp_irqmap;
+    sc->memmap = aspeed_soc_ast27x0ssp_memmap;
+    sc->num_cpus = 1;
+    sc->get_irq = aspeed_soc_ast27x0ssp_get_irq; }
+
+static const TypeInfo aspeed_soc_ast27x0ssp_types[] = {
+    {
+        .name           = TYPE_ASPEED27X0SSP_SOC,
+        .parent         = TYPE_ASPEED_SOC,
+        .instance_size  = sizeof(Aspeed27x0SSPSoCState),
+        .abstract       = true,

The abstract class doesn't seem useful. why keep it ?



Thanks for pointing that out, it was originally introduced to support both A0 
and A1 SoCs.
After dropping A0 support, I forgot to remove the abstract class.
I'll clean it up in the v4 patch series.
Thanks,

C.



Reply via email to