2021-02-12
md
Installing an OS on the Rock Pi S

The Rock Pi S model D4W purchased from Seeed Studio almost a year ago looked like a good fit for a project because of its Wi-Fi capability. As it turned out, setting up Wi-Fi with a static address on this very small single board computer turned into something of an obstacle course. To be fair, part of the difficulties were the result of stupid mistakes and in the end, the solutions is pretty simple. I hope this post will nevertheless be useful for some and that documenting the lessons learned, could mean never repeating those mistakes. Honestly, there's not much hope of that.

Table of contents

  1. Hardware
  2. Lessons Learned... Maybe
    1. Lesson 1 - Use a Proper Power Supply and SD Card
    2. Lesson 2 - Connect to the Serial Console
    3. Lesson 3 - Read the Documentation with Care and Caution
  3. Which Distribution?
  4. Current Radxa Debian/Ubuntu Distributions
    1. First Boot
    2. User Password
    3. System Update and Upgrades
    4. Random Wi-Fi MAC Address
    5. Wireless Network Interface
    6. Pesky Second Wi-Fi Interface
    7. Static IP Address
  5. Current Armbian Distributions

Hardware toc

The label on the plastic box containing the Rock Pi S (RPiS for short from now on) said that it was a mode D4W with 512MB RAM/4Gb NAND Flash. That was wrong as there is no Flash memory on that model (and the SeeedStudio product page says so). Here is a quick comparison of the Rock Pi S D4W with the Raspberry Pi 3 and the original Orange Pi Zero that are also contenders for that planned project.

Rock Pi S D4WRaspberry Pi 3Orange Pi Zero
SOCRK3308BCM 2837Allwinner H2+
CPUARM Cortex A35ARM Cortex A53ARM Cortex A7
Cores4 (64 bits)4 (64 bits)4 (32 bits)
Frequency1.3GHz1.2GHz1.2GHz
GPU---VideoCoreIV (400Mhz)Mali400 (600MHz)
RAM512MB1GB512MB
StorageMicroSDHC
SPI Flash------2MB
Ethernet10/100Mb
WiFi802.11 b/g/n
Bluetooth4.2 & 4.0 BLE4.1 & BLE---
USB141
USB OTG1---1
HDMI output---yes---
Composite video---yesyes
Camera connector---CSI---
GPIO2x26 pins40 pins26 pins, 13 pins
Dimensions44x44mm85.6x56.5mm46x48 mm

Not shown are prices, but nominally, the RPiS is considerably cheaper than the other two, although one has to look at shipping charges which do tend to represent a large proportion of the total cost for inexpensive items.

Aside from the transposition of the digits, what is the difference between the A35 and A53 Arm cores? I found this (The Arm Cortex-A35 in Comparison) succinct exposition.

The Cortex-A35 and Cortex-A53 share a lot of similarities, including the 64-bit Armv8-A architecture, an in-order, limited dual-issue architecture with an eight-stage pipeline. At the same clock speed the Cortex-A35 reaches 80%-100% of the performance of a Cortex-A53 depending on the workload; interestingly, it only consumes 68% of the available power when doing so.

This does indicate that the Rock Pi S may be up to the task I have in mind for it; but that remains to be tested.

Lessons Learned... Maybe toc

In the next section, a step-by-step description of how to set up the OS and the network is provided. It will look relatively simple and straightforward, but in actuality I struggled because information is not easy to find but also because of mistakes I made. Here are some of the lessons learned.

Lesson 1 - Use a Proper Power Supply and SD Card toc

Make sure to get a "proper power supply according to the board manufacturer requirements (basic usage example: 5V/2A with DC Jack barrel or thick USB cable)" (Armbian documentation - Prerequisistes for new users. The Armbian Forums are full of warnings about problems linked to inadequate power supplies. Despite all this information, I spent much too much time investigating network problems that had nothing to do with the network. The USB hub used to power the RPiS was just able to run the board under light load but it could not provide the power needed to run the Wi-Fi radio.

The Radxa documentation is a bit vague about the power requirements of the RPiS:

A "standard" USB 1.0 or 2.0 port provides about 0.5A. That seems like quite a range: from 0.5A to 2A. However that there are many models of the RPiS starting at the D2 with 256 MB of RAM, no Flash memory, no Wi-Fi/Bluetooh to the D4WPN8 with 512 MB of rams, 1GB of Flash memory, Wi-Fi/Bluetooth with obvious differences in power requirements.

The power supply for my "anemic" 7 port USB hub puts out a total of 1A at 5 volts, so it is surprising that the RPiS functioned at all, even if it was the only device connected to the hub. In retrospect, it would have been better had it not worked at all. Just because I was able to open SSH sessions over the wired Ethernet connection, I assumed that the power requirements were being met. One should never assume anything. As soon as I connected the RPiS to a decent 5V 1A power supply, all network problems disappeared. And currently, just to be safe as I test this system, I am using a good tablet power supply providing 1.35A at 5.2V.

There are many warning about SD cards on the Armbian Forums and documentation. I must admit to a good amount of luck in this regard even when buying cheap "no name" cards. I do try to check these when they arrive using the testing utilities F3 (in Linux, H2testw in Windows). See How to prepare a SD card?.

Lesson 2 - Connect to the Serial Console toc

When running a headless system, get a serial connection up. It is very difficult to debug network problems when connected to the system over that same network with SSH. As explained in the previous lesson, I thought there was a network problem when in actuality the power supply was inadequate. As soon as I connected a USB to TTL serial cable to the RPiS serial console, it was obvious that the system was resetting itself whenever an attempt at bringing up the wireless interface was made. Another advantage of the serial connection is that the whole boot process can be viewed.

The physical connection for the version 12 of the board is shown at right. Note that there is no Vcc connection with the USB-TTL converter; power is provided to the RPiS over the USB-C connection, properly as discussed above. Beside the connection, one needs to know the serial settings used:

baud: 1500000 data bits: 8 stop bit: 1 parity: none flow control: none

At 1.5 Mbits/sec, the serial port is unusually fast. The Wiki says that some USB-TTL converters cannot keep up with that speed. I encountered no problem with the very cheap CH-340 based converter shown in the image above. However, the terminal program Kermit (or more precisely ckermit found in Linux repositories) will not work at that speed. On the other hand, Python based terminal programs such as minimterm.py and minicom will communicate with the RPiS at the default rate. Unfortunately, these programs did not play well with the NetManager text user interface utility nmtui used to modify the network settings. As far I have ascertained, the curses library, which provides ANSI terminal support, is used by the utility and I quickly gave up trying to get minimterm.py and minicom to emulate such a terminal.

Luckily, the well-known screen terminal emulator can be used if the -U Tell screen to use UTF-8 encoding option is specified.

michel@hp:~$ screen /dev/ttyUSB0 1500000 -U

For casual use, screen, which is rather complex, is not my preferred tool. Very often, I find that I cannot reconnect with it because I detached the previous session instead of killing it. The screen -ls command is great help here. Instead, I much prefer to use cu (for Call up another system) which is decidedly lean and easy to use. I think it was installed by default in my desktop.

michel@hp:~$ sudo apt-cache policy cu cu: Installé : 1.07-24 Candidat : 1.07-24 Table de version : *** 1.07-24 500 500 http://mirror.csclub.uwaterloo.ca/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status

If not, presumably a simple sudo install cu -y will add the command to the system. The following will connect the desktop to the RPiS console.

michel@hp:~$ cu -l /dev/ttyUSB0 -s 1500000

To close the session, enter ~.. To view all commands enter ~?, but I never do that. Sometimes it helps to press the Enter key before entering an escape sequence starting with the tilde to ensure that the sequence is recognized.

Another good choice is picocom. It is small and works well.

michel@hp:~$ sudo apt install picocom ... 0 mis à jour, 1 nouvellement installés, 0 à enlever et 126 non mis à jour. Il est nécessaire de prendre 33,8 ko dans les archives. Après cette opération, 94,2 ko d'espace disque supplémentaires seront utilisés. ... michel@hp:~$ picocom /dev/ttyUSB0 -b 1500000 picocom v2.2 port is : /dev/ttyUSB0 ... Type [C-a] [C-h] to see available commands

The key combinations CtrlA, CtrlQ closes the session while CtrlA, CtrlH shows available commands.

In the above example it was assumed that the USB serial port is device ttyUSB0 which will usually be the case if the USB-TTL cable is the only connected USB serial device. Otherwise it will be easy to find the device using the ls /dev/tty* command while plugging and unplugging the USB-TTL converter.

There are a couple of references for the RPiS console in the Radxa Wiki: Serial Console, and UART.

Lesson 3 - Read the Documentation with Care and Caution toc

The Radxa Wiki and Armbian sites are the main sources of information on the RPiS as far as I can determine. The documentation found there should be read carefully. However this is not an easy task, the Wiki which is "... the documentation for ROCK Pi S, written by Radxa Team with community contributions" does reflect that it is an accretion of bits that has not benefitted from regular updating and editing to prune no longer accurate descriptions. For example, SSH Accesss and Option 3: SSH explicitly say that an SSH session can be opened with the ssh rock@rockpis.local command. I'll show below that this is not the case with the current stable Debian Buster distribution. Of course the Armbian site which is a forum is, almost by definition, something of a mess. With enough care and perseverance, gold nuggets can be found there.

So I think the real lesson here is RTFM but take nothing at face value. Well, that is a bit too drastic. Just don't assume everything is accurate.

Here are some articles or sites related to the RPiS that I found in my search on the Web that could be of interest.

Which Distribution? toc

Because my desktop and portable computers, the Raspberry Pi hosting the home automation system, and the other single board computers that I play with all have Debian based Linux distributions, I wanted to use something similar on the RPiS. There seems to be two flavours, Debian and Ubuntu (which is itself based on Debian), available from two sources: Radxa and Armbian. The relationship between these two distributions is not entirely clear to me.

DietPi supports the Rock Pi single board computers. Basically the site provides "lighweight justice" in the form of a stripped-down version of a single more or less current Armbian distribution for each supported board. In addition the site provides an extensive collection of install scripts for many applications. I have used a DietPi distribution on an early Raspberry Pi model to extend the life and usefulness of an old orphaned laser printer with the CUPS printing system. The installation of the OS and additional software was a straightforward albeit rather lengthy task. Consequently, Dietpi may be a good distribution for the RPiS especially for neophytes, but I have not tested it.

The Radxa downloads page has links to two other distributions: Slackware(Jan. 2021) and OpenWrt (Oct. 2020).

There's no point in putting direct links to each of these image files, as they are quickly replaced with newer versions. Just consult the download pages.

Current Radxa Debian/Ubuntu Distribution toc

Below I'll describe the installation of the latest Debian Buster server and Ubuntu Bionic server images by Radxa from the GitHub repository (files: rockpis_buster_server_arm64_20210126_0109-gpt.img.gz and rockpis_ubuntu_bionic_server_arm64_20210126_0114-gpt.img.gz). Here is what is in these images.

rock@rockpis:~$ uname -a Linux rockpis 4.4.143-61-rockchip-g1f77a85486f7 #1 SMP PREEMPT Mon Nov 16 15:05:11 UTC 2020 aarch64 GNU/Linux rock@rockpis:~$ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" rock@rockpis:~$ cat /etc/debian_version 10.7

The above is for the Debian distribution, below shows the same information for Ubuntu.

rock@rockpis:~$ rock@rockpis:~$ uname -a Linux rockpis 4.4.143-61-rockchip-g1f77a85486f7 #1 SMP PREEMPT Mon Nov 16 15:05:11 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux rock@rockpis:~$ cat /etc/os-release NAME="Ubuntu" VERSION="18.04 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic rock@rockpis:~$ cat /etc/debian_version buster/sid

Both distributions have the same Linux kernel. Furthermore, currently (Feb. 8 2021), these distributions are older than both the Legacy and current Armbian distributions. Both Radxa distributions are almost identical, the difference in what is discussed below are mostly cosmetic except for setting the system time zone.

The Getting started Wiki page gives some instructions on using Balena Etcher on copying the image to an SD card. It's already out of date, I have version 1.5.113 on my Linux box while the Wiki is talking about version 1.4.5. Nevertheless, the instructions on the Wiki are mostly accurate. There are plenty of sites that describe this operation if trouble is encountered.

The main references for what follows are Work with ROCK Pi S Debian and Work with ROCK Pi S Ubuntu. However be sure to follow up on every link found in that page and be aware that those guide is out of date.

First Boot toc

To boot the RPiS for the first time

  1. put the SD card with the freshly burned OS image in RPiS SD card reader,
  2. (optional) connect an Ethernet cable to the RPiS and the local network,
  3. (optional) connect the USB-TTL cable from the desktop to the RPiS console port and start a terminal program such as cu,
  4. (optional) connect an antenna to the miniature (IPEX/U.FL) RF connector
  5. then connect the RPiS to a proper power supply.

While the Ethernet and USB-TTL connections are shown as optional, at least one of them will be needed. If using the serial connection then many, many boot messages will be displayed in very rapid succession in the terminal as the RPiS boots. Wait until you see something like this.

... [ 10.774981] EXT4-fs (mmcblk0p2): resized filesystem to 1933068 [ OK ] Started Resize root filesy…m to fit available disk space. Debian GNU/Linux 10 rockpis ttyS0 rockpis login: rock Password: rock not shown on screen! Linux rockpis 4.4.143-61-rockchip-g1f77a85486f7 #1 SMP PREEMPT Mon Nov 16 15:05:11 UTC 2020 aarch64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.

The serial console is also the debug serial link, so what may seem like extraneous messages will be displayed in the session window.

rock@rockpis:~$ [ 358.063701] IPv6: ADDRCONF(NETDEV_UP): p2p0: link is not ready [ 358.073454] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

This can play havoc when typing in messages. You could just continue to type a command as if nothing happened, and then press the Enter key hoping that everything will be alright. It is also possible to press the CtrlC combination of keys to abort the command and to start over.

That was the Debian image. With the Ubuntu image the initial boot is almost identical:

[ OK ] Started Update UTMP about System Runlevel Changes. [ OK ] Started Resize root filesystem to fit available disk space. Ubuntu 18.04 LTS rockpis ttyS0 rockpis login: rockpis login: rock Password: rock not shown on screen! Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.4.143-61-rockchip-g1f77a85486f7 aarch64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage rock@rockpis:~$

Note how debug messages are not piped to the console in Ubuntu.

The next command confirms that the cabled Ethernet connection to the network is up, no matter which distribution is used.

rock@rockpis:~$ ip address ... 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether ce:17:9c:08:a8:3e brd ff:ff:ff:ff:ff:ff inet 192.168.1.150/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0 valid_lft 604271sec preferred_lft 604271sec inet6 2607:fea8:f1a0:d1d8::1e/128 scope global dynamic noprefixroute ... 3: wlan0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 52:75:9c:4c:47:bd brd ff:ff:ff:ff:ff:ff 4: p2p0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 56:27:16:ca:8b:51 brd ff:ff:ff:ff:ff:ff

I have shown in bold that an IPv4 address has been assigned to the Ethernet interface by the DHCP server. Knowing the IP address it will be easy to open an SSH session. But before, here is the proof that rockpis.local cannot be used to connect to the device by querying the Zeronconf system for the IP address assigned to the host name and by trying to find the host name given the IP address on the desktop.

michel@hp:~$ avahi-resolve -n rockpis.local Échec de la résolution du nom d'hôte « rockpis.local »  : Temps d'attente écoulé michel@hp:~$ avahi-resolve -a 192.168.1.150 Échec de la résolution de l'adresse « 192.168.1.150 »  : Temps d'attente écoulé

Since the IP address in now known, opening an SSH session is very simple.

michel@hp:~$ ssh rock@192.168.1.150
rock@192.168.1.150's password: rock not shown on screen! Linux rockpis 4.4.143-61-rockchip-g1f77a85486f7 #1 SMP PREEMPT Mon Nov 16 15:05:11 UTC 2020 aarch64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Fri Feb 5 01:07:55 2021 rock@rockpis:~$

The SSH login in Ubuntu is the same, the initial message is slightly different.

michel@hp:~$ ssh rock@192.168.1.150
rock@192.168.1.150's password: rock not shown on screen! Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.4.143-61-rockchip-g1f77a85486f7 aarch64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage

Since extraneous debug messages will not be displayed in that SSH session, I find it easier to use that type of session instead of the serial link. But the IP address assigned to the board is needed. There are at least two other ways of obtaining it without using the USB-TTL connection. One can look at the list of connected devices on the network router. Most routers do display such lists although they all have different ways of doing this. Another approach is to rely on a network mapping utility such as nmap in Linux or angryip in Windows. Again, numerous sites including my own have instructions on this topic.

User Password toc

No matter if using an SSH connection or the serial link, the first thing to do is to change the user password.

rock@rockpis:~$ passwd Changing password for rock. Current password: rock New password: xxxxxxxx whatever you want Retype new password: xxxxxxxx just make sure to remember it! passwd: password updated successfully

Again the important bits are the same in Ubuntu, but messagess are slightly different.

rock@rockpis:~$ passwd Changing password for rock. (current) UNIX password: rock Enter new UNIX password: xxxxxxxx whatever you want Retype new UNIX password: xxxxxxxx just make sure to remember it! passwd: password updated successfully

I think Vim is installed, but I prefer the simpler nano editor for dealing with configuration files. Before installing any package, it is necessary to update the list of packages available from all the repositories specified by the authors of the distribution. There are 25 of them in the Debian distribution, 34 in Ubuntu!

rock@rockpis:~$ sudo apt update ... rock@rockpis:~$ sudo apt install nano ... Need to get 541 kB of archives. After this operation, 2290 kB of additional disk space will be used. ... rock@rockpis:~$

Another thing that simplifies the configuration is to remove the need to enter the password each time the sudo is used to execute a command as a "super user" (i.e. root). This is best done with the visudo "editor" which will use nano (or vim if nano was not installed) to edit the file in a safe fashion by locking the sudoers file during the edit process and checking modifications before changing the file.

rock@rockpis:~$ sudo visudo

Simply add the line

rock ALL=(ALL) NOPASSWD:ALL

in the /etc/sudoers file. I like to add it just after the line beginning with %sudo.

System Update and Upgrades toc

The second thing to do is to upgrade the distribution. Do not forget to update before if this was not done in the previous step. Here is part of the dialog in Debian.

rock@rockpis:~$ sudo apt update; sudo apt upgrade -y ... 22 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 13.6 MB of archives. After this operation, 9216 B disk space will be freed. ...

Not shown above, the time zone had to be specified during the upgrade. That meant entering two numbers, the first identifying the region/continent

Configuring tzdata ------------------ Please select the geographic area in which you live. Subsequent configuration questions will narrow this down by presenting a list of cities, representing the time zones in which they are located. 1. Africa 4. Australia 7. Atlantic 10. Pacific 13. Etc 2. America 5. Arctic 8. Europe 11. SystemV 3. Antarctica 6. Asia 9. Indian 12. US Geographic area: 2

and the second a nearby city. Lists are provided for those numbers.

Please select the city or region corresponding to your time zone. 1. Adak 79. Juneau 2. Anchorage 80. Kentucky/Louisville 3. Anguilla 81. Kentucky/Monticello 4. Antigua 82. Kralendijk 5. Araguaina 83. La_Paz ... [More] ... Time zone: 65 Current default time zone: 'America/Halifax'

Those not in Atlantic Canada, will have to adjust those two values. After the upgrade, the Debian version was bumped up, but the version of the kernel remained unchanged.

rock@rockpis:~$ cat /etc/debian_version 10.8

In Ubuntu, the upgrade is somewhat different, as 19.5MB of additional disk space is used after 136 packages are upgraded. Notwithstanding the number of packages changed, the kernel remains the same as before, but the Ubuntu version number is bumped up to 18.04.5. The tzdata package is not include in the image or upgrade so the time zone is still not set in Ubuntu. It needs to be initiated manually after the upgrade.

rock@rockpis:~$ sudo apt install tzdata

As in Debian, the region and a nearby city will have to be specified.

One can check that the time zone is correctly set and change it if need be in the same fashion in both distributions. Below, I want to set the timezone for Nancy in eastern France. However, Nancy is not in the time zone database, so I used Paris to set the time zone which the same as the one in effect in the smaller city.

rock@rockpis:~$ timedatectl list-timezones | grep Nancy rock@rockpis:~$ timedatectl list-timezones | grep Paris Europe/Paris rock@rockpis:~$ sudo timedatectl set-timezone Europe/Paris rock@rockpis:~$ timedatectl Local time: Fri 2021-02-12 23:56:12 CET Universal time: Fri 2021-02-12 22:56:12 UTC RTC time: n/a Time zone: Europe/Paris (CET, +0100) System clock synchronized: yes systemd-timesyncd.service active: yes RTC in local TZ: no

I checked those specific upgrades mentioned in the Update necessary packages instructions.

PackageInstalledCandidate
rockchip-overlay2.82.8
resize-assistant0.20.2
rtl8723ds-firmware0.50.5
linux-4.4-rockpi-s-latest4.4.143-61-rockchip4.4.143-61-rockchip
rockchip-adbd0.60.6
rockpis-dtbonone4.4

I could not find a package named linux-4.4-rockpi-s-latest in the Ubuntu repositories but what looks to be the same file is installed under as slightly different name:
linux-4.4-rock-pi-s-latest: Installed: 4.4.143-61-rockchip Candidate: 4.4.143-61-rockchip Version table:

As can be seen, the first five packages are up to date. That leaves the ROCK Pi S compiled device tree overlays blob rockpis-dtbo. The update instructions in the Radxa Wiki, which are reproduced below,

DO NOT DO THIS $ sudo apt-get update $ sudo apt-get install -y rockchip-overlay $ sudo apt-get install -y linux-4.4-rockpis-latest (sic) rockpis-dtbo $ sudo apt-get install -y rtl8723ds-firmware rockchip-adb resize-assistant $ sudo apt-get install -y rockpis-dtbo # For those ROCK Pi S system images released before March 1st, 2020

are now contradictory. If followed step by step, the rockpis-dtbo package would have been added in the third instructions but the last instruction says to do that only if the distribution predates March 1, 2020. Given the more recent date of the installed distribution, I decided not to install the package.

This is a good place to mention that recommendations to update the U-Boot image are found on the Radxa Forum. Currently this is not necessary because in Debian and Ubuntu, the current version available is

rock@rockpis:~$ sudo apt-cache policy rockpis-rk-u-boot-latest rockpis-rk-u-boot-latest: Installed: (none) Candidate: 2017.09-02383-g233a23e3ed Version table: 2017.09-02383-g233a23e3ed 500 500 http://apt.radxa.com/buster-stable buster/main arm64 Packages

which is already in place:

U-Boot 2017.09-02383-g233a23e3ed (Nov 23 2020 - 01:51:25 +0000), Build: jenkins-linux-build-release-409

Being able to see this message is one of the advantages of using a serial connection over an SSH session which can only be active once the boot process is finished.

Random Wi-Fi MAC Address toc

Following to the letter the WIFI Connection instructions to enable the wireless network interface using the Net Manager command line utility nmcli worked... almost. I ran into two problems.

There may be valid reasons for random MAC address especially for mobile devices that get connected to various Wi-Fi hotspots as users go about their daily movements. Note that there is controversy about the usefulness of randomizing the address, but this is not germane to this post. The RPiS will act as a server connected to the local area network over Wi-Fi. It is important that the IP address of the server be static to make it easily reachable. Fixed IP addresses are allocated to devices by the network DHCP server on the basis of their MAC address. So here is how I ensured that the Wi-Fi interface MAC address remains fixed.

First I followed the advice in the Radxa forum entry Making wlan0 MAC address static/fixed by pitz, "I added something like the following into /boot/uEnv.txt to feed a specific MAC address of my choice:"

rock@rockpis:~$ sudo nano /boot/uEnv.txt
... extraargs=rtl8723ds.rtw_initmac="00:E0:4C:01:02:03"

changing the last three values to something unique. This is actually setting the MAC address of the Wi-Fi radio in the Realek chip which does not have a factory burned in address. So set the 48-bit MAC address to whatever you want, but the 3 leading bytes of the address do correspond to the manufacturer.

The device-specific configuration file 20-rock.conf needs to be modified.

rock@rockpis:~$ sudo nano /usr/lib/NetworkManager/conf.d/20-rock.conf
[device-mac-randomization] wifi.scan-rand-mac-address=no [connection-mac-randomization] wifi.cloned-mac-address=permanent

Instead of modifying the original file, the same content as shown above could be stored in /etc/NetworkManager/conf.d/20-rock.conf and it will take precedence over the original file (see NetworkManager.conf - NetworkMaager configuration file - not tested!)

Reboot and test that the MAC address is fixed.

rock@rockpis:~$ sudo reboot ... rock@rockpis:~$ ip a 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether ce:17:9c:08:a8:3e brd ff:ff:ff:ff:ff:ff ... 3: wlan0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:e0:4c:01:02:03 brd ff:ff:ff:ff:ff:ff 4: p2p0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 02:e0:4c:01:02:03 brd ff:ff:ff:ff:ff:ff

Success! By the way, it appears that the p2p0 IP MAC address is also fixed and the the same except for the first byte.

Wireless Network Interface toc

It is now possible to proceed with the original instructions for enabling the Wi-Fi interface with one change shown in bold below.

rock@rockpis:~$ sudo su root@rockpis:/home/rock# nmcli radio wifi on root@rockpis:/home/rock# nmcli dev wifi connect "network-ssid" password "network-password" ifname wlan0 adjust, of course!! ... [ 2678.330821] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 2685.999088] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Device 'wlan0' successfully activated with 'eed45b09-a55e-4fd4-9f6c-6391a380a63e'. root@rockpis:/home/rock# exit rock@rockpis:~$

The connection UUID will be different. This will create a Network Manager connection file.

root@rockpis:/home/rock# ls -l /etc/NetworkManager/system-connections/ total 4 -rw------- 1 root root 345 Feb 11 20:53 network-ssid.nmconnection

In Ubuntu, the .nmconnection extension is not used. At this point I restarted the system at least three different ways:

rock@rockpis:~$ sudo reboot ... rock@rockpis:~$ sudo shutdown now followed by turning the power to the RPiS off the on ... pressing the reset button nearest the USB-C connector of the RPiS

Each time I verified that the eth0 and wlan0 interfaces came up and that their MAC (ether) addresses remained the same.

rock@rockpis:~$ ip a ... 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether ce:17:9c:08:a8:3e brd ff:ff:ff:ff:ff:ff inet 192.168.1.150/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0 ... 3: wlan0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:e0:4c:01:02:03 brd ff:ff:ff:ff:ff:ff inet 192.168.1.190/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0 ... 4: p2p0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 02:e0:4c:01:02:03 brd ff:ff:ff:ff:ff:ff

Don't be in too much of a hurry to check after the system boots, it takes a few seconds for the Wi-Fi network to come up as seen by looking at kernel messages.

rock@rockpis:~$ dmesg ... [ 11.442511] rk_gmac-dwmac ff4e0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 17.993539] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 25.606311] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

