[PATCH 0/1] hw/arm/aspeed: Add fby35 machine type

[PATCH 0/1] hw/arm/aspeed: Add fby35 machine type

[Peter Delevoryas]

Hey everyone,

I'm submitting another Facebook (Meta Platforms) machine type: this time I'm
including an acceptance test too.

Unfortunately, this machine boots _very_ slowly. 300+ seconds. I'm not sure why
this is (so I don't know how to fix it easily) and I don't know how to override
the avocado test timeout just for a single test, so I increased the global
timeout for all "boot_linux_console.py" tests from 90s to 400s. I doubt this is
acceptable, but what other option is there? Should I add
AVOCADO_TIMEOUT_EXPECTED?

@skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')

What is the point of this environment variable though, except to skip it in CIT?
If I run the test with this environment variable defined, it doesn't disable the
timeout, it just skips it right? I want an option to run this test with a larger
timeout.

Thanks,
Peter

Peter Delevoryas (1):
  hw/arm/aspeed: Add fby35 machine type

 hw/arm/aspeed.c                     | 63 +++++++++++++++++++++++++++++
 tests/avocado/boot_linux_console.py | 20 ++++++++-
 2 files changed, 82 insertions(+), 1 deletion(-)

-- 
2.30.2

[PATCH 1/1] hw/arm/aspeed: Add fby35 machine type

[Peter Delevoryas]

Add the 'fby35-bmc' machine type based on the kernel DTS[1] and userspace
i2c setup scripts[2]. Undefined values are inherited from the AST2600-EVB.

I also added an avocado test that uses a reference image I built and
uploaded to the FB Github Releases.

[1] https://github.com/facebook/openbmc-linux/blob/412d5053258007117e94b1e36015aefc1301474b/arch/arm/boot/dts/aspeed-bmc-facebook-fby35.dts
[2] https://github.com/facebook/openbmc/blob/e2294ff5d31dd65c248fe396a385286d6d5c463d/meta-facebook/meta-fby35/recipes-fby35/plat-utils/files/setup-dev.sh

Signed-off-by: Peter Delevoryas <pdel@fb.com>
---
 hw/arm/aspeed.c                     | 63 +++++++++++++++++++++++++++++
 tests/avocado/boot_linux_console.py | 20 ++++++++-
 2 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index a74c13ab0f..725c169488 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -21,6 +21,7 @@
 #include "hw/misc/led.h"
 #include "hw/qdev-properties.h"
 #include "sysemu/block-backend.h"
+#include "sysemu/reset.h"
 #include "hw/loader.h"
 #include "qemu/error-report.h"
 #include "qemu/units.h"
@@ -951,6 +952,35 @@ static void bletchley_bmc_i2c_init(AspeedMachineState *bmc)
     i2c_slave_create_simple(i2c[12], TYPE_PCA9552, 0x67);
 }
 
+static void fby35_i2c_init(AspeedMachineState *bmc)
+{
+    AspeedSoCState *soc = &bmc->soc;
+    I2CBus *i2c[16];
+
+    for (int i = 0; i < 16; i++) {
+        i2c[i] = aspeed_i2c_get_bus(&soc->i2c, i);
+    }
+
+    i2c_slave_create_simple(i2c[2], TYPE_LM75, 0x4f);
+    i2c_slave_create_simple(i2c[8], TYPE_TMP421, 0x1f);
+    /* Hotswap controller is actually supposed to be mp5920 or ltc4282. */
+    i2c_slave_create_simple(i2c[11], "adm1272", 0x44);
+    i2c_slave_create_simple(i2c[12], TYPE_LM75, 0x4e);
+    i2c_slave_create_simple(i2c[12], TYPE_LM75, 0x4f);
+
+    aspeed_eeprom_init(i2c[4], 0x51, 128 * KiB);
+    aspeed_eeprom_init(i2c[6], 0x51, 128 * KiB);
+    aspeed_eeprom_init(i2c[8], 0x50, 32 * KiB);
+    aspeed_eeprom_init(i2c[11], 0x51, 128 * KiB);
+    aspeed_eeprom_init(i2c[11], 0x54, 128 * KiB);
+
+    /*
+     * TODO: There is a multi-master i2c connection to an AST1030 MiniBMC on
+     * buses 0, 1, 2, 3, and 9. Source address 0x10, target address 0x20 on
+     * each.
+     */
+}
+
 static bool aspeed_get_mmio_exec(Object *obj, Error **errp)
 {
     return ASPEED_MACHINE(obj)->mmio_exec;
@@ -1293,6 +1323,35 @@ static void aspeed_machine_bletchley_class_init(ObjectClass *oc, void *data)
         aspeed_soc_num_cpus(amc->soc_name);
 }
 
