The tacoma-bmc machine was a board including an AST2600 SoC based BMC
and a witherspoon like OpenPOWER system. It was used for bring up of
the AST2600 SoC in labs. It can be easily replaced by the rainier-bmc
machine which is part of a real product offering.

Signed-off-by: Cédric Le Goater <clg@redhat.com>
---

 Changes since v2:
 - rephrased deprecation reason
 - remove extra line in docs
 
 docs/about/deprecated.rst | 8 ++++++++
 hw/arm/aspeed.c           | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index ff3da68208ac..5d9e4d8de725 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -256,6 +256,14 @@ images are not available, OpenWRT dropped support in 2019, U-Boot in
 2017, Linux also is dropping support in 2024. It is time to let go of
 this ancient hardware and focus on newer CPUs and platforms.
 
+Arm ``tacoma-bmc`` machine (since 9.1)
+''''''''''''''''''''''''''''''''''''''''
+
+The ``tacoma-bmc`` machine was a board including an AST2600 SoC based
+BMC and a witherspoon like OpenPOWER system. It was used for bring up
+of the AST2600 SoC in labs.  It can be easily replaced by the
+``rainier-bmc`` machine which is a real product.
+
 Backend options
 ---------------
 
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 40dc0e4c76db..53a4f665d0d0 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -1379,6 +1379,8 @@ static void aspeed_machine_tacoma_class_init(ObjectClass *oc, void *data)
     amc->i2c_init  = witherspoon_bmc_i2c_init; /* Same board layout */
     mc->default_ram_size = 1 * GiB;
     aspeed_machine_class_init_cpus_defaults(mc);
+
+    mc->deprecation_reason = "Please use the similar 'rainier-bmc' machine";
 };
 
 static void aspeed_machine_g220a_class_init(ObjectClass *oc, void *data)
-- 
2.45.2

Hi,

On Tue, Jun 25, 2024 at 09:08:30AM +0200, Cédric Le Goater wrote:
> The tacoma-bmc machine was a board including an AST2600 SoC based BMC
> and a witherspoon like OpenPOWER system. It was used for bring up of
> the AST2600 SoC in labs. It can be easily replaced by the rainier-bmc
> machine which is part of a real product offering.
> 
> Signed-off-by: Cédric Le Goater <clg@redhat.com>

I have been using tacoma-bmc to test tcg,tpm-tis-i2c functionality
on arm. rainier-bmc doesn't support that, and other IBM BMCs which
do support it (bonnell, everest, system1) are not supported in qemu.

Do you have a suggested alternative ?

Thanks,
Guenter

Hello Guenter,

On 8/9/24 00:05, Guenter Roeck wrote:
> Hi,
> 
> On Tue, Jun 25, 2024 at 09:08:30AM +0200, Cédric Le Goater wrote:
>> The tacoma-bmc machine was a board including an AST2600 SoC based BMC
>> and a witherspoon like OpenPOWER system. It was used for bring up of
>> the AST2600 SoC in labs. It can be easily replaced by the rainier-bmc
>> machine which is part of a real product offering.
>>
>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
> 
> I have been using tacoma-bmc to test tcg,tpm-tis-i2c functionality
> on arm. rainier-bmc doesn't support that, and other IBM BMCs which
> do support it (bonnell, everest, system1) are not supported in qemu.
> 
> Do you have a suggested alternative ?

Could you use the ast2600-evb machine instead ? as done in
machine_aspeed.py, see routine test_arm_ast2600_evb_buildroot_tpm.

We can't add a "tpm-tis-i2c" device to the tacoma-bmc machine init
routine because a TPM backend is required.

Thanks,

C.

Hi,

On 8/26/24 02:58, Cédric Le Goater wrote:
> Hello Guenter,
> 
> On 8/9/24 00:05, Guenter Roeck wrote:
>> Hi,
>>
>> On Tue, Jun 25, 2024 at 09:08:30AM +0200, Cédric Le Goater wrote:
>>> The tacoma-bmc machine was a board including an AST2600 SoC based BMC
>>> and a witherspoon like OpenPOWER system. It was used for bring up of
>>> the AST2600 SoC in labs. It can be easily replaced by the rainier-bmc
>>> machine which is part of a real product offering.
>>>
>>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
>>
>> I have been using tacoma-bmc to test tcg,tpm-tis-i2c functionality
>> on arm. rainier-bmc doesn't support that, and other IBM BMCs which
>> do support it (bonnell, everest, system1) are not supported in qemu.
>>
>> Do you have a suggested alternative ?
> 
> Could you use the ast2600-evb machine instead ? as done in
> machine_aspeed.py, see routine test_arm_ast2600_evb_buildroot_tpm.
> 

Unfortunately, that does not work for me because that requires instantiating
the tpm chip from the CLI by writing into the new_device sysfs attribute,
and I can not do that in my test environment.

> We can't add a "tpm-tis-i2c" device to the tacoma-bmc machine init
> routine because a TPM backend is required.
> 

Not sure I understand; tacoma-bmc instantiates the TPM chip through its
devicetree file which is what I was looking for.

I solved the problem by adding support for IBM Bonnell (which instantiates
the TPM chip through its devicetree file, similar to tacoma-bmc) to my local
copy of qemu. It isn't perfect since I don't know the correct HW pin strapping
and reused the strapping from Rainier, but it works for me.

Thanks,
Guenter

On 8/26/24 20:50, Guenter Roeck wrote:
> Hi,
> 
> On 8/26/24 02:58, Cédric Le Goater wrote:
>> Hello Guenter,
>>
>> On 8/9/24 00:05, Guenter Roeck wrote:
>>> Hi,
>>>
>>> On Tue, Jun 25, 2024 at 09:08:30AM +0200, Cédric Le Goater wrote:
>>>> The tacoma-bmc machine was a board including an AST2600 SoC based BMC
>>>> and a witherspoon like OpenPOWER system. It was used for bring up of
>>>> the AST2600 SoC in labs. It can be easily replaced by the rainier-bmc
>>>> machine which is part of a real product offering.
>>>>
>>>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
>>>
>>> I have been using tacoma-bmc to test tcg,tpm-tis-i2c functionality
>>> on arm. rainier-bmc doesn't support that, and other IBM BMCs which
>>> do support it (bonnell, everest, system1) are not supported in qemu.
>>>
>>> Do you have a suggested alternative ?
>>
>> Could you use the ast2600-evb machine instead ? as done in
>> machine_aspeed.py, see routine test_arm_ast2600_evb_buildroot_tpm.
>>
> 
> Unfortunately, that does not work for me because that requires instantiating
> the tpm chip from the CLI by writing into the new_device sysfs attribute,
> and I can not do that in my test environment.

Ah. too bad.

>> We can't add a "tpm-tis-i2c" device to the tacoma-bmc machine init
>> routine because a TPM backend is required.
>>
> 
> Not sure I understand; tacoma-bmc instantiates the TPM chip through its
> devicetree file which is what I was looking for.

I meant at the "HW" board level in QEMU.

We can not instantiate the TPM I2C chip device model in the tacoma-bmc
machine init routine and attach it to the I2C bus because of the required
TPM backend. This means that the device is necessarily defined on the QEMU
command line and this makes the ast2600-evb and tacoma-bmc machine very
similar in terms of HW definitions.
  
> I solved the problem by adding support for IBM Bonnell (which instantiates
> the TPM chip through its devicetree file, similar to tacoma-bmc) to my local
> copy of qemu. 

Hmm, did you copy the rainier-bmc machine definition ?

> It isn't perfect since I don't know the correct HW pin strapping
> and reused the strapping from Rainier, but it works for me.

Keeping the tacoma-bmc machine is fine if there is a use for it. Testing
the TPM I2C device driver is certainly a good use but we should reflect
that in QEMU also (so that we don't forget). Could we change the test in
machine_aspeed.py to use the tacoma-bmc machine instead ? and revert the
deprecation patch of course.

Thanks,

C.

On 8/28/24 05:35, Cédric Le Goater wrote:
> On 8/26/24 20:50, Guenter Roeck wrote:
>> Hi,
>>
>> On 8/26/24 02:58, Cédric Le Goater wrote:
>>> Hello Guenter,
>>>
>>> On 8/9/24 00:05, Guenter Roeck wrote:
>>>> Hi,
>>>>
>>>> On Tue, Jun 25, 2024 at 09:08:30AM +0200, Cédric Le Goater wrote:
>>>>> The tacoma-bmc machine was a board including an AST2600 SoC based BMC
>>>>> and a witherspoon like OpenPOWER system. It was used for bring up of
>>>>> the AST2600 SoC in labs. It can be easily replaced by the rainier-bmc
>>>>> machine which is part of a real product offering.
>>>>>
>>>>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
>>>>
>>>> I have been using tacoma-bmc to test tcg,tpm-tis-i2c functionality
>>>> on arm. rainier-bmc doesn't support that, and other IBM BMCs which
>>>> do support it (bonnell, everest, system1) are not supported in qemu.
>>>>
>>>> Do you have a suggested alternative ?
>>>
>>> Could you use the ast2600-evb machine instead ? as done in
>>> machine_aspeed.py, see routine test_arm_ast2600_evb_buildroot_tpm.
>>>
>>
>> Unfortunately, that does not work for me because that requires instantiating
>> the tpm chip from the CLI by writing into the new_device sysfs attribute,
>> and I can not do that in my test environment.
> 
> Ah. too bad.
> 
>>> We can't add a "tpm-tis-i2c" device to the tacoma-bmc machine init
>>> routine because a TPM backend is required.
>>>
>>
>> Not sure I understand; tacoma-bmc instantiates the TPM chip through its
>> devicetree file which is what I was looking for.
> 
> I meant at the "HW" board level in QEMU.
> 
> We can not instantiate the TPM I2C chip device model in the tacoma-bmc
> machine init routine and attach it to the I2C bus because of the required
> TPM backend. This means that the device is necessarily defined on the QEMU
> command line and this makes the ast2600-evb and tacoma-bmc machine very
> similar in terms of HW definitions.
> 

Yes, I found that as well.

>> I solved the problem by adding support for IBM Bonnell (which instantiates
>> the TPM chip through its devicetree file, similar to tacoma-bmc) to my local
>> copy of qemu. 
> 
> Hmm, did you copy the rainier-bmc machine definition ?
> 
For aspeed_machine_bonnell_class_init(), pretty much yes, since I don't know
the actual hardware. For I2C initialization I used the devicetree file.
You can find the patch in the master-local or v9.1.0-local branches
of my qemu clone at https://github.com/groeck/qemu if you are interested.

>> It isn't perfect since I don't know the correct HW pin strapping
>> and reused the strapping from Rainier, but it works for me.
> 
> Keeping the tacoma-bmc machine is fine if there is a use for it. Testing
> the TPM I2C device driver is certainly a good use but we should reflect
> that in QEMU also (so that we don't forget). Could we change the test in
> machine_aspeed.py to use the tacoma-bmc machine instead ? and revert the
> deprecation patch of course.
> 

No need from my perspective. This isn't the only patch I carry on top of
upstream qemu, after all.

Thanks,
Guenter

Hello,


>>> I solved the problem by adding support for IBM Bonnell (which instantiates
>>> the TPM chip through its devicetree file, similar to tacoma-bmc) to my local
>>> copy of qemu. 
>>
>> Hmm, did you copy the rainier-bmc machine definition ?
>>
> For aspeed_machine_bonnell_class_init(), pretty much yes, since I don't know
> the actual hardware. For I2C initialization I used the devicetree file.
> You can find the patch in the master-local or v9.1.0-local branches
> of my qemu clone at https://github.com/groeck/qemu if you are interested.

Oh nice ! Let's merge the IBM Bonnell machine. We can ask IBM to help fixing
the definitions (strapping). Enabling the PCA9554 is good to have too.

Why are you keeping the tmp105 changes ? LGTM. Same for the new tmp models,
they could be upstreamed.


Thanks,

C.

On Fri, Aug 30, 2024 at 10:09:25AM +0200, Cédric Le Goater wrote:
> Hello,
> 
> 
> > > > I solved the problem by adding support for IBM Bonnell (which instantiates
> > > > the TPM chip through its devicetree file, similar to tacoma-bmc) to my local
> > > > copy of qemu.
> > > 
> > > Hmm, did you copy the rainier-bmc machine definition ?
> > > 
> > For aspeed_machine_bonnell_class_init(), pretty much yes, since I don't know
> > the actual hardware. For I2C initialization I used the devicetree file.
> > You can find the patch in the master-local or v9.1.0-local branches
> > of my qemu clone at https://github.com/groeck/qemu if you are interested.
> 
> Oh nice ! Let's merge the IBM Bonnell machine. We can ask IBM to help fixing
> the definitions (strapping). Enabling the PCA9554 is good to have too.
> 

Sure, let me do that.

> Why are you keeping the tmp105 changes ? LGTM. Same for the new tmp models,
> they could be upstreamed.
> 
Ok, I'll work on that.

Thanks,
Guenter

On Sat, 31 Aug 2024 at 05:41, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Fri, Aug 30, 2024 at 10:09:25AM +0200, Cédric Le Goater wrote:
> > Hello,
> >
> >
> > > > > I solved the problem by adding support for IBM Bonnell (which instantiates
> > > > > the TPM chip through its devicetree file, similar to tacoma-bmc) to my local
> > > > > copy of qemu.
> > > >
> > > > Hmm, did you copy the rainier-bmc machine definition ?
> > > >
> > > For aspeed_machine_bonnell_class_init(), pretty much yes, since I don't know
> > > the actual hardware. For I2C initialization I used the devicetree file.
> > > You can find the patch in the master-local or v9.1.0-local branches
> > > of my qemu clone at https://github.com/groeck/qemu if you are interested.
> >
> > Oh nice ! Let's merge the IBM Bonnell machine. We can ask IBM to help fixing
> > the definitions (strapping). Enabling the PCA9554 is good to have too.

Instead of adding Bonnell to qemu, could we use the Rainier machine? I
know the kernel device tree removed the i2c tpm, but there's no harm
in it being present in the qemu machine.

The bonnell device tree should boot fine on the rainier machine for
your purposes.

Cheers,

Joel

On 9/9/24 04:20, Joel Stanley wrote:
> On Sat, 31 Aug 2024 at 05:41, Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On Fri, Aug 30, 2024 at 10:09:25AM +0200, Cédric Le Goater wrote:
>>> Hello,
>>>
>>>
>>>>>> I solved the problem by adding support for IBM Bonnell (which instantiates
>>>>>> the TPM chip through its devicetree file, similar to tacoma-bmc) to my local
>>>>>> copy of qemu.
>>>>>
>>>>> Hmm, did you copy the rainier-bmc machine definition ?
>>>>>
>>>> For aspeed_machine_bonnell_class_init(), pretty much yes, since I don't know
>>>> the actual hardware. For I2C initialization I used the devicetree file.
>>>> You can find the patch in the master-local or v9.1.0-local branches
>>>> of my qemu clone at https://github.com/groeck/qemu if you are interested.
>>>
>>> Oh nice ! Let's merge the IBM Bonnell machine. We can ask IBM to help fixing
>>> the definitions (strapping). Enabling the PCA9554 is good to have too.
> 
> Instead of adding Bonnell to qemu, could we use the Rainier machine? I
> know the kernel device tree removed the i2c tpm, but there's no harm
> in it being present in the qemu machine.
> 
> The bonnell device tree should boot fine on the rainier machine for
> your purposes.
> 

Yes, I confirmed that works. Ok, I'll do that.

Thanks,
Guenter

On 9/9/24 17:10, Guenter Roeck wrote:
> On 9/9/24 04:20, Joel Stanley wrote:
>> On Sat, 31 Aug 2024 at 05:41, Guenter Roeck <linux@roeck-us.net> wrote:
>>>
>>> On Fri, Aug 30, 2024 at 10:09:25AM +0200, Cédric Le Goater wrote:
>>>> Hello,
>>>>
>>>>
>>>>>>> I solved the problem by adding support for IBM Bonnell (which instantiates
>>>>>>> the TPM chip through its devicetree file, similar to tacoma-bmc) to my local
>>>>>>> copy of qemu.
>>>>>>
>>>>>> Hmm, did you copy the rainier-bmc machine definition ?
>>>>>>
>>>>> For aspeed_machine_bonnell_class_init(), pretty much yes, since I don't know
>>>>> the actual hardware. For I2C initialization I used the devicetree file.
>>>>> You can find the patch in the master-local or v9.1.0-local branches
>>>>> of my qemu clone at https://github.com/groeck/qemu if you are interested.
>>>>
>>>> Oh nice ! Let's merge the IBM Bonnell machine. We can ask IBM to help fixing
>>>> the definitions (strapping). Enabling the PCA9554 is good to have too.
>>
>> Instead of adding Bonnell to qemu, could we use the Rainier machine? I
>> know the kernel device tree removed the i2c tpm, but there's no harm
>> in it being present in the qemu machine.
>>
>> The bonnell device tree should boot fine on the rainier machine for
>> your purposes.
>>
> 
> Yes, I confirmed that works. Ok, I'll do that.

So I will drop the bonnell to avoid redundancy. Is that OK ?


Thanks,

C.

On 9/11/24 10:33, Cédric Le Goater wrote:
> On 9/9/24 17:10, Guenter Roeck wrote:
>> On 9/9/24 04:20, Joel Stanley wrote:
>>> On Sat, 31 Aug 2024 at 05:41, Guenter Roeck <linux@roeck-us.net> wrote:
>>>>
>>>> On Fri, Aug 30, 2024 at 10:09:25AM +0200, Cédric Le Goater wrote:
>>>>> Hello,
>>>>>
>>>>>
>>>>>>>> I solved the problem by adding support for IBM Bonnell (which instantiates
>>>>>>>> the TPM chip through its devicetree file, similar to tacoma-bmc) to my local
>>>>>>>> copy of qemu.
>>>>>>>
>>>>>>> Hmm, did you copy the rainier-bmc machine definition ?
>>>>>>>
>>>>>> For aspeed_machine_bonnell_class_init(), pretty much yes, since I don't know
>>>>>> the actual hardware. For I2C initialization I used the devicetree file.
>>>>>> You can find the patch in the master-local or v9.1.0-local branches
>>>>>> of my qemu clone at https://github.com/groeck/qemu if you are interested.
>>>>>
>>>>> Oh nice ! Let's merge the IBM Bonnell machine. We can ask IBM to help fixing
>>>>> the definitions (strapping). Enabling the PCA9554 is good to have too.
>>>
>>> Instead of adding Bonnell to qemu, could we use the Rainier machine? I
>>> know the kernel device tree removed the i2c tpm, but there's no harm
>>> in it being present in the qemu machine.
>>>
>>> The bonnell device tree should boot fine on the rainier machine for
>>> your purposes.
>>>
>>
>> Yes, I confirmed that works. Ok, I'll do that.
> 
> So I will drop the bonnell to avoid redundancy. Is that OK ?
> 
Ok with me.

Guenter

On 6/25/24 9:08 AM, Cédric Le Goater wrote:
> The tacoma-bmc machine was a board including an AST2600 SoC based BMC
> and a witherspoon like OpenPOWER system. It was used for bring up of
> the AST2600 SoC in labs. It can be easily replaced by the rainier-bmc
> machine which is part of a real product offering.
> 
> Signed-off-by: Cédric Le Goater <clg@redhat.com>


Applied to aspeed-next.

Thanks,

C.


> ---
> 
>   Changes since v2:
>   - rephrased deprecation reason
>   - remove extra line in docs
>   
>   docs/about/deprecated.rst | 8 ++++++++
>   hw/arm/aspeed.c           | 2 ++
>   2 files changed, 10 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index ff3da68208ac..5d9e4d8de725 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -256,6 +256,14 @@ images are not available, OpenWRT dropped support in 2019, U-Boot in
>   2017, Linux also is dropping support in 2024. It is time to let go of
>   this ancient hardware and focus on newer CPUs and platforms.
>   
> +Arm ``tacoma-bmc`` machine (since 9.1)
> +''''''''''''''''''''''''''''''''''''''''
> +
> +The ``tacoma-bmc`` machine was a board including an AST2600 SoC based
> +BMC and a witherspoon like OpenPOWER system. It was used for bring up
> +of the AST2600 SoC in labs.  It can be easily replaced by the
> +``rainier-bmc`` machine which is a real product.
> +
>   Backend options
>   ---------------
>   
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 40dc0e4c76db..53a4f665d0d0 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -1379,6 +1379,8 @@ static void aspeed_machine_tacoma_class_init(ObjectClass *oc, void *data)
>       amc->i2c_init  = witherspoon_bmc_i2c_init; /* Same board layout */
>       mc->default_ram_size = 1 * GiB;
>       aspeed_machine_class_init_cpus_defaults(mc);
> +
> +    mc->deprecation_reason = "Please use the similar 'rainier-bmc' machine";
>   };
>   
>   static void aspeed_machine_g220a_class_init(ObjectClass *oc, void *data)

On 25/6/24 09:08, Cédric Le Goater wrote:
> The tacoma-bmc machine was a board including an AST2600 SoC based BMC
> and a witherspoon like OpenPOWER system. It was used for bring up of
> the AST2600 SoC in labs. It can be easily replaced by the rainier-bmc
> machine which is part of a real product offering.
> 
> Signed-off-by: Cédric Le Goater <clg@redhat.com>
> ---
> 
>   Changes since v2:
>   - rephrased deprecation reason
>   - remove extra line in docs
>   
>   docs/about/deprecated.rst | 8 ++++++++
>   hw/arm/aspeed.c           | 2 ++
>   2 files changed, 10 insertions(+)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>