Here we see that the wireless connection was established about 14 seconds after the wired conection.

Finally, I also verified that the Wi-Fi interface came up even when the Ethernet cable is not connected. This has been a problem in the past with some other devices.

Pesky Second Wi-Fi Interface toc

The second p2p0 interface for the same Wi-Fi card and for which I have no use remains in place and it is the cause of not ready messages every five minutes.

root@rockpis:/home/rock# dmesg | grep p2p0 [ 1308.051282] IPv6: ADDRCONF(NETDEV_UP): p2p0: link is not ready [ 1623.061345] IPv6: ADDRCONF(NETDEV_UP): p2p0: link is not ready [ 1938.065464] IPv6: ADDRCONF(NETDEV_UP): p2p0: link is not ready

If like me, you find this distracting even if it will not be visible except in log files and over the serial console (in Debian not Ubuntu), then the following addition to the Net Manager configuration file /etc/NetworkManager/NetworkManager.conf will eliminate the message. The idea is to disable management of the interface by Net Manager.

[keyfile] unmanaged-devices=interface-name:p2p0

I should mention that Ubuntu seems to give up on the p2p0 fairly quickly and the link is not ready messages stop. There's probably no harm in not letting Network Magager handle the interface.

This solution and another based on udev rules found in the Armbian forum entry Interface p2p0 is preferred over wlan0 how do I disable it? does not prevent the creation of the p2p0 interface which is something that I would have preferred. Try as I may, solutions touted in RTL8188EU usb dongle creates two interfaces and wifi-rt8723-pine64.conf would not work for me. From what I understand, I was supposed to create a module configuration file such as what follows.

