| Message ID | 20200626235519.591734-1-hskinnemoen@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add Nuvoton NPCM730/NPCM750 SoCs and two BMC machines | expand |
Patchew URL: https://patchew.org/QEMU/20200626235519.591734-1-hskinnemoen@google.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#! /bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=a230e4bd116749a0878a758b497ee67e', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-vg6aufvv/src/docker-src.2020-06-26-20.09.42.21707:/var/tmp/qemu:z,ro', 'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=a230e4bd116749a0878a758b497ee67e
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-vg6aufvv/src'
make: *** [docker-run-test-mingw@fedora] Error 2
real 5m38.662s
user 0m9.129s
The full log is available at
http://patchew.org/logs/20200626235519.591734-1-hskinnemoen@google.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
On Sat, 27 Jun 2020 at 00:55, Havard Skinnemoen <hskinnemoen@google.com> wrote: > > Time for another refresh of this patchset. Sorry it took so long -- I've been > trying to figure out why the Winbond flash model isn't working with > npcm750-evb, and I'm fairly convinced the number of dummy cycles in DIO mode > should be 4, not 1. Unfortunately, I don't see any other machines using Winbond > flash in DIO mode, so it's hard to prove that it's correct. I'm planning to > post a libqos-based test suite separately. > > I'm also planning to add the vbootrom to qemu as a submodule, similar to the > other roms, but not in this pathset (let me know if you do want me to include > this in the series). Hi; it looks like codewise this patchset is ready to go in and it's all been reviewed. I see however that all the new files are GPL-v2-only. We usually prefer GPL-v2-or-later for new code: is it possible to use that license instead ? thanks -- PMM
On 7/3/20 2:27 PM, Peter Maydell wrote: > On Sat, 27 Jun 2020 at 00:55, Havard Skinnemoen <hskinnemoen@google.com> wrote: >> >> Time for another refresh of this patchset. Sorry it took so long -- I've been >> trying to figure out why the Winbond flash model isn't working with >> npcm750-evb, and I'm fairly convinced the number of dummy cycles in DIO mode >> should be 4, not 1. Unfortunately, I don't see any other machines using Winbond >> flash in DIO mode, so it's hard to prove that it's correct. I'm planning to >> post a libqos-based test suite separately. >> >> I'm also planning to add the vbootrom to qemu as a submodule, similar to the >> other roms, but not in this pathset (let me know if you do want me to include >> this in the series). > > Hi; it looks like codewise this patchset is ready to go in > and it's all been reviewed. I see however that all the > new files are GPL-v2-only. We usually prefer GPL-v2-or-later > for new code: is it possible to use that license instead ? This series has been posted before Markus qdev & error cleanups. Maybe some newer error patterns should be used now instead? Phil.
On Fri, Jul 3, 2020 at 5:27 AM Peter Maydell <peter.maydell@linaro.org> wrote: > On Sat, 27 Jun 2020 at 00:55, Havard Skinnemoen <hskinnemoen@google.com> > wrote: > > > > Time for another refresh of this patchset. Sorry it took so long -- I've > been > > trying to figure out why the Winbond flash model isn't working with > > npcm750-evb, and I'm fairly convinced the number of dummy cycles in DIO > mode > > should be 4, not 1. Unfortunately, I don't see any other machines using > Winbond > > flash in DIO mode, so it's hard to prove that it's correct. I'm planning > to > > post a libqos-based test suite separately. > > > > I'm also planning to add the vbootrom to qemu as a submodule, similar to > the > > other roms, but not in this pathset (let me know if you do want me to > include > > this in the series). > > Hi; it looks like codewise this patchset is ready to go in > and it's all been reviewed. I see however that all the > new files are GPL-v2-only. We usually prefer GPL-v2-or-later > for new code: is it possible to use that license instead ? > I sent an e-mail to our licensing team to see if there are any issues with doing that. I don't expect a response until next week though, since this is a long weekend. I'll send out a v4 with updated headers if they approve. Thanks, Havard
On Fri, Jul 3, 2020 at 6:35 AM Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > On 7/3/20 2:27 PM, Peter Maydell wrote: > > On Sat, 27 Jun 2020 at 00:55, Havard Skinnemoen <hskinnemoen@google.com> wrote: > >> > >> Time for another refresh of this patchset. Sorry it took so long -- I've been > >> trying to figure out why the Winbond flash model isn't working with > >> npcm750-evb, and I'm fairly convinced the number of dummy cycles in DIO mode > >> should be 4, not 1. Unfortunately, I don't see any other machines using Winbond > >> flash in DIO mode, so it's hard to prove that it's correct. I'm planning to > >> post a libqos-based test suite separately. > >> > >> I'm also planning to add the vbootrom to qemu as a submodule, similar to the > >> other roms, but not in this pathset (let me know if you do want me to include > >> this in the series). > > > > Hi; it looks like codewise this patchset is ready to go in > > and it's all been reviewed. I see however that all the > > new files are GPL-v2-only. We usually prefer GPL-v2-or-later > > for new code: is it possible to use that license instead ? > > This series has been posted before Markus qdev & error cleanups. > Maybe some newer error patterns should be used now instead? I'm not sure if I understand exactly what you're referring to, but I'll do 'git log origin/master --author=armbru@redhat.com' to see if I can apply any similar fixes or cleanups to this series. Havard
On 7/3/20 11:15 PM, Havard Skinnemoen wrote: > On Fri, Jul 3, 2020 at 6:35 AM Philippe Mathieu-Daudé <philmd@redhat.com> wrote: >> >> On 7/3/20 2:27 PM, Peter Maydell wrote: >>> On Sat, 27 Jun 2020 at 00:55, Havard Skinnemoen <hskinnemoen@google.com> wrote: >>>> >>>> Time for another refresh of this patchset. Sorry it took so long -- I've been >>>> trying to figure out why the Winbond flash model isn't working with >>>> npcm750-evb, and I'm fairly convinced the number of dummy cycles in DIO mode >>>> should be 4, not 1. Unfortunately, I don't see any other machines using Winbond >>>> flash in DIO mode, so it's hard to prove that it's correct. I'm planning to >>>> post a libqos-based test suite separately. >>>> >>>> I'm also planning to add the vbootrom to qemu as a submodule, similar to the >>>> other roms, but not in this pathset (let me know if you do want me to include >>>> this in the series). >>> >>> Hi; it looks like codewise this patchset is ready to go in >>> and it's all been reviewed. I see however that all the >>> new files are GPL-v2-only. We usually prefer GPL-v2-or-later >>> for new code: is it possible to use that license instead ? >> >> This series has been posted before Markus qdev & error cleanups. >> Maybe some newer error patterns should be used now instead? > > I'm not sure if I understand exactly what you're referring to, but > I'll do 'git log origin/master --author=armbru@redhat.com' to see if I > can apply any similar fixes or cleanups to this series. Sorry this was a quick comment for Peter, that he might get conflicts when applying. See Markus "Fix realize error API violations" commits: 7cd1c981eb, b40181942e & 3e9a88c372, and commit 123327d14 "Clean up roundabout error propagation".
Time for another refresh of this patchset. Sorry it took so long -- I've been trying to figure out why the Winbond flash model isn't working with npcm750-evb, and I'm fairly convinced the number of dummy cycles in DIO mode should be 4, not 1. Unfortunately, I don't see any other machines using Winbond flash in DIO mode, so it's hard to prove that it's correct. I'm planning to post a libqos-based test suite separately. I'm also planning to add the vbootrom to qemu as a submodule, similar to the other roms, but not in this pathset (let me know if you do want me to include this in the series). I also pushed this and the previous two patchsets to my qemu fork on github. The branches are named npcm7xx-v[1-3]. https://github.com/hskinnemoen/qemu This patch series models enough of the Nuvoton NPCM730 and NPCM750 SoCs to boot an OpenBMC image built for quanta-gsj. This includes device models for: - Global Configuration Registers - Clock Control - Timers - Fuses - Memory Controller - Flash Controller These modules, along with the existing Cortex A9 CPU cores and built-in peripherals, are integrated into a NPCM730 or NPCM750 SoC, which in turn form the foundation for the quanta-gsj and npcm750-evb machines, respectively. The two SoCs are very similar; the only difference is that NPCM730 is missing some peripherals that NPCM750 has, and which are not considered essential for datacenter use (e.g. graphics controllers). For more information, see https://www.nuvoton.com/products/cloud-computing/ibmc/ Both quanta-gsj and npcm750-evb correspond to real boards supported by OpenBMC. At the end of the series, qemu can boot an OpenBMC image built for one of these boards with some minor modifications. The patches in this series were developed by Google and reviewed by Nuvoton. We will be maintaining the machine and peripheral support together. The data sheet for these SoCs is not generally available. Please let me know if more comments are needed to understand the device behavior. Changes since v2: - Simplified the MAINTAINERS entry. - Added link to OpenPOWER jenkins for gsj BMC images. - Reverted the smpboot change, back to byte swapping. - Adapted to upstream API changes: - sysbus_init_child_obj -> object_initialize_child - object_property_set_bool -> qdev_realize / sysbus_realize - ssi_create_slave_no_init -> qdev_new - qdev_init_nofail -> qdev_realize_and_unref - ssi_auto_connect_slaves removed - Moved Boot ROM loading from soc to machine init. - Plumbed power-on-straps property from GCR to the machine init code so it can be properly initialized. Turns out npcm750 memory init doesn't work without this. npcm730 is fine either way, though I'm not sure why. - Reworked the flash init code so it looks more like aspeed (i.e. the flash device gets added even if there's no drive). Changes since v1 (requested by reviewers): - Clarify the source of CLK reset values. - Made smpboot a constant byte array, eliinated byte swapping. - NPCM7xxState now stores an array of ARMCPUs, not pointers to ARMCPUs. - Clarify why EL3 is disabled. - Introduce NPCM7XX_NUM_IRQ constant. - Set the number of CPUs according to SoC variant, and disallow command line overrides (i.e. you can no longer override the number of CPUs with the -smp parameter). This is trying to follow the spirit of https://patchwork.kernel.org/patch/11595407/. - Switch register operations to DEVICE_LITTLE_ENDIAN throughout. - Machine documentation added (new patch). Changes since v1 to support flash booting: - GCR reset value changes to get past memory initialization when booting from flash (patches 2 and 5): - INTCR2 now indicates that the DDR controller is initialized. - INTCR3 is initialized according to DDR memory size. A realize() method was implemented to achieve this. - Refactor the machine initialization a bit to make it easier to drop in machine-specific flash initialization (patch 6). - Extend the series with additional patches to enable booting from flash: - Boot ROM (through the -bios option). - OTP (fuse) controller. - Memory Controller stub (just enough to skip memory training). - Flash controller. - Board-specific flash initialization. Thanks for reviewing, Havard Havard Skinnemoen (12): npcm7xx: Add config symbol hw/misc: Add NPCM7xx System Global Control Registers device model hw/misc: Add NPCM7xx Clock Controller device model hw/timer: Add NPCM7xx Timer device model hw/arm: Add NPCM730 and NPCM750 SoC models hw/arm: Add two NPCM7xx-based machines hw/arm: Load -bios image as a boot ROM for npcm7xx hw/nvram: NPCM7xx OTP device model hw/mem: Stubbed out NPCM7xx Memory Controller model hw/ssi: NPCM7xx Flash Interface Unit device model hw/arm: Wire up BMC boot flash for npcm750-evb and quanta-gsj docs/system: Add Nuvoton machine documentation MAINTAINERS | 8 + default-configs/arm-softmmu.mak | 1 + docs/system/arm/nuvoton.rst | 92 ++++++ docs/system/target-arm.rst | 1 + hw/arm/Kconfig | 9 + hw/arm/Makefile.objs | 1 + hw/arm/npcm7xx.c | 429 ++++++++++++++++++++++++++ hw/arm/npcm7xx_boards.c | 188 ++++++++++++ hw/mem/Makefile.objs | 1 + hw/mem/npcm7xx_mc.c | 83 ++++++ hw/misc/Makefile.objs | 2 + hw/misc/npcm7xx_clk.c | 216 ++++++++++++++ hw/misc/npcm7xx_gcr.c | 211 +++++++++++++ hw/misc/trace-events | 8 + hw/nvram/Makefile.objs | 1 + hw/nvram/npcm7xx_otp.c | 391 ++++++++++++++++++++++++ hw/ssi/Makefile.objs | 1 + hw/ssi/npcm7xx_fiu.c | 496 +++++++++++++++++++++++++++++++ hw/ssi/trace-events | 9 + hw/timer/Makefile.objs | 1 + hw/timer/npcm7xx_timer.c | 437 +++++++++++++++++++++++++++ hw/timer/trace-events | 5 + include/hw/arm/npcm7xx.h | 106 +++++++ include/hw/mem/npcm7xx_mc.h | 35 +++ include/hw/misc/npcm7xx_clk.h | 65 ++++ include/hw/misc/npcm7xx_gcr.h | 76 +++++ include/hw/nvram/npcm7xx_otp.h | 93 ++++++ include/hw/ssi/npcm7xx_fiu.h | 99 ++++++ include/hw/timer/npcm7xx_timer.h | 95 ++++++ 29 files changed, 3160 insertions(+) create mode 100644 docs/system/arm/nuvoton.rst create mode 100644 hw/arm/npcm7xx.c create mode 100644 hw/arm/npcm7xx_boards.c create mode 100644 hw/mem/npcm7xx_mc.c create mode 100644 hw/misc/npcm7xx_clk.c create mode 100644 hw/misc/npcm7xx_gcr.c create mode 100644 hw/nvram/npcm7xx_otp.c create mode 100644 hw/ssi/npcm7xx_fiu.c create mode 100644 hw/timer/npcm7xx_timer.c create mode 100644 include/hw/arm/npcm7xx.h create mode 100644 include/hw/mem/npcm7xx_mc.h create mode 100644 include/hw/misc/npcm7xx_clk.h create mode 100644 include/hw/misc/npcm7xx_gcr.h create mode 100644 include/hw/nvram/npcm7xx_otp.h create mode 100644 include/hw/ssi/npcm7xx_fiu.h create mode 100644 include/hw/timer/npcm7xx_timer.h