On Sat, Jun 30, 2018 at 5:53 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > 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.
Ok, I'm sending an updated PR now. I can't reproduce the failure for some reason so hopefully I have fixed the problem by not modifying the virtio include. Alistair > > thanks > -- PMM