QEMU and CI
Andrew Jeffery
andrew at aj.id.au
Thu Apr 11 10:25:34 AEST 2019
On Thu, 11 Apr 2019, at 05:23, Bills, Jason M wrote:
> >>> 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)
Right, sounds like the cause of your issue. I'm meant to be modelling the
GPIO controller properly, though that task is still languishing somewhere
in my todo list.
If you want to take up hacking on it, please do (and let me know)!
Andrew
>
> >
> > 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