Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vm_virtio_net: add zcu102 support #57

Merged
merged 1 commit into from
Jan 31, 2024

Conversation

chrisguikema
Copy link
Contributor

@chrisguikema chrisguikema commented Jan 25, 2024

(Edit: testing with merged PRs)

@axel-h
Copy link
Member

axel-h commented Jan 27, 2024

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?

@lsf37 lsf37 added the hw-test hardware builds + runs for this PR label Jan 28, 2024
@axel-h axel-h force-pushed the zcu102_virtio_net branch from 275be01 to 00ebce4 Compare January 29, 2024 13:05
@chrisguikema
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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 chrisguikema force-pushed the zcu102_virtio_net branch 2 times, most recently from bfa7446 to fc3773c Compare January 29, 2024 16:35
@chrisguikema
Copy link
Contributor Author

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
Copy link
Member

axel-h commented Jan 29, 2024

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
Copy link
Contributor Author

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
Copy link
Member

axel-h commented Jan 29, 2024

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 ?

Copy link
Member

@axel-h axel-h left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks ok to me.

@chrisguikema
Copy link
Contributor Author

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 chrisguikema force-pushed the zcu102_virtio_net branch 2 times, most recently from 6af071d to ec6c485 Compare January 29, 2024 18:17
@chrisguikema
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Member

lsf37 commented Jan 29, 2024

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
Copy link
Contributor Author

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.

@chrisguikema chrisguikema force-pushed the zcu102_virtio_net branch 2 times, most recently from 40777c1 to f6ded33 Compare January 30, 2024 15:36
@axel-h
Copy link
Member

axel-h commented Jan 30, 2024

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
Copy link
Contributor Author

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

@chrisguikema
Copy link
Contributor Author

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
Copy link
Member

axel-h commented Jan 30, 2024

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
Copy link
Member

lsf37 commented Jan 30, 2024

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
Copy link

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.

@lsf37 lsf37 merged commit 8c9108a into seL4:master Jan 31, 2024
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hw-test hardware builds + runs for this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants