1. Patchew
  2. QEMU
  3. View series

[PATCH v2] aspeed: Add support for the sonorapass-bmc board

Patrick Williams posted 1 patch 5 years, 6 months ago
Test docker-mingw@fedora passed
Test checkpatch passed
Test asan passed
Test docker-quick@centos7 passed
Test FreeBSD passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20200506173035.2154053-1-patrick@stwcx.xyz
There is a newer version of this series
hw/arm/aspeed.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
[PATCH v2] aspeed: Add support for the sonorapass-bmc board
Posted by Patrick Williams 5 years, 6 months ago 
Sonora Pass is a 2 socket x86 motherboard designed by Facebook
and supported by OpenBMC.  Strapping configuration was obtained
from hardware and i2c configuration is based on dts found at:

https://github.com/facebook/openbmc-linux/blob/1633c87b8ba7c162095787c988979b748ba65dc8/arch/arm/boot/dts/aspeed-bmc-facebook-sonorapass.dts

Booted a test image of http://github.com/facebook/openbmc to login
prompt.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
---
 hw/arm/aspeed.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index a6a2102a93..01e74e34be 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -84,6 +84,21 @@ struct AspeedBoardState {
         SCU_AST2500_HW_STRAP_ACPI_ENABLE |                              \
         SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_MASTER))
 
+/* Sonorapass hardware value: 0xF100D216 */
+#define SONORAPASS_BMC_HW_STRAP1 (                                      \
+        SCU_AST2500_HW_STRAP_SPI_AUTOFETCH_ENABLE |                     \
+        SCU_AST2500_HW_STRAP_GPIO_STRAP_ENABLE |                        \
+        SCU_AST2500_HW_STRAP_UART_DEBUG |                               \
+        SCU_AST2500_HW_STRAP_RESERVED28 |                               \
+        SCU_AST2500_HW_STRAP_DDR4_ENABLE |                              \
+        SCU_HW_STRAP_VGA_CLASS_CODE |                                   \
+        SCU_HW_STRAP_LPC_RESET_PIN |                                    \
+        SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_MASTER) |                \
+        SCU_AST2500_HW_STRAP_SET_AXI_AHB_RATIO(AXI_AHB_RATIO_2_1) |     \
+        SCU_HW_STRAP_VGA_BIOS_ROM |                                     \
+        SCU_HW_STRAP_VGA_SIZE_SET(VGA_16M_DRAM) |                       \
+        SCU_AST2500_HW_STRAP_RESERVED1)
+
 /* Witherspoon hardware value: 0xF10AD216 (but use romulus definition) */
 #define WITHERSPOON_BMC_HW_STRAP1 ROMULUS_BMC_HW_STRAP1
 
@@ -372,6 +387,49 @@ static void swift_bmc_i2c_init(AspeedBoardState *bmc)
     i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 12), "tmp105", 0x4a);
 }
 
+static void sonorapass_bmc_i2c_init(AspeedBoardState *bmc)
+{
+    AspeedSoCState *soc = &bmc->soc;
+
+    /* bus 2 : */
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 2), "tmp105", 0x48);
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 2), "tmp105", 0x49);
+    /* bus 2 : pca9546 @ 0x73 */
+
+    /* bus 3 : pca9548 @ 0x70 */
+
+    /* bus 4 : */
+    uint8_t *eeprom4_54 = g_malloc0(8 * 1024);
+    smbus_eeprom_init_one(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 4), 0x54,
+                          eeprom4_54);
+    /* PCA9539 @ 0x76, but PCA9552 is compatible */
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 4), "pca9552", 0x76);
+    /* PCA9539 @ 0x77, but PCA9552 is compatible */
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 4), "pca9552", 0x77);
+
+    /* bus 6 : */
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 6), "tmp105", 0x48);
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 6), "tmp105", 0x49);
+    /* bus 6 : pca9546 @ 0x73 */
+
+    /* bus 8 : */
+    uint8_t *eeprom8_56 = g_malloc0(8 * 1024);
+    smbus_eeprom_init_one(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 8), 0x56,
+                          eeprom8_56);
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 8), "pca9552", 0x60);
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 8), "pca9552", 0x61);
+    /* bus 8 : adc128d818 @ 0x1d */
+    /* bus 8 : adc128d818 @ 0x1f */
+
+    /* bus 13 : pca9548 @ 0x71
+     *      - channel 3:
+     *          - tmm421 @ 0x4c
+     *          - tmp421 @ 0x4e
+     *          - tmp421 @ 0x4f
+     */
+
+}
+
 static void witherspoon_bmc_i2c_init(AspeedBoardState *bmc)
 {
     AspeedSoCState *soc = &bmc->soc;
@@ -499,6 +557,21 @@ static void aspeed_machine_swift_class_init(ObjectClass *oc, void *data)
     mc->default_ram_size       = 512 * MiB;
 };
 
