* QEMU and CI @ 2019-04-08 19:24 Bills, Jason M 2019-04-09 0:46 ` Andrew Jeffery 0 siblings, 1 reply; 9+ messages in thread From: Bills, Jason M @ 2019-04-08 19:24 UTC (permalink / raw) To: OpenBMC Maillist Hello, I'm looking into what it might take to get the Intel S2600WF (Wolf Pass) board running in QEMU and possibly CI. In the OpenBMC docs, it points to a QEMU fork here: https://github.com/openbmc/qemu. Is this the right place for me to start looking at what is currently implemented for QEMU in OpenBMC? Thanks! -Jason ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QEMU and CI 2019-04-08 19:24 QEMU and CI Bills, Jason M @ 2019-04-09 0:46 ` Andrew Jeffery 2019-04-09 2:55 ` Joel Stanley 0 siblings, 1 reply; 9+ messages in thread From: Andrew Jeffery @ 2019-04-09 0:46 UTC (permalink / raw) To: Bills, Jason M, OpenBMC Maillist; +Cc: Cédric Le Goater, Joel Stanley Hi Jason, On Tue, 9 Apr 2019, at 04:56, Bills, Jason M wrote: > Hello, > > I'm looking into what it might take to get the Intel S2600WF (Wolf Pass) > board running in QEMU and possibly CI. > > In the OpenBMC docs, it points to a QEMU fork here: > https://github.com/openbmc/qemu. Is this the right place for me to > start looking at what is currently implemented for QEMU in OpenBMC? Yes, with the note that most of the support is already upstream. openbmc/qemu contains the patches that haven't quite yet made it. If you're planning to add S2600WF support to QEMU I suggest you send your patches upstream first (like we do for the kernel), and we can backport them to our fork once they're accepted. It's mainly Cédric, Joel and myself hacking on it - if you have WIP patches that you want to run past people before sending upstream then Cc us and the OpenBMC list for some quick feedback. Hope that helps! Andrew > > Thanks! > -Jason > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QEMU and CI 2019-04-09 0:46 ` Andrew Jeffery @ 2019-04-09 2:55 ` Joel Stanley 2019-04-09 6:12 ` Cédric Le Goater 0 siblings, 1 reply; 9+ messages in thread From: Joel Stanley @ 2019-04-09 2:55 UTC (permalink / raw) To: Bills, Jason M; +Cc: OpenBMC Maillist, Cédric Le Goater, Andrew Jeffery On Tue, 9 Apr 2019 at 00:46, Andrew Jeffery <andrew@aj.id.au> wrote: > > Hi Jason, > > On Tue, 9 Apr 2019, at 04:56, Bills, Jason M wrote: > > Hello, > > > > I'm looking into what it might take to get the Intel S2600WF (Wolf Pass) > > board running in QEMU and possibly CI. 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@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. 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. 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. Cheers, Joel > > > > In the OpenBMC docs, it points to a QEMU fork here: > > https://github.com/openbmc/qemu. Is this the right place for me to > > start looking at what is currently implemented for QEMU in OpenBMC? > > Yes, with the note that most of the support is already upstream. > openbmc/qemu contains the patches that haven't quite yet made it. If > you're planning to add S2600WF support to QEMU I suggest you send > your patches upstream first (like we do for the kernel), and we can > backport them to our fork once they're accepted. > > It's mainly Cédric, Joel and myself hacking on it - if you have WIP patches > that you want to run past people before sending upstream then Cc us > and the OpenBMC list for some quick feedback. > > Hope that helps! > > Andrew > > > > > Thanks! > > -Jason > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QEMU and CI 2019-04-09 2:55 ` Joel Stanley @ 2019-04-09 6:12 ` Cédric Le Goater 2019-04-09 23:51 ` Bills, Jason M 0 siblings, 1 reply; 9+ messages in thread From: Cédric Le Goater @ 2019-04-09 6:12 UTC (permalink / raw) To: Joel Stanley, Bills, Jason M; +Cc: Andrew Jeffery, OpenBMC Maillist On 4/9/19 4:55 AM, Joel Stanley wrote: > On Tue, 9 Apr 2019 at 00:46, Andrew Jeffery <andrew@aj.id.au> wrote: >> >> Hi Jason, >> >> On Tue, 9 Apr 2019, at 04:56, Bills, Jason M wrote: >>> Hello, >>> >>> I'm looking into what it might take to get the Intel S2600WF (Wolf Pass) >>> board running in QEMU and possibly CI. > > 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@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. > 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. > 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, C. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QEMU and CI 2019-04-09 6:12 ` Cédric Le Goater @ 2019-04-09 23:51 ` Bills, Jason M 2019-04-10 1:09 ` Andrew Jeffery 0 siblings, 1 reply; 9+ messages in thread From: Bills, Jason M @ 2019-04-09 23:51 UTC (permalink / raw) To: Cédric Le Goater, Joel Stanley; +Cc: Andrew Jeffery, OpenBMC Maillist >> 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@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? 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. > >> 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@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)", -- 2.17.1 -Jason ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: QEMU and CI 2019-04-09 23:51 ` Bills, Jason M @ 2019-04-10 1:09 ` Andrew Jeffery 2019-04-10 6:16 ` Cédric Le Goater 0 siblings, 1 reply; 9+ messages in thread From: Andrew Jeffery @ 2019-04-10 1:09 UTC (permalink / raw) To: Bills, Jason M, Cédric Le Goater, Joel Stanley; +Cc: OpenBMC Maillist 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@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@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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QEMU and CI 2019-04-10 1:09 ` Andrew Jeffery @ 2019-04-10 6:16 ` Cédric Le Goater 2019-04-10 19:53 ` Bills, Jason M 0 siblings, 1 reply; 9+ messages in thread From: Cédric Le Goater @ 2019-04-10 6:16 UTC (permalink / raw) To: Andrew Jeffery, Bills, Jason M, Joel Stanley; +Cc: OpenBMC Maillist 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@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@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@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@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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QEMU and CI 2019-04-10 6:16 ` Cédric Le Goater @ 2019-04-10 19:53 ` Bills, Jason M 2019-04-11 0:25 ` Andrew Jeffery 0 siblings, 1 reply; 9+ messages in thread From: Bills, Jason M @ 2019-04-10 19:53 UTC (permalink / raw) To: Cédric Le Goater, Andrew Jeffery, Joel Stanley; +Cc: OpenBMC Maillist >>> 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@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@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@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. > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QEMU and CI 2019-04-10 19:53 ` Bills, Jason M @ 2019-04-11 0:25 ` Andrew Jeffery 0 siblings, 0 replies; 9+ messages in thread From: Andrew Jeffery @ 2019-04-11 0:25 UTC (permalink / raw) To: Bills, Jason M, Cédric Le Goater, Joel Stanley; +Cc: OpenBMC Maillist 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@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@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@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. > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-04-11 0:25 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-04-08 19:24 QEMU and CI Bills, Jason M 2019-04-09 0:46 ` Andrew Jeffery 2019-04-09 2:55 ` Joel Stanley 2019-04-09 6:12 ` Cédric Le Goater 2019-04-09 23:51 ` Bills, Jason M 2019-04-10 1:09 ` Andrew Jeffery 2019-04-10 6:16 ` Cédric Le Goater 2019-04-10 19:53 ` Bills, Jason M 2019-04-11 0:25 ` Andrew Jeffery
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.