vm_virtio_net: add zcu102 support

[chrisguikema]

(Edit: testing with merged PRs)

[axel-h]

The ZCU102 hardware tests are failing in my test hack at #64 that uses seL4/ci-actions#319.
But I'm not sure if this is still missing something there now?

[chrisguikema]

Which one is failing? This is what I get on a local run:

hwclock: can't open '/dev/misc/rtc': No such file or directory
Starting syslogd/klogd: done
Starting tcf-agent: Packet Contents:
0:      45 0 0 24 a4 8a 40 0 40 11 11 ee c0 a8 1 
15:     1 c0 a8 1 ff 5 fe 5 fe 0 10 d4 b 54 43 
30:     46 32 1 0 0 0 
IP Header - Version: IPv4 protocol: 17 | src address: 192.168.1.1 | dest address: 192.168.1.255
ICMP Header - Type: 5 | id: 4096 | seq: 3028

Packet Contents:
0:      45 0 1 14 a4 90 40 0 40 11 10 f8 c0 a8 1 
15:     1 c0 a8 1 ff 5 fe 5 fe 1 0 bd 1c 54 43 
30:     46 32 2 0 0 0 49 44 3d 54 43 50 3a 31 39 
45:     32 2e 31 36 38 2e 31 2e 31 3a 31 35 33 34 0 
60:     4e 61 6d 65 3d 54 43 46 20 41 67 65 6e 74 0 
75:     4f 53 4e 61 6d 65 3d 4c 69 6e 75 78 20 34 2e 
90:     31 34 2e 30 2d 78 69 6c 69 6e 78 2d 76 32 30 
105:    31 38 2e 33 2d 64 69 72 74 
IP Header - Version: IPv4 protocol: 17 | src address: 192.168.1.1 | dest address: 192.168.1.255
ICMP Header - Type: 5 | id: 1 | seq: 7357

OK

PetaLinux 2018.3 xilinx-zcu102-2018_3 /dev/ttyPS0

xilinx-zcu102-2018_3 login: Packet Contents:
0:      45 0 1 14 ad 42 40 0 40 11 8 46 c0 a8 1 
15:     1 c0 a8 1 ff 5 fe 5 fe 1 0 bd 1c 54 43 
30:     46 32 2 0 0 0 49 44 3d 54 43 50 3a 31 39 
45:     32 2e 31 36 38 2e 31 2e 31 3a 31 35 33 34 0 
60:     4e 61 6d 65 3d 54 43 46 20 41 67 65 6e 74 0 
75:     4f 53 4e 61 6d 65 3d 4c 69 6e 75 78 20 34 2e 
90:     31 34 2e 30 2d 78 69 6c 69 6e 78 2d 76 32 30 
105:    31 38 2e 33 2d 64 69 72 74 
IP Header - Version: IPv4 protocol: 17 | src address: 192.168.1.1 | dest address: 192.168.1.255
ICMP Header - Type: 5 | id: 1 | seq: 7357

[chrisguikema]

Okay, I see it now. I don't think the init script is configured properly in the overlay fs. I've loaded some init scripts before, so I should be able to make the change to get it working right

[chrisguikema]

Alright, I got the ping test working, but arping doesn't exist on the Petalinux file system:

/etc/rc5.d/S90arping_test: line 9: arping: command not found

[chrisguikema]

I did try to compile a static version of arping for an aarch64 host, but it didn't work. So for now, I just err out with VIRTIO_NET_PING isn't set on the zcu102.

[axel-h]

If we have the ping test working, that makes a good baseline to merge everything. We can easily leave the other test out for now.

[chrisguikema]

That works for me.

What is the "dependency chain" we want to work with here? I'm thinking we start with the vm_minimal 2018.3 Petalinux version commit, then I can update this, and the other vm_minimal to follow that same methodology.

[axel-h]

That works for me.
What is the "dependency chain" we want to work with here? I'm thinking we start with the vm_minimal 2018.3 Petalinux version commit, then I can update this, and the other vm_minimal to follow that same methodology.

