On 29 June 2018 at 18:22, Alistair Francis <alistair.fran...@wdc.com> wrote: > The following changes since commit 75507f1aba6feb73ae43329922d51571550b9128: > > Merge remote-tracking branch 'remotes/berrange/tags/min-glib-pull-request' > into staging (2018-06-29 15:04:20 +0100) > > are available in the Git repository at: > > g...@github.com:alistair23/qemu.git tags/pull-riscv-pull-20180629 > > for you to fetch changes up to e4847c96685e210649e6ec90fecd732a744dad75: > > hw/riscv/sifive_u: Connect the Cadence GEM Ethernet device (2018-06-29 > 09:51:05 -0700) > > ---------------------------------------------------------------- > RISC-V: SoCify SiFive boards and connect GEM > > This series has three tasks: > 1. To convert the SiFive U and E machines into SoCs and boards > 2. To connect the Cadence GEM device to the SiFive U board > 3. Fix some device tree problems with the SiFive U board > > After this series the SiFive E and U boards have their SoCs split into > seperate QEMU objects, which can be used on future boards if desired. > > The RISC-V Virt and Spike boards have not been converted. They haven't > been converted as they aren't physical boards, so it doesn't make a > whole lot of sense to split them into an SoC and board. The only > disadvantage with this is that they now differ to the SiFive boards. > > This series also connect the Cadence GEM device to the SiFive U board. > There are some interrupt line changes requried before this is possible.
Hi; this fails to build I'm afraid: LINK riscv32-softmmu/qemu-system-riscv32 ../fsdev/qemu-fsdev.o:(.data.rel.ro+0x8): undefined reference to `local_ops' ../fsdev/qemu-fsdev.o:(.data.rel.ro+0x18): undefined reference to `handle_ops' ../fsdev/qemu-fsdev.o:(.data.rel.ro+0x28): undefined reference to `synth_ops' ../fsdev/qemu-fsdev.o:(.data.rel.ro+0x38): undefined reference to `proxy_ops' I'm not sure exactly what's going on here but I suspect commit e4847c96685, which made the riscv default-config files stop including virtio.mak. I think the bit of code that defines these _ops structs and the bit of code that's using them aren't guarded by exactly the same set of CONFIG_* defines. That inconsistency is arguably a bug, but nobody notices it because you just use virtio.mak to get all the virtio defines. The definitions are guarded by "CONFIG_VIRTIO_9P || CONFIG_XEN" but the use by "CONFIG_VIRTFS && (CONFIG_VIRTIO || CONFIG_XEN)", so if you define CONFIG_VIRTIO without CONFIG_VIRTIO_9P you're going to run into this. The guard on the definitions was only added in commit b5dfdb082fc350f3, so you've had an unfortunate race with that pullreq I think. All that said, it looks to me like e4847c98 should not have been changing how the virtio configs are set -- the commit message doesn't say anything about it -- so the simplest thing is just to fix that up. thanks -- PMM
