For qemu-user or on an existing riscv64 system, focal-riscv64-20200404-buildd.tar.gz is an Ubuntu buildd chroot including focal, focal-proposed and the bootstrap archive.

For qemu-system or HiFive Unleashed, focal-riscv64-20200422.qcow2 is a GPT-partitioned image that's bootable with an external OpenSBI and u-boot. The root password is ubuntu, and it's configured to DHCP. sshd is not preinstalled.

qemu-system

To run the system image in a modern qemu, download firmware/qemu-virt-20200504-ubuntu-firmware.bin and invoke qemu like so:

  qemu-system-riscv64 -machine virt -m 2048 -smp 4 \
    -bios qemu-virt-20200504-ubuntu-firmware.bin \
    -device virtio-blk-device,drive=vda \
    -drive file=focal-riscv64-20200422.qcow2,id=vda \
    -device virtio-net-device,netdev=eth0 -netdev user,id=eth0

You'll see bootloader and kernel output followed by a getty on the serial console (Ctrl+Alt+2 in the GUI).

With a sufficiently new qemu, opensbi and u-boot-qemu installed on your host, this should work instead of the provided firmware image:

    -kernel /usr/lib/riscv64-linux-gnu/opensbi/qemu/virt/fw_jump.elf \
    -device loader,file=/usr/lib/u-boot/qemu-riscv64_smode/uboot.elf,addr=0x80200000

If it drops you to a u-boot shell, run virtio_boot should kick it along.

If u-boot complains there's no device tree available, your u-boot is probably missing CONFIG_PREBOOT. Running setenv fdt_addr ${fdtcontroladdr}; run bootcmd should have the same effect.

If the kernel sees only a single CPU despite multiple being configured, ensure that your OpenSBI and Linux versions are compatible. The provided 20200504 firmware contains OpenSBI 0.6, which works with Linux before 5.7. The 20200422 firmware erroneously contained OpenSBI 0.7, which required Linux 5.7 for multiple CPU support.

qemu 4.2's riscv64 emulation has a floating point bug which results in general instability, including sshd hanging. 4.1 and 5.0 are unaffected, and focal's 1:4.2-3ubuntu6 has the fix backported.

HiFive Unleashed

The image boots as-is when written to microSD (once converted from qcow2 with something like qemu-img convert -O raw focal-riscv64-20200422.qcow2 focal-riscv64-20200422.img), as long as you have a sufficiently new u-boot installed. It is likely, however, that you don't.

The board's SPI flash ships with an old recovery kernel and old recovery Linux image. To run Ubuntu, it's recommended to replace these with more modern firmware based on OpenSBI and u-boot. A properly configured firmware image can be found at firmware/hifive-unleashed-20200504-ubuntu-firmware.bin, and can be written to SPI flash.

WARNING: This may render older microSD images unbootable due to changes in the boot process. However, the board is unbrickable as the SoC's boot ROM can jump straight to either SPI or microSD.

If you haven't used the board before, it's probably easiest to ignore the shipped image and boot from microSD. The firmware image can run from microSD as well as SPI flash, so can be used to bootstrap and flash itself:

1. Insert a microSD card with the firmware image written to it.

2. Boot the board direct from microSD by setting MSEL=1011 (MSEL2 to the outside of the board, the rest to the inside).

3. Interrupt u-boot's automatic boot, or wait for it to fail.

4. While at the u-boot prompt, insert a microSD card with the Ubuntu image written to it.

5. Resume the boot from microSD with run bootcmd.

6. Once the system has booted, log in as root:ubuntu.

7. apt install mtd-utils; modprobe spi_nor

8. flashcp -v hifive-unleashed-20200504-ubuntu-firmware.bin /dev/mtd0

9. Reboot the board with MSEL=0110 (MSEL0 and MSEL3 to the outside of the board).

As long as MSEL remains set to 0110, this will load the system-specific firmware (FSBL, OpenSBI and u-boot) from the on-board SPI flash, and then boot the generic Ubuntu image from microSD.

It's also possible to permanently boot purely from microSD by including the firmware partitions alongside the rootfs on microSD, but that's outside the scope of this document.

If u-boot complains there's no device tree available, your u-boot is probably missing CONFIG_PREBOOT. Running setenv fdt_addr ${fdtcontroladdr}; run bootcmd should have the same effect.

If the kernel sees only a single CPU despite multiple being configured, ensure that your OpenSBI and Linux versions are compatible. The provided 20200504 firmware contains OpenSBI 0.6, which works with Linux before 5.7. The 20200422 firmware erroneously contained OpenSBI 0.7, which required Linux 5.7 for multiple CPU support.

Firmware internals

The provided firmware is u-boot wrapped in OpenSBI. u-boot is configured with these options to ensure its device tree is passed through to the generic kernel:

  CONFIG_USE_PREBOOT=y
  CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr}; fdt addr ${fdtcontroladdr};"

The HiFive Unleashed blob additionally contains the FU540 FSBL. Both images are wrapped in a GPT partition table, with GUIDs that are known to the firmware. There are some quirks with the firmware, and trouble has been seen when loading partitions from too far into the disk. The provided image is structured like this:

  sgdisk --clear \
    --new=1:0:+32K --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
    --change-name=1:fsbl \
    --new=2:0:+4M: --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
    --change-name=2:opensbi-u-boot /dev/loop0

If preparing a combined firmware+rootfs GPT image, note that u-boot expects the rootfs to either be in partition 1 or to have the legacy MBR active flag set.

	Name	Last modified	Size	Description
	Parent Directory		-
	HEADER.html	2021-08-31 11:28	6.3K
	README	2020-06-02 13:06	5.6K
	SHA256SUMS	2020-05-04 06:09	516
	SHA256SUMS.gpg	2020-05-04 06:10	833
	firmware/	2020-05-04 06:03	-
	focal-riscv64-20200404-buildd.tar.gz	2020-04-22 08:32	118M
	focal-riscv64-20200422.qcow2	2020-04-22 08:37	641M
	hifive-unleashed-a00-microsemi.dtb	2021-02-27 03:15	8.3K