+static void aspeed_machine_sonorapass_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+    AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
+
+    mc->desc       = "OpenPOWER SonoraPass BMC (ARM1176)";
+    amc->soc_name  = "ast2500-a1";
+    amc->hw_strap1 = SONORAPASS_BMC_HW_STRAP1;
+    amc->fmc_model = "mx66l1g45g";
+    amc->spi_model = "mx66l1g45g";
+    amc->num_cs    = 2;
+    amc->i2c_init  = sonorapass_bmc_i2c_init;
+    mc->default_ram_size       = 512 * MiB;
+};
+
 static void aspeed_machine_witherspoon_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
@@ -563,6 +636,10 @@ static const TypeInfo aspeed_machine_types[] = {
         .name          = MACHINE_TYPE_NAME("swift-bmc"),
         .parent        = TYPE_ASPEED_MACHINE,
         .class_init    = aspeed_machine_swift_class_init,
+    }, {
+        .name          = MACHINE_TYPE_NAME("sonorapass-bmc"),
+        .parent        = TYPE_ASPEED_MACHINE,
+        .class_init    = aspeed_machine_sonorapass_class_init,
     }, {
         .name          = MACHINE_TYPE_NAME("witherspoon-bmc"),
         .parent        = TYPE_ASPEED_MACHINE,
-- 
2.26.2
Re: [PATCH v2] aspeed: Add support for the sonorapass-bmc board
Posted by Amithash Prasad via 5 years, 6 months ago 
>> +    mc->desc       = "OpenPOWER SonoraPass BMC (ARM1176)";
Open Compute Project?
Re: [PATCH v2] aspeed: Add support for the sonorapass-bmc board
Posted by Patrick Williams 5 years, 6 months ago 
On Wed, May 06, 2020 at 06:06:34PM +0000, Amithash Prasad wrote:
> >> +    mc->desc       = "OpenPOWER SonoraPass BMC (ARM1176)";
> Open Compute Project?

Oops.  Yeah, this is not an OpenPOWER machine.  Will send a v3.

-- 
Patrick Williams
[PATCH v3] aspeed: Add support for the sonorapass-bmc board
Posted by Patrick Williams 5 years, 6 months ago 
Sonora Pass is a 2 socket x86 motherboard designed by Facebook
and supported by OpenBMC.  Strapping configuration was obtained
from hardware and i2c configuration is based on dts found at:

https://github.com/facebook/openbmc-linux/blob/1633c87b8ba7c162095787c988979b748ba65dc8/arch/arm/boot/dts/aspeed-bmc-facebook-sonorapass.dts

Booted a test image of http://github.com/facebook/openbmc to login
prompt.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Reviewed-by: Amithash Prasad <amithash@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
---
 hw/arm/aspeed.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 6f4d7075c4..74c46681e8 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -74,6 +74,21 @@ struct AspeedBoardState {
         SCU_AST2500_HW_STRAP_ACPI_ENABLE |                              \
         SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_MASTER))
 
