Hi Tuomas, On Mon, Sep 10, 2018 at 8:16 AM Tuomas Tynkkynen <tuomas.tynkky...@iki.fi> wrote: > > On 09/08/2018 04:28 AM, Bin Meng wrote: > > Hi Tuomas, > > > > On Sat, Sep 8, 2018 at 7:14 AM Tuomas Tynkkynen <tuomas.tynkky...@iki.fi> > > wrote: > [...] > >> > >> 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 > > Yeah, VIRTIO_GENERIC ended up looking quite weird. It's not even used > normally, e.g. virtio-net doesn't end up using it at all: > > => dm tree > Class index Probed Driver Name > ----------------------------------------- > virtio 31 [ + ] virtio_mmi |-- virtio_mmio@a003e00 > eth 1 [ + ] virtio_net | `-- virtio_net > > It does get used for virtio-blk though: > > virtio 30 [ + ] virtio_mmi |-- virtio_mmio@a003c00 > virtio_gen 0 [ + ] virtio_blk | `-- virtio_blk > blk 0 [ + ] virtblk | `-- virtio_blk.blk > > But that is only because I couldn't make the block device (i.e. > the one with UCLASS_BLK) without introducing some device in the > middle. All of the functions like blk_create_device() seem to be > designed for the use cases of say, an AHCI controller having > multiple SATA ports or an SCSI device having multiple LUNs. > > I guess the right thing to do would be to split blk_create_device() > so that it would be possible to have a tree like this: > > virtio 30 [ + ] virtio_mmi |-- virtio_mmio@a003c00 > blk 0 [ + ] virtio_blk | `-- virtio_blk > > Then the need for UCLASS_VIRTIO_GENERIC would go away.
I used another way to do this, by not calling blk_create_device API and some other changes. I now get the virtio-blk driver working with my uclass implementation. Stay tuned :) > > > 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot