mbox

[PULL,00/11] riscv-to-apply queue

Message ID 20210712225348.213819-1-alistair.francis@wdc.com (mailing list archive)
State New, archived
Headers show

Pull-request

git@github.com:alistair23/qemu.git tags/pull-riscv-to-apply-20210712

Message

Alistair Francis July 12, 2021, 10:53 p.m. UTC
The following changes since commit 57e28d34c0cb04abf7683ac6a12c87ede447c320:

  Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20210708' into staging (2021-07-12 19:15:11 +0100)

are available in the Git repository at:

  git@github.com:alistair23/qemu.git tags/pull-riscv-to-apply-20210712

for you to fetch changes up to d6b87906f09f72a837dc68c33bfc3d913ef74b7d:

  hw/riscv: opentitan: Add the flash alias (2021-07-13 08:47:52 +1000)

----------------------------------------------------------------
Fourth RISC-V PR for 6.1 release

 - Code cleanups
 - Documentation improvements
 - Hypervisor extension improvements with hideleg and hedeleg
 - sifive_u fixes
 - OpenTitan register layout updates

----------------------------------------------------------------
Alistair Francis (3):
      char: ibex_uart: Update the register layout
      hw/riscv: opentitan: Add the unimplement rv_core_ibex_peri
      hw/riscv: opentitan: Add the flash alias

Bin Meng (7):
      target/riscv: pmp: Fix some typos
      target/riscv: csr: Remove redundant check in fp csr read/write routines
      docs/system: riscv: Fix CLINT name in the sifive_u doc
      docs/system: riscv: Add documentation for virt machine
      docs/system: riscv: Update Microchip Icicle Kit for direct kernel boot
      hw/riscv: sifive_u: Correct the CLINT timebase frequency
      hw/riscv: sifive_u: Make sure firmware info is 8-byte aligned

Jose Martins (1):
      target/riscv: hardwire bits in hideleg and hedeleg

 docs/system/riscv/microchip-icicle-kit.rst |  54 +++++++++--
 docs/system/riscv/sifive_u.rst             |   2 +-
 docs/system/riscv/virt.rst                 | 138 +++++++++++++++++++++++++++++
 docs/system/target-riscv.rst               |   1 +
 include/hw/riscv/opentitan.h               |   3 +
 hw/char/ibex_uart.c                        |  19 ++--
 hw/riscv/opentitan.c                       |   9 ++
 hw/riscv/sifive_u.c                        |  12 ++-
 target/riscv/csr.c                         |  37 +++-----
 target/riscv/pmp.c                         |  10 +--
 10 files changed, 233 insertions(+), 52 deletions(-)
 create mode 100644 docs/system/riscv/virt.rst

Comments

Peter Maydell July 13, 2021, 6 p.m. UTC | #1
On Mon, 12 Jul 2021 at 23:53, Alistair Francis <alistair.francis@wdc.com> wrote:
>
> The following changes since commit 57e28d34c0cb04abf7683ac6a12c87ede447c320:
>
>   Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20210708' into staging (2021-07-12 19:15:11 +0100)
>
> are available in the Git repository at:
>
>   git@github.com:alistair23/qemu.git tags/pull-riscv-to-apply-20210712
>
> for you to fetch changes up to d6b87906f09f72a837dc68c33bfc3d913ef74b7d:
>
>   hw/riscv: opentitan: Add the flash alias (2021-07-13 08:47:52 +1000)
>
> ----------------------------------------------------------------
> Fourth RISC-V PR for 6.1 release
>
>  - Code cleanups
>  - Documentation improvements
>  - Hypervisor extension improvements with hideleg and hedeleg
>  - sifive_u fixes
>  - OpenTitan register layout updates

Hi; this fails to compile on some hosts:

../../target/riscv/csr.c:437:48: error: initializer element is not constant
 static const target_ulong vs_delegable_excps = delegable_excps &
                                                ^~~~~~~~~~~~~~~


That happens on s390x, x86-64, aarch32, NetBSD. I think this is
"gcc older than gcc 8 is stricter about what it allows as a
constant expression". If I understand the GCC bugzilla issue I
ran into via a bit of googling, the C spec is quite limiting in
what it considers to be a "constant expression", and in particular
"some other variable with the 'const' attribute" isn't one.
The spec does allow compilers the impdef leeway to allow a wider
range of things to be constant expressions, and gcc 8 is cleverer
here than gcc 7 was.

If delegable_excps was a #define rather than a 'const' variable
it would be OK here, I think.

thanks
-- PMM
Alistair Francis July 15, 2021, 6:56 a.m. UTC | #2
On Wed, Jul 14, 2021 at 4:01 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Mon, 12 Jul 2021 at 23:53, Alistair Francis <alistair.francis@wdc.com> wrote:
> >
> > The following changes since commit 57e28d34c0cb04abf7683ac6a12c87ede447c320:
> >
> >   Merge remote-tracking branch 'remotes/cohuck-gitlab/tags/s390x-20210708' into staging (2021-07-12 19:15:11 +0100)
> >
> > are available in the Git repository at:
> >
> >   git@github.com:alistair23/qemu.git tags/pull-riscv-to-apply-20210712
> >
> > for you to fetch changes up to d6b87906f09f72a837dc68c33bfc3d913ef74b7d:
> >
> >   hw/riscv: opentitan: Add the flash alias (2021-07-13 08:47:52 +1000)
> >
> > ----------------------------------------------------------------
> > Fourth RISC-V PR for 6.1 release
> >
> >  - Code cleanups
> >  - Documentation improvements
> >  - Hypervisor extension improvements with hideleg and hedeleg
> >  - sifive_u fixes
> >  - OpenTitan register layout updates
>
> Hi; this fails to compile on some hosts:
>
> ../../target/riscv/csr.c:437:48: error: initializer element is not constant
>  static const target_ulong vs_delegable_excps = delegable_excps &
>                                                 ^~~~~~~~~~~~~~~
>
>
> That happens on s390x, x86-64, aarch32, NetBSD. I think this is
> "gcc older than gcc 8 is stricter about what it allows as a
> constant expression". If I understand the GCC bugzilla issue I
> ran into via a bit of googling, the C spec is quite limiting in
> what it considers to be a "constant expression", and in particular
> "some other variable with the 'const' attribute" isn't one.
> The spec does allow compilers the impdef leeway to allow a wider
> range of things to be constant expressions, and gcc 8 is cleverer
> here than gcc 7 was.
>
> If delegable_excps was a #define rather than a 'const' variable
> it would be OK here, I think.

Sorry about that, sending a new version.

Alistair

>
> thanks
> -- PMM
>