Assorted resources about the Allwinner Nezha D1 RISC-V development board

Some useful links

• Allwinner documentation
• sunxi wiki: Allwinner Nezha page
• sunxi wiki: D1 page
• RVBoards D1 demos
• RVBoards D1 documentation (source)
• riscv.org devboard-community mailing list
• D1 40-pin header pin-out label
• Fedora RISC-V wiki pages: D1-specific information, generic installation guide
• Tiny FEL tools for Allwinner SoC
• D1 buildroot for Docker containers
• OpenixCard free software for Allwinner PhoenixCard images
• Source code of this page

Hardware

Power supply

Robert Lipe explains why Apple hardware and Nezha D1 do not work together using a USB-C to USB-C cable. It should be possible to work around the problem using the USB-A to USB-C cable(s) supplied with the board.

SPI NAND layout

Kernel 5.4.61 (as reported by Gabe R):

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00040000 "boot0"
mtd1: 00400000 00040000 "uboot"
mtd2: 00100000 00040000 "secure_storage"
mtd3: 0fa00000 00040000 "sys"

In this thread Samuel Holland notes that this partitioning is an effect of Allwinner firmware, which is not compatible with upstream Linux.

Kernel 5.16.0-rc2:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 10000000 00020000 "spi0.0"

The same stands for kernels in the Ubuntu 22.04 image below.

Serial console

The USB serial adapter that comes with the board connects to the 3-pin "DEBUG" header on the board as follows:

• black—GND pin
• green—RX pin
• white—TX pin
• red—do not connect

Peter Gutmann notes that the supplied serial cable can be faulty. If this is the case, it needs to be replaced with a serial adapter that uses 3.3V levels.

RGB LED

With kernel 5.16.0 (which is available in some disk images and does not boot by default) it is possible to control the RGB LED of the board, which is labelled "LED" and sits next to the red "PWR" LED:

LED=/sys/class/leds/rgb:indicator
echo 0 50 50 >"$LED"/multi_intensity
echo mmc0 >"$LED"/trigger

The same stands for kernels in the Ubuntu 22.04 image below.

Temperature sensor

Some kernels (at least those in Ubuntu 22.04 disk image) support the temperature sensor built into the board/chip:

# sensors
cpu_thermal-virtual-0
Adapter: Virtual device
temp1:        +32.2°C  (crit = +110.0°C)

Some files (may be mirrored, or not)

Notes

5

By Gary E. Miller.

6

As published on Fedora RISC-V wiki and openkoji service of Institute of Software, Chinese Academy of Sciences.

7

The Linux kernel in this disk image does not auto-detect the RAM size, but uses a hard-coded size from a DeviceTree file. Each boot menu item has its own DeviceTree file, and the default boot menu item (1) stands for 2 GB:

Fedora-riscv64-d1-developer-xfce-with-esp-Rawhide-20210912.n.0 Boot Options.
1:      Fedora-riscv64-d1-developer-xfce-with-esp-Rawhide (5.4.61+ 2G)
2:      Fedora-riscv64-d1-developer-xfce-with-esp-Rawhide (5.4.61+ 1G)
3:      Fedora-riscv64-d1-developer-xfce-with-esp-Rawhide (5.4.61+ 512M)
4:      Fedora-riscv64-d1-developer-xfce-with-esp-Rawhide (5.4.61+ 128M)
Enter choice: 1:        Fedora-riscv64-d1-developer-xfce-with-esp-Rawhide (5.4.61+ 2G)
[...]
Retrieving file: /aw_nezha_d1_2G.dtb

If you try to use more RAM than the D1 board actually has, it will sooner or later crash. The following commands can be used to change the default to 1 GB:

# For the 2021-09-12 revision:
echo 'default Fedora-riscv64-d1-developer-xfce-with-esp-Rawhide (5.4.61+ 1G)' >>/boot/extlinux/extlinux.conf

# For the 2021-11-30 revision:
echo 'default Fedora-riscv64-d1-developer-xfce-with-esp-Rawhide (5.4.16.riscv64.fc33.riscv64 1G)' >>/boot/extlinux/extlinux.conf

# For the 2022-01-17 revision:
echo 'default Fedora-riscv64-d1-developer-xfce-with-esp-Rawhide (kernel-5.4.61 HDMI 1080p 1G RAM)' >>/boot/extlinux/extlinux.conf

8

To boot the latest kernel, this image requires booting through GRUB. This can be done manually during the boot sequence as follows:

[...]
Importing environment from mmc0 ...
Autoboot in 2 seconds  <---------------------------------- press "v"
[Nezha]#
[Nezha]# run boot_grub
4681728 bytes read in 808 ms (5.5 MiB/s)
Scanning disk mmc@4020000.blk...
Scanning disk mmc@4021000.blk...
Disk mmc@4021000.blk not ready
Found 4 disks
No EFI system partition
Booting /\EFI\fedora\grubriscv64.efi
Welcome to GRUB!
[...]

The following command can be used after booting to have U-Boot load GRUB by default:

echo 'bootcmd=run boot_grub' >>/boot/boot/uEnv.txt

9

When booting the latest kernel from this image, it will use the RAM size provided by U-Boot, not the RAM size in DeviceTree files. However, U-Boot in this image has the RAM size hard-coded to 2GB, so to work with the latest kernel on D1-1GB this image requires to replace the bootloader with a custom version (provided by Fu Wei):

dd if=fedora-2021-11-30_D1-1GB_bootloader.bin bs=512 seek=32800 of=/dev/mmcblk0

10

All files hosted here are stored as ZIP archives, so if the original file is not a ZIP archive, the mirror copy has an extra ZIP container around it. This way, a .zip file is stored as is, but a .raw.zst file becomes a .raw.zst.zip file, the "Packed Size" column refers to the .raw.zst file and the "Unpacked Size" column refers to the .raw file, and so on.

11

In this image U-boot is hard-coded to 2GB RAM and there is no replacement version as of time of this writing. Also kernel 5.4.61 does not detect the MTD. Also GRUB defaults to the 2GB RAM menu entry and uses incorrect DeviceTree file paths. The error messages about the paths can be squelched using the commands below:

sed --in-place=.orig 's/\/dtbs\/5.16.0+\//\/5.16.0-rc2+\//g' /boot/grub.cfg
# 0 is the default (2GB), 1 is 1GB
sed --in-place 's/^set default=0/set default=1/' /boot/grub.cfg

However, kernel 5.16.0 in this disk image disregards DeviceTree data anyway and boots assuming 2GB RAM (possibly using the memory size from U-boot). In all likelihood this disk image cannot boot kernel 5.16.0 on D1-1GB.

13

The file is available for download here, additional information is available here.

14

This image by default omits much of the boot progress from the serial console (Ubuntu bug 1994072). Clang 14 package was broken (Ubuntu bug 1994071), but has been fixed now. Updating the GRUB packages makes the system unbootable (Ubuntu bug 2011744), which can be worked around as follows:

dpkg --set-selections <<EOF
grub-common hold
grub-efi-riscv64-bin hold
grub-efi-riscv64 hold
grub2-common hold
u-boot-nezha hold
EOF