1Xilinx Versal Virt (``xlnx-versal-virt``) 2========================================= 3 4Xilinx Versal is a family of heterogeneous multi-core SoCs 5(System on Chip) that combine traditional hardened CPUs and I/O 6peripherals in a Processing System (PS) with runtime programmable 7FPGA logic (PL) and an Artificial Intelligence Engine (AIE). 8 9More details here: 10https://www.xilinx.com/products/silicon-devices/acap/versal.html 11 12The family of Versal SoCs share a single architecture but come in 13different parts with different speed grades, amounts of PL and 14other differences. 15 16The Xilinx Versal Virt board in QEMU is a model of a virtual board 17(does not exist in reality) with a virtual Versal SoC without I/O 18limitations. Currently, we support the following cores and devices: 19 20Implemented CPU cores: 21 22- 2 ACPUs (ARM Cortex-A72) 23 24Implemented devices: 25 26- Interrupt controller (ARM GICv3) 27- 2 UARTs (ARM PL011) 28- An RTC (Versal built-in) 29- 2 GEMs (Cadence MACB Ethernet MACs) 30- 8 ADMA (Xilinx zDMA) channels 31- 2 SD Controllers 32- OCM (256KB of On Chip Memory) 33- XRAM (4MB of on chip Accelerator RAM) 34- DDR memory 35- BBRAM (36 bytes of Battery-backed RAM) 36- eFUSE (3072 bytes of one-time field-programmable bit array) 37- 2 CANFDs 38 39QEMU does not yet model any other devices, including the PL and the AI Engine. 40 41Other differences between the hardware and the QEMU model: 42 43- QEMU allows the amount of DDR memory provided to be specified with the 44 ``-m`` argument. If a DTB is provided on the command line then QEMU will 45 edit it to include suitable entries describing the Versal DDR memory ranges. 46 47- QEMU provides 8 virtio-mmio virtio transports; these start at 48 address ``0xa0000000`` and have IRQs from 111 and upwards. 49 50Running 51""""""" 52If the user provides an Operating System to be loaded, we expect users 53to use the ``-kernel`` command line option. 54 55Users can load firmware or boot-loaders with the ``-device loader`` options. 56 57When loading an OS, QEMU generates a DTB and selects an appropriate address 58where it gets loaded. This DTB will be passed to the kernel in register x0. 59 60If there's no ``-kernel`` option, we generate a DTB and place it at 0x1000 61for boot-loaders or firmware to pick it up. 62 63If users want to provide their own DTB, they can use the ``-dtb`` option. 64These DTBs will have their memory nodes modified to match QEMU's 65selected ram_size option before they get passed to the kernel or FW. 66 67When loading an OS, we turn on QEMU's PSCI implementation with SMC 68as the PSCI conduit. When there's no ``-kernel`` option, we assume the user 69provides EL3 firmware to handle PSCI. 70 71A few examples: 72 73Direct Linux boot of a generic ARM64 upstream Linux kernel: 74 75.. code-block:: bash 76 77 $ qemu-system-aarch64 -M xlnx-versal-virt -m 2G \ 78 -serial mon:stdio -display none \ 79 -kernel arch/arm64/boot/Image \ 80 -nic user -nic user \ 81 -device virtio-rng-device,bus=virtio-mmio-bus.0 \ 82 -drive if=none,index=0,file=hd0.qcow2,id=hd0,snapshot \ 83 -drive file=qemu_sd.qcow2,if=sd,index=0,snapshot \ 84 -device virtio-blk-device,drive=hd0 -append root=/dev/vda 85 86Direct Linux boot of PetaLinux 2019.2: 87 88.. code-block:: bash 89 90 $ qemu-system-aarch64 -M xlnx-versal-virt -m 2G \ 91 -serial mon:stdio -display none \ 92 -kernel petalinux-v2019.2/Image \ 93 -append "rdinit=/sbin/init console=ttyAMA0,115200n8 earlycon=pl011,mmio,0xFF000000,115200n8" \ 94 -net nic,model=cadence_gem,netdev=net0 -netdev user,id=net0 \ 95 -device virtio-rng-device,bus=virtio-mmio-bus.0,rng=rng0 \ 96 -object rng-random,filename=/dev/urandom,id=rng0 97 98Boot PetaLinux 2019.2 via ARM Trusted Firmware (2018.3 because the 2019.2 99version of ATF tries to configure the CCI which we don't model) and U-boot: 100 101.. code-block:: bash 102 103 $ qemu-system-aarch64 -M xlnx-versal-virt -m 2G \ 104 -serial stdio -display none \ 105 -device loader,file=petalinux-v2018.3/bl31.elf,cpu-num=0 \ 106 -device loader,file=petalinux-v2019.2/u-boot.elf \ 107 -device loader,addr=0x20000000,file=petalinux-v2019.2/Image \ 108 -nic user -nic user \ 109 -device virtio-rng-device,bus=virtio-mmio-bus.0,rng=rng0 \ 110 -object rng-random,filename=/dev/urandom,id=rng0 111 112Run the following at the U-Boot prompt: 113 114.. code-block:: bash 115 116 Versal> 117 fdt addr $fdtcontroladdr 118 fdt move $fdtcontroladdr 0x40000000 119 fdt set /timer clock-frequency <0x3dfd240> 120 setenv bootargs "rdinit=/sbin/init maxcpus=1 console=ttyAMA0,115200n8 earlycon=pl011,mmio,0xFF000000,115200n8" 121 booti 20000000 - 40000000 122 fdt addr $fdtcontroladdr 123 124Boot Linux as DOM0 on Xen via U-Boot: 125 126.. code-block:: bash 127 128 $ qemu-system-aarch64 -M xlnx-versal-virt -m 4G \ 129 -serial stdio -display none \ 130 -device loader,file=petalinux-v2019.2/u-boot.elf,cpu-num=0 \ 131 -device loader,addr=0x30000000,file=linux/2018-04-24/xen \ 132 -device loader,addr=0x40000000,file=petalinux-v2019.2/Image \ 133 -nic user -nic user \ 134 -device virtio-rng-device,bus=virtio-mmio-bus.0,rng=rng0 \ 135 -object rng-random,filename=/dev/urandom,id=rng0 136 137Run the following at the U-Boot prompt: 138 139.. code-block:: bash 140 141 Versal> 142 fdt addr $fdtcontroladdr 143 fdt move $fdtcontroladdr 0x20000000 144 fdt set /timer clock-frequency <0x3dfd240> 145 fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=/uart@ff000000 dom0_mem=640M bootscrub=0 maxcpus=1 timer_slop=0" 146 fdt set /chosen xen,dom0-bootargs "rdinit=/sbin/init clk_ignore_unused console=hvc0 maxcpus=1" 147 fdt mknode /chosen dom0 148 fdt set /chosen/dom0 compatible "xen,multiboot-module" 149 fdt set /chosen/dom0 reg <0x00000000 0x40000000 0x0 0x03100000> 150 booti 30000000 - 20000000 151 152Boot Linux as Dom0 on Xen via ARM Trusted Firmware and U-Boot: 153 154.. code-block:: bash 155 156 $ qemu-system-aarch64 -M xlnx-versal-virt -m 4G \ 157 -serial stdio -display none \ 158 -device loader,file=petalinux-v2018.3/bl31.elf,cpu-num=0 \ 159 -device loader,file=petalinux-v2019.2/u-boot.elf \ 160 -device loader,addr=0x30000000,file=linux/2018-04-24/xen \ 161 -device loader,addr=0x40000000,file=petalinux-v2019.2/Image \ 162 -nic user -nic user \ 163 -device virtio-rng-device,bus=virtio-mmio-bus.0,rng=rng0 \ 164 -object rng-random,filename=/dev/urandom,id=rng0 165 166Run the following at the U-Boot prompt: 167 168.. code-block:: bash 169 170 Versal> 171 fdt addr $fdtcontroladdr 172 fdt move $fdtcontroladdr 0x20000000 173 fdt set /timer clock-frequency <0x3dfd240> 174 fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=/uart@ff000000 dom0_mem=640M bootscrub=0 maxcpus=1 timer_slop=0" 175 fdt set /chosen xen,dom0-bootargs "rdinit=/sbin/init clk_ignore_unused console=hvc0 maxcpus=1" 176 fdt mknode /chosen dom0 177 fdt set /chosen/dom0 compatible "xen,multiboot-module" 178 fdt set /chosen/dom0 reg <0x00000000 0x40000000 0x0 0x03100000> 179 booti 30000000 - 20000000 180 181It's possible to change the OSPI flash model emulated by using the machine model 182option ``ospi-flash``. 183 184BBRAM File Backend 185"""""""""""""""""" 186BBRAM can have an optional file backend, which must be a seekable 187binary file with a size of 36 bytes or larger. A file with all 188binary 0s is a 'blank'. 189 190To add a file-backend for the BBRAM: 191 192.. code-block:: bash 193 194 -drive if=pflash,index=0,file=versal-bbram.bin,format=raw 195 196To use a different index value, N, from default of 0, add: 197 198.. code-block:: bash 199 200 -global driver=xlnx.bbram-ctrl,property=drive-index,value=N 201 202eFUSE File Backend 203"""""""""""""""""" 204eFUSE can have an optional file backend, which must be a seekable 205binary file with a size of 3072 bytes or larger. A file with all 206binary 0s is a 'blank'. 207 208To add a file-backend for the eFUSE: 209 210.. code-block:: bash 211 212 -drive if=pflash,index=1,file=versal-efuse.bin,format=raw 213 214To use a different index value, N, from default of 1, add: 215 216.. code-block:: bash 217 218 -global xlnx-efuse.drive-index=N 219 220.. warning:: 221 In actual physical Versal, BBRAM and eFUSE contain sensitive data. 222 The QEMU device models do **not** encrypt nor obfuscate any data 223 when holding them in models' memory or when writing them to their 224 file backends. 225 226 Thus, a file backend should be used with caution, and 'format=luks' 227 is highly recommended (albeit with usage complexity). 228 229 Better yet, do not use actual product data when running guest image 230 on this Xilinx Versal Virt board. 231 232Using CANFDs for Versal Virt 233"""""""""""""""""""""""""""" 234Versal CANFD controller is developed based on SocketCAN and QEMU CAN bus 235implementation. Bus connection and socketCAN connection for each CAN module 236can be set through command lines. 237 238To connect both CANFD0 and CANFD1 on the same bus: 239 240.. code-block:: bash 241 242 -object can-bus,id=canbus -machine canbus0=canbus -machine canbus1=canbus 243 244To connect CANFD0 and CANFD1 to separate buses: 245 246.. code-block:: bash 247 248 -object can-bus,id=canbus0 -object can-bus,id=canbus1 \ 249 -machine canbus0=canbus0 -machine canbus1=canbus1 250 251The SocketCAN interface can connect to a Physical or a Virtual CAN interfaces on 252the host machine. Please check this document to learn about CAN interface on 253Linux: docs/system/devices/can.rst 254 255To connect CANFD0 and CANFD1 to host machine's CAN interface can0: 256 257.. code-block:: bash 258 259 -object can-bus,id=canbus -machine canbus0=canbus -machine canbus1=canbus 260 -object can-host-socketcan,id=canhost0,if=can0,canbus=canbus 261