QEMU and CI
Andrew Jeffery
andrew at aj.id.au
Wed Apr 10 11:09:58 AEST 2019
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)?
>
> 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`).
>
> >
> >> 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
>
> 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!
Andrew
> --
> 2.17.1
>
> -Jason
>
More information about the openbmc
mailing list