rock@rockpis:~$ sudo nano /etc/modprobe.d/rtl8723ds.conf
options rtl8723ds if2name=p2p0 rtw_power_mgnt=0

As I said it did not work and there are good reasons that it should not have worked. The rtw_power_mgnt parameter sets power saving mode, which by default is 2 meaning maximum power saving is enabled. Putting it at 0 disables power saving altogether for the whole chip as far as I can make out reading How To Disable WiFi Power Saving On The Raspberry Pi. This is another instance where using the serial console is definitely a plus because the system messages where shown after modprobe commands as I interactively tested the proposed solution.

rock@rockpis:~$ sudo cat /sys/module/rtl8723ds/parameters/rtw_power_mgnt 2 rock@rockpis:~$ sudo modprobe -r rtl8723ds [ 107.728802] [ 107.728974] ======================================================= [ 107.729536] ==== Dislaunching Wi-Fi driver! (Powered by Rockchip) ==== [ 107.730120] ======================================================= [ 107.730682] Realtek 8723DS SDIO WiFi driver (Powered by Rockchip,Ver v5.6.5_31752.20181221_COEX20181130-2e2e) init. [ 107.943330] mmc2:mmc host rescan start! [ 107.943722] [WLAN_RFKILL]: rockchip_wifi_power: 0 [ 107.944172] [WLAN_RFKILL]: wifi shut off power. rock@rockpis:~$ sudo modprobe rtl8723ds if2name=test0 rtw_power_mgnt=0 [ 131.702030] [ 131.702242] ======================================================= [ 131.702814] ==== Launching Wi-Fi driver! (Powered by Rockchip) ==== [ 131.703377] ======================================================= [ 131.703939] Realtek 8723DS SDIO WiFi driver (Powered by Rockchip,Ver v5.6.5_31752.20181221_COEX20181130-2e2e) init. [ 131.704871] [WLAN_RFKILL]: rockchip_wifi_power: 1 [ 131.705298] [WLAN_RFKILL]: wifi turn on power. -1 [ 131.705721] mmc2:mmc host rescan start! [ 132.706397] [WLAN_RFKILL]: rockchip_wifi_get_oob_irq: Enter rock@rockpis:~$ [ 132.937754] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 133.265658] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 133.273960] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 133.301290] IPv6: ADDRCONF(NETDEV_UP): test0: link is not ready [ 133.302317] IPv6: ADDRCONF(NETDEV_UP): test0: link is not ready [ 133.307161] IPv6: ADDRCONF(NETDEV_UP): test0: link is not ready [ 133.460991] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 133.494100] IPv6: ADDRCONF(NETDEV_UP): test0: link is not ready rock@rockpis:~$ sudo cat /sys/module/rtl8723ds/parameters/rtw_power_mgnt 0 rock@rockpis:~$ ip a ... 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether ce:17:9c:08:a8:3e brd ff:ff:ff:ff:ff:ff inet 192.168.1.150/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0 ... 5: wlan0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 92:ff:c4:90:29:44 brd ff:ff:ff:ff:ff:ff 6: test0: mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether ae:53:2e:3f:d0:dd brd ff:ff:ff:ff:ff:ff