We have minimal and ping working now (https://github.com/seL4/camkes-vm-examples/actions/runs/7699640620/job/20981854409?pr=64), so for me this looks like a good point to merge things - @lsf37 ?

[axel-h]

Looks ok to me.

[chrisguikema]

FYI, I tried to update this to also run with Petalinux 2021.1, and it does. However, there seems to be an issue with the device tree generation and the virtio-pci?

I get this line: [ 3.998219] xuartps ff000000.serial: could not find pctldev for node /firmware/zynqmp-firmware/pinctrl/uart0-default, deferring probe, which doesn't show up in the 2021.1 vm_minimal, so the prompt never shows up.

[chrisguikema]

I need to compile artifacts for 2022.1 for a different project. You can add arping to busybox, so we can keep this one on the backburner, and I'll make a PR for 2022.1 support. Does that work for everyone?

[chrisguikema]

I've gotten 2022.1 booting, but there are some permissions issues that i'll have to work through

ping: permission denied (are you root?)

Probably just a configuration value in the buildroot/petalinux configuration.

[lsf37]

We have minimal and ping working now (https://github.com/seL4/camkes-vm-examples/actions/runs/7699640620/job/20981854409?pr=64), so for me this looks like a good point to merge things - @lsf37 ?

Happy to start merging things for these two and add arping later.

[chrisguikema]

Got the ping and arping tests working with 2022.1 Petalinux:

Testing arping on virtual interface:
[  OK  ] Started Kernel Logging Service.
[  OK  ] Started System Logging Service.
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Started NFS status monitor for NFSv2/3 locking..
         Starting LSB: NFS support for both client and server...
         Starting User Login Management...
         Starting Permit User Sessions...
         Starting Target Communication Framework agent...
[  OK  ] Started LSB: NFS support for both client and server.
[  OK  ] Finished Permit User Sessions.
[  OK  ] Started Target Communication Framework agent.
[  OK  ] Started Getty on tty1.
         Starting inetd.busybox.service...
         Starting LSB: Kernel NFS server support...
[  OK  ] Started Serial Getty on ttyPS0.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started inetd.busybox.service.
[FAILED] Failed to start LSB: Kernel NFS server support.
See 'systemctl status nfsserver.service' for details.
[  OK  ] Started User Login Management.
arping test was successful

2022.1 switched from init.d -> systemd, which means I needed to add a zynqmp directory for the init scripts. Beyond that, it should be good to merge, provided my changes didn't break the existing run. I'll make a PR for the linux artifacts, and the camkes-vm change, and then update this PR.

[axel-h]

Seems my CI test job crashes on the hardware run, see #64. It should pick up you latest change, is some configuration missing there?

[chrisguikema]

Does it always try to load two images to the same address?

[chrisguikema]

Here is a good run:

  ZynqMP> tftp ${pxefile_addr_r} /zcu102_2/local-kernel
  tftp ${pxefile_addr_r} /zcu102_2/local-kernel
  Unknown command 'tftp' - try 'help'
  ZynqMP> bootelf ${pxefile_addr_r}
  bootelf ${pxefile_addr_r}
  ## Starting application at 0x02efe000 ...

On the failing runs, its actually running a tftp to grab the local-kernel, then the board is crashing when booting from 0x10000000.

@lsf37 did something change with the ZCU102 hardware?

[axel-h]

There has been seL4/ci-actions#310, but this was revered by seL4/ci-actions#324. However, there is this change to binary images that might impact this, see seL4/machine_queue#14

[lsf37]

There has been seL4/ci-actions#310, but this was revered by seL4/ci-actions#324. However, there is this change to binary images that might impact this, see seL4/machine_queue#14

It's possible that the machine queue update yesterday messed something up. It shouldn't have, but it's shell scripts..

Edit: rerunning https://github.com/seL4/camkes-vm-examples/actions/runs/7705607749 which has previously passed, to check if it's something with the infrastructure.

[Ivan-Velickovic]

There has been seL4/ci-actions#310, but this was revered by seL4/ci-actions#324. However, there is this change to binary images that might impact this, see seL4/machine_queue#14

It's possible that the machine queue update yesterday messed something up. It shouldn't have, but it's shell scripts..

Edit: rerunning https://github.com/seL4/camkes-vm-examples/actions/runs/7705607749 which has previously passed, to check if it's something with the infrastructure.

My fault as I was changing stuff around yesterday, fixed now.