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.
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 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.
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.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
I would prefer mainline vpu inside the desktop ready…. 🙁
Is this relevant?
https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-1.2.196-H265-Encode
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 »
There used to be the OpenMax standard for video playback, but AFAIK it never really took off. It just infrequently pops up in the news: https://www.cnx-software.com/news/openmax/
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*.