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

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

[Jamin Lin]

Hi all

> Subject: aspeed: Split the machine definition into individual source files
> 
> 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


I’ve started working on this refactoring and have sent the first patch for the AST1030:
https://patchwork.kernel.org/project/qemu-devel/patch/20251015081219.2766143-2-jamin_lin@aspeedtech.com/
I’m doing this because I plan to add a new machine for the AST1060, and it seems like a good opportunity to perform this cleanup first.
I just want to make sure I’m moving in the right direction — could you please help review it?

If you agree with the following plan, I’ll create a new patch series to move all existing machines into separate aspeed_ast<rev>_boards.c files:

Planned structure
Create aspeed_ast10x0_boards.c
 ast1030-evb

Create aspeed_ast2400_boards.c
  palmetto-bmc
  quanta-q71l-bmc
  supermicrox11-bmc

Create aspeed_ast2500_boards.c
(Or should these be grouped with aspeed_ast2400_boards.c? — I’d appreciate your thoughts.)
 ast2500-evb
 romulus-bmc
 sonorapass-bmc
 witherspoon-bmc
 yosemitev2-bmc
 supermicro-x11spi-bmc
 fp5280g2-bmc
 g220a-bmc
 tiogapass-bmc

Create aspeed_ast2600_boards.c
 ast2600-evb
 qcom-dc-scm-v1-bmc
 qcom-firework-bmc
 rainier-bmc
 fuji-bmc
 bletchley-bmc

Rename
fby35.c -> aspeed_ast2600-fby35.c
 fby35-bmc

Create aspeed_ast27x0_board.c
    ast2700a0-evb
    ast2700a1-evb

Keep
aspeed_ast27x0-fc.c
  ast2700fc


One last question
Do you think it’s better to:
Create one commit per SoC generation (e.g. one for all AST2500-based machines),
or
Create one commit per board (e.g. one for ast2500-evb, one for romulus-bmc, etc.)?

Thanks,
Jamin

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

[Philippe Mathieu-Daudé]

On 19/6/25 11:23, 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.
> 
> Comments ?

Good idea, but please split ASPEED_SOC in Kconfig accordingly.

Regards,

Phil.

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

[Cédric Le Goater]

On 10/16/25 04:30, Jamin Lin wrote:
> Hi all
> 
>> Subject: aspeed: Split the machine definition into individual source files
>>
>> 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
> 
> 
> I’ve started working on this refactoring and have sent the first patch for the AST1030:
> https://patchwork.kernel.org/project/qemu-devel/patch/20251015081219.2766143-2-jamin_lin@aspeedtech.com/
> I’m doing this because I plan to add a new machine for the AST1060, and it seems like a good opportunity to perform this cleanup first.
> I just want to make sure I’m moving in the right direction — could you please help review it?
> 
> If you agree with the following plan, I’ll create a new patch series to move all existing machines into separate aspeed_ast<rev>_boards.c files:
> > Planned structure
> Create aspeed_ast10x0_boards.c
>   ast1030-evb
> 
> Create aspeed_ast2400_boards.c
>    palmetto-bmc
>    quanta-q71l-bmc
>    supermicrox11-bmc
> 
> Create aspeed_ast2500_boards.c
> (Or should these be grouped with aspeed_ast2400_boards.c? — I’d appreciate your thoughts.)

no. I'd prefer keeping a consistent 'aspeed_ast<rev>' prefix.

>   ast2500-evb
>   romulus-bmc
>   sonorapass-bmc
>   witherspoon-bmc
>   yosemitev2-bmc
>   supermicro-x11spi-bmc
>   fp5280g2-bmc
>   g220a-bmc
>   tiogapass-bmc
> 
> Create aspeed_ast2600_boards.c
>   ast2600-evb
>   qcom-dc-scm-v1-bmc
>   qcom-firework-bmc
>   rainier-bmc
>   fuji-bmc
>   bletchley-bmc
> 
> Rename
> fby35.c -> aspeed_ast2600-fby35.c
>   fby35-bmc
> 
> Create aspeed_ast27x0_board.c
>      ast2700a0-evb
>      ast2700a1-evb
> 
> Keep
> aspeed_ast27x0-fc.c
>    ast2700fc
> 
> 
> One last question
> Do you think it’s better to:
> Create one commit per SoC generation (e.g. one for all AST2500-based machines),
> or
> Create one commit per board (e.g. one for ast2500-evb, one for romulus-bmc, etc.)?