+static void fby35_reset(MachineState *state)
+{
+    AspeedMachineState *bmc = ASPEED_MACHINE(state);
+    AspeedGPIOState *gpio = &bmc->soc.gpio;
+
+    qemu_devices_reset();
+
+    /* Board ID */
+    object_property_set_bool(OBJECT(gpio), "gpioV4", true, &error_fatal);
+    object_property_set_bool(OBJECT(gpio), "gpioV5", true, &error_fatal);
+    object_property_set_bool(OBJECT(gpio), "gpioV6", true, &error_fatal);
+    object_property_set_bool(OBJECT(gpio), "gpioV7", false, &error_fatal);
+}
+
+static void aspeed_machine_fby35_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+    AspeedMachineClass *amc = ASPEED_MACHINE_CLASS(oc);
+
+    mc->desc       = "Facebook fby35 BMC (Cortex-A7)";
+    mc->reset      = fby35_reset;
+    amc->fmc_model = "mx66l1g45g";
+    amc->num_cs    = 2;
+    amc->macs_mask = ASPEED_MAC3_ON;
+    amc->i2c_init  = fby35_i2c_init;
+    /* FIXME: Replace this macro with something more general */
+    mc->default_ram_size = FUJI_BMC_RAM_SIZE;
+}
+
 #define AST1030_INTERNAL_FLASH_SIZE (1024 * 1024)
 /* Main SYSCLK frequency in Hz (200MHz) */
 #define SYSCLK_FRQ 200000000ULL
