03:19 <swetland> so I notice that you need to issue a dcache flush to vexriscv to avoid getting stale data from the liteeth packet sram sometimes

03:20 <swetland> isn't this sram in the IO memory area? shouldn't it just *never* be cached? vexriscv issue? litex issue? something else?

05:04 <swetland> shenki: so, I think I have your liteeth peripheral bolted into my local qemu build but can't quite get it going...

05:04 <swetland> $ /work/qemu/build/qemu-system-riscv32 -machine micro -bios out/boot.elf -device liteeth,id=network0 -netdev tap,id=network0,ifname=qemu0,script=no,downscript=no

05:04 <swetland> qemu-system-riscv32: -device liteeth,id=network0: Parameter 'driver' expects a pluggable device type

05:05 <swetland> if I drop the -device portion I get:

05:05 <swetland> qemu-system-riscv32: warning: netdev network0 has no peer

05:05 <swetland> qemu-system-riscv32: warning: nic liteeth.0 has no peer

06:51 <swetland> okay -nic tap,ifname=qemu0,script=no,downscript=no,mac=72:72:aa:bb:cc:dd gets me closer. multicast makes it through. pings do not (maybe a qemu limitation? but I thought tap mode was better for that?)

06:56 <swetland> ah, correction, all inbound traffic looks good. outbound (qemu vm -> tun/tap) is not happy

06:58 <cr1901> _florent_: Understood, thanks. Deleted those repos then :P. AFAICT, opentitan uses the ibex core

06:58 <swetland> ah, the qemu model does not accept packets if reader events are disabled

07:00 <swetland> $ ping6 fe80::7072:aaff:febb:ccdd%qemu0

07:00 <swetland> PING fe80::7072:aaff:febb:ccdd%qemu0(fe80::7072:aaff:febb:ccdd%qemu0) 56 data bytes

07:00 <swetland> 64 bytes from fe80::7072:aaff:febb:ccdd%qemu0: icmp_seq=1 ttl=255 time=0.973 ms

07:00 <swetland> 64 bytes from fe80::7072:aaff:febb:ccdd%qemu0: icmp_seq=3 ttl=255 time=0.904 ms

07:00 <swetland> 64 bytes from fe80::7072:aaff:febb:ccdd%qemu0: icmp_seq=2 ttl=255 time=0.972 ms

16:44 <jevinskie[m]> Congrats! Nice work!

21:01 <swetland> well, shenki did the hard work. I just had to figure out which of the five different sets of options for configuring network stuff in qemu to use ^^

21:20 <jevinskie[m]> I tweeted back in January “Qemu args are a CTF from hell by themselves” ;-)

21:21 <swetland> ahaha

21:22 <swetland> qemu reminds me of working on the linux kernel. there are N different APIs for everything and it's an adventure figuring out which ones are the correct/modern/bestsupported for whatever you're trying to do. and THEN there are half a dozen ways to configure anything

22:35 <jevinskie[m]> Hmm I wonder how difficult verilator cosimulation of a UTMI usb core would be. You’d have usb-ip speaking Linux USB request blocks and have to pack/unpack them into UTMI protocol. Would be super spiffy to have virtual usb devices with simulation!

23:23 <swetland> I bet setup/bulk/interrupt LS/FS wouldn't be too bad. HS likely challenging, isoch maybe not practical