+/* Sonorapass hardware value: 0xF100D216 */
+#define SONORAPASS_BMC_HW_STRAP1 (                                      \
+        SCU_AST2500_HW_STRAP_SPI_AUTOFETCH_ENABLE |                     \
+        SCU_AST2500_HW_STRAP_GPIO_STRAP_ENABLE |                        \
+        SCU_AST2500_HW_STRAP_UART_DEBUG |                               \
+        SCU_AST2500_HW_STRAP_RESERVED28 |                               \
+        SCU_AST2500_HW_STRAP_DDR4_ENABLE |                              \
+        SCU_HW_STRAP_VGA_CLASS_CODE |                                   \
+        SCU_HW_STRAP_LPC_RESET_PIN |                                    \
+        SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_MASTER) |                \
+        SCU_AST2500_HW_STRAP_SET_AXI_AHB_RATIO(AXI_AHB_RATIO_2_1) |     \
+        SCU_HW_STRAP_VGA_BIOS_ROM |                                     \
+        SCU_HW_STRAP_VGA_SIZE_SET(VGA_16M_DRAM) |                       \
+        SCU_AST2500_HW_STRAP_RESERVED1)
+
 /* Swift hardware value: 0xF11AD206 */
 #define SWIFT_BMC_HW_STRAP1 (                                           \
         AST2500_HW_STRAP1_DEFAULTS |                                    \
@@ -434,6 +449,49 @@ static void swift_bmc_i2c_init(AspeedBoardState *bmc)
     i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 12), "tmp105", 0x4a);
 }
 
+static void sonorapass_bmc_i2c_init(AspeedBoardState *bmc)
+{
+    AspeedSoCState *soc = &bmc->soc;
+
+    /* bus 2 : */
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 2), "tmp105", 0x48);
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 2), "tmp105", 0x49);
+    /* bus 2 : pca9546 @ 0x73 */
+
+    /* bus 3 : pca9548 @ 0x70 */
+
+    /* bus 4 : */
+    uint8_t *eeprom4_54 = g_malloc0(8 * 1024);
+    smbus_eeprom_init_one(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 4), 0x54,
+                          eeprom4_54);
+    /* PCA9539 @ 0x76, but PCA9552 is compatible */
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 4), "pca9552", 0x76);
+    /* PCA9539 @ 0x77, but PCA9552 is compatible */
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 4), "pca9552", 0x77);
+
+    /* bus 6 : */
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 6), "tmp105", 0x48);
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 6), "tmp105", 0x49);
+    /* bus 6 : pca9546 @ 0x73 */
+
+    /* bus 8 : */
+    uint8_t *eeprom8_56 = g_malloc0(8 * 1024);
+    smbus_eeprom_init_one(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 8), 0x56,
+                          eeprom8_56);
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 8), "pca9552", 0x60);
+    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 8), "pca9552", 0x61);
+    /* bus 8 : adc128d818 @ 0x1d */
+    /* bus 8 : adc128d818 @ 0x1f */
+
+    /* bus 13 : pca9548 @ 0x71
+     *      - channel 3:
+     *          - tmm421 @ 0x4c
+     *          - tmp421 @ 0x4e
+     *          - tmp421 @ 0x4f
+     */
+
+}
+
 static void witherspoon_bmc_i2c_init(AspeedBoardState *bmc)
 {
     AspeedSoCState *soc = &bmc->soc;
@@ -552,6 +610,21 @@ static void aspeed_machine_romulus_class_init(ObjectClass *oc, void *data)
     mc->default_ram_size       = 512 * MiB;
 };
 
+static void aspeed_machine_sonorapass_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+    AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
+
+    mc->desc       = "OCP SonoraPass BMC (ARM1176)";
+    amc->soc_name  = "ast2500-a1";
+    amc->hw_strap1 = SONORAPASS_BMC_HW_STRAP1;
+    amc->fmc_model = "mx66l1g45g";
+    amc->spi_model = "mx66l1g45g";
+    amc->num_cs    = 2;
+    amc->i2c_init  = sonorapass_bmc_i2c_init;
+    mc->default_ram_size       = 512 * MiB;
+};
+
 static void aspeed_machine_swift_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
