[230331] System Release Notice for ROCK 3C & CM3S IO

#1

2023/04/21 update

We now added ROCK 3 Compute Module SODIMM IO Board (CM3S IO) to this release.

After testing the upcoming ROCK 3B with KDE desktop, we now decided to stay on Xfce desktop for RK356X based system due to performance concern. We have some improvement ideas that need to be tested.

Below is the original release notice written when only ROCK 3C was announced.

Greetings. Today we are happy to announce the initial system release for ROCK 3C.

Unlike our earlier ROCK 4 release, today’s release only covers a single device. This is because ROCK 3C is an entry level offering with only up to 2GB memory. As such, we are still using Xfce desktop on this product. Our plan for the rest of ROCK 3 family is to also release a KDE based system, just like ROCK 4.

Besides the desktop choice, this release is also built by our new rbuild tool, which means many of the same new features and improvements are also inherited in this image, even when compared to our old Xfce systems. You can read more about this new system here.

TL;DR

  • Default account is now radxa/radxa
  • rsetup to manage overlays and more
  • NEW SSH is now enabled when the first boot is headless
  • NEW Ubuntu CLI images are now bootable

We are listening

While this is not strictly related to ROCK 3C, we’d like to thanks all the feedbacks from our community members like @dominik. We know our first release won’t be perfect, but what matters is how we improve it in the long run, since we are here to stay. In this regards, any feedbacks help us to discover new potentials and possibilities, so we can deliver even better quality products, both hardware and software, back to our users.

One of such feedback is that SSH is disabled, unlike our earlier releases. This was an intentional decision, since our default user account uses a known weak password, so we don’t want our products to become an attack vector in it’s default configuration, especially when user is not aware of it. Think about Windows, by default, RDP is not enabled. Raspberry Pi also has SSH disabled, and the user has to make an explicit decision to turn it on. These are the reasons we decided to err on the safe side to disable the SSH by default. Just like Raspberry Pi, user can also manually edit files under our config partition to override this behavior.

However, unlike Raspberry Pi, we don’t have a dedicated image flasher to present this options nicely to the user. Our documentation is also lacking since so much focus has been put on to the problem solving side. The result is that for most users, this override might as well be non existent.

This is when we step back and rethink our approach. We still don’t like enabling SSH by default, but we also need to balance with usability. The most affected users are those who run our devices headlessly, as they are entirely relied on SSH to manage their devices.

We have reworked our first boot configuration script, which now will check if any displays is plugged. When no display is detected, it will assume the user is running headlessly, and enable SSH service. Both desktop and CLI images work the same way, since we want to reduce the surprise when users switch between different images, expecting SSH will be enabled under the same condition.

We also fixed Ubuntu CLI image booting issue. A few different issues are related to this, but they are resolved now. Desktop image is still problematic since the Rockchip kernel doesn’t play nicely with upstream unpatched packages. This is again why we currently do not officially support Ubuntu, and suggest our users to use Debian unless you have a special requirement.

Since both issues happened before user can log into the system, the only way to fix them for ROCK 4 will be a new image. Our build system create monthly images on first day of each month, so new test images for ROCK 4 should be available tomorrow or the day after (we have a long list of images that need to be built).

After 3C, our plan is to work on ROCK 5A. As we use the same kernel for ROCK 4 and ROCK 5, we are also looking to clean up some overlay issues when we release a new kernel.

Download

The following systems have been validated by Radxa for various use cases:

ROCK 3C: 20230330-0236 Build 31

CM3S IO: Build 24

More build variants can be found at radxa-build.

Kernel version: 4.19.193-1

Known issues

  • When booting with SPI+USB, only the USB 2 ports are supported.
  • When ROCK 3C is paired with macOS devices, 3C cannot enter suspend mode.
  • Ethernet’s MAC address will change when flashing a new system. It will NOT change if the device is rebooted.
  • Raspberry Pi Camera v1.3 and OKdo 5MP camera are currently missing image tuning profile. Raspberry Pi Camera v2 is thus recommended for now as we only have the profile for this camera. Additional profiles will be available in a future package update.
  • On-board Wi-Fi currently does not support WPA3.
  • ROCK 3C equipped with AzureWave AM-CM256SM Wireless module has no working Wi-Fi.
    Workaround: update the system via Ethernet first.
