[230315] System Release Notice for ROCK 4 family

Greetings. Today we are happy to announce the new system release for our ROCK 4 family. The new system was in development for almost a year, and represents some significant changes to our older systems. We believe this release marks the foundation for better quality software in the future, and we are very eager to share it with you.

TL;DR

  • Default account is now radxa/radxa
  • New KDE desktop
  • rsetup to manage overlays and more

New build system

The most notable change to this new image release is that they are built with a new set of tools. At the center is rbuild Radxa image builder. Compared to our previous build script, rbuild provides higher level of system abstraction, allowing us to deliver a unified experience across our products. Any improvements or bug fixes are applied across the entire portfolio by default, so our developers can work on a known environment to speed up feature delivery.

Additionally, we try to eliminate local non-tracable builds. From source codes to the final image, everything is performed by GitHub Workflows. With exceptions of some vendor pre-built packages, we are fully open about our software stacks.

We also mandate change log and version tagging as part of the release process, so we can better track the improvements and regressions with our development process.

Those may not affect you directly, but with improved infrastructure, we hope to deliver higher quality code that can benefit everyone.

New Desktop Environment — KDE

With this release we also switched our default desktop to KDE. KDE is a fully featured desktop environment, with a modern look and a tightly integrated app ecosystem. We hope this switch can provide you a familiar control, comparable to your tried and true desktop.

For our more resource limited products, we still provide Xfce desktop as a lighter alternative. There is also a CLI version for advanced users to customize you own system. Vendor packages are not preinstalled in our CLI version.

New system configuration tool — rsetup

For many of you that come from Windows, using Linux is a big enough challenge already. Running command line stuff? “That’s Greek to me!” To be clear, here in Radxa, our work language is Chinese, although that doesn’t seem to make those tasks less daunting.

As part of our new system, we included a new system configuration tool called rsetup. This tool is tightly integrated into our build system and pulls multiple duties, and one of them is to provide a system configuration interface for tasks not available in desktop environment’s settings app.

The most notable feature of rsetup is managing overlays. Various hardware interfaces can only be enabled with overlays, which is a key selling point for using an ARM-based single board computer compared to something x86-based. We created a separate overlays repository to foster faster development cycle, and we also added custom metadata to annotate shipped overlays. The result is an intuitive list for user to choose from, instead of deciphering various file names that may or may not indicate what they are doing.

Another common request is controlling the LED. You guys love to run our products in the bedrooms, but the bright LEDs are annoying at night. We used to recommend tapes for that problem, but now we have a more environmental friendly solution, that also persists across boot.

The initially released feature set of rsetup is limited, but we hope to discover more possibilities along with you.

First-boot configuration

To allow persistent settings to work, rsetup implements an on-boot service to reapply them every time the system is booted. We also take advantage of this service to defer some default configurations till the first boot, so you could make some changes to it.

Currently the persistent settings and the first boot script are saved at the first partition of the image, properly named as config partition. The old boot partition was merged into the main rootfs partition, so we can properly update the kernel via apt upgrade.

Old on-disk partition layout:

Partition Size Mount point File system
boot first 512M /boot FAT32
rootfs rest of the disk / ext4

New on-disk partition layout:

Partition Size Mount point File system
config first 16M /config FAT
rootfs rest of the disk / ext4

The config partition is formatted in FAT, so it can be accessed by all major operating systems. The default first boot script can be viewed here, which creates the default account and disables some services among other things. The default account is changed to radxa to better represent our diverse products. The services are disabled because our default account uses a weak password. If you want to enable SSH on boot, please also remember to change the default password after you log in.

Download

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

ROCK 4SE: 20230312-1521 Build 33

ROCK 4C+: 20230312-1521 Build 55

The following systems are built using the same code base as above releases, but have not been extensively tested by Radxa. As such, they are provided as testing images:

ROCK 4A: 20230314-1317 Build 11

ROCK 4A+: 20230314-1308 Build 10

ROCK 4B: 20230314-1307 Build 28

ROCK 4B+: 20230314-1328 Build 17

ROCK 4C: 20230314-1308 Build 22

More build variants can be found at radxa-build.

Kernel version: 5.10.110-1

Known issues

  • Ubuntu variants is not bootable. (Ubuntu is not currently supported by Radxa.)
  • When MIPI-DSI display is enabled, HDMI will have DSI’s output shown on top. Fix: run sudo rm /etc/X11/xorg.conf.d/10-monitor.conf and reboot.
  • When MIPI-DSI display is enabled and HDMI is set to 4K 60p, display artifacts may occur. Workaround: reduce HDMI to 4K 30p, as 4K 60p+DSI is beyond hardware spec.
  • ROCK 4SE only: when system is suspended, it cannot be wake up via the USB OTG port.
  • ROCK 4C+ only: some monitors are incompatible with the 2K HDMI port. Workaround: use 4K HDMI port instead.
5 Likes

Thanks for information and all hard work,

I quickly reviewed some downloads and few things are unclear.

  1. there is no information about ubuntu not working now. It should not be included in builds for now if it fails to start, no info at front page or release page and everything else seems to be generic.
  2. no information about kernel version - I could not find that in any of releases or readme, also no information how to add/recompile kernel.
  3. nothing about whole purpose of those builds, as You know more build systems were used, I don’t know there if this one is recent, official and what is it’s status.
  4. there are also Armbian edge builds - why not just link to armbian if those are not tested, not changed and not signed, not supported? It takes most of release page and on readme there is information to rather use official their releases.
  5. Of course I am interested in CLI builds - and there are some cli build there, for armbian probably called minimal. I would like to install those on nvme, probably there is some information on wiki how to do that (or rather if someone already tried that), but not here, there should be something about about burning images, bootloader, spi there, even link to right thing on wiki.
  6. docs are generic, so from Rock 4b points to all rock4 sbcs, that is confusing
  7. support via wiki, forum, discord. Last one is not working for me (I can;t get to this particular channel), not indexable. What about github itself? where You should report that broken ubuntu image if You get into that trap?
  8. is rsetup different project or variant for particular board?
  9. If something is needed from kernel, what You should do?
1 Like

Congratulations @RadxaYuntian and the team for this milestone!

May I ask why the partition layout change has been made?

For the update process of our product, we rely on a separate boot partition. Are there informations available on how U-Boot selects the boot partition? Does it just look for the first partition with a boot flag and the content on the /boot folder?

Do you guys create the Armbian images? I got the image from the link below:

Ubuntu issue is mentioned in this release note. Currently the Wiki Download page is being maintained with the current info (ex. the release download links were updated). I’ll need to think about what to do with GitHub release page though.

It is currently running this kernel. We currently do not offer alternative kernel on this platform, and I’m waiting for our documentation site to go online to add guide for bsp which is the kernel/bootloader build script.

This was actually due to in the past Armbian removed downloadable images for many of our products, citing no official maintainer. We created those as an alternative to build manually. Since then they have resumed the image generation.

Ultimately many issues are due to GitHub release page is not end-user friendly. This is currently blocked by our new documentation site. I’m waiting for it to be online so I can work on the new documentations and link them on GitHub.

Discord try https://rock.sh/go? I saw new members today. GitHub issues is also valid option. They are enabled on the image repos.

rsetup is a configuration tool similar to raspi-config or armbian-config. Although in our implementations it does more than that. I’m considering about breaking it into several projects to make it more manageable.

Can you be more specific about this and give an example?

The old partition layout put /boot in a FAT32 partition, which will cause issue when trying to update kernel, or installing a kernel with the same version (happen frequently during development). This is because dpkg expect the file system to support symbolic link, which is not the case on FAT32.

It has a predefined boot media order (mmc1 mmc0 nvme0 usb0 pxe dhcp sf0), and lists all bootable partitions in a given boot media, then it tries the following methods to boot: extlinux.conf/boot.scr/EFI executable.

You can find the exact boot logic in U-Boot console with command env print -a. The entry point is bootcmd variable.

1 Like

We build Armbian images because in the past downloadable images were not available for many of our products. Now Armbian provides rolling images for our products we suggest you to use those.

That is what I’m saying - I could find this information only here. Most users will go for recommended link, which is for example this one https://github.com/radxa-build/rock-4se/releases/latest and they will not notice that half of images are broken. Alse there is no clear way to report that, get some support, forums/discord is not right place and issues tab on github may be not best place if there are so many projects.
I know this is complex project and require hard work to deliver everything but with this release it just was multiplied with many places, most with automatic information which don’t help, and missing so important one.

OK, kernel information is just very important and now it’s missing. I expected it will be still 4.x and I don;t know much now about this one when it’s important to know what You can expect. This will save users from trying to run things that are just not supported. I know that there is no NPU for 3399 (except pro of course) but for now we know that those are not working on anything except legacy, Here for sure there are other features that are tested and supported and know to work or not. For now this information is just missing.

We talked about that with @jack and for now it’s just not working for me. Other channels are ok, this one worked for some time and now I have error trying to rejoin. @tkaiser is right about this - discord is just great, modern IRC replacement for free talks but not for any support or knowledge base. As You can see it may just not work as well as whole server could be deleted without notice.
Github is much better, but for now there are so many projects, variants etc. that You can be easily lost. I expect that most of issues will be same for whole family and now You can’t find that on particular board and for support there is information to use wiki/forum/discord and not github which has empty issues tab.
I’m just trying to say that it’s not intuitive now, most information is automatic (and not accurate), some important are missing, and no clear good place to report issue.

