system/riscv/sifive_u.rst

13 * Up to 4 U54 / U34 cores
31 With QEMU, one can create a machine with 1 E51 core and up to 4 U54 cores. It
32 is also possible to create a 32-bit variant with the same peripherals except
33 that the RISC-V cores are replaced by the 32-bit ones (E31 and U34), to help
40 which it passes to the guest, if there is no ``-dtb`` option. This provides
44 hardware, as some of the devices are not modeled by QEMU and trying to access
47 If users want to provide their own DTB, they can use the ``-dtb`` option.
75   The current usage is only used to store the serial number of the board at
77   it to generate a unique MAC address to be programmed to the on-chip GEM
79   and connected to the same subnet, they all have the same MAC address hence
81   values to serial= when creating different ``sifive_u`` machines.
85   When given, QEMU's ROM codes jump to QSPI memory-mapped flash directly.
86   Otherwise QEMU will jump to DRAM or L2LIM depending on the msel= value.
87   When not given, it defaults to direct DRAM booting.
91   Mode Select (MSEL[3:0]) pins value, used to control where to boot from.
114 Linux mainline v5.10 release is tested at the time of writing. To build a
125 To boot the newly built Linux kernel in QEMU with the ``sifive_u`` machine:
132       -initrd /path/to/rootfs.ext4 \
135 Alternatively, we can use a custom DTB to boot the machine by inserting a CLINT
158       -initrd /path/to/rootfs.ext4 \
161 To build a Linux mainline kernel that can be booted by the ``sifive_u`` machine
162 in 32-bit mode, use the rv32_defconfig configuration. A patch is required to
175 line above to boot the 32-bit Linux kernel. A rootfs image containing 32-bit
176 applications shall be used in order for kernel to boot to user space.
181 VxWorks 7 SR0650 release is tested at the time of writing. To build a 64-bit
184 VxWorks image project to generate the bootable VxWorks image, by following the
188 part of the VxWorks SDK for testing as well. Instructions to download the SDK:
196 To boot the VxWorks kernel in QEMU with the ``sifive_u`` machine, use:
203       -kernel /path/to/vxWorks \
206 It is also possible to test 32-bit VxWorks on the ``sifive_u`` machine. Create
207 a 32-bit project to build the 32-bit VxWorks image, and use exact the same
213 U-Boot mainline v2024.01 release is tested at the time of writing. To build a
221   $ export OPENSBI=/path/to/opensbi-riscv64-generic-fw_dynamic.bin
226 To start U-Boot using the ``sifive_u`` machine, prepare an SPI flash image, or
228 genimage_ can be used to generate these images.
255 SPI flash image has slightly different partition offsets, and the size has to
256 be 32 MiB to match the ISSI 25WP256 flash on the real board:
289 to QEMU ``sifive_u`` machine:
295       -bios /path/to/u-boot-spl.bin \
296       -drive file=/path/to/sdcard.img,if=sd
298 Changing msel= value to 6, allows booting U-Boot from the SPI flash:
304       -bios /path/to/u-boot-spl.bin \
305       -drive file=/path/to/spi-nor.img,if=mtd
309 U-Boot proper. Hence the number of cores and size of memory have to match
312 Above use case is to run upstream U-Boot for the SiFive HiFive Unleashed
313 board on QEMU ``sifive_u`` machine out of the box. This allows users to
315 case: ZSBL (in QEMU) loads U-Boot SPL from SD card or SPI flash to L2LIM,
319 However sometimes we want to have a quick test of booting U-Boot on QEMU
321 way can be used, which is to create a U-Boot S-mode image by modifying the
333 This changes U-Boot to use the QEMU generated device tree blob, and bypass
342       -kernel /path/to/u-boot.bin
344 It's possible to create a 32-bit U-Boot S-mode image as well.
358 Use the same command line options to boot the 32-bit U-Boot S-mode image:
364       -kernel /path/to/u-boot.bin