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 and Newer Radxa Images

Hardware

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.

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.

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

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

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:

• "The ROCK Pi S can be powered from the PC/Laptop USB ports directly"
• "If you want to power ROCK Pi S standalone, you can use 5V/1A or 5V/2A power adapter with USB C ports."

A "standard" computer USB 2.0 Type-A port should provide a minimum of 0.5A (2.5 W) and a USB 3 port should provide a minimum of 0.9A (4.5 W). Assuming a USB-C connector on the PC/laptop is a version 3.X USB port, it seems that the ROCK Pi S needs from 0.9A to 2A (4.5 W to 10 W). That seems like quite a range. It does make sense because 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, I am using a good tablet power supply providing 1.35A at 5.2V. Just to prove the point, the Rock Pi S does not work properly if a 1 meter USB cable is replaced with a 3 meter cable by the same manufacturer.

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

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:

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.

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.

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

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.

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

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.

• Radxa Rock Pi S Wiki and Rock Pi S Community (forum)
• Igor Pecovnik and Community Armbian Distributions and forum
• Athanasios (Thanassis) Tsiodras Rock PI S - an RK3308 based SBC
• Alex Goldcheidt Rock Pi S 512 MB RAM SBC and Rock Pi S + WiFi Access Point
• t2age RPS, Little RockPI S Single Board Compute[r]

• Timm Murray The Rock Pi S Review
• Mauro Riva Rock Pi S: a tinier version of the Raspberry Pi with Alexa functionalities
• Darmur Experimental setup: RockPi S + Vacuum Tube Hybrid Headphone Amplifier

Which Distribution?

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.

• Official Images on the Radxa downloads page
  • Debian Buster rockpis_buster_minimal_arm64_20200809_0853-gpt.img
  • Ubuntu Bionic rockpis_ubuntu_bionic_minimal_arm64_20200809_0856-gpt.img
• ROCK Pi boards images in the Radxa GitHub repository
  • Debian Buster rockpis_buster_server_arm64_20210126_0109-gpt.img
  • Ubuntu Bionic rockpis_ubuntu_bionic_server_arm64_20210126_0114-gpt.img
• Armbian Rockpi S Recommended Downloads
  • Armbian Buster Current Armbian_21.02.1_Rockpi-s_buster_current_5.10.12_minimal.img
  • Armbian Buster Legacy Armbian_21.02.1_Rockpi-s_buster_legacy_4.4.247_minimal.img
  • Armbian Focal Current Armbian_21.02.1_Rockpi-s_focal_current_5.10.12_minimal.img
  • Armbian Focal Legacy Armbian_21.02.1_Rockpi-s_focal_legacy_4.4.247_minimal.img

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

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.

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

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 guides are out of date.

First Boot

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.

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

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:

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.

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.

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

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

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

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

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

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!

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.

Simply add the line

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

System Update and Upgrades

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.

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

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

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.

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.

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.

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

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,

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

which is already in place:

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

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.

• Two Wi-Fi interfaces are created, the usual wlan0 and a second p2p0 whose purpose escapes me. It was rather disconcerting that sometimes the wireless network connected to the wlan0 interface and sometimes to the p2p0 interface in what seemed to be a random fashion.
• Furthermore the MAC address of the Wi-Fi interfaces would be different with each reboot.

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:"

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.

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.

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

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

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

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

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

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.

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

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.

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.

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.

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.

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:

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

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.

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:

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.

with

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.

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.

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

Current Armbian Distributions and Newer Radxa Images

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.

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.