QEMU and CI

Cédric Le Goater clg at kaod.org
Wed Apr 10 16:16:42 AEST 2019


On 4/10/19 3:09 AM, Andrew Jeffery wrote:
> 
> 
> On Wed, 10 Apr 2019, at 09:21, Bills, Jason M wrote:
>>
>>
>>>> You can boot your wolf pass image in the current qemu. To demonstrate
>>>> I grabbed a tiogapass flash image from CI and booted it:
>>>>
>>>> $ arm-softmmu/qemu-system-arm -M ast2500-evb -drive
>>>> file=flash-tiogapass,format=raw,if=mtd -serial mon:stdio  -nographic
>>>> ...
>>>> root at tiogapass:~# cat /etc/os-release
>>>> ID="openbmc-phosphor"
>>>> NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro)"
>>>> VERSION="2.7.0-dev"
>>>> VERSION_ID="2.7.0-dev-347-gd631110d4"
>>>> PRETTY_NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference
>>>> Distro) 2.7.0-dev"
>>>> BUILD_ID="2.7.0-dev"
>>>> OPENBMC_TARGET_MACHINE="tiogapass"
>>>>
>>>> As Andrew said, your next step would be to add a wolfpass machine type
>>>> to upstream qemu. Take a look at the aspeed_boards array in
>>>> hw/arm/aspeed.c.
>>>
>>> Yes. it should be relatively easy to add the machine.
>> Thanks! I was able to get an initial s2600wf machine booted from one of 
>> my own builds.
>>
>> One issue I have on my machine, that I don't see with witherspoon-bmc, 
>> is something in U-Boot that is preventing it from booting automatically. 
>>   When I start my image, it stops at the U-Boot prompt below where I can 
>> just run 'boot' and it will boot normally.  Is this something you have 
>> seen before?
> 
> How are you testing witherspoon-bmc? Using a Witherspoon OpenBMC
> image?
> 
> My gut feeling is it's some kind of u-boot configuration issue. I don't see
> the output `Hit any key to stop autoboot:  0` in the log below, which might
> hint that your u-boot has auto-boot disabled (or something like that).
> 
> Have you tried running your u-boot on hardware to see if it has the same
> behaviour (eliminating qemu as the cause)?

what is the u-boot environment like ? 

> 
>>
>> qemu-system-arm: Aspeed iBT has no chardev backend
>>
>>
>> U-Boot 2016.07 (Apr 04 2019 - 23:46:17 +0000)
>>
>> SOC : AST2500-A1
>> RST : 0x01
>> PLL :     24 MHz
>> CPU :    792 MHz
>> MEM :   2.240 MHz, EEC: Disable, Cache: Disable
>> VGA :    16 MiB
>> DRAM :   init by SOC
>>         Watchdog enabled
>> DRAM:  240 MiB
>> kcs_init Channel: 3
>> Flash: 64 MiB
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Net:   MAC0 : RMII/NCSI
>> MAC1 : RGMII
>> FTGMAC100#0
>> Error: FTGMAC100#0 address not set.
>> , FTGMAC100#1
>> Error: FTGMAC100#1 address not set.
>>
>> ast#
>>
>>
>>>
>>>>  From there the next step is to add the peripherals that your machine
>>>> has. This will involve writing models for the i2c devices you have
>>>> attached, and perhaps emulators for host connected devices (PECI?).
>>>> This could be more involved so please use the list to discuss your
>>>> plans.
>>>
>>> Yes please. It would be nice to have better support for I2C devices
>>> and work on a simple interface (QMP based) to interact with them, so
>>> that we can exercise the monitoring done by OpenBMC. PSU devices are
>>> a good topic for that.
>> I added some i2c temp sensor devices from the existing models. They were
>> detected and loaded properly by entity-manager, but the readings were 
>> all zeroes.  This is all new for me, so I assume I'm missing something. 
>> I still need to go through the existing QEMU tests on OpenBMC and see 
>> what is done there.
> 
> If the kernel exposes the devices then you've probably got them hooked up
> correctly. Have you looked at the models to see what data they should be
> producing? How were you observing the values? Probably best to poke
> directly with e.g. i2cget (either unbind the drivers, or just use `-f`).

yes. take a look at the tmp421. tmp105 should be the same.


The palmetto machine sets the temperature values at init time :

    object_property_set_int(OBJECT(dev), 31000, "temperature0", &error_abort);
    object_property_set_int(OBJECT(dev), 28000, "temperature1", &error_abort);
    object_property_set_int(OBJECT(dev), 20000, "temperature2", &error_abort);
    object_property_set_int(OBJECT(dev), 110000, "temperature3", &error_abort);

which can be seen at run time :

   root at palmetto:~# cat /sys/class/hwmon/hwmon0/temp*input 
   30938
   27938
   19938
   109938
   
if you run from the monitor : 

   (qemu) qom-set /machine/unattached/device[5]/ temperature0 10000
   (qemu) qom-set /machine/unattached/device[5]/ temperature1 20000
   (qemu) qom-set /machine/unattached/device[5]/ temperature2 30000
   (qemu) qom-set /machine/unattached/device[5]/ temperature3 40000