One per machine/board please.

Initially, I thought we would introduce one 'aspeed_ast<rev>_<board>.c'
file per machine/board but that might be too intrusive. At the same
time, it would provide a clear view of how many boards QEMU models
for each SoC revision. What do you think ?


Eventually, file 'aspeed_eeprom.c' would be removed, so would file
'aspeed.c'. 'aspeed_coprocessor_common.c' should probably be renamed.
File 'aspeed_soc_common.c' should become 'aspeed_common.c' probably.


Thanks,

C.

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

[Jamin Lin]

Hi Cédric, 

> Subject: Re: aspeed: Split the machine definition into individual source files
> 
> On 10/16/25 04:30, Jamin Lin wrote:
> > Hi all
> >
> >> Subject: aspeed: Split the machine definition into individual source
> >> files
> >>
> >> 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
> >
> >
> > I’ve started working on this refactoring and have sent the first patch for the
> AST1030:
> > https://patchwork.kernel.org/project/qemu-devel/patch/20251015081219.2
> > 766143-2-jamin_lin@aspeedtech.com/
> > I’m doing this because I plan to add a new machine for the AST1060, and it
> seems like a good opportunity to perform this cleanup first.
> > I just want to make sure I’m moving in the right direction — could you please
> help review it?
> >
> > If you agree with the following plan, I’ll create a new patch series to move
> all existing machines into separate aspeed_ast<rev>_boards.c files:
> > > Planned structure
> > Create aspeed_ast10x0_boards.c
> >   ast1030-evb
> >
> > Create aspeed_ast2400_boards.c
> >    palmetto-bmc
> >    quanta-q71l-bmc
> >    supermicrox11-bmc
> >
> > Create aspeed_ast2500_boards.c
> > (Or should these be grouped with aspeed_ast2400_boards.c? — I’d
> > appreciate your thoughts.)
> 
> no. I'd prefer keeping a consistent 'aspeed_ast<rev>' prefix.
> 
> >   ast2500-evb
> >   romulus-bmc
> >   sonorapass-bmc
> >   witherspoon-bmc
> >   yosemitev2-bmc
> >   supermicro-x11spi-bmc
> >   fp5280g2-bmc
> >   g220a-bmc
> >   tiogapass-bmc
> >
> > Create aspeed_ast2600_boards.c
> >   ast2600-evb
> >   qcom-dc-scm-v1-bmc
> >   qcom-firework-bmc
> >   rainier-bmc
> >   fuji-bmc
> >   bletchley-bmc
> >
> > Rename
> > fby35.c -> aspeed_ast2600-fby35.c
> >   fby35-bmc
> >
> > Create aspeed_ast27x0_board.c
> >      ast2700a0-evb
> >      ast2700a1-evb
> >
> > Keep
> > aspeed_ast27x0-fc.c
> >    ast2700fc
> >
> >
> > One last question
> > Do you think it’s better to:
> > Create one commit per SoC generation (e.g. one for all AST2500-based
> > machines), or Create one commit per board (e.g. one for ast2500-evb,
> > one for romulus-bmc, etc.)?
> 
> One per machine/board please.
> 
> Initially, I thought we would introduce one 'aspeed_ast<rev>_<board>.c'
> file per machine/board but that might be too intrusive. At the same time, it
> would provide a clear view of how many boards QEMU models for each SoC
> revision. What do you think ?
> 
> 
> Eventually, file 'aspeed_eeprom.c' would be removed, so would file 'aspeed.c'.
> 'aspeed_coprocessor_common.c' should probably be renamed.
> File 'aspeed_soc_common.c' should become 'aspeed_common.c' probably.
> 

I plan to submit the following patch series to implement these changes.

Patch series 1
hw/arm/aspeed_ast1030_evb.c (ast1030-evb) ---> or hw/arm/aspeed_ast10x0_evb.c, then we can place (ast1030-evb and ast1060-evb)
hw/arm/aspeed_ast27x0_evb.c (ast2700a0-evb, ast2700a1-evb)

Patch series 2
hw/arm/aspeed_ast2400_palmetto.c (palmetto-bmc)
hw/arm/aspeed_ast2400_quanta-q71l.c (quanta-q71l-bmc)
hw/arm/aspeed_ast2400_supermicrox11.c (supermicrox11-bmc)

Patch series 3
hw/arm/aspeed_ast2500_evb.c (ast2500-evb)
hw/arm/aspeed_ast2500_romulus.c (romulus-bmc)
hw/arm/aspeed_ast2500_sonorapass.c (sonorapass-bmc)
hw/arm/aspeed_ast2500_witherspoon.c (witherspoon-bmc)
hw/arm/aspeed_ast2500_yosemitev2.c (yosemitev2-bmc)
hw/arm/aspeed_ast2500_supermicro-x11spi.c (supermicro-x11spi-bmc)
hw/arm/aspeed_ast2500_fp5280g2.c (fp5280g2-bmc)
hw/arm/aspeed_ast2500_g220a.c (g220a-bmc)
hw/arm/aspeed_ast2500_tiogapass.c (tiogapass-bmc)

Patch series 4
hw/arm/aspeed_ast2600_evb.c (ast2600-evb)
hw/arm/aspeed_ast2600_qcom-dc-scm-v1.c (qcom-dc-scm-v1-b mc)
hw/arm/aspeed_ast2600_qcom-firework-bmc.c (qcom-firework-bmc)
hw/arm/aspeed_ast2600_rainier.c (rainier-bmc)
hw/arm/aspeed_ast2600_fuji.c (fuji-bmc)
hw/arm/aspeed_ast2600_bletchley.c (bletchley-bmc)
hw/arm/aspeed_ast2600_ fby35.c (fby35-bmc)

For the FBY35 platform, since it includes both AST1030 and AST2600, we may consider renaming the file to:
hw/arm/aspeed_ast1030_ast2600_fby35.c  (hw/arm/fby35.c)

We will keep the following file as is:
hw/arm/aspeed_ast27x0-fc.c (ast2700fc)

Thanks,
Jamin

> 
> Thanks,
> 
> C.
> 

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

[Cédric Le Goater]

Hi,


> Patch series 1
> hw/arm/aspeed_ast1030_evb.c (ast1030-evb) ---> or hw/arm/aspeed_ast10x0_evb.c, then we can place (ast1030-evb and ast1060-evb)
> hw/arm/aspeed_ast27x0_evb.c (ast2700a0-evb, ast2700a1-evb)
> 
> Patch series 2
> hw/arm/aspeed_ast2400_palmetto.c (palmetto-bmc)
> hw/arm/aspeed_ast2400_quanta-q71l.c (quanta-q71l-bmc)
> hw/arm/aspeed_ast2400_supermicrox11.c (supermicrox11-bmc)
> 
> Patch series 3
> hw/arm/aspeed_ast2500_evb.c (ast2500-evb)
> hw/arm/aspeed_ast2500_romulus.c (romulus-bmc)
> hw/arm/aspeed_ast2500_sonorapass.c (sonorapass-bmc)
> hw/arm/aspeed_ast2500_witherspoon.c (witherspoon-bmc)
> hw/arm/aspeed_ast2500_yosemitev2.c (yosemitev2-bmc)
> hw/arm/aspeed_ast2500_supermicro-x11spi.c (supermicro-x11spi-bmc)
> hw/arm/aspeed_ast2500_fp5280g2.c (fp5280g2-bmc)
> hw/arm/aspeed_ast2500_g220a.c (g220a-bmc)
> hw/arm/aspeed_ast2500_tiogapass.c (tiogapass-bmc)
> 
> Patch series 4
> hw/arm/aspeed_ast2600_evb.c (ast2600-evb)
> hw/arm/aspeed_ast2600_qcom-dc-scm-v1.c (qcom-dc-scm-v1-b mc)
> hw/arm/aspeed_ast2600_qcom-firework-bmc.c (qcom-firework-bmc)
> hw/arm/aspeed_ast2600_rainier.c (rainier-bmc)
> hw/arm/aspeed_ast2600_fuji.c (fuji-bmc)
> hw/arm/aspeed_ast2600_bletchley.c (bletchley-bmc)
> hw/arm/aspeed_ast2600_ fby35.c (fby35-bmc)
> 
> For the FBY35 platform, since it includes both AST1030 and AST2600, we may consider renaming the file to:
> hw/arm/aspeed_ast1030_ast2600_fby35.c  (hw/arm/fby35.c)

