Category Archives: RISC-V

32/64/128bits RISC-V processor ISA

Using ESP-IDF with RISC-V ESP32-C3 nodeMCU module on a Linux system

>NodeMCU ESP32-C3S”></a></p>
<h2 id=Table of Content

* Introduction
* Step 1, install dependencies
* Step 2, install ESP-IDF
* Step 3, setup working environment
* Step 4, test “Hello World” example
* Step 5, tune the target, if needed
* Step 6, flash the project
* Step 7, viewing the output
* Troubleshooting
** Invalid value for ‘{esp32|esp32s2}’: ‘esp32c3′ is not one of ‘esp32′, ‘esp32s2′
** libsodium/crypto_box/curve25519xchacha20poly1305/box_seal_curve25519xchacha20poly1305.c
** Flashing errors
*** Detection, power, and device that disappear
*** usbfs: interface 0 claimed by ch341 while ‘brltty’ sets config #1
** Problem with CA certificates bundle

Introduction

The list of existing ESP32-C3 SoC modules (with their specs) is very interesting, This one RISC-V core SoC has lower computing power than the ESP32-S3 (dual-core Xtensa ISA based, with a RISC-V co-processor core for “ultra low power” (ULP) mode), but RISC-V architecture is also far more efficient and will for sure have longer lifetime support and evolution due to its openness. ESP32-C3 use an RV32IMC (Integer, Multiplication/division and Compressed extensions) core.

I bought for my test a ESP-C3-32S-Kit on AliExpress (for ~3.4€). There is also an interesting option, where you can use really tiny 3~4 € ESP-C3-01M-Kit programmer interface/mother board, with a SoC included alone on a daughter (ESP32-C3M with an on PCB antenna). This allows, to flash several pads one only one programmer board. This reduce size of the needed system for final application to just the SoC and it’s power supply and peripherals. Pads of the SoC daughter board are wide enough to be easily soldered.

ESP-IDF is a tool to develop in C language on Espressif platforms, including ESP8266 and ESP32 series. It uses FreeRTOS free and open source embedded real-time OS for its SoCs. Sadly the official documentation for installing it is incomplete with the current state (November 2021) of GIT repository. Here is the mean to install a working ESP-IDF for this SoC series on Linux. This will be more compact and straight forward that the official with Linux+Windows installation.

About RISC-V more generally, I created this week a list of available Open Source RISC-V implementations, and open sources tools to build them or work with them.

Step 1, install dependencies

Instruction for Arch Linux, CentOS and Debian, based Linux systems:

* Debian/Ubuntu/…

sudo apt-get install git wget flex bison gperf python3 python3-pip python3-setuptools cmake \
  ninja-build ccache libffi-dev libssl-dev dfu-util libusb-1.0-0

* CentOS

sudo yum -y update && sudo yum install git wget flex bison gperf python3 python3-pip python3-setuptools \
  cmake ninja-build ccache dfu-util libusbx

* Arch Linux/Manjaro/…

sudo pacman -S --needed gcc git make flex bison gperf python-pip cmake ninja ccache dfu-util libusb

Step 2, install ESP-IDF

This will take at least 1.2GB of disk space (size of the git clone at the time I write this article).

mkdir -p ~/esp
cd ~/esp
git clone --recursive https://github.com/espressif/esp-idf.git

They didn’t mention, that 4.3 is required to use ESP32-C3. At the time I tried it, version 4.2 is currently (November 2021) the default branch, you can see the current version by this commands. Warning: This start the environment, so you will probably need to log again or simply start another shell to avoid problems when finishing the installation.:

cd ~/esp/esp-idf
. ./export.sh
idf.py --version

So you need to checkout the 4.3 branch to have a working version with ESP32-C3, and then update submodule to match the new version:

cd ~/esp/esp-idf
git checkout release/v4.3
git submodule update --init --recursive

Then you need to install some binaries/libs. Warning, it will create a ~/.expressif directory to place all downloaded files inside, don’t forget to create the directory + a link to a partition with enough place (about 1GB needed for all versions).

cd ~/esp/esp-idf
./install.sh esp32c3

After the installation, the following command is suggested to enter in the working (python pyenv) environment (don’t forget the first . and space)

Step 3, setup working environment

. ./export.sh

A message will be displayed that explain to you how to compile a program:

Done! You can now compile ESP-IDF projects.
Go to the project directory and run:

  idf.py build

They suggest in the documentation to add an alias to your .bashrc:

alias get_idf='. $HOME/esp/esp-idf/export.sh'

So you will only have to type get_idf to get ready to use it.

Step 4, test “Hello World” example

I would personally make it this way:

cd ~/esp/
mkdir tests
cd tests
cp -a ~/esp/esp-idf/examples/get-started/hello_world .
cd hello_world
idf.py set-target esp32c3

Errors possible, see:
* Invalid value for ‘{esp32|esp32s2}’: ‘esp32c3′ is not one of ‘esp32′, ‘esp32s2′
* libsodium/crypto_box/curve25519xchacha20poly1305/box_seal_curve25519xchacha20poly1305.c

Step 5, tune the target, if needed

You need now to use menuconfig if you want to setup some parameters, default one should just work fine.

idf.py menuconfig

This show you an interactive cli menu interface like for the Linux kernel, that allow you to tune some parameters. You don’t need to tune them for this test.

You can navigate with cursor keys, validate or enter submenus with enter, and quit them without modification with esc key. When you quit it, it will say you if you didn’t done any modification:

No changes to save (for '~/esp/test/hello_world/sdkconfig')

Step 5 build the project

Now as everything is setup, you only need to build the project, this could take some time, as it, at first time, compile, the whole embedded system:

idf.py build

It will end with a message displaying the location of the binary to be flashed and the instruction to type to flash it, the long explicit way and the short implicit way (I coloured them here):

Generated >/data/arc/esp/test/hello_world/build/hello-world.bin

Project build complete. To flash, run this command:
/home/popolon/.espressif/python_env/idf4.3_py3.9_env/bin/python ../../esp-idf/components/esptool_py/esptool/esptool.py -p (PORT) -b 460800 --before default_reset --after hard_reset --chip esp32c3  write_flash --flash_mode dio --flash_size detect --flash_freq 80m 0x0 build/bootloader/bootloader.bin 0x8000 build/partition_table/partition-table.bin 0x10000 build/hello-world.bin
or run 'idf.py -p (PORT) flash'

* Problem with CA certificates

Step 6, flash the project

