[U-Boot] [PATCH 12/12] riscv: Add QEMU virt board support

[Bin Meng]

Hi Tuomas,

On Sat, Sep 8, 2018 at 7:14 AM Tuomas Tynkkynen <tuomas.tynkkynen at iki.fi> wrote:
>
> Hi Bin,
>
> On Fri, 7 Sep 2018 09:49:24 +0800
> Bin Meng <bmeng.cn at gmail.com> wrote:
>
> > Hi Tuomas,
> >
> > On Fri, Sep 7, 2018 at 5:03 AM Tuomas Tynkkynen
> > <tuomas.tynkkynen at iki.fi> wrote:
> > >
> > > Hi Bin,
> > >
> > > On 09/04/2018 12:31 PM, Bin Meng wrote:
> > > > Hi Lukas,
> > > >
> > > > On Tue, Sep 4, 2018 at 5:39 AM Auer, Lukas
> > > > <lukas.auer at aisec.fraunhofer.de> wrote:
> > > >>
> > > >> On Thu, 2018-08-30 at 00:54 -0700, Bin Meng wrote:
> > > >>> This adds QEMU RISC-V 'virt' board target support, with the
> > > >>> hope of helping people easily test U-Boot on RISC-V.
> > > >>>
> > > >>> The QEMU virt machine models a generic RISC-V virtual machine
> > > >>> with support for the VirtIO standard networking and block
> > > >>> storage devices. It has CLINT, PLIC, 16550A UART devices in
> > > >>> addition to VirtIO and it also uses device-tree to pass
> > > >>> configuration information to guest software. It implements
> > > >>> RISC-V privileged architecture spec v1.10.
> > > >>>
> > > >>> Both 32-bit and 64-bit builds are supported. Support is pretty
> > > >>> much preliminary, only booting to U-Boot shell with the UART
> > > >>> driver on a single core. Booting Linux is not supported yet.
> > > >>>
> > > >>
> > > >> For your information and to avoid duplicate work, I am working
> > > >> on a patch set that improves RISC-V support in u-boot. I am
> > > >> currently able to boot Linux on a multi-core setup in QEMU, but
> > > >> they are not quite ready to submit yet.
> > > >>
> > > >
> > > > This is great! My next step is to work on virtio driver support in
> > > > U-Boot as qemu-riscv virt machine has these devices but we don't
> > > > have corresponding drivers in U-Boot.
> > > At some point I was working on porting the virtio stack from Linux
> > > to U-Boot and IIRC got virtio-blk and virtio-net working on ARM.
> > > But other things consumed my time and I never quite finished that
> > > work. Let me know if you want to take a look.
> >
> > This is great. I just finished reading the virtio 1.0 spec and was
> > about to start the work. My interest was to add virtio-blk and
> > virtio-net driver to U-Boot too since they are most common devices
> > (others are not used too much I believe). If you already have the
> > drivers working, I can help to bring them upstream.
>
> You can find my branch here:
>
> https://github.com/dezgeg/u-boot/tree/virtio
>
> It should work under qemu_arm64_defconfig as follows:
>
> qemu-system-aarch64 -machine virt -cpu cortex-a57 -m 512 \
>   -bios u-boot.bin -s -nographic \
>   -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
>   -drive if=none,file=disk.img,id=disk0 \
>   -device virtio-blk-device,drive=disk0
>
> I tried with Fedora-Server-netinst-aarch64-28-1.1.iso I had lying
> around and letting it auto-boot worked fine.
>
> Also interrupting the boot and doing 'virtio scan; dhcp' gets a
> successful DHCP lease from QEMU's internal server.
>

Thank you for sharing your WIP. I just did a quick look and it seems
that you implemented the virtio uclass in a similar way like pci
uclass. My implementation is slightly different. I don't introduce
VIRTIO_GENERIC device and a complex driver matching logci like PCI. I
just did simple driver matching based on virtio device id. I wrote
some skeleton drivers to verify this can work with both virtio-mmio
and virtio-pci devices.

> I took a brief look and these things still need work:
>
> - Some of the virtio headers imported verbatim cause compiler
>   warnings because we don't disable strict aliasing.
>
> - Architectures need to import various definitions from Linux.
>   At least PAGE_SIZE & PAGE_SHIFT and wmb() & rmb().
>   (currently there are just gross hacks around this)
>
> - Feature negotiation (needed for virtio-net to be able to
>   set/get a MAC address) is not implemented yet.
>
> - The virtio-pci transport is not implemented, only virtio-mmio.
>
> - Error handling is missing in many places.
>
> - Resource cleanup in some places, like virtio-net which needs to
>   remove live buffers from the RX virtqueue on shutdown and I haven't
>   looked into how to do that.
>
> - Lots of small things like removing debug/commented out code, wrong
>   kerneldoc comments, dead/uneeded code etc. to be cleaned up.
>
> Have fun and let me know if you have questions.
>

Thanks for all these details! I will try integrating some of your WIP
with mine. I think I can directly use the virtio-blk and virtio-net
drivers from your tree as a start.

Regards,
Bin