[PATCH] aspeed: Deprecate the fby35 machine

[PATCH] aspeed: Deprecate the fby35 machine

[Cédric Le Goater]

There are no functional tests for the 'fby35' machine which makes
harder to determine when something becomes deprecated or unused.

The 'fby35' machine was originally added as an example of a multi-SoC
system, with the expectation the models would evolve over time in an
heterogeneous system. This hasn't happened and no public firmware is
available to boot it. It can be replaced by the 'ast2700fc', another
multi-SoC machine based on the newer AST2700 SoCs which are excepted
to receive better support in the future.

Cc: Peter Delevoryas <peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
---
 docs/about/deprecated.rst | 13 ++++++++++++-
 hw/arm/fby35.c            |  1 +
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 9386cffba26d..ac31a2bce427 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -308,13 +308,24 @@ I2C devices connected to the board can be defined via the QEMU command
 line.
 
 Arm ``fp5280g2-bmc`` machine (since 10.2)
-'''''''''''''''''''''''''''''''''''''''''''
+'''''''''''''''''''''''''''''''''''''''''
 
 The ``fp5280g2-bmc`` machine does not rely on any specific device
 models, it can be replaced by the ``ast2500-evb`` machine using the
 ``fmc-model`` option to specify the flash type. The I2C devices
 connected to the board can be defined via the QEMU command line.
 
+Arm ``fby35`` machine (since 10.2)
+''''''''''''''''''''''''''''''''''
+
+The ``fby35`` machine was originally added as an example of a
+multi-SoC system, with the expectation the models would evolve over
+time in an heterogeneous system. This hasn't happened and no public
+firmware is available to boot it. It can be replaced by the
+``ast2700fc``, another multi-SoC machine based on the newer AST2700
+SoCs which are excepted to receive better support in the future.
+
+
 RISC-V default machine option (since 10.0)
 ''''''''''''''''''''''''''''''''''''''''''
 
diff --git a/hw/arm/fby35.c b/hw/arm/fby35.c
index 70d3a99d79e8..e61a6438fefa 100644
--- a/hw/arm/fby35.c
+++ b/hw/arm/fby35.c
@@ -175,6 +175,7 @@ static void fby35_class_init(ObjectClass *oc, const void *data)
     MachineClass *mc = MACHINE_CLASS(oc);
 
     mc->desc = "Meta Platforms fby35";
+    mc->deprecation_reason = "For a multi-soc machine, use 'ast2700fc' instead";
     mc->init = fby35_init;
     mc->no_floppy = 1;
     mc->no_cdrom = 1;
-- 
2.51.1

Re: [PATCH] aspeed: Deprecate the fby35 machine

[Cédric Le Goater]

Hello,

On 11/26/25 11:24, Cédric Le Goater wrote:
> There are no functional tests for the 'fby35' machine which makes
> harder to determine when something becomes deprecated or unused.
> 
> The 'fby35' machine was originally added as an example of a multi-SoC
> system, with the expectation the models would evolve over time in an
> heterogeneous system. This hasn't happened and no public firmware is
> available to boot it. It can be replaced by the 'ast2700fc', another
> multi-SoC machine based on the newer AST2700 SoCs which are excepted
> to receive better support in the future.
> 
> Cc: Peter Delevoryas <peter@pjd.dev>
> Signed-off-by: Cédric Le Goater <clg@redhat.com>


No objections ? If not, I will queue the deprecation for QEMU 10.2.
Since deprecation is tolerated in the -rc phase.

Thanks,

C.

Re: [PATCH] aspeed: Deprecate the fby35 machine

[Peter Delevoryas]

> On Dec 2, 2025, at 11:42 PM, Cédric Le Goater <clg@kaod.org> wrote:
> 
> Hello,
> 
>> On 11/26/25 11:24, Cédric Le Goater wrote:
>> There are no functional tests for the 'fby35' machine which makes
>> harder to determine when something becomes deprecated or unused.
>> The 'fby35' machine was originally added as an example of a multi-SoC
>> system, with the expectation the models would evolve over time in an
>> heterogeneous system. This hasn't happened and no public firmware is
>> available to boot it. It can be replaced by the 'ast2700fc', another
>> multi-SoC machine based on the newer AST2700 SoCs which are excepted
>> to receive better support in the future.
>> Cc: Peter Delevoryas <peter@pjd.dev>
>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
> 
> 
> No objections ? If not, I will queue the deprecation for QEMU 10.2.
> Since deprecation is tolerated in the -rc phase.

