Raspberry Pi 4, Rockchip RK3399 SBC’s get Arm SystemReady IR certification

The first hardware platforms getting Arm SystemReady IR certification for IoT Edge applications were announced a few months ago with namely NXP i.MX 8 Mini evaluation kit and Compulab IOT-GATE-IMX8 gateway being able to run off-the-shelf operating system images such as Fedora IoT, OpenSuSE Leap 15.3, and Debian 11 thanks to UEFI firmware.

But following PinePhone Pro Linux smartphone announcement, and Pine64 October update, we also learned that Rockchip RK3399 based RockPro64 was also Arm SystemReady IR certified, and check Arm’s website directly revealed it was joined by Lenovo Leez P710 “Gateway” SBC, as well as Raspberry Pi 4 and Pi 400 platforms. Let’s check the details and see what off-the-shelf images each board has been tested with.

RockPro64 RK3399 Arm SystemReady IR certification

Pine64 RockPro64 RK3399 SBC achieved SystemReady IR v1.0 Level 1 certification meaning it complies with some waivers and workarounds found in the errata document. The board has been successfully tested with Fedora IoT 34, Debian 11, Ubuntu Desktop 21.10 (dated August 20 2021), and openSUSE Tumbleweed Rescue CD Snapshot20210818. I assume the date is specified for Ubuntu Desktop 21.10 because it was made before the official release which happened this week. Installation is a bit more complicated than just flash an SD card image, and you’d need to build the UEFI firmware from scratch, or at least flash to a microSD card before booting ISO files.

Lenovo Leez P710 GatewayLenovo Leez P710 Gateway has the same certification level, relies on the same open-source firmware, but the errata differ. It’s been tested with the OS as RockPro64, plus Fedora IoT 35 dated from August 2021.

Raspberry Pi 4 Pi 400 Arm-SystemReady IR Certification Both the Raspberry PI 4 Model B SBC and Raspberry Pi 400 Keyboard PC are SystemReadry IR certified but only to level 0 meaning OS modifications are required, and not only some workarounds. The errata files show the platforms must boot in Devicetree mode instead of ACPI mode also available in the UEFI firmware. There’s a known issue in the start4/fixup4 binary files (ThreadX firmware) that prevents booting in Devicetree mode, and requires some workaround. You’ll find the Raspberry Pi 4 UEFI firmware on the Pi Firmware Taskforce Project’s Github account. The Raspberry Pi platforms have been tested with Fedora IoT 34, Fedora Workstation 34, and SUSE Linux Enterprise Server (SLES) 15 SP3, while openSUSE Leap 15.3 was only tested on Raspberry Pi 4. We previously noted that Raspberry Pi 4 had Arm SystemReady ES (server) certification allowing it to run Windows 11 for instance.

I should probably test this once I’m done with the other hardware reviews I’ve been working on.

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

Notify of
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
1 month ago

I would prefer mainline vpu inside the desktop ready…. 🙁

1 month ago

While it may be fine for PCs, Vulkan video will never be viable on the majority of ARM based systems. Those working on the specification (according to the article) are AMD, Intel, and NVidia. All these manufacturers integrate a display controller, a VPU, and a GPU. However, in the world of ARM SoCs, the display controller, VPU, and GPU are discrete IP blocks typically all provided by different vendors. There is also an additional consideration regarding the assumption of GPU use. On a PC it is common to use the GPU to scale and color convert video. On ARM devices,… Read more »

1 month ago

Openmax is being dropped and mmal isnt working on aarch64. As a engineer at rpi foundation forum said… v4l2 is the way to go but that have a very long road. So far rpi3/rpi4 have excellent h264 1080p60fps inside the desktop with vlc and others.. but it stops there. No h265 of course.

On aarch64 v4l2 works horrible on every platform I had tried so far. Including potato 4, the most supported platform ever*.