@@ -631,6 +704,10 @@ static const TypeInfo aspeed_machine_types[] = {
         .name          = MACHINE_TYPE_NAME("swift-bmc"),
         .parent        = TYPE_ASPEED_MACHINE,
         .class_init    = aspeed_machine_swift_class_init,
+    }, {
+        .name          = MACHINE_TYPE_NAME("sonorapass-bmc"),
+        .parent        = TYPE_ASPEED_MACHINE,
+        .class_init    = aspeed_machine_sonorapass_class_init,
     }, {
         .name          = MACHINE_TYPE_NAME("witherspoon-bmc"),
         .parent        = TYPE_ASPEED_MACHINE,
-- 
2.26.2
Re: [PATCH v3] aspeed: Add support for the sonorapass-bmc board
Posted by Cédric Le Goater 1 month, 2 weeks ago 
Hello Patrick

On 5/6/20 20:32, Patrick Williams wrote:
> Sonora Pass is a 2 socket x86 motherboard designed by Facebook
> and supported by OpenBMC.  Strapping configuration was obtained
> from hardware and i2c configuration is based on dts found at:
> 
> https://github.com/facebook/openbmc-linux/blob/1633c87b8ba7c162095787c988979b748ba65dc8/arch/arm/boot/dts/aspeed-bmc-facebook-sonorapass.dts
> 
> Booted a test image of http://github.com/facebook/openbmc to login
> prompt.
> 
> Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
> Reviewed-by: Amithash Prasad <amithash@fb.com>
> Reviewed-by: Cédric Le Goater <clg@kaod.org>
> ---
>   hw/arm/aspeed.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 77 insertions(+)


Would it be possible to contribute a functional test for this
machine ?

The request applies to these Facebook machines :

   sonorapass-bmc
   yosemitev2-bmc
   tiogapass-bmc
   fuji-bmc
   fby35-bmc

Since these machines contribute little to the Aspeed models,
their value lies in the firmware they can run to exercise the
models. Without functional tests, I plan to schedule their
removal in the QEMU 10.2 cycle.

The fby35-bmc value is in its multisoc nature. We now have the
ast2700fc available as its replacement

Thanks,

C.

> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 6f4d7075c4..74c46681e8 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -74,6 +74,21 @@ struct AspeedBoardState {
>           SCU_AST2500_HW_STRAP_ACPI_ENABLE |                              \
>           SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_MASTER))
>   
> +/* Sonorapass hardware value: 0xF100D216 */
> +#define SONORAPASS_BMC_HW_STRAP1 (                                      \
> +        SCU_AST2500_HW_STRAP_SPI_AUTOFETCH_ENABLE |                     \
> +        SCU_AST2500_HW_STRAP_GPIO_STRAP_ENABLE |                        \
> +        SCU_AST2500_HW_STRAP_UART_DEBUG |                               \
> +        SCU_AST2500_HW_STRAP_RESERVED28 |                               \
> +        SCU_AST2500_HW_STRAP_DDR4_ENABLE |                              \
> +        SCU_HW_STRAP_VGA_CLASS_CODE |                                   \
> +        SCU_HW_STRAP_LPC_RESET_PIN |                                    \
> +        SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_MASTER) |                \
> +        SCU_AST2500_HW_STRAP_SET_AXI_AHB_RATIO(AXI_AHB_RATIO_2_1) |     \
> +        SCU_HW_STRAP_VGA_BIOS_ROM |                                     \
> +        SCU_HW_STRAP_VGA_SIZE_SET(VGA_16M_DRAM) |                       \
> +        SCU_AST2500_HW_STRAP_RESERVED1)
> +
>   /* Swift hardware value: 0xF11AD206 */
>   #define SWIFT_BMC_HW_STRAP1 (                                           \
>           AST2500_HW_STRAP1_DEFAULTS |                                    \
> @@ -434,6 +449,49 @@ static void swift_bmc_i2c_init(AspeedBoardState *bmc)
>       i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 12), "tmp105", 0x4a);
>   }
>   
> +static void sonorapass_bmc_i2c_init(AspeedBoardState *bmc)
> +{
> +    AspeedSoCState *soc = &bmc->soc;
> +
> +    /* bus 2 : */
> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 2), "tmp105", 0x48);
> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 2), "tmp105", 0x49);
> +    /* bus 2 : pca9546 @ 0x73 */
> +
> +    /* bus 3 : pca9548 @ 0x70 */
> +
> +    /* bus 4 : */
> +    uint8_t *eeprom4_54 = g_malloc0(8 * 1024);
> +    smbus_eeprom_init_one(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 4), 0x54,
> +                          eeprom4_54);
> +    /* PCA9539 @ 0x76, but PCA9552 is compatible */
> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 4), "pca9552", 0x76);
> +    /* PCA9539 @ 0x77, but PCA9552 is compatible */
> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 4), "pca9552", 0x77);
> +
> +    /* bus 6 : */
> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 6), "tmp105", 0x48);
> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 6), "tmp105", 0x49);
> +    /* bus 6 : pca9546 @ 0x73 */
> +
> +    /* bus 8 : */
> +    uint8_t *eeprom8_56 = g_malloc0(8 * 1024);
> +    smbus_eeprom_init_one(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 8), 0x56,
> +                          eeprom8_56);
> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 8), "pca9552", 0x60);
> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 8), "pca9552", 0x61);
> +    /* bus 8 : adc128d818 @ 0x1d */
> +    /* bus 8 : adc128d818 @ 0x1f */
> +
> +    /* bus 13 : pca9548 @ 0x71
> +     *      - channel 3:
> +     *          - tmm421 @ 0x4c
> +     *          - tmp421 @ 0x4e
> +     *          - tmp421 @ 0x4f
> +     */
> +
> +}
> +
>   static void witherspoon_bmc_i2c_init(AspeedBoardState *bmc)
>   {
>       AspeedSoCState *soc = &bmc->soc;
> @@ -552,6 +610,21 @@ static void aspeed_machine_romulus_class_init(ObjectClass *oc, void *data)
>       mc->default_ram_size       = 512 * MiB;
>   };
>   
> +static void aspeed_machine_sonorapass_class_init(ObjectClass *oc, void *data)
> +{
> +    MachineClass *mc = MACHINE_CLASS(oc);
> +    AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
> +
> +    mc->desc       = "OCP SonoraPass BMC (ARM1176)";
> +    amc->soc_name  = "ast2500-a1";
> +    amc->hw_strap1 = SONORAPASS_BMC_HW_STRAP1;
> +    amc->fmc_model = "mx66l1g45g";
> +    amc->spi_model = "mx66l1g45g";
> +    amc->num_cs    = 2;
> +    amc->i2c_init  = sonorapass_bmc_i2c_init;
> +    mc->default_ram_size       = 512 * MiB;
> +};
> +
>   static void aspeed_machine_swift_class_init(ObjectClass *oc, void *data)
>   {
>       MachineClass *mc = MACHINE_CLASS(oc);
> @@ -631,6 +704,10 @@ static const TypeInfo aspeed_machine_types[] = {
>           .name          = MACHINE_TYPE_NAME("swift-bmc"),
>           .parent        = TYPE_ASPEED_MACHINE,
>           .class_init    = aspeed_machine_swift_class_init,
> +    }, {
> +        .name          = MACHINE_TYPE_NAME("sonorapass-bmc"),
> +        .parent        = TYPE_ASPEED_MACHINE,
> +        .class_init    = aspeed_machine_sonorapass_class_init,
>       }, {
>           .name          = MACHINE_TYPE_NAME("witherspoon-bmc"),
>           .parent        = TYPE_ASPEED_MACHINE,
Re: [PATCH v3] aspeed: Add support for the sonorapass-bmc board
Posted by Patrick Williams 1 month, 1 week ago 
On Tue, Sep 30, 2025 at 07:51:15AM +0200, Cédric Le Goater wrote:
> Hello Patrick
> 
> Would it be possible to contribute a functional test for this
> machine ?
> 
> The request applies to these Facebook machines :
> 
>    sonorapass-bmc

This machine type is deprecated and never went to production.

>    yosemitev2-bmc
>    tiogapass-bmc
>    fuji-bmc
>    fby35-bmc

All of these are used by OpenBMC and/or Meta for QEMU validation of
new BMC images.  I can get you an image for these if necessary.

> 
> Since these machines contribute little to the Aspeed models,
> their value lies in the firmware they can run to exercise the
> models. Without functional tests, I plan to schedule their
> removal in the QEMU 10.2 cycle.

I don't understand this statement.  What does "little value to the
Aspeed models" have to do with keeping machines in place.  If we are
only going to have support for machines that you deem as "valuable" why
would anyone contribute a new machine?  Is this a new policy that QEMU
only wants specific machine models for any particular SOC?

> The fby35-bmc value is in its multisoc nature. We now have the
> ast2700fc available as its replacement

We actually don't use the multisoc aspect of this machine.  I'd be fine
if we drop those pieces specifically but the general "can the BMC image
boot" is regularly used.


-- 
Patrick Williams
Re: [PATCH v3] aspeed: Add support for the sonorapass-bmc board
Posted by Cédric Le Goater 1 month, 1 week ago 
Hello Patrick

On 10/2/25 04:21, Patrick Williams wrote:
> On Tue, Sep 30, 2025 at 07:51:15AM +0200, Cédric Le Goater wrote:
>> Hello Patrick
>>
>> Would it be possible to contribute a functional test for this
>> machine ?
>>
>> The request applies to these Facebook machines :
>>
>>     sonorapass-bmc
> 
> This machine type is deprecated and never went to production.

OK. Let's deprecate then.

> 
>>     yosemitev2-bmc
>>     tiogapass-bmc
>>     fuji-bmc
>>     fby35-bmc
> 
> All of these are used by OpenBMC and/or Meta for QEMU validation of
> new BMC images.  I can get you an image for these if necessary.

That would be great ! Pointing to the latest images would be preferred.
  
>> Since these machines contribute little to the Aspeed models,
>> their value lies in the firmware they can run to exercise the
>> models. Without functional tests, I plan to schedule their
>> removal in the QEMU 10.2 cycle.
> 
> I don't understand this statement.  What does "little value to the
> Aspeed models" have to do with keeping machines in place. If we are> only going to have support for machines that you deem as "valuable" why
> would anyone contribute a new machine?  

This is specific to the Aspeed machines.

We maintain *many* Aspeed machines with only minor differences. If
the only distinction is the flash model, the 'ast2600-evb' machine
can be used with the 'fmc-model' option to specify the flash type.

The I2C devices attached to the board do introduce differences, but
if upstream is to maintain the QEMU machine, there must be a way to
test it. By the way, I liked the idea of introducing a file per
machine.

Finally, without tests, it is harder to determine when something
becomes deprecated/unused.

> Is this a new policy that QEMU
> only wants specific machine models for any particular SOC?

This is not a new policy, but it is strongly recommended to have
a way to test the machine, and I try to enforce that. However, if
someone indicates that a board is being used for kernel testing
but lacks an image, I consider that sufficient to conclude it is
not deprecated (and that providing a functional test is possible ;)

I hope this clarifies the intentions. It's more about making tests
available than limiting contributions.

> 
>> The fby35-bmc value is in its multisoc nature. We now have the
>> ast2700fc available as its replacement
> 
> We actually don't use the multisoc aspect of this machine.  I'd be fine
> if we drop those pieces specifically but the general "can the BMC image
> boot" is regularly used.

ok. I am fine with that if we don't need to boot the coprocessor.
Peter provided me images in the past (2022) and I am using :

   $qemu -machine fby35 \
      -drive file=$flash,format=raw,if=mtd \
      -device loader,file=Y35BCL.elf,addr=0,cpu-num=2 \
      -nographic  -display none -serial pty -serial pty -serial mon:stdio

and it seems that without Y35BCL.elf, the machine crashes.

Thanks,

C.
Re: [PATCH v3] aspeed: Add support for the sonorapass-bmc board
Posted by Peter Maydell 5 years, 6 months ago 
On Wed, 6 May 2020 at 19:32, Patrick Williams <patrick@stwcx.xyz> wrote:
>
> Sonora Pass is a 2 socket x86 motherboard designed by Facebook
> and supported by OpenBMC.  Strapping configuration was obtained
> from hardware and i2c configuration is based on dts found at:
>
> https://github.com/facebook/openbmc-linux/blob/1633c87b8ba7c162095787c988979b748ba65dc8/arch/arm/boot/dts/aspeed-bmc-facebook-sonorapass.dts
>
> Booted a test image of http://github.com/facebook/openbmc to login
> prompt.
>
> Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
> Reviewed-by: Amithash Prasad <amithash@fb.com>
> Reviewed-by: Cédric Le Goater <clg@kaod.org>



Applied to target-arm.next, thanks.

-- PMM
Re: [PATCH v3] aspeed: Add support for the sonorapass-bmc board
Posted by Peter Maydell 5 years, 6 months ago 
On Wed, 6 May 2020 at 19:32, Patrick Williams <patrick@stwcx.xyz> wrote:
>
> Sonora Pass is a 2 socket x86 motherboard designed by Facebook
> and supported by OpenBMC.  Strapping configuration was obtained
> from hardware and i2c configuration is based on dts found at:
>
> https://github.com/facebook/openbmc-linux/blob/1633c87b8ba7c162095787c988979b748ba65dc8/arch/arm/boot/dts/aspeed-bmc-facebook-sonorapass.dts
>
> Booted a test image of http://github.com/facebook/openbmc to login
> prompt.
>
> Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
> Reviewed-by: Amithash Prasad <amithash@fb.com>
> Reviewed-by: Cédric Le Goater <clg@kaod.org>

Looking up through the thread I can't find the email where
Amithash gave his reviewed-by tag -- did I miss it?

PS: for the future, v2/v3 etc patches should be sent as
fresh emails, not as followups/replies to the v1.

thanks
-- PMM
Re: [PATCH v3] aspeed: Add support for the sonorapass-bmc board
Posted by Patrick Williams 5 years, 6 months ago 
On Mon, May 11, 2020 at 11:54:42AM +0100, Peter Maydell wrote:
> On Wed, 6 May 2020 at 19:32, Patrick Williams <patrick@stwcx.xyz> wrote:

> Looking up through the thread I can't find the email where
> Amithash gave his reviewed-by tag -- did I miss it?

I probably shouldn't have done this.  I asked Amithash off-list for his
approval to add his Reviewed-by.  I'll ask him to reply to this with
confirmation.

> PS: for the future, v2/v3 etc patches should be sent as
> fresh emails, not as followups/replies to the v1.

Thanks.  I missed this detail when I read [1] before but I see it now.
It seems like LKML tends to do the opposite?

1. https://wiki.qemu.org/Contribute/SubmitAPatch

-- 
Patrick Williams
Re: [PATCH v3] aspeed: Add support for the sonorapass-bmc board
Posted by Peter Maydell 5 years, 6 months ago 
On Mon, 11 May 2020 at 14:13, Patrick Williams <patrick@stwcx.xyz> wrote:
>
> On Mon, May 11, 2020 at 11:54:42AM +0100, Peter Maydell wrote:
> > On Wed, 6 May 2020 at 19:32, Patrick Williams <patrick@stwcx.xyz> wrote:
>
> > Looking up through the thread I can't find the email where
> > Amithash gave his reviewed-by tag -- did I miss it?
>
> I probably shouldn't have done this.  I asked Amithash off-list for his
> approval to add his Reviewed-by.  I'll ask him to reply to this with
> confirmation.

Thanks; no big deal. I figured I'd check because the details
of how we handle reviewed-by tags are a bit non-obvious if you
haven't worked with projects like QEMU or the kernel that use
this email-based workflow before.

> > PS: for the future, v2/v3 etc patches should be sent as
> > fresh emails, not as followups/replies to the v1.
>
> Thanks.  I missed this detail when I read [1] before but I see it now.
> It seems like LKML tends to do the opposite?

I don't do kernel development but AIUI they have the same
general approach we do. Their process doc:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n771
says:
  "for a multi-patch series, it is generally
   best to avoid using In-Reply-To: to link to older versions of the
   series.  This way multiple versions of the patch don't become an
   unmanageable forest of references in email clients."

thanks
-- PMM

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.