[solved] Sel4 on qemu emulated zcu102

1

I followed the instructions here:

https://docs.sel4.systems/Hardware/ZCU102.html

to build uboot and sel4. I tried booting the resulting elf files in the xilinx fork of qemu. I was going to try booting seL4 via tftp from uboot but booting uboot yeilds no error or output:

$ ./qemu/build/qemu-system-aarch64 -M arm-generic-fdt -serial none -serial mon:stdio -device loader,file=u-boot-xlnx/u-boot.elf,cpu-num=0 -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 -hw-dtb ./qemu-devicetrees/LATEST/SINGLE_ARCH/zcu102-arm.dtb
VNC server running on ::1:5900

Directly booting seL4 gives the following error:

$ ./qemu/build/qemu-system-aarch64 -M arm-generic-fdt -serial none -serial mon:stdio -device loader,file=./sel4/repo_sel4/cbuild/images/sel4test-driver-image-arm-zynqmp,cpu-num=0 -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 -hw-dtb ./qemu-devicetrees/LATEST/SINGLE_ARCH/zcu102-arm.dtb
VNC server running on ::1:5900
Not in hyp mode, cannot reset CNTVOFF_EL2

ELF-loader started on CPU: ARM Ltd. Cortex-A53 r0p4
  paddr=[a30000..f0e117]
No DTB passed in from boot loader.
Looking for DTB in CPIO archive...found at b7af30.
Loaded DTB from b7af30.
   paddr=[23f000..243fff]
ELF-loading image 'kernel' to 0
  paddr=[0..23efff]
  vaddr=[ffffff8000000000..ffffff800023efff]
  virt_entry=ffffff8000000000
ELF-loading image 'sel4test-driver' to 244000
  paddr=[244000..639fff]
  vaddr=[400000..7f5fff]
  virt_entry=40e568
Enabling MMU and paging
Jumping to kernel-image entry point...

ERROR: Kernel returned back to the ELF Loader
abort() called.

The VNC server display for both uboot and sel4 just shows:

The guest has not initialized the display (yet)

What am I doing wrong?

2

I was able to boot into the prebuilt uboot that comes with the zcu102 project in petalinux. From there I tried to use tftp to load sel4. I tried this using both an sel4 elf and a uboot image generated via mkimage. So the steps in uboot are:

setenv serverip 10.11.12.34

and then either

tftpboot 0x8000000 seL4-uImage
tftpboot 0x7000000 zcu102-arm.dtb
bootm 0x8000000 - 0x7000000

for the uboot image, or:

tftpboot 0x8000000 sel4test-driver-image-arm-zynqmp
bootm  0x8000000

for the elf. Unfortunately they both have the same resulting output:

## Starting application at 0x08000000 ...
"Synchronous Abort" handler, esr 0x02000000
elr: ffffffff983f5000 lr : 0000000010084d64 (reloc)
elr: 0000000008000000 lr : 000000007fc8fd64
x0 : 0000000000000000 x1 : 0000000000000000
x2 : 0000000000000000 x3 : 0000000000000000
x4 : 0000000008000000 x5 : 0000000000000001
x6 : 00000000000003c5 x7 : 00000000a0000000
x8 : 0000000000000010 x9 : 0000000000000008
x10: 0000000009200003 x11: 0000000000000001
x12: 0000000000000000 x13: 0000000000000200
x14: 0000000000000003 x15: 000000007fc8c830
x16: 000000007fc985fc x17: 000000007fd8fd66
x18: 000000007bc0ada0 x19: 0000000008000000
x20: 0000000008000000 x21: 0000000000000002
x22: 000000007bc285e0 x23: 0000000000000002
x24: 000000007fdc7ad4 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 000000007bc28640 x29: 000000007bbfcaf0

Code: 00000000 00000000 00000000 00000000 (464c457f) 
Resetting CPU ...

### ERROR ### Please RESET the board ###
3

Reading about the elfloader here, the following caught my attention:

  1. If the kernel window overlaps the elfloader’s code:
    • (AArch32 EFI only) the elfloader relocates itself. See relocate_below_kernel for a detailed explanation of the relocation logic.
    • (Other platforms) the elfloader aborts.

Could it be that the kernel is not properly packaged so it clashes with the elfloader somehow?

4

Just had to use bootelf instead of bootm.

1 Like