Oh hey, sorry I missed the original email, yeah no objections! Totally fair. :) We’re not using this internally either, we’ve mostly ended up pursuing multi-process solutions. Even though I think single-process stuff is interesting, getting multi master i2c to work between socs in the same process can be tricky.

Thanks,
Peter

> 
> Thanks,
> 
> C.
> 

Re: [PATCH] aspeed: Deprecate the fby35 machine

[Cédric Le Goater]

On 12/4/25 20:45, Peter Delevoryas wrote:
> 
> 
>> On Dec 2, 2025, at 11:42 PM, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> Hello,
>>
>>> On 11/26/25 11:24, Cédric Le Goater wrote:
>>> There are no functional tests for the 'fby35' machine which makes
>>> harder to determine when something becomes deprecated or unused.
>>> The 'fby35' machine was originally added as an example of a multi-SoC
>>> system, with the expectation the models would evolve over time in an
>>> heterogeneous system. This hasn't happened and no public firmware is
>>> available to boot it. It can be replaced by the 'ast2700fc', another
>>> multi-SoC machine based on the newer AST2700 SoCs which are excepted
>>> to receive better support in the future.
>>> Cc: Peter Delevoryas <peter@pjd.dev>
>>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
>>
>>
>> No objections ? If not, I will queue the deprecation for QEMU 10.2.
>> Since deprecation is tolerated in the -rc phase.
> 
> Oh hey, sorry I missed the original email, yeah no objections! Totally fair. :) We’re not using this internally either, we’ve mostly ended up pursuing multi-process solutions. 

Could we have your Acked-by then ?

> Even though I think single-process stuff is interesting, getting multi master i2c to work between socs in the same process can be tricky.

Yeah. This is still WIP. Making good progres though.

Thanks,

C.

Re: [PATCH] aspeed: Deprecate the fby35 machine

[Alex Bennée]

Cédric Le Goater <clg@redhat.com> writes:

> There are no functional tests for the 'fby35' machine which makes
> harder to determine when something becomes deprecated or unused.
>
> The 'fby35' machine was originally added as an example of a multi-SoC
> system, with the expectation the models would evolve over time in an
> heterogeneous system. This hasn't happened and no public firmware is
> available to boot it. It can be replaced by the 'ast2700fc', another
> multi-SoC machine based on the newer AST2700 SoCs which are excepted
> to receive better support in the future.

Queued to pr/051225-10.2-final-fixes-1, thanks.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH] aspeed: Deprecate the fby35 machine

[Peter Delevoryas]

> On Dec 5, 2025, at 12:43 AM, Cédric Le Goater <clg@kaod.org> wrote:
> 
> On 12/4/25 20:45, Peter Delevoryas wrote:
>>>> On Dec 2, 2025, at 11:42 PM, Cédric Le Goater <clg@kaod.org> wrote:
>>> 
>>> Hello,
>>> 
>>>> On 11/26/25 11:24, Cédric Le Goater wrote:
>>>> There are no functional tests for the 'fby35' machine which makes
>>>> harder to determine when something becomes deprecated or unused.
>>>> The 'fby35' machine was originally added as an example of a multi-SoC
>>>> system, with the expectation the models would evolve over time in an
>>>> heterogeneous system. This hasn't happened and no public firmware is
>>>> available to boot it. It can be replaced by the 'ast2700fc', another
>>>> multi-SoC machine based on the newer AST2700 SoCs which are excepted
>>>> to receive better support in the future.
>>>> Cc: Peter Delevoryas <peter@pjd.dev>
>>>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
>>> 
>>> 
>>> No objections ? If not, I will queue the deprecation for QEMU 10.2.
>>> Since deprecation is tolerated in the -rc phase.
>> Oh hey, sorry I missed the original email, yeah no objections! Totally fair. :) We’re not using this internally either, we’ve mostly ended up pursuing multi-process solutions.
> 
> Could we have your Acked-by then ?

Oh sure, ehh:

Acked-by: Peter Delevoryas <peter@pjd.dev>

> 
>> Even though I think single-process stuff is interesting, getting multi master i2c to work between socs in the same process can be tricky.
> 
> Yeah. This is still WIP. Making good progres though.
> 
> Thanks,
> 
> C.
> 
>