1 SiFive HiFive Unleashed (``sifive_u``)
2 ======================================
4 SiFive HiFive Unleashed Development Board is the ultimate RISC-V development
5 board featuring the Freedom U540 multi-core RISC-V processor.
10 The ``sifive_u`` machine supports the following devices:
13 * Up to 4 U54 / U34 cores
14 * Core Level Interruptor (CLINT)
15 * Platform-Level Interrupt Controller (PLIC)
16 * Power, Reset, Clock, Interrupt (PRCI)
17 * L2 Loosely Integrated Memory (L2-LIM)
18 * DDR memory controller
20 * 1 GEM Ethernet controller
22 * 1 One-Time Programmable (OTP) memory with stored serial number
25 * 1 ISSI 25WP256 flash
26 * 1 SD card in SPI mode
28 Please note the real world HiFive Unleashed board has a fixed configuration of
29 1 E51 core and 4 U54 core combination and the RISC-V core boots in 64-bit mode.
30 With QEMU, one can create a machine with 1 E51 core and up to 4 U54 cores. It
31 is also possible to create a 32-bit variant with the same peripherals except
32 that the RISC-V cores are replaced by the 32-bit ones (E31 and U34), to help
33 testing of 32-bit guest software.
35 Hardware configuration information
36 ----------------------------------
38 The ``sifive_u`` machine automatically generates a device tree blob ("dtb")
39 which it passes to the guest, if there is no ``-dtb`` option. This provides
40 information about the addresses, interrupt lines and other configuration of
41 the various devices in the system. Guest software should discover the devices
42 that are present in the generated DTB instead of using a DTB for the real
43 hardware, as some of the devices are not modeled by QEMU and trying to access
44 these devices may cause unexpected behavior.
46 If users want to provide their own DTB, they can use the ``-dtb`` option.
47 These DTBs should have the following requirements:
49 * The /cpus node should contain at least one subnode for E51 and the number
50 of subnodes should match QEMU's ``-smp`` option
51 * The /memory reg size should match QEMU’s selected ram_size via ``-m``
52 * Should contain a node for the CLINT device with a compatible string
53 "riscv,clint0" if using with OpenSBI BIOS images
58 The ``sifive_u`` machine can start using the standard -kernel functionality
59 for loading a Linux kernel, a VxWorks kernel, a modified U-Boot bootloader
60 (S-mode) or ELF executable with the default OpenSBI firmware image as the
61 -bios. It also supports booting the unmodified U-Boot bootloader using the
62 standard -bios functionality.
64 Machine-specific options
65 ------------------------
67 The following machine-specific options are supported:
71 The board serial number. When not given, the default serial number 1 is used.
73 SiFive reserves the first 1 KiB of the 16 KiB OTP memory for internal use.
74 The current usage is only used to store the serial number of the board at
75 offset 0xfc. U-Boot reads the serial number from the OTP memory, and uses
76 it to generate a unique MAC address to be programmed to the on-chip GEM
77 Ethernet controller. When multiple QEMU ``sifive_u`` machines are created
78 and connected to the same subnet, they all have the same MAC address hence
79 it creates an unusable network. In such scenario, user should give different
80 values to serial= when creating different ``sifive_u`` machines.
84 When given, QEMU's ROM codes jump to QSPI memory-mapped flash directly.
85 Otherwise QEMU will jump to DRAM or L2LIM depending on the msel= value.
86 When not given, it defaults to direct DRAM booting.
90 Mode Select (MSEL[3:0]) pins value, used to control where to boot from.
92 The FU540 SoC supports booting from several sources, which are controlled
93 using the Mode Select pins on the chip. Typically, the boot process runs
94 through several stages before it begins execution of user-provided programs.
95 These stages typically include the following:
97 1. Zeroth Stage Boot Loader (ZSBL), which is contained in an on-chip mask
98 ROM and provided by QEMU. Note QEMU implemented ROM codes are not the
99 same as what is programmed in the hardware. The QEMU one is a simplified
100 version, but it provides the same functionality as the hardware.
101 2. First Stage Boot Loader (FSBL), which brings up PLLs and DDR memory.
103 3. Second Stage Boot Loader (SSBL), which further initializes additional
104 peripherals as needed. This is U-Boot proper combined with an OpenSBI
105 fw_dynamic firmware image.
107 msel=6 means FSBL and SSBL are both on the QSPI flash. msel=11 means FSBL
108 and SSBL are both on the SD card.
113 Linux mainline v5.10 release is tested at the time of writing. To build a
114 Linux mainline kernel that can be booted by the ``sifive_u`` machine in
115 64-bit mode, simply configure the kernel using the defconfig configuration:
120 $ export CROSS_COMPILE=riscv64-linux-
124 To boot the newly built Linux kernel in QEMU with the ``sifive_u`` machine:
128 $ qemu-system-riscv64 -M sifive_u -smp 5 -m 2G \
129 -display none -serial stdio \
130 -kernel arch/riscv/boot/Image \
131 -initrd /path/to/rootfs.ext4 \
132 -append "root=/dev/ram"
134 Alternatively, we can use a custom DTB to boot the machine by inserting a CLINT
135 node in fu540-c000.dtsi in the Linux kernel,
139 clint: clint@2000000 {
140 compatible = "riscv,clint0";
141 interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7
142 &cpu1_intc 3 &cpu1_intc 7
143 &cpu2_intc 3 &cpu2_intc 7
144 &cpu3_intc 3 &cpu3_intc 7
145 &cpu4_intc 3 &cpu4_intc 7>;
146 reg = <0x00 0x2000000 0x00 0x10000>;
149 with the following command line options:
153 $ qemu-system-riscv64 -M sifive_u -smp 5 -m 8G \
154 -display none -serial stdio \
155 -kernel arch/riscv/boot/Image \
156 -dtb arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb \
157 -initrd /path/to/rootfs.ext4 \
158 -append "root=/dev/ram"
160 To build a Linux mainline kernel that can be booted by the ``sifive_u`` machine
161 in 32-bit mode, use the rv32_defconfig configuration. A patch is required to
162 fix the 32-bit boot issue for Linux kernel v5.10.
167 $ export CROSS_COMPILE=riscv64-linux-
168 $ curl https://patchwork.kernel.org/project/linux-riscv/patch/20201219001356.2887782-1-atish.patra@wdc.com/mbox/ > riscv.patch
170 $ make rv32_defconfig
173 Replace ``qemu-system-riscv64`` with ``qemu-system-riscv32`` in the command
174 line above to boot the 32-bit Linux kernel. A rootfs image containing 32-bit
175 applications shall be used in order for kernel to boot to user space.
177 Running VxWorks kernel
178 ----------------------
180 VxWorks 7 SR0650 release is tested at the time of writing. To build a 64-bit
181 VxWorks mainline kernel that can be booted by the ``sifive_u`` machine, simply
182 create a VxWorks source build project based on the sifive_generic BSP, and a
183 VxWorks image project to generate the bootable VxWorks image, by following the
184 BSP documentation instructions.
186 A pre-built 64-bit VxWorks 7 image for HiFive Unleashed board is available as
187 part of the VxWorks SDK for testing as well. Instructions to download the SDK:
191 $ wget https://labs.windriver.com/downloads/wrsdk-vxworks7-sifive-hifive-1.01.tar.bz2
192 $ tar xvf wrsdk-vxworks7-sifive-hifive-1.01.tar.bz2
193 $ ls bsps/sifive_generic_1_0_0_0/uboot/uVxWorks
195 To boot the VxWorks kernel in QEMU with the ``sifive_u`` machine, use:
199 $ qemu-system-riscv64 -M sifive_u -smp 5 -m 2G \
200 -display none -serial stdio \
201 -nic tap,ifname=tap0,script=no,downscript=no \
202 -kernel /path/to/vxWorks \
203 -append "gem(0,0)host:vxWorks h=192.168.200.1 e=192.168.200.2:ffffff00 u=target pw=vxTarget f=0x01"
205 It is also possible to test 32-bit VxWorks on the ``sifive_u`` machine. Create
206 a 32-bit project to build the 32-bit VxWorks image, and use exact the same
207 command line options with ``qemu-system-riscv32``.
212 U-Boot mainline v2021.01 release is tested at the time of writing. To build a
213 U-Boot mainline bootloader that can be booted by the ``sifive_u`` machine, use
214 the sifive_fu540_defconfig with similar commands as described above for Linux:
218 $ export CROSS_COMPILE=riscv64-linux-
219 $ export OPENSBI=/path/to/opensbi-riscv64-generic-fw_dynamic.bin
220 $ make sifive_fu540_defconfig
222 You will get spl/u-boot-spl.bin and u-boot.itb file in the build tree.
224 To start U-Boot using the ``sifive_u`` machine, prepare an SPI flash image, or
225 SD card image that is properly partitioned and populated with correct contents.
226 genimage_ can be used to generate these images.
228 A sample configuration file for a 128 MiB SD card image is:
232 $ cat genimage_sdcard.cfg
240 partition u-boot-spl {
241 image = "u-boot-spl.bin"
243 partition-type-uuid = 5B193300-FC78-40CD-8002-E86C45580B47
249 partition-type-uuid = 2E54B353-1271-4842-806F-E436D6AF6985
253 SPI flash image has slightly different partition offsets, and the size has to
254 be 32 MiB to match the ISSI 25WP256 flash on the real board:
258 $ cat genimage_spi-nor.cfg
266 partition u-boot-spl {
267 image = "u-boot-spl.bin"
269 partition-type-uuid = 5B193300-FC78-40CD-8002-E86C45580B47
275 partition-type-uuid = 2E54B353-1271-4842-806F-E436D6AF6985
279 Assume U-Boot binaries are put in the same directory as the config file,
280 we can generate the image by:
284 $ genimage --config genimage_<boot_src>.cfg --inputpath .
286 Boot U-Boot from SD card, by specifying msel=11 and pass the SD card image
287 to QEMU ``sifive_u`` machine:
291 $ qemu-system-riscv64 -M sifive_u,msel=11 -smp 5 -m 8G \
292 -display none -serial stdio \
293 -bios /path/to/u-boot-spl.bin \
294 -drive file=/path/to/sdcard.img,if=sd
296 Changing msel= value to 6, allows booting U-Boot from the SPI flash:
300 $ qemu-system-riscv64 -M sifive_u,msel=6 -smp 5 -m 8G \
301 -display none -serial stdio \
302 -bios /path/to/u-boot-spl.bin \
303 -drive file=/path/to/spi-nor.img,if=mtd
305 Note when testing U-Boot, QEMU automatically generated device tree blob is
306 not used because U-Boot itself embeds device tree blobs for U-Boot SPL and
307 U-Boot proper. Hence the number of cores and size of memory have to match
308 the real hardware, ie: 5 cores (-smp 5) and 8 GiB memory (-m 8G).
310 Above use case is to run upstream U-Boot for the SiFive HiFive Unleashed
311 board on QEMU ``sifive_u`` machine out of the box. This allows users to
312 develop and test the recommended RISC-V boot flow with a real world use
313 case: ZSBL (in QEMU) loads U-Boot SPL from SD card or SPI flash to L2LIM,
314 then U-Boot SPL loads the combined payload image of OpenSBI fw_dynamic
315 firmware and U-Boot proper. However sometimes we want to have a quick test
316 of booting U-Boot on QEMU without the needs of preparing the SPI flash or
317 SD card images, an alternate way can be used, which is to create a U-Boot
318 S-mode image by modifying the configuration of U-Boot:
324 then manually select the following configuration in U-Boot:
326 Device Tree Control > Provider of DTB for DT Control > Prior Stage bootloader DTB
328 This lets U-Boot to use the QEMU generated device tree blob. During the build,
329 a build error will be seen below:
334 ./tools/mkimage: Can't open arch/riscv/dts/hifive-unleashed-a00.dtb: No such file or directory
335 ./tools/mkimage: failed to build FIT
336 make: *** [Makefile:1440: u-boot.img] Error 1
338 The above errors can be safely ignored as we don't run U-Boot SPL under QEMU
339 in this alternate configuration.
341 Boot the 64-bit U-Boot S-mode image directly:
345 $ qemu-system-riscv64 -M sifive_u -smp 5 -m 2G \
346 -display none -serial stdio \
347 -kernel /path/to/u-boot.bin
349 It's possible to create a 32-bit U-Boot S-mode image as well.
353 $ export CROSS_COMPILE=riscv64-linux-
354 $ make sifive_fu540_defconfig
357 then manually update the following configuration in U-Boot:
359 Device Tree Control > Provider of DTB for DT Control > Prior Stage bootloader DTB
360 RISC-V architecture > Base ISA > RV32I
361 Boot images > Text Base > 0x80400000
363 Use the same command line options to boot the 32-bit U-Boot S-mode image:
367 $ qemu-system-riscv32 -M sifive_u -smp 5 -m 2G \
368 -display none -serial stdio \
369 -kernel /path/to/u-boot.bin
371 .. _genimage: https://github.com/pengutronix/genimage