Armbian has its own sins about that,
but I just don’t think that building some snapshots of their sources is helping. I would just mirror some of their official (and signed) images, maybe with fixed main versions. I know that today it’s easy to do some workflows to build something but for now there is no value added to those and for armbian they are unofficial/not supported/containing backdoors. Real Armbian advantage lays in build system that can be customized and tweaked for own needs so until there are changes that fixes something, adding some important stuff, making Armbian better with radxa point of view. If it’s just unofficial snapshot - then it’s no point of that.

I expect that there is more hard work to do about that including work on wiki, on older sites with deprecation notice etc. Hopefully it will be intuitive when it’s ready, that is why I’m commenting on that.

I expect that it’s tight integrated with radxa boards. Hopefully will make life easier for many users.
I did not yet tried it, but I hope it will have information about all firmwares/loaders on board as well as maybe some radxa hats and accessories (lcd, sata hats etc). I expect from that utility it will tell me about board updates and status of that.

Sure, for some usages You need particular kernel option and this leads sometimes to kernel recompilation. Let’s say for docker some specific things are needed, more for kubernetes. What is a path to get missing module/option to kernel?

That is why I asked why You are building those images. Today it’s super easy to to that via snap/docker/vm, also You can build particular revision if needed, but still there is no value added for those.
Armbian also releases broken images from time to time. Duplicating those with no support is just wrong way until You will try to solve any of those issues. Is raspberry building or even linking for any third party system? Are those snapshots even tested for basic first boot? I guess not…

This release still uses Rockchip kernel. They released their own take of 5.10 a while ago.

Thanks for the clarification!

Since I am not familiar with the U-Boot console, in which folders does U-Boot look for extlinux.conf? Only in /boot or also in /?

Ok, this is important information, what we can expect from this release?
Is there anything that works on 4.x and not working on 5.10?

This is defined in boot_prefixes variable, which is equal to / /boot. So U-Boot will search both /extlinux/extlinux.conf and /boot/extlinux/extlinux.conf for each bootable partition.

1 Like

Everything should work:

  • GPU (we use Mali driver so OpenGL-ES only)
  • CSI (Raspberry Pi Camera v1.3 and v2)
  • DSI (Raspberry Pi 7-Inch Touchscreen* and our Radxa 8HD Display)
  • Video decode (works with Chromium and Dragon player)

Let me know if there is anything missing.

Note: older Raspberry Pi scree uses a different touch panel. For this screen the touch is not working in either 4.4 or 5.10.

1 Like

Thanks! It is already working now with that information.

When will ubuntu server with kernel 5.x be released. The Armbian version is horrible and doesnt work well.

It is something we are working on. BTW is there any specific reason that Debian CLI image cannot suit your use case?

With this new release, which library should be used for GPIO control.
I’m assuming it is Gpiod as it is already installed. :blush:

I installed buster-cli version on my Rock4-se board.

I decided for some reason to install emacs. When doing so, it stopped with an error ‘/var/lib/dpkg/status’: No space left on device

Even since then I’ve had problems. I tried removing emacs… same message.

Now it regularly pops up. It even popped up when using the sudo apt autoremove command.

I’m now trying to fix but I am not sure how.

I tried df -i and have plenty of iFree space. Only this space shows 48%
/dev/mmcblk0p2 121440 58141 63299 48% /

Similarly df -h | grep tmpfs returns healthy results.

I then tried dpkg -l | grep linux-image | grep ii and this shows 2 kernel versions. Is this correct?

ii linux-image-5.10.110-1-rockchip 5.10.110-1-0a544b8c7 arm64 Linux kernel, version 5.10.110-1-rockchip
ii linux-image-rock-4se 5.10.110-1-71086bd all Radxa virtual Linux package for rock-4se

We recommend gpiod. We are also working on up-streaming our modifications on wiringX and mraa, so currently they are not available in our apt, and have to be installed from source.

This is expected result and the 2nd package is a meta package (I need to update the description). The idea is that you install the meta package, and when meta package upgrades, it pulls a different kernel package (note the name of the first package is linux-image-5.10.110-1-rockchip which contains the version number), so both old and new kernels can be installed on your system. This also gives us a human readable name for kernel package (you can tell what linux-image-rock-4se is for) to ease up installation process.

This is the same scheme Debian uses to manage its own kernels.

1 Like