If you didn’t have plugged your board in the USB port it’s the time to do. Then (by default white colour RGB led is enlighten. Type then the suggested command. I choose the short way here:

idf.py --port /dev/ttyUSB0 flash

It should now do the flashing sequence. I show only some important steps. In color you MAC address is given, it can be useful to detect if everything run fine.

Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: XX:XX:XX:XX:XX:XX
Uploading stub...
[...] <- lot of output
Writing at 0x00010000... (20 %)
[...] <- lot of output
Leaving...
Hard resetting via RTS pin...
Done

Read this if you have some troubles at flashing.

Step 7, viewing the output

You can connect to the board, still with its ttyUSB0 port, need to connect at speed 115200. I previously wrote an article about how to control a remote board, including serial

I use TinySerial here:

com /dev/ttyUSB0 115200

You can also use idf.py to monitor the output like this (idf.py monitor shortcuts and launching GDB with GDBStub:

idf.py -p /dev/ttyUSB0 monitor

In both case, you will see a booting sequence, an Hello World! some characteristics of your board, then a 10 seconds counter and a reboot. This is looping until you unplug or flash again the board.

Hello world!
This is esp32c3 chip with 1 CPU core(s), WiFi/BLE, silicon revision 3, 2MB external flash
Minimum free heap size: 327588 bytes
Restarting in 10 seconds...
Restarting in 9 seconds...
Restarting in 8 seconds...

You can quit by typing: the 2 keys ctrl-c followed then by a

Building, flashing and monitor can be combined by one command:
idf.py -p /dev/ttyUSB0 flash monitor

Troubleshooting

I don’t want to pollute too much the reading of the workflow and keep it as reference, so people can found answer when they encouter the same errors.

Invalid value for ‘{esp32|esp32s2}’: ‘esp32c3′ is not one of ‘esp32′, ‘esp32s2′

If you have the following error, you didn’t checkout the 4.3 branch at Step 2

Usage: /data/arc/esp/esp-idf/tools/idf.py set-target [OPTIONS] {esp32|esp32s2}
Try '/data/arc/esp/esp-idf/tools/idf.py set-target --help' for help.

Error: Invalid value for '{esp32|esp32s2}': 'esp32c3' is not one of 'esp32', 'esp32s2'.

libsodium/crypto_box/curve25519xchacha20poly1305/box_seal_curve25519xchacha20poly1305.c

If during the set-target you have the following error:

CMake Error at ~/esp/esp-idf/tools/cmake/component.cmake:475 (add_library):
  Cannot find source file:

    ~/esp/esp-idf/components/libsodium/libsodium/src/libsodium/crypto_box/curve25519xchacha20poly1305/box_seal_curve25519xchacha20poly1305.c

This mean you didn’t made the git submodules update in Step 2. So return in ~/esp/esp-idf and git submodule update.

You will then need to remove the hello_world directory and copy it again in tests: cd ~/esp/tests/; rm -R hello_word; cp -a ~/esp/esp-idf/examples/get-started/hello_world ..

Flashing errors

There are several problems possible for flashing part, most of them are about ttyUSB0 detection/usage.

Detection, power, and device that disappear

NodeMCU ESP32-C3S

First look if your board is detected by lsusb.

* If the device isn’t detected at all, verify if you USB wire is not a powering only wire. Try by connecting other USB devices, if all of them aren’t detected by the wire, this is probably the case, if you use a wire for your phone with the same kind of connector, try if it detected with it, then your board.

* Another case, a board that worked perfectly the first day, was not detected any more the second day. I looked at it with artisanal microscope using phone zoom + cheap lens, and seen a hair or wire, like on the detail picture at left, just above two pins of the USB connector. After removing it, the board work again.

* If the interface is displayed by lsusb but disappear when flashing it, try to disable power saving (autosuspend) for this device or all USB devices, lots of old mother boards have problems with USB devices power saving. Some mouses keep stuck, some flashable devices disappear, etc…

usbfs: interface 0 claimed by ch341 while ‘brltty’ sets config #1

If it fails with a long error message including around the 10th line:

FileNotFoundError: [Errno 2] No such file or directory: '/dev/ttyUSB0'

Then there is a problem with the USB detection in your system configuration.

You can dig in kernel message with dmesg | less then search for ttyUSB0 (just type /ttyUSB0 to found the problem.

In my case for example, the brtty (tty for braille) driver tried to get the serial device and then disconnected it:

[36767.028312] usb 1-1.6: ch341-uart converter now attached to ttyUSB0
[36767.252867] audit: type=1130 audit(1637441179.890:468): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=brltty-device@sys-devices-pci0000:00-0000:00:1a.0-usb1-1\x2d1-1\x2d1.6 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[36767.878792] audit: type=1130 audit(1637441180.513:469): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=brltty@-sys-devices-pci0000:00-0000:00:1a.0-usb1-1\x2d1-1\x2d1.6 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[36767.883002] usb 1-1.6: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
[36767.883975] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[36767.883998] ch341 1-1.6:1.0: device disconnected

You can in this case not the device id with the following command (the ID in the result is coloured here:

lsusb | grep CH340
Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics CH340 serial converter

Then edit the 90-brltty-device.rules:

>code>sudo vi /usr/lib/udev/rules.d/90-brltty-device.rules

Search the line containing 1a86/7523 by typing /1a86/7523, then comment the line by adding a # at start:

#ENV{PRODUCT}=="1a86/7523/*", ENV{BRLTTY_BRAILLE_DRIVER}="bm", GOTO="brltty_usb_run"

save and quit by typing :x if you use vi/vim/nvim… and then reload udev rules by typing:

systemctl reload systemd-udevd

It should now be ok, by just unplugging and replugging the USB wire from your computer.

Generally all the kind of (tty)USB connection problem can be solved by tuning /etc/udev/rules.d/

Problem with CA certificates bundle

With the 4.2 version of ESP-IDF, some FAILED are thrown in relation with a x509_crt_bundle and cacrt_all.pem invalid certificate.

Updating the Certificate Bundle section has a link to himself as solution. ^^. Looks like the problem is on ESP-IF 4.2, 4.3 runs just fine, see install + upgrade process.

My system CA-certificates are already up to date but it want a specific version to put somewhere (not documented) to be able to push it on the board firmware. Ca-certificates, are certificates about CA (Certificate Authorities) that you need to be sure that this authorities are still be considered as valid. anyway ESP-IF 4.3 works just fine.

Linux syscall and RISC-V assembly

Sample of RISC-V assembly code

Syscall in Linux kernel, is an interface to access to kernel basic functions. They are described in section 2 of man pages. The introduction is in man 2 syscall (indirect system call), and the list of functions are described in man 2 syscalls. Update: System Calls in lectures of official Linux kernel documentation including “Linux system calls implementation”, “VDSO and virtual syscalls” and “Accessing user space from system calls”

This article follow previous one about RISC-V overall progress and available tools to play with, I will try to make a short article here about Linux syscall usage and the RISC-V assembly case.

Table of Content

* Description section of the man page
* Getting the list of function and how to access them
* Passing parameters
* Function number and registers of return values
* Return values and error code
* Compiling and executing on virtual environment
* Update: Bronzebeard assembler and its baremetal environment for real hardware

Description section of the man page

* syscall() is a small library function that invokes the system call whose assembly language interface has the specified number with the specified arguments. Employing
* syscall() is useful, for example, when invoking a system call that has no wrapper function in the C library.
* syscall() saves CPU registers before making the system call, restores the registers upon return from the system call, and stores any error returned by the system call in errno(3).
* Symbolic constants for system call numbers can be found in the header file .

You can find here function, like access to files open/close/read/write/flush, access to sockets, ioctl, uid, gid, pid, messages, ptrace, restart system, etc…

Getting the list of function and how to access them

As far I know, now only a part of syscall functions are accessible easily in assembly, they are defined in /usr/include/unistd.h, and function numbers assigned in ABI are defined in /usr/include/asm-generic/unistd.h.

The more practical match I found is using /usr/include/asm-generic/unistd.h to see which function are available and there respective manpage for the function header definition. For example:
* asm-generic: #define __NR_read 63
* man 2 read: ssize_t read(int fd, void *buf, size_t count);

The ABI with RISC_V as defined in man 2 syscall in section Architecture calling conventions use the registers following 2 tables rules.

Passing parameters

The second table in this section of the man page shows the registers used to pass the system call arguments.

Arch/ABI      arg1  arg2  arg3  arg4  arg5  arg6  arg7  Notes
──────────────────────────────────────────────────────────────
riscv         a0    a1    a2    a3    a4    a5    -

Here are the arguments in the order of the function definition, for example, in read (63) function:

ssize_t      read  ( int fd, void *buf, size_t count );
a0(result) = a7(63)( a0(fd),  a1(*buf),    a2(count) )

For remember, 3 standard I/O file descriptors are STDIN=0, STDOUT=1, STDERR=2, the other are used when opened a file with open and closed by close.

So we set the arguments as this. x0 is the always 0 register:

        addi  a0, x0, 0       # Set STDIN as sources
        la    a1, buffer_addr # load address of helloworld
        addi  a2, x0, 3       # reaad 3 bytes

Function number and registers of return values

And the first one give the register in which put the function number, that will receive return value and errno (error value)

Arch/ABI    Instruction           System  Ret  Ret  Error    Notes
                                  call #  val  val2
───────────────────────────────────────────────────────────────────
riscv       ecall                 a7      a0   a1   -

So for the read function, we need to put 63 (as found in /usr/include/asm-generic/unistd.h in register a7, and registers and following registers will receive the return values, a0 will receive system call result, and a1 an error message (the errno value).

ssize_t read(int fd, void *buf, size_t count);
a0    =  63 (    a0,       a1,         a2)

So can set them as this:

        addi  a7, x0, 63     # set called function as read()
        ecall                # call the function

Return values and error code

After the man page of read(2):
* On success, the number of bytes read is returned
* On error, -1 is returned, and errno is set to indicate the error.

So we can test first the return value of a0 and if a0 < 0 then we jump to part for display the error message, else we can simply display a OK message. So for the branching part, RISC-V in its super reduced set only have < (lt) and <= (le) comparators, you just need to swap registers to compute > (gt) and >= (ge), but this avoid lots more of transistors.

    addi a3,x0,0           # x3=0
    blt  a1,a3, error_seq  # if x1<0 branch to error_seq

We so use here the syscall write function (64) defined as:
* asm-generic: #define __NR_write 64
* man 2 write: ssize_t write(int fd, const void *buf, size_t count);
* So, registers: a0=1 (STDOUT), a1=*buf, a2=count, a7=64 (function number)

And we will finish with exit() syscall, defined as:
* asm-generic: #define __NR_exit 93
* man 2 exit: noreturn void _exit(int status);
* So, registers: a0=return code, a7=93 (function number)

    la    a1, ok           # load address (pseudo code) of ok string
    addi  a2, x0, 3        # set length of text to 3 (O + K + \n)
    addi  a7, x0, 64       # set ecall to write function
    ecall                  # Call the function

    addi  a0, x0, 0        # set return code to 0 (OK) for exit (93) function
    j     end              # unconditional jump to end before quit

error_seq:
    la    a1, error        # load address (pseudo code) of error string
    addi  a2, a2, 0x30     # add 0x30 (0 ASCII code) to the error code
    sb    a2, 7(a1)        # put the (byte) value at position 7 of Error string (before \n)
    addi  a2, x0, 10       # set now length of our string
    addi  a7, x0, 64       # set ecall to write function
    ecall                  # Call the function

    addi  a0, x0, -1       # set return code to -1 (error) for exit (93) function
end:
    addi    a7, x0, 93     # set ecall to exit (93) function
    ecall                  # Call linux to terminate the program

.data:
ok:     .ascii "OK\n"
error:  .ascii "Error:  \n"

RISC-V Longan nano

Compiling and executing on virtual environment

If you don't have a RISC-V hardware (can be found as low as 3€ now), you need to have a cross compiler and qemu for emulating instructions, or a whole system installed.

Packages needed for compiling on ArchLinux x86 or ARM for example.

sudo pacman -S riscv64-linux-gnu-gcc  riscv64-linux-gnu-glibc riscv64-elf-binutils riscv64-elf-binutils riscv64-elf-gcc riscv64-elf-gdb

Note: If you have the following error, just comment the .data: line by a #

test.s: Assembler messages:
test.s:22: Error: symbol `.data' is already defined

Newlib is a lightweight RV32 (RISC-V 32bits) lightweight library for bare metal that can be used instead of a whole GNU system on embedded devices with low memory capacity (as Longan nano, less than 8€ with screen, see picture below, or 3€ Sipeed RV): riscv32-elf-newlib.

I made a simple shell script to don't have to remember the commands to assemble the code from an x86 platform (work also on ARM or RISC-V one) that take the .s as argument:

name=$1
riscv64-linux-gnu-as -march=rv64imac -o ${name}.o ${name}.s
riscv64-linux-gnu-ld -o ${name} ${name}.o

You can add a strip but better to avoid it if you need to debug it:

riscv64-elf-strip --strip-all ${name}

And it can be executed on non RISC-V platforms by using qemu-riscv64, if it doesn't depend on libraries or if you have them installed, it allow you to test it without having a full RISC-V system installed, qemu is so fantastic. On ArchLinux it is available in package qemu-arch-extra:

qemu-riscv64 ${name}

And can be disassembled (will probably use different instruction than your assembly code, due to RISC-V assembly pseudo-instructions:

riscv64-linux-gnu-objdump -d ${name}

Bronzebeard assembler and its baremetal environment for real hardware

RISC-V Longan nano

Update: Bronzebeard is an assembler with light baremetal environment builder for RISC-V, GD32VF103 as Longan Nano (about 8€ with a screen, as pictured on this article pictures) and Wio (similar board with an added ESP8266 SoC). I made an AUR package of Bronzebeard, and someone made a Mandelbrot set demo in 918 bytes pure RISC-V assembly. You can find some other example in the source of Bronzebeard. gd32vf103inator is a set of tools for GD32V, to manage from a simple random text editor.

RISC-V overall progress

WordPress is so cumbersome (brut long text in SQL DB and other misconception (WTF?), buggy (especially to multilingual content missing) and hard to maintain on long term that I didn’t posted for long time I want to migrate. You can test the new log engine (here specialised in TIC-80 256 bytes code on https://256b.popolon.org/.

I continued my travel toward RISC-V I started as said in a previous post in may 2018.

RISC-V Benefits

Among the benefit of RISC-V beside other implementations:
* Open source and without license fee availability, allowing everyone to participate, implement and have full specifications
* Highest modularity for a processor in specifications, You can reduce the core to only the set of functions you want for a specific tasks, allowing less transistor/more compact specialized cores, and then multiply cores with some specialized in some kind of tasks.
* Vector extension

As example of specific task oriented cores:
* You don’t need a SIMD if you have a more powerful DSP unit, and you can implement this DSP unit using a RISC-V core with Vector extension, that is more efficient that a simple SIMD for this kind of task.
* JIT extension could be useful for some dynamic web server using scripting language (as PHP, Ruby, JS), but less useful for static web server (PCRE-jit computation in servers like nginx is marginal a core could be dedicated on a processor with many cores without this extension). Alibaba Group (Chinese Amazon) developed it’s own RISC-V implementation for its web servers).
* The European processor Initiative started in 2018, with first goal to uses United Kingdom made ARM core for main processor (at this time ARM had solid build/compilation/system ecosystem) with several kind of computing accelerators based on RISC-V, called EPAC (European Processor Accelerators)(a.is). It is developed at Barcelone with several partners inside European Union(a.is), Sadly as most European union project it will help USA industry for manufacturing, (GlobalFoundries) instead of maintain, sustain and develop local knowledge, experience and workforce for independence, employment and smaller carbon footprint shipments (as China and United-States do). The first test version is a 22nm FPGA, the production one will be 12nm ASIC, and among the objectives, there will be to highest throughput while not going above the 1GHz top barrier, to achieve higher energy efficiency.

Operating System working on RISC-V in June 2021

First efforts with toward embedded operating systems as first available RISC-V chips was in this domain. As the RISC-V embedded market is mature, more effort are made toward mobile and desktop Operating Systems.

Several Linux distribution already work on RISC-V now. Next Debian Bulleye (release August 14 2021, already in beta), Fedora have a RISC-V flavor already working on the BeagleV Starlight open-source board and its StarFive JH7100 processor, and there is a port of Yocto.

For reference, here is instructions about making the RISCV64 virtual machine on Debian Wiki, and a more general guide to make Linux run on Qemu, RISC-V.

You can find the Debian RISC-V system image on this page, just click on to download (direct link). This image is made with Debian Quick Image Baker (dqib)

To run it, you also need OpenSBI (Open Source Supervisor Binary Interface) needed to load the bootloader (Documentation, Prebuild deb packages) I used deb package on Archlinux:

ar x ../opensbi_0.9-1_all.deb
SBIPATH=`pwd`
(cd /; sudo tar xf "$SBIPATH/data.tar.xz")

And the Uboot for Qemu. I personally just extract and the directory that also contain, the “artifacts” Debian image.

By default image is in Qcow format, that is more compact for unused blocks, but also really slower.
You can convert it easily by:

qemu-img convert -f qcow2 -O raw image.qcow2 image.raw

Here is the boot.sh to launch it (you can replace image.raw by image.qcow2, if you have a verypowerfull system and only place count: I use 2 cores and 512M of RAM. For huge compilation I restart it with more mem (1536M is generally enough, but more means more cache and faster compilation).

cores=2
mem=512M
qemu-system-riscv64 -machine virt -cpu rv64 -smp ${cores} -m ${mem} \
  -device virtio-blk-device,drive=hd -drive file=image.raw,if=none,id=hd \
  -device virtio-net-device,netdev=net -netdev user,id=net,hostfwd=tcp::2222-:22 \
  -bios /usr/riscv64-linux-gnu/lib/opensbi/generic/fw_jump.elf \
  -kernel ../qemu-riscv64_smode/uboot.elf \
  -object rng-random,filename=/dev/urandom,id=rng -device virtio-rng-device,rng=rng \
  -nographic -append "root=LABEL=rootfs console=ttyS0"

The login/pass are root/root.

you can connect by ssh:

ssh -p 2222 root@127.0.0.1

and rsync files via:

rsync -a --rsh="ssh -p 2222" root@127.0.0.1:path/to/rsync .

I already managed to compile TIC-80 on it and run it on Qemu:

.

There is also BareDOOM a port of DOOM that run on RISC-V emulated in TinyEmu (source code in the same page, there is also a fork with additional features on GitHub, a system emulator for the RISC-V and x86 architectures), JSLinux allow to run it in a browser (There is also a Quake port on RISC-V K210 microcontroller based Sipeed Maix Bit board). There is also a patched version of buildroot for K210 (no-mmu), for building Linux on this platform.

There is an important Note in system images from Fabrice Bellard site to make binary working with TinyEMU:


- TinyEMU only supports raw boot loader and kernel images. So after
  building riscv-pk or the Linux kernel, you must convert the ELF
  image to a raw image with:

  riscv64-unknown-linux-gnu-objcopy -O binary bbl bbl.bin
  
  riscv64-unknown-linux-gnu-objcopy -O binary vmlinux kernel.bin

A port of Haiku has already well progressed, also use TinyEMU for the port.

Update 2 July 2021: Another RISC-V (RV32 only) emulator is Nemu (github) it is a part of XiangShan (香山) RISC-V open processor from Chinese Academy of Sciences (OpenXiangShan (Gitee)) made by Chinese Academy of Sciences, the processors should have the performances of an ARM Cortex-A72/A73 in july 2021 with a 28nm process in first batch (Yanqi hu / Yanqi Lake / 雁栖湖), and performances of an Intel i9-10900K in second batch ( Nanhu / South Lake / 南湖) in fall 2021, with 14nm process, both manufactured by TSMC, and it already run GNU/Linux distribution Debian. See also(中文).

Another Virtual Machine emulator for RISC-V is JuiceVM supporting RV64IMASU. It is lightweight, support small UART serial I/O and MMU

Available RISC-V Hardware in June 2021

Several developers have received a first beta version of BeagleV RISC-V board. Here are demos (on youtube sadly) of first tries of different devs at beginning of may "BeagleV RISC-V Computer (Beta)" (unboxing), "BeagleV from BeagleBoard.org Fedora image Live Booting - 1" (booting), now BeagleV give a prepared Fedora with XFCE working on HDMI.


I have now 2 embedded microcontroller oriented RISC-V Board from Sipeed, one 32bits and one MaixDuino SipeedM1 (microPython (by default), dual-core 64bits+AI module) of the young hackers, Shenzhen based, SiPeed company. The last one support lot of embedded systems including default MicroPython based MaixDuino system (and cool plateforrm.io interface, Arduino, PlatformIO, microPython, OpenMV, FreeRTOS, et TensorFlow, etc..

The Nezha board of SiPeed, is a bit more expansive and with lower specs in first version, but very promising for the future Nezha: Your first RV64 Linux SBC for IoT~ (video Youtube).

Huawei Hi3861 is oriented toward their LiteOS kernel that is used in their new Android compatible HarmonyOS.

The BL602/BL604 de Bouffalo Lab (RISC-V WiFi & Bluetooth 5.0 LE) based on ESP32-C (RISC-V variant of ESP32, pin2pin compatible) is a 100 % open source BootLoader & driver (no blob needed), thanks to the work of Lup Yuen Lee (李立源). He wrote lot of interesting articles about the process of making the driver and a book about this chip, and several article around Ecosystem, including using Rust, How to simulate it in WebAssembly, etc.

China Science Academy is currently working on optimizing Firefox (SpiderMonkey) and Chrome/ium (Webkit) engines for RISC-V 2000 laptops with equivalent power of a Cartex-A78 should be available at then end of 2022

At the same time the port of true GNU/Linux on embedded devices like phones progress fast, on ARM architecture, with specialized distributions like PostMarket OS (and it's derivative Alpine Linux), or more general distributions, including Debian, Manjaro (ArchLinux derivative) etc. Port of KDE Plasma and GTK4/GNOME40 (especially GTK4.1+ with very efficient OpenGL acceleration, are of great help in this area. PinePhone from Pine64.org community is really an active and efficient hub for these ports. This phone (developer oriented in current state) is at the same time cheap (<200€) have hard switch for all network features, and every part can be easily changed. Those project are all ready to be ported on RISC-V versions of this kind of devices. Pine64 is already working on RISC-V opensource bl602 driver (see above) and a RISC-V (GD32VF103TB) running a smart/programmable iron solderer, and a future RISC-V based mother board to replace the current ARM one on the PinePhone could be totally realistic. See also LINux on MOBile for news on the port of Linux on Mobile devices.

An interesting post (and blog) about RISC-V assembly programming from Stephen Marz, another blog about RISC-V assembly from Daniel Mangun and one from ieee.org Build a RISC-V CPU From Scratch. A simple HelloWorld example, with deep explanations, including Linux RISC-V Application Binary Interface (ABI), to start with RISC-V assembly, based on GNU Assembler (support RV32 & RV64). There is also a Python made, limited, RISC-V assembler. A complete tutorial in French for starting with the Sipeed Longan Nano, (available for ~5 € with LCD screen).

Update: see also the very interesting Bronzebeard assembler + bare-metal environment in a newer arcticle. And an article about bare-metal RISC-V Development with the GD32VF103CB.

HTML5 RISC-V Interpreter/simulator. There is also RARS a really slow/unusable Java RISC-V simulator (pacaur -S rars), jupiter (with link to other simulators) (pacaur -S jupiter) is another one, and spike (pacman -S spike) is a c made simulator. Ripes (pacaur -S ripes-git) is a very advanced one, with multiple level of pipe, data/instruction cache states, etc... Venus with online simulator in Kotlin language.

Tutorial serie about designing RISC-V processor in VHDL.

I hope that with progress I made in real-time programming and different new programming languages in last few years (Lua, some bit of RISC-V assembly, JavaScript), I will make quickly some RISC-V demo on embedded board.