you will see the changes in the guest :
 
   root at palmetto:~# cat /sys/class/hwmon/hwmon0/temp*input
   9938
   19938
   29938
   39938


>>
>>>
>>>> There are also a large number of peripherals inside the ASPEED SoC
>>>> that lack models. Let us know on the list if you think you will start
>>>> working on one so we don't duplicate efforts.
>>>>
>>>> Submit your patches against the upstream qemu tree. Andrew, Cedric and
>>>> I are the upstream maintainers so we will be on cc there.
>>>
>>> We are keeping the models in development under in this tree :
>>>    
>>>     https://github.com/openbmc/qemu
>>>
>>> Some have been there a bit too long because we lacked time to make
>>> them ready but please prefer mainline. We rebase quite often anyhow.
>>> I should push today a new version on 4.0-rc3.
>>>
>>> Check out this page before sending :
>>>
>>>     https://wiki.qemu.org/Contribute/SubmitAPatch
>>>
>>
>> Thanks for the help!  Here is what I have for my s2600wf machine so far:
>> Subject: [PATCH] Add an s2600wf machine type

add a "hw/arm/aspeed: " prefix to the subject.


>>
>> Include the HW strap setting and some I2C temperature sensors.
>>
>> Signed-off-by: Jason M. Bills <jason.m.bills at linux.intel.com>
>> ---
>>   hw/arm/aspeed.c | 36 ++++++++++++++++++++++++++++++++++++
>>   1 file changed, 36 insertions(+)
>>
>> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
>> index 465e65f323..c9d9c23995 100644
>> --- a/hw/arm/aspeed.c
>> +++ b/hw/arm/aspeed.c
>> @@ -60,6 +60,21 @@ struct AspeedBoardState {
>>           SCU_HW_STRAP_MAC0_RGMII) &                                      \
>>           ~SCU_HW_STRAP_2ND_BOOT_WDT)
>>
>> +/* S2600WF hardware value: 0xF3CCC286 */
>> +#define S2600WF_BMC_HW_STRAP1 ((                                        \
>> +        AST2500_HW_STRAP1_DEFAULTS |                                    \
>> +        SCU_AST2500_HW_STRAP_SPI_AUTOFETCH_ENABLE |                     \
>> +        SCU_AST2500_HW_STRAP_GPIO_STRAP_ENABLE |                        \
>> +        SCU_AST2500_HW_STRAP_UART_DEBUG |                               \
>> +        SCU_AST2500_HW_STRAP_ESPI_ENABLE |                              \
>> +        SCU_AST2500_HW_STRAP_DDR4_ENABLE |                              \
>> +        SCU_HW_STRAP_GPIOE_PT_EN |                                      \
>> +        SCU_AST2400_HW_STRAP_ACPI_DIS |                                 \
>> +        SCU_HW_STRAP_CLK_48M_IN |                                       \
>> +        SCU_HW_STRAP_VGA_CLASS_CODE |                                   \
>> +        SCU_HW_STRAP_MAC1_RGMII) &                                      \
>> +        ~SCU_HW_STRAP_2ND_BOOT_WDT)
>> +
>>   /* Romulus hardware value: 0xF10AD206 */
>>   #define ROMULUS_BMC_HW_STRAP1 (                                         \
>>           AST2500_HW_STRAP1_DEFAULTS |                                    \
>> @@ -281,6 +296,18 @@ static void ast2500_evb_i2c_init(AspeedBoardState *bmc)
>>       i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 11), 
>> "ds1338", 0x32);
>>   }
>>
>> +static void s2600wf_bmc_i2c_init(AspeedBoardState *bmc)
>> +{
>> +    AspeedSoCState *soc = &bmc->soc;
>> +
>> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 6), 
>> "tmp421", 0x4d);
>> +    /* The s2600wf expects a TMP75 but a TMP105 is compatible */
>> +    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);
>> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 6), 
>> "tmp105", 0x4a);
>> +    i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 6), 
>> "tmp105", 0x4b);
>> +}
>> +
>>   static void romulus_bmc_i2c_init(AspeedBoardState *bmc)
>>   {
>>       AspeedSoCState *soc = &bmc->soc;
>> @@ -390,6 +417,15 @@ static const AspeedBoardConfig aspeed_boards[] = {
>>           .spi_model = "mx25l25635e",
>>           .num_cs    = 1,
>>           .i2c_init  = ast2500_evb_i2c_init,
>> +    }, {
>> +        .name      = MACHINE_TYPE_NAME("s2600wf-bmc"),
>> +        .desc      = "Intel S2600WF BMC (ARM1176)",
>> +        .soc_name  = "ast2500-a1",
>> +        .hw_strap1 = S2600WF_BMC_HW_STRAP1,
>> +        .fmc_model = "n25q512a",
>> +        .spi_model = "n25q512a",
>> +        .num_cs    = 1,
>> +        .i2c_init  = s2600wf_bmc_i2c_init,
>>       }, {
>>           .name      = MACHINE_TYPE_NAME("romulus-bmc"),
>>           .desc      = "OpenPOWER Romulus BMC (ARM1176)",
> 
> Nice!

Yes. Please send to mainline.

Thanks,

C.


More information about the openbmc mailing list