aspeed: Split the machine definition into individual source files

aspeed: Split the machine definition into individual source files

[Cédric Le Goater]

Hi,

This is a follow up of a private discussion with Patrick.

Aspeed modeling started nearly 10y ago with the palmetto-bmc machine.
We now have 5 SoCs and 25 machines which are mostly defined in
in a single aspeed.c file. Multi SoC machines, fby35 and ast2700fc,
are defined in fby35.c and aspeed_ast27x0-fc.c respectively.

Since we started separating the SoCs :

   hw/arm/aspeed_ast10x0.c
   hw/arm/aspeed_ast2400.c
   hw/arm/aspeed_ast2600.c
   hw/arm/aspeed_ast27x0.c
   hw/arm/aspeed_ast27x0-ssp.c
   hw/arm/aspeed_ast27x0-tsp.c

We could do the same for the machines keeping an 'aspeed_ast<rev>'
prefix (and maybe avoid the 'bmc' suffix). I think this would ease
introduction of new machines. We would be able to get rid of
aspeed_eeprom.[ch] and move machine custom data in the machine source
file. Which seems cleaner.

Timing is about right for code reshuffling, still 3w before soft
freeze, no important changes inflight, but if we start doing this
conversion, we should do it for all. See the list below for the brave.

Comments ?

Thanks,

C.



* AST2400
   
   palmetto-bmc
   quanta-q71l-bmc
   supermicrox11-bmc
   
* AST2500
   
   ast2500-evb
   romulus-bmc
   sonorapass-bmc
   witherspoon-bmc
   yosemitev2-bmc
   supermicro-x11spi-bmc
   fp5280g2-bmc
   g220a-bmc
   tiogapass-bmc
   
* AST2600
   
   ast2600-evb
   qcom-dc-scm-v1-bmc
   qcom-firework-bmc
   rainier-bmc
   fuji-bmc
   bletchley-bmc
   fby35-bmc           (fby35.c should rename to aspeed_ast2600-fby35.c)
   
* AST2700
   
   ast2700a0-evb
   ast2700a1-evb
   ast2700fc           (aspeed_ast27x0-fc.c)
   
* AST1030
   
   ast1030-evb

Re: aspeed: Split the machine definition into individual source files

[Troy Lee]

Hi,
On Thu, Jun 19, 2025 at 5:24 PM Cédric Le Goater <clg@kaod.org> wrote:
>
> Hi,
>
> This is a follow up of a private discussion with Patrick.
>
> Aspeed modeling started nearly 10y ago with the palmetto-bmc machine.
> We now have 5 SoCs and 25 machines which are mostly defined in
> in a single aspeed.c file. Multi SoC machines, fby35 and ast2700fc,
> are defined in fby35.c and aspeed_ast27x0-fc.c respectively.
>

Sounds good to me.
While we're on this subject, we have many variants of the AST27x0 SoC
and development boards in different form factors. Should we also create
separate SoC models and machine definitions for each one? Or can we
treat AST27x0 as a superset of AST2700, AST2750, AST2720, and
any future models?

Thanks,
Troy Lee

> Since we started separating the SoCs :
>
>    hw/arm/aspeed_ast10x0.c
>    hw/arm/aspeed_ast2400.c
>    hw/arm/aspeed_ast2600.c
>    hw/arm/aspeed_ast27x0.c
>    hw/arm/aspeed_ast27x0-ssp.c
>    hw/arm/aspeed_ast27x0-tsp.c
>
> We could do the same for the machines keeping an 'aspeed_ast<rev>'
> prefix (and maybe avoid the 'bmc' suffix). I think this would ease
> introduction of new machines. We would be able to get rid of
> aspeed_eeprom.[ch] and move machine custom data in the machine source
> file. Which seems cleaner.
>
> Timing is about right for code reshuffling, still 3w before soft
> freeze, no important changes inflight, but if we start doing this
> conversion, we should do it for all. See the list below for the brave.
>
> Comments ?
>
> Thanks,
>
> C.
>
>
>
> * AST2400
>
>    palmetto-bmc
>    quanta-q71l-bmc
>    supermicrox11-bmc
>
> * AST2500
>
>    ast2500-evb
>    romulus-bmc
>    sonorapass-bmc
>    witherspoon-bmc
>    yosemitev2-bmc
>    supermicro-x11spi-bmc
>    fp5280g2-bmc
>    g220a-bmc
>    tiogapass-bmc
>
> * AST2600
>
>    ast2600-evb
>    qcom-dc-scm-v1-bmc
>    qcom-firework-bmc
>    rainier-bmc
>    fuji-bmc
>    bletchley-bmc
>    fby35-bmc           (fby35.c should rename to aspeed_ast2600-fby35.c)
>
> * AST2700
>
>    ast2700a0-evb
>    ast2700a1-evb
>    ast2700fc           (aspeed_ast27x0-fc.c)
>
> * AST1030
>
>    ast1030-evb
>

Re: aspeed: Split the machine definition into individual source files

[Cédric Le Goater]

On 6/19/25 16:54, Troy Lee wrote:
> Hi,
> On Thu, Jun 19, 2025 at 5:24 PM Cédric Le Goater <clg@kaod.org> wrote:
>>
>> Hi,
>>
>> This is a follow up of a private discussion with Patrick.
>>
>> Aspeed modeling started nearly 10y ago with the palmetto-bmc machine.
>> We now have 5 SoCs and 25 machines which are mostly defined in
>> in a single aspeed.c file. Multi SoC machines, fby35 and ast2700fc,
>> are defined in fby35.c and aspeed_ast27x0-fc.c respectively.
>>
> 
> Sounds good to me.
>
> While we're on this subject, we have many variants of the AST27x0 SoC
> and development boards in different form factors. Should we also create
> separate SoC models and machine definitions for each one? Or can we
> treat AST27x0 as a superset of AST2700, AST2750, AST2720, and
> any future models?

I think keeping models for the AST27x0 SoC family in the same
source file is fine for now. We have introduced aspeed_ast27x0-ssp.c
and aspeed_ast27x0-tsp.c but these are service processor and are using
Cortex-M4 processors.

Thanks,

C.

Re: aspeed: Split the machine definition into individual source files

[Andrew Jeffery]

On Thu, 2025-06-19 at 11:23 +0200, Cédric Le Goater wrote:
> Hi,
> 
> This is a follow up of a private discussion with Patrick.
> 
> Aspeed modeling started nearly 10y ago with the palmetto-bmc machine.
> We now have 5 SoCs and 25 machines which are mostly defined in
> in a single aspeed.c file. Multi SoC machines, fby35 and ast2700fc,
> are defined in fby35.c and aspeed_ast27x0-fc.c respectively.
> 
> Since we started separating the SoCs :
> 
>    hw/arm/aspeed_ast10x0.c
>    hw/arm/aspeed_ast2400.c
>    hw/arm/aspeed_ast2600.c
>    hw/arm/aspeed_ast27x0.c
>    hw/arm/aspeed_ast27x0-ssp.c
>    hw/arm/aspeed_ast27x0-tsp.c
> 
> We could do the same for the machines keeping an 'aspeed_ast<rev>'
> prefix (and maybe avoid the 'bmc' suffix). I think this would ease
> introduction of new machines. We would be able to get rid of
> aspeed_eeprom.[ch] and move machine custom data in the machine source
> file. Which seems cleaner.
> 
> Timing is about right for code reshuffling, still 3w before soft
> freeze, no important changes inflight, but if we start doing this
> conversion, we should do it for all. See the list below for the
> brave.

My involvement has dropped off quite a bit, but for what it's worth,
this seems sensible to me :)

Andrew