Since ast2600 is the main SoC of the fby35, "hw/arm/aspeed_ast2600_fby35.c"
should be a more relevant name.

The rest looks good to me.

Thanks,

C.

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

[Jamin Lin]

Hi Cédric, 

> Subject: Re: aspeed: Split the machine definition into individual source files
> 
> Hi,
> 
> 
> > Patch series 1
> > hw/arm/aspeed_ast1030_evb.c (ast1030-evb) ---> or
> > hw/arm/aspeed_ast10x0_evb.c, then we can place (ast1030-evb and
> > ast1060-evb) hw/arm/aspeed_ast27x0_evb.c (ast2700a0-evb,
> > ast2700a1-evb)
> >
> > Patch series 2
> > hw/arm/aspeed_ast2400_palmetto.c (palmetto-bmc)
> > hw/arm/aspeed_ast2400_quanta-q71l.c (quanta-q71l-bmc)
> > hw/arm/aspeed_ast2400_supermicrox11.c (supermicrox11-bmc)
> >
> > Patch series 3
> > hw/arm/aspeed_ast2500_evb.c (ast2500-evb)
> > hw/arm/aspeed_ast2500_romulus.c (romulus-bmc)
> > hw/arm/aspeed_ast2500_sonorapass.c (sonorapass-bmc)
> > hw/arm/aspeed_ast2500_witherspoon.c (witherspoon-bmc)
> > hw/arm/aspeed_ast2500_yosemitev2.c (yosemitev2-bmc)
> > hw/arm/aspeed_ast2500_supermicro-x11spi.c (supermicro-x11spi-bmc)
> > hw/arm/aspeed_ast2500_fp5280g2.c (fp5280g2-bmc)
> > hw/arm/aspeed_ast2500_g220a.c (g220a-bmc)
> > hw/arm/aspeed_ast2500_tiogapass.c (tiogapass-bmc)
> >
> > Patch series 4
> > hw/arm/aspeed_ast2600_evb.c (ast2600-evb)
> > hw/arm/aspeed_ast2600_qcom-dc-scm-v1.c (qcom-dc-scm-v1-b mc)
> > hw/arm/aspeed_ast2600_qcom-firework-bmc.c (qcom-firework-bmc)
> > hw/arm/aspeed_ast2600_rainier.c (rainier-bmc)
> > hw/arm/aspeed_ast2600_fuji.c (fuji-bmc)
> > hw/arm/aspeed_ast2600_bletchley.c (bletchley-bmc)
> > hw/arm/aspeed_ast2600_ fby35.c (fby35-bmc)
> >
> > For the FBY35 platform, since it includes both AST1030 and AST2600, we may
> consider renaming the file to:
> > hw/arm/aspeed_ast1030_ast2600_fby35.c  (hw/arm/fby35.c)
> 
> Since ast2600 is the main SoC of the fby35, "hw/arm/aspeed_ast2600_fby35.c"
> should be a more relevant name.
> 

hw/arm/aspeed_ast2600_ fby35.c (fby35-bmc from aspeed.c)
hw/arm/aspeed_ast2600_fby35.c  (hw/arm/fby35.c)

Both them use the same name. Do you mean to move them in one file?

Thanks,
Jamin


> The rest looks good to me.
> 
> Thanks,
> 
> C.

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

[Cédric Le Goater]