1 Like
[230428] System Release Notice for ROCK 3C
[230428] System Release Notice for ROCK 5A
Enable openssh-server and latest kernel in ubuntu image
#2

Great, thanks for all hard work, I’ll try new version when it comes to more board, like 3A.

Enabling SSH by default is good choice and makes setup little bit easier. Recently I found out that with ROCK 4 UART makes board not stable and cause kernel panics as well as some power issues (board not working on PD with it). That makes using those questionable so ssh into board without UART is yet again precious.

1 Like
#3
#4

Post is now completed. 3A should get a new image when we work on either CM3 or 3B.

#5

userID/pw of rock/rock does not work for Debian or Ubuntu.

Looks like the downloads page was updated sometime in the last day or so, and now it’s “radxa/radxa”.

Further, there is no wifi reported. I purchased a rock3c, which pretty clearly indicates wifi onboard, but there’s no adapter showing up, nor any connector on the board.

#6

Unable to connect to wifi.
command: nmcli dev wifi does not list anything.
When trying to connect using command: nmcli dev wifi connect I receive Error: no wi-fi device found.

#7

onboard wifi worked perfectly fine with previous debian 11, Ubuntu and Android. unfortunately these previous version I used had other major issues…

#8

Hi to All,

I’m new in the Radxa boards and software.
I bought Rock 3C with Wifi chip Azure on the board.

Unfortunatelly I can’t got it to work, as reported above " [IndicaChie]" also.

I’m doing something wrong?

Installed Debian11 from link above and used Wiki as manual, but nmcli dev wifi connect I receive Error: no wi-fi device found.

What’s wrong?

Can somebody help me?
Thx

#9

Hi Skopek,

Check the assets on the link below, wifi works fine however something causes ridiculously high CPU usage,

If you find anything better please let me know.

#10

Jeah, I flashed some older build yesterday and voila Wifi works! Ifconfig works also.

Thank you for advice.

#11

Hi @darrylhadfield, @IndicaChie, and @skopek,

When we worked on ROCK 3C, we were working with v1.3+ hardware, which uses Ampak AP6256. Versions before v1.3 were based on AzureWave AM-CM256SM instead. However, we were not aware that some of the early boards were already on the market, so they were untested.

We are currently looking into this issue.

Edit: updated firmware package is now available on apt repo. After installing the latest firmware the Wi-Fi should work again.

#12

Thanks @RadxaYuntian , but that still doesn’t address the lack of an onboard uFL connector for an external antenna.

#13

Further:

sudo apt-get install -y rockchip-overlay

results in:

radxa@rock-3c:~$ sudo apt-get install -y rockchip-overlay
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package rockchip-overlay

or must I flash the OS from scratch again? I’m not clear if “after installing the latest firmware” is inclusive of the OS, or if you mean the overlay.

#14

Currently we only have SKU with onboard antenna.

That package is no longer shipped since we use a new build system for our images. Just update you system normally with sudo apt update && sudo apt full-upgrade -y.

#15

Added CM3S IO release to this notice.

1 Like
#16

It would seem to make more sense to detect an INPUT (keyboard) rather than an OUTPUT (display) device in order to determine whether or not to enable SSH service. If there’s no keyboard device attached, how would a user enable SSH service from just a display?

#17

Here is this magic thing called touch display. You can pull up an on-screen keyboard and enable SSH without a physical keyboard. But I think you are missing the mark here. We are not here to find out which hardware connected (or not) gives the highest statistical possibility that the user also want to have SSH enabled. We just need to give the user a way to enable it. If it is intuitive, great! But editing a config file like what Raspberry Pi did is also acceptable, so it is not a hard requirement. Detecting if a monitor is connected is simpler than detecting a keyboard, so that’s why we chose it.

#18

That’s still INPUT, not just output! :rofl:

That makes a lot more sense, for a simple beginning.

Agreed! The config file is quick and relatively easy. Integrating with their OS flasher is even more user-friendly.