QEMU and CI
Bills, Jason M
jason.m.bills at linux.intel.com
Thu Apr 11 05:53:24 AEST 2019
>>> 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?
Yes, I built a Witherspoon OpenBMC image to test the QEMU machine.
>>
>> 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)?
Yes, I'm running the same image as on the physical platform. However, I
may know what is causing it to stop booting. On the S2600WF system, we
have a "force update" jumper connected to GPIOD0 that forces the system
to stop in U-Boot.
On my QEMU system that GPIO is 0 (low-asserted), but on my physical
platform it is 1 which explains why QEMU stops in U-Boot and my physical
system doesn't.
I searched around in the qemu repo and online but so far haven't found
the right way to set GPIOD0 to 1 during init (or during runtime for that
matter). I found the Aspeed GPIO device, but it looks like it might
just be the memory region, so not sure if manipulating the registers is
the right approach:
(qemu) qom-list /machine/soc/gpio/aspeed.gpio[0]
type (string)
addr (uint64)
container (link<qemu:memory-region>)
priority (uint32)
size (uint64)
>
> what is the u-boot environment like ?
Not sure it's still needed, but here is my u-boot environment for
completeness:
ast# print
baudrate=115200
bootargs=console=ttyS4,115200n8 root=/dev/ram rw resetreason=0x1
resetreason=0x1
bootcmd=bootm 20080000
bootdelay=2
ethact=FTGMAC100#0
spi_dma=yes
stderr=serial
stdin=serial
stdout=serial
verify=yes
Environment size: 236/65531 bytes
>
>>
>>>
>>> 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
>
>
This example was excellent! I was able to find my temperature sensor
devices and use qom-set to change them above the threshold and see
OpenBMC log a SEL event. I've updated my patch to set each sensor to
50C at init time.
>>>
>>>>
>>>>> 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.
Done. I also added the default 50C setting to each temp sensor. Once I
can get the GPIO to stop interfering with boot, I think it will be ready
to go.
Thanks again for your time and help!
-Jason
>
>
>>>
>>> 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