On 10/21/25 08:41, Jamin Lin wrote:
> Hi Cédric,
> 
>> Subject: Re: aspeed: Split the machine definition into individual source files
>>
>> Hi,
>>
>>
>>> Patch series 1
>>> hw/arm/aspeed_ast1030_evb.c (ast1030-evb) ---> or
>>> hw/arm/aspeed_ast10x0_evb.c, then we can place (ast1030-evb and
>>> ast1060-evb) hw/arm/aspeed_ast27x0_evb.c (ast2700a0-evb,
>>> ast2700a1-evb)
>>>
>>> Patch series 2
>>> hw/arm/aspeed_ast2400_palmetto.c (palmetto-bmc)
>>> hw/arm/aspeed_ast2400_quanta-q71l.c (quanta-q71l-bmc)
>>> hw/arm/aspeed_ast2400_supermicrox11.c (supermicrox11-bmc)
>>>
>>> Patch series 3
>>> hw/arm/aspeed_ast2500_evb.c (ast2500-evb)
>>> hw/arm/aspeed_ast2500_romulus.c (romulus-bmc)
>>> hw/arm/aspeed_ast2500_sonorapass.c (sonorapass-bmc)
>>> hw/arm/aspeed_ast2500_witherspoon.c (witherspoon-bmc)
>>> hw/arm/aspeed_ast2500_yosemitev2.c (yosemitev2-bmc)
>>> hw/arm/aspeed_ast2500_supermicro-x11spi.c (supermicro-x11spi-bmc)
>>> hw/arm/aspeed_ast2500_fp5280g2.c (fp5280g2-bmc)
>>> hw/arm/aspeed_ast2500_g220a.c (g220a-bmc)
>>> hw/arm/aspeed_ast2500_tiogapass.c (tiogapass-bmc)
>>>
>>> Patch series 4
>>> hw/arm/aspeed_ast2600_evb.c (ast2600-evb)
>>> hw/arm/aspeed_ast2600_qcom-dc-scm-v1.c (qcom-dc-scm-v1-b mc)
>>> hw/arm/aspeed_ast2600_qcom-firework-bmc.c (qcom-firework-bmc)
>>> hw/arm/aspeed_ast2600_rainier.c (rainier-bmc)
>>> hw/arm/aspeed_ast2600_fuji.c (fuji-bmc)
>>> hw/arm/aspeed_ast2600_bletchley.c (bletchley-bmc)
>>> hw/arm/aspeed_ast2600_ fby35.c (fby35-bmc)
>>>
>>> For the FBY35 platform, since it includes both AST1030 and AST2600, we may
>> consider renaming the file to:
>>> hw/arm/aspeed_ast1030_ast2600_fby35.c  (hw/arm/fby35.c)
>>
>> Since ast2600 is the main SoC of the fby35, "hw/arm/aspeed_ast2600_fby35.c"
>> should be a more relevant name.
>>
> 
> hw/arm/aspeed_ast2600_ fby35.c (fby35-bmc from aspeed.c)
> hw/arm/aspeed_ast2600_fby35.c  (hw/arm/fby35.c)
> 
> Both them use the same name. Do you mean to move them in one file?
Oh. I forgot that we had 2 machines.

I would leave hw/arm/fby35.c untouched. I am thinking of dropping
the "fby35" machine since it it not maintained and we have another
multi-soc machine: "ast2700fc".

Thanks,

C.

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

[Jamin Lin]

Hi Cédric

> >>
> >
> > hw/arm/aspeed_ast2600_ fby35.c (fby35-bmc from aspeed.c)
> > hw/arm/aspeed_ast2600_fby35.c  (hw/arm/fby35.c)
> >
> > Both them use the same name. Do you mean to move them in one file?
> Oh. I forgot that we had 2 machines.
> 
> I would leave hw/arm/fby35.c untouched. I am thinking of dropping the
> "fby35" machine since it it not maintained and we have another multi-soc
> machine: "ast2700fc".
> 

Thanks for your suggestions.
Will do.

Jamin
> Thanks,
> 
> C.
>