We can see that the power saving was disabled and that both Wi-Fi interfaces are created, with the twist that the second one was renamed test0. We can also see that the wlan0 interface has been assigned a new MAC address which explains why it is not automatically connected to the wireless network.

The Linux Wi-Fi module for the Realek RTL8723DS accepts many options:

rock@rockpis:~$ sudo modinfo rtl8723ds filename: /lib/modules/4.4.143-55-rockchip-g6b7accbc999b/kernel/drivers/net/wireless/rockchip_wlan/rtl8723ds/rtl8723ds.ko version: v5.6.5_31752.20181221_COEX20181130-2e2e author: Realtek Semiconductor Corp. description: Realtek Wireless Lan Driver license: GPL srcversion: B3770E4B053D3FD0B616B2D alias: sdio:c07v*d* alias: sdio:c*v024CdD724* alias: sdio:c*v024CdD723* depends: intree: Y vermagic: 4.4.143-55-rockchip-g6b7accbc999b SMP preempt mod_unload aarch64 parm: rtw_wireless_mode:int parm: rtw_ips_mode:The default IPS mode (int) parm: rtw_lps_level:The default LPS level (int) parm: rtw_lps_chk_by_tp:int parm: rtw_max_bss_cnt:int parm: rtw_usb_rxagg_mode:int parm: rtw_dynamic_agg_enable:int parm: rtw_drv_log_level:set log level when insert driver module, default log level is _DRV_INFO_ = 4 (uint) parm: rtw_mp_customer_str:Whether or not to enable customer str support on MP mode (uint) parm: rtw_tx_bw_mode:The max tx bw for 2.4G and 5G. format is the same as rtw_bw_mode (uint) parm: rtw_rx_ampdu_sz_limit_1ss:RX AMPDU size limit for 1SS link of each BW, 0xFF: no limitation (array of uint) parm: rtw_rx_ampdu_sz_limit_2ss:RX AMPDU size limit for 2SS link of each BW, 0xFF: no limitation (array of uint) parm: rtw_rx_ampdu_sz_limit_3ss:RX AMPDU size limit for 3SS link of each BW, 0xFF: no limitation (array of uint) parm: rtw_rx_ampdu_sz_limit_4ss:RX AMPDU size limit for 4SS link of each BW, 0xFF: no limitation (array of uint) parm: rtw_rf_config:int parm: rtw_country_code:The default country code (in alpha2) (charp) parm: rtw_channel_plan:The default chplan ID when rtw_alpha2 is not specified or valid (int) parm: rtw_excl_chs:exclusive channel array (array of uint) parm: rtw_btcoex_enable:BT co-existence on/off, 0:off, 1:on, 2:by efuse (int) parm: rtw_ant_num:Antenna number setting, 0:by efuse (int) parm: rtw_qos_opt_enable:int parm: ifname:The default name to allocate for first interface (charp) parm: if2name:The default name to allocate for second interface (charp) parm: rtw_wowlan_sta_mix_mode:int parm: rtw_pwrtrim_enable:int parm: rtw_initmac:charp parm: rtw_special_rf_path:int parm: rtw_chip_version:int parm: rtw_rfintfs:int parm: rtw_lbkmode:int parm: rtw_network_mode:int parm: rtw_channel:int parm: rtw_mp_mode:int parm: rtw_wmm_enable:int parm: rtw_vrtl_carrier_sense:int parm: rtw_vcs_type:int parm: rtw_busy_thresh:int parm: rtw_ht_enable:int parm: rtw_bw_mode:int parm: rtw_ampdu_enable:int parm: rtw_rx_stbc:int parm: rtw_rx_ampdu_amsdu:int parm: rtw_tx_ampdu_amsdu:int parm: rtw_lowrate_two_xmit:int parm: rtw_power_mgnt:iTheir onboard DHCP service can assign fixed IP addresses to devices based on their MAC address.ath:int parm: rtw_switch_usb_mode:int parm: rtw_enusbss:int parm: rtw_hwpdn_mode:int parm: rtw_hwpwrp_detect:int parm: rtw_hw_wps_pbc:int parm: rtw_check_hw_status:int parm: rtw_max_roaming_times:The max roaming times to try (uint) parm: rtw_mc2u_disable:int parm: rtw_notch_filter:0:Disable, 1:Enable, 2:Enable only for P2P (uint) parm: rtw_hiq_filter:0:allow all, 1:allow special, 2:deny all (uint) parm: rtw_adaptivity_en:0:disable, 1:enable (uint) parm: rtw_adaptivity_mode:0:normal, 1:carrier sense (uint) parm: rtw_adaptivity_th_l2h_ini:th_l2h_ini for Adaptivity (int) parm: rtw_adaptivity_th_edcca_hl_diff:th_edcca_hl_diff for Adaptivity (int) parm: rtw_amplifier_type_2g:BIT3:2G ext-PA, BIT4:2G ext-LNA (uint) parm: rtw_amplifier_type_5g:BIT6:5G ext-PA, BIT7:5G ext-LNA (uint) parm: rtw_RFE_type:default init value:64 (uint) parm: rtw_powertracking_type:default init value:64 (uint) parm: rtw_GLNA_type:default init value:0 (uint) parm: rtw_TxBBSwing_2G:default init value:0xFF (uint) parm: rtw_TxBBSwing_5G:default init value:0xFF (uint) parm: rtw_OffEfuseMask:default open Efuse Mask value:0 (uint) parm: rtw_FileMaskEfuse:default drv Mask Efuse value:0 (uint) parm: rtw_rxgain_offset_2g:default RF Gain 2G Offset value:0 (uint) parm: rtw_rxgain_offset_5gl:default RF Gain 5GL Offset value:0 (uint) parm: rtw_rxgain_offset_5gh:uint parm: rtw_rxgain_offset_5gm:default RF Gain 5GM Offset value:0 (uint) parm: rtw_pll_ref_clk_sel:force pll_ref_clk_sel, 0xF:use autoload value (uint) parm: rtw_tx_pwr_by_rate:0:Disable, 1:Enable, 2: Depend on efuse (int) parm: rtw_target_tx_pwr_2g_a:2.4G target tx power (unit:dBm) of RF path A for each rate section, should match the real calibrate power, -1: undefined (array of int) parm: rtw_target_tx_pwr_2g_b:2.4G target tx power (unit:dBm) of RF path B for each rate section, should match the real calibrate power, -1: undefined (array of int) parm: rtw_target_tx_pwr_2g_c:2.4G target tx power (unit:dBm) of RF path C for each rate section, should match the real calibrate power, -1: undefined (array of int) parm: rtw_target_tx_pwr_2g_d:2.4G target tx power (unit:dBm) of RF path D for each rate section, should match the real calibrate power, -1: undefined (array of int) parm: rtw_tsf_update_pause_factor:num of bcn intervals to stay TSF update pause status (int) parm: rtw_tsf_update_restore_factor:num of bcn intervals to stay TSF update restore status (int) parm: rtw_phy_file_path:The path of phy parameter (charp) parm: rtw_load_phy_file:PHY File Bit Map (int) parm: rtw_decrypt_phy_file:Enable Decrypt PHY File (int) parm: rtw_en_napi:int parm: rtw_en_gro:int parm: rtw_iqk_fw_offload:int parm: rtw_ch_switch_offload:int parm: rtw_wakeup_event:uint parm: rtw_suspend_type:uint

