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

-- 
2.27.0.212.ge8ba1cc988-goog

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 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 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 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".