@@ -1411,6 +1470,10 @@ static const TypeInfo aspeed_machine_types[] = {
         .name          = MACHINE_TYPE_NAME("bletchley-bmc"),
         .parent        = TYPE_ASPEED_MACHINE,
         .class_init    = aspeed_machine_bletchley_class_init,
+    }, {
+        .name          = MACHINE_TYPE_NAME("fby35-bmc"),
+        .parent        = MACHINE_TYPE_NAME("ast2600-evb"),
+        .class_init    = aspeed_machine_fby35_class_init,
     }, {
         .name           = MACHINE_TYPE_NAME("ast1030-evb"),
         .parent         = TYPE_ASPEED_MACHINE,
diff --git a/tests/avocado/boot_linux_console.py b/tests/avocado/boot_linux_console.py
index 45a2ceda22..8ba7dafb63 100644
--- a/tests/avocado/boot_linux_console.py
+++ b/tests/avocado/boot_linux_console.py
@@ -89,7 +89,7 @@ class BootLinuxConsole(LinuxKernelTest):
     Boots a Linux kernel and checks that the console is operational and the
     kernel command line is properly passed from QEMU to the kernel
     """
-    timeout = 90
+    timeout = 400
 
     def test_x86_64_pc(self):
         """
@@ -1111,6 +1111,24 @@ def test_arm_ast2600_debian(self):
         self.wait_for_console_pattern("SMP: Total of 2 processors activated")
         self.wait_for_console_pattern("No filesystem could mount root")
 
+    def test_arm_ast2600_fby35(self):
+        """
+        :avocado: tags=arch:arm
+        :avocado: tags=machine:fby35-bmc
+        """
+        image_url = ('https://github.com/facebook/openbmc/releases'
+                     '/download/openbmc-e2294ff5d31d/fby35.mtd')
+        image_hash = ('0a3635646f38373e318811be1ec374'
+                      '3540cc456aafe87234655081684b03b713')
+        image_path = self.fetch_asset(image_url, asset_hash=image_hash,
+                                      algorithm='sha256')
+        self.vm.set_console()
+        self.vm.add_args('-drive', f'file={image_path},if=mtd,format=raw',
+                         '-drive', f'file={image_path},if=mtd,format=raw')
+        self.vm.launch()
+        self.wait_for_console_pattern('OpenBMC Release fby35-e2294ff5d3')
+        self.wait_for_console_pattern('bmc-oob. login:')
+
     def test_m68k_mcf5208evb(self):
         """
         :avocado: tags=arch:m68k
-- 
2.30.2

Re: [PATCH 0/1] hw/arm/aspeed: Add fby35 machine type

[Cédric Le Goater]

On 5/3/22 22:44, Peter Delevoryas wrote:
> Hey everyone,
> 
> I'm submitting another Facebook (Meta Platforms) machine type: this time I'm
> including an acceptance test too.
> 
> Unfortunately, this machine boots _very_ slowly. 300+ seconds. 

This is too much for avocado tests.

> I'm not sure why this is (so I don't know how to fix it easily)

The fuji has the same kind of problem. It takes ages to load the lzma ramdisk.
Could it be a modeling issue ? or how the FW image is compiled ?

Thanks,

C.


> and I don't know how to override
> the avocado test timeout just for a single test, so I increased the global
> timeout for all "boot_linux_console.py" tests from 90s to 400s. I doubt this is
> acceptable, but what other option is there? Should I add
> AVOCADO_TIMEOUT_EXPECTED?
> 
> @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
> 
> What is the point of this environment variable though, except to skip it in CIT?
> If I run the test with this environment variable defined, it doesn't disable the
> timeout, it just skips it right? I want an option to run this test with a larger
> timeout.
> 
> Thanks,
> Peter
> 
> Peter Delevoryas (1):
>    hw/arm/aspeed: Add fby35 machine type
> 
>   hw/arm/aspeed.c                     | 63 +++++++++++++++++++++++++++++
>   tests/avocado/boot_linux_console.py | 20 ++++++++-
>   2 files changed, 82 insertions(+), 1 deletion(-)
> 

Re: [PATCH 0/1] hw/arm/aspeed: Add fby35 machine type

[Peter Delevoryas]

> On May 3, 2022, at 2:35 PM, Cédric Le Goater <clg@kaod.org> wrote:
> 
> On 5/3/22 22:44, Peter Delevoryas wrote:
>> Hey everyone,
>> I'm submitting another Facebook (Meta Platforms) machine type: this time I'm
>> including an acceptance test too.
>> Unfortunately, this machine boots _very_ slowly. 300+ seconds. 
> 
> This is too much for avocado tests.

Erg, yeah I figured as much. I’ll just resubmit it without the avocado test then,
if that sounds ok to you.

> 
>> I'm not sure why this is (so I don't know how to fix it easily)
> 
> The fuji has the same kind of problem. It takes ages to load the lzma ramdisk.
> Could it be a modeling issue ? or how the FW image is compiled ?

Yeah, one reason is that Facebook OpenBMC machines have an unnecessarily
big initramfs that includes all the rootfs stuff, whereas regular OpenBMC
machines have a smaller initramfs right? I don’t entirely know what I’m talking
about though.

I think most FB machines have moved to zstd compression recently though,
but this one may have been missed: I can fix that on the image side. I’ll
also experiment more to see if it’s something wrong with the image, or possibly
a regression in QEMU. It would really be super awesome if it could boot faster,
so I’m very motivated to find a solution.

> 
> Thanks,
> 
> C.
> 
> 
>> and I don't know how to override
>> the avocado test timeout just for a single test, so I increased the global
>> timeout for all "boot_linux_console.py" tests from 90s to 400s. I doubt this is
>> acceptable, but what other option is there? Should I add
>> AVOCADO_TIMEOUT_EXPECTED?
>> @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
>> What is the point of this environment variable though, except to skip it in CIT?
>> If I run the test with this environment variable defined, it doesn't disable the
>> timeout, it just skips it right? I want an option to run this test with a larger
>> timeout.
>> Thanks,
>> Peter
>> Peter Delevoryas (1):
>>   hw/arm/aspeed: Add fby35 machine type
>>  hw/arm/aspeed.c                     | 63 +++++++++++++++++++++++++++++
>>  tests/avocado/boot_linux_console.py | 20 ++++++++-
>>  2 files changed, 82 insertions(+), 1 deletion(-)
> 

Re: [PATCH 0/1] hw/arm/aspeed: Add fby35 machine type

[Peter Delevoryas]

> On May 3, 2022, at 3:47 PM, Peter Delevoryas <pdel@fb.com> wrote:
> 
> 
> 
>> On May 3, 2022, at 2:35 PM, Cédric Le Goater <clg@kaod.org> wrote:
>> 
>> On 5/3/22 22:44, Peter Delevoryas wrote:
>>> Hey everyone,
>>> I'm submitting another Facebook (Meta Platforms) machine type: this time I'm
>>> including an acceptance test too.
>>> Unfortunately, this machine boots _very_ slowly. 300+ seconds. 
>> 
>> This is too much for avocado tests.
> 
> Erg, yeah I figured as much. I’ll just resubmit it without the avocado test then,
> if that sounds ok to you.
> 
>> 
>>> I'm not sure why this is (so I don't know how to fix it easily)
>> 
>> The fuji has the same kind of problem. It takes ages to load the lzma ramdisk.
>> Could it be a modeling issue ? or how the FW image is compiled ?
> 
> Yeah, one reason is that Facebook OpenBMC machines have an unnecessarily
> big initramfs that includes all the rootfs stuff, whereas regular OpenBMC
> machines have a smaller initramfs right? I don’t entirely know what I’m talking
> about though.
> 
> I think most FB machines have moved to zstd compression recently though,
> but this one may have been missed: I can fix that on the image side. I’ll
> also experiment more to see if it’s something wrong with the image, or possibly
> a regression in QEMU. It would really be super awesome if it could boot faster,
> so I’m very motivated to find a solution.

Oh: I forgot, somebody reminded me, we also execute early U-Boot SPL code in-flash,
e.g. without SRAM/etc. That is also probably different from most other machines.

> 
>> 
>> Thanks,
>> 
>> C.
>> 
>> 
>>> and I don't know how to override
>>> the avocado test timeout just for a single test, so I increased the global
>>> timeout for all "boot_linux_console.py" tests from 90s to 400s. I doubt this is
>>> acceptable, but what other option is there? Should I add
>>> AVOCADO_TIMEOUT_EXPECTED?
>>> @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'), 'Test might timeout')
>>> What is the point of this environment variable though, except to skip it in CIT?
>>> If I run the test with this environment variable defined, it doesn't disable the
>>> timeout, it just skips it right? I want an option to run this test with a larger
>>> timeout.
>>> Thanks,
>>> Peter
>>> Peter Delevoryas (1):
>>>  hw/arm/aspeed: Add fby35 machine type
>>> hw/arm/aspeed.c                     | 63 +++++++++++++++++++++++++++++
>>> tests/avocado/boot_linux_console.py | 20 ++++++++-
>>> 2 files changed, 82 insertions(+), 1 deletion(-)
>> 
> 

Re: [PATCH 0/1] hw/arm/aspeed: Add fby35 machine type

[Cédric Le Goater]

On 5/4/22 00:47, Peter Delevoryas wrote:
> 
> 
>> On May 3, 2022, at 2:35 PM, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> On 5/3/22 22:44, Peter Delevoryas wrote:
>>> Hey everyone,
>>> I'm submitting another Facebook (Meta Platforms) machine type: this time I'm
>>> including an acceptance test too.
>>> Unfortunately, this machine boots _very_ slowly. 300+ seconds.
>>
>> This is too much for avocado tests.
> 
> Erg, yeah I figured as much. I’ll just resubmit it without the avocado test then,
> if that sounds ok to you.
> 
>>
>>> I'm not sure why this is (so I don't know how to fix it easily)
>>
>> The fuji has the same kind of problem. It takes ages to load the lzma ramdisk.
>> Could it be a modeling issue ? or how the FW image is compiled ?
> 
> Yeah, one reason is that Facebook OpenBMC machines have an unnecessarily
> big initramfs that includes all the rootfs stuff, 

Indeed,

    Trying 'ramdisk@1' ramdisk subimage
      Description:  RAMDISK
      Type:         RAMDisk Image
      Compression:  lzma compressed
      Data Start:   0x2047da18
      Data Size:    21938373 Bytes = 20.9 MiB

That doesn't help for sure.

> whereas regular OpenBMC machines have a smaller initramfs right? 

yes, about 1MB.

> I don’t entirely know what I’m talking about though.
> 
> I think most FB machines have moved to zstd compression recently though,
> but this one may have been missed: I can fix that on the image side. I’ll
> also experiment more to see if it’s something wrong with the image, or possibly
> a regression in QEMU. It would really be super awesome if it could boot faster,
> so I’m very motivated to find a solution.

there is something else because loading the kernel on the fuji takes
much longer than on the ast2600-evb and it is the same size :

    Trying 'kernel@1' kernel subimage
      Description:  Linux kernel
      Type:         Kernel Image
      Compression:  uncompressed
      Data Start:   0x201000e0
      Data Size:    3659848 Bytes = 3.5 MiB


Is uboot doing some special CPU configuration which would slow down
emulation ? Try profiling may be.

Thanks,

C.

Re: [PATCH 0/1] hw/arm/aspeed: Add fby35 machine type

[Philippe Mathieu-Daudé via]

On 4/5/22 00:47, Peter Delevoryas wrote:
> 
> 
>> On May 3, 2022, at 2:35 PM, Cédric Le Goater <clg@kaod.org> wrote:
>>
>> On 5/3/22 22:44, Peter Delevoryas wrote:
>>> Hey everyone,
>>> I'm submitting another Facebook (Meta Platforms) machine type: this time I'm
>>> including an acceptance test too.
>>> Unfortunately, this machine boots _very_ slowly. 300+ seconds.
>>
>> This is too much for avocado tests.

Use:

   @skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
   @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'),
               'Big initramfs and run from flash')

> Erg, yeah I figured as much. I’ll just resubmit it without the avocado test then,
> if that sounds ok to you.

No, please keep the test. While it won't run on CI, we can run it 
locally, very useful to bisect.

>>> I'm not sure why this is (so I don't know how to fix it easily)
>>
>> The fuji has the same kind of problem. It takes ages to load the lzma ramdisk.
>> Could it be a modeling issue ? or how the FW image is compiled ?
> 
> Yeah, one reason is that Facebook OpenBMC machines have an unnecessarily
> big initramfs that includes all the rootfs stuff, whereas regular OpenBMC
> machines have a smaller initramfs right? I don’t entirely know what I’m talking
> about though.
> 
> I think most FB machines have moved to zstd compression recently though,
> but this one may have been missed: I can fix that on the image side. I’ll
> also experiment more to see if it’s something wrong with the image, or possibly
> a regression in QEMU. It would really be super awesome if it could boot faster,
> so I’m very motivated to find a solution.

Re: [PATCH 0/1] hw/arm/aspeed: Add fby35 machine type

[Peter Delevoryas]

> On May 30, 2022, at 8:29 AM, Philippe Mathieu-Daudé via <qemu-arm@nongnu.org> wrote:
> 
> On 4/5/22 00:47, Peter Delevoryas wrote:
>>> On May 3, 2022, at 2:35 PM, Cédric Le Goater <clg@kaod.org> wrote:
>>> 
>>> On 5/3/22 22:44, Peter Delevoryas wrote:
>>>> Hey everyone,
>>>> I'm submitting another Facebook (Meta Platforms) machine type: this time I'm
>>>> including an acceptance test too.
>>>> Unfortunately, this machine boots _very_ slowly. 300+ seconds.
>>> 
>>> This is too much for avocado tests.
> 
> Use:
> 
>  @skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
>  @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'),
>              'Big initramfs and run from flash')

Thanks for this suggestion!

> 
>> Erg, yeah I figured as much. I’ll just resubmit it without the avocado test then,
>> if that sounds ok to you.
> 
> No, please keep the test. While it won't run on CI, we can run it locally, very useful to bisect.

Ok, I’d be happy to resubmit the test now with the @skipIf and @skipUnless decorators
(Since the machine definition has been merged at this point).

> 
>>>> I'm not sure why this is (so I don't know how to fix it easily)
>>> 
>>> The fuji has the same kind of problem. It takes ages to load the lzma ramdisk.
>>> Could it be a modeling issue ? or how the FW image is compiled ?
>> Yeah, one reason is that Facebook OpenBMC machines have an unnecessarily
>> big initramfs that includes all the rootfs stuff, whereas regular OpenBMC
>> machines have a smaller initramfs right? I don’t entirely know what I’m talking
>> about though.
>> I think most FB machines have moved to zstd compression recently though,
>> but this one may have been missed: I can fix that on the image side. I’ll
>> also experiment more to see if it’s something wrong with the image, or possibly
>> a regression in QEMU. It would really be super awesome if it could boot faster,
>> so I’m very motivated to find a solution.
>