but I can find precious little information about them. It's above my pay scale to decipher the source code for the driver to try to figure it out. So this is the best I can do at this point. While this is disappointing, there is a silver lining. Perhaps there is the explanation for the latency of the WiFi interface of some single board computers that are part of my home automation system.

Static IP Address toc

The RPiS is to be used as a small server, so its network interfaces should have static IP addresses. This can be relatively easy to accomplish with many routers. Typically, they assign fixed IP addresses to a device based on its MAC address. So that's why all that effort was expended on setting a fixed MAC address for the Wi-Fi interface in the previous section.

My router has a rather small fixed IP address table, so it is almost always better that servers set their own IP address in a range of addresses set aside for that purpose. This is fairly easy to do with the Net Manager command line utility nmcli and a basic editor such as nemo.

First set the static IP address of the wired connection.

rock@rockpis:~$ sudo su root@rockpis:/home/rock# nmcli con add con-name "Wired" ifname eth0 type ethernet ip4 192.168.1.18/24 gw4 192.168.1.1 Connection 'Wired' (4291ff17-fca4-44cd-ae5e-a5619ab0f41a) successfully added. root@rockpis:/home/rock# nmcli con mod "Wired" ipv4.dns "9.9.9.9,8.8.8.8" root@rockpis:/home/rock# nmcli con up "Wired" Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/5) root@rockpis:/home/rock# nmcli con NAME UUID TYPE DEVICE network-ssid 3efbadbd-3922-4e65-b2f3-c5ffa18424b9 wifi wlan0 Wired 4291ff17-fca4-44cd-ae5e-a5619ab0f41a ethernet eth0 Wired connection 1 68c081c1-6a57-39b9-becf-044ace47df96 ethernet -- root@rockpis:/home/rock# nmcli con del 'Wired connection 1' Connection 'Wired connection 1' (68c081c1-6a57-39b9-becf-044ace47df96) successfully deleted.

If these commands are done in an SSH session, the link will be broken after the nmcli con up "Wired command. It will be necessary to open a new SSH session to continue.

Time to check the Ethernet IP address and that the interface is working by pinging the gateway and then a well know outside server which will exercise DNS:

root@rockpis:/home/rock# ip a ... 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether ce:17:9c:08:a8:3e brd ff:ff:ff:ff:ff:ff inet 192.168.1.18/24 brd 192.168.1.255 scope global noprefixroute eth0 valid_lft forever preferred_lft forever ... root@rockpis:/home/rock# ping -c 3 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.81 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=2.31 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.62 ms --- 192.168.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 5ms rtt min/avg/max/mdev = 1.623/1.913/2.309/0.294 ms root@rockpis:/home/rock# ping -c 3 bing.com PING bing.com(2620:1ec:c11::200 (2620:1ec:c11::200)) 56 data bytes 64 bytes from 2620:1ec:c11::200 (2620:1ec:c11::200): icmp_seq=1 ttl=51 time=53.8 ms 64 bytes from 2620:1ec:c11::200 (2620:1ec:c11::200): icmp_seq=2 ttl=51 time=45.2 ms 64 bytes from 2620:1ec:c11::200 (2620:1ec:c11::200): icmp_seq=3 ttl=51 time=40.6 ms --- bing.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 4ms rtt min/avg/max/mdev = 40.638/46.531/53.806/5.469 ms

One could try to do something similar for the wireless interface, but I think it's simpler to edit the wireless connection while looking at the content of Wired connection because only a small section needs to be changed.

root@rockpis:/home/rock# nano /etc/NetworkManager/system-connections/network-ssid.nmconnection
[ipv4] dns-search= method=auto

with

[ipv4] address1=192.168.1.19/24,192.168.1.1 dns=9.9.9.9;8.8.8.8; dns-search= method=manual

which is the same [ipv4] section from the Wired connection except for the difference in the interface static IP address highlighted in bold.

Of course the name of the Wi-Fi connection will be the true network SSID. Furthermore, there is no .nmconnection in Ubuntu. Time to reboot to test.

root@rockpis:/home/rock# reboot ... Debian GNU/Linux 10 rockpis ttyS0 rockpis login: rock Password: xxxxxx not shown on the screen Last login: Wed Feb 10 19:17:34 AST 2021 from 192.168.1.100 on pts/0 Linux rockpis 4.4.143-61-rockchip-g1f77a85486f7 #1 SMP PREEMPT Mon Nov 16 15:05:11 UTC 2020 aarch64 ... rock@rockpis:~$ ip a ... 2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether ce:17:9c:08:a8:3e brd ff:ff:ff:ff:ff:ff inet 192.168.1.18/24 brd 192.168.1.255 scope global noprefixroute eth0 ... 3: wlan0: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:e0:4c:01:02:03 brd ff:ff:ff:ff:ff:ff inet 192.168.1.19/24 brd 192.168.1.255 scope global noprefixroute wlan0 ... 4: p2p0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 02:e0:4c:01:02:03 brd ff:ff:ff:ff:ff:ff rock@rockpis:~$

Disconnect the Ethernet cable and repeat the ping tests to ensure that the wlan0 interface correctly. It may be necessary to try more than once until the system has adjusted to the absence of the wired connection.

If preferred, the Net Manager utility, nmtui, with a text-based user interface, could be used instead of nmcli. This is the command.

rock@rockpis:~$ sudo nmtui

Don't forget the sudo prefix or else all changes made will be lost.

Current Armbian Distributions toc

While going through the Armbian forum I came across the following entry by its chief architect:

What prevents you to use this kernel [5.8y]? 4.4.y is significantly lower quality and will be dropped and will not be supported any more the moment most of the features are here. 4.4.y is a private kernel which was frozen that board specific features were developed. Wireless driver was probably never updated while in modern kernel it was many times. Also the whole wifi / network sub system is much more recent.
Source: Igor Pecovnik in reply to Rockpi S Wifi Intermittent Stalls/Hanging

That convinced me to try these newer Armbian distributions. The report on these will be very short. I was not able to load them running into the following error during the boot process.

=> load ${devtype} ${devnum}:1 ${fdt_addr_r} ${prefix}dtb/${fdtfile} 51492 bytes read in 36 ms (1.4 MiB/s) => booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}; ## Loading init Ramdisk from Legacy Image at 04080000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 15300785 Bytes = 14.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree

This problem has been reported as bug AR-593, Rockpi S doesn't boot mainline kernel. According to the entry Igor fixed the problem on February 3 and it will be available in version 21.05. I'll wait until then.