Running RISC OS on a OKdo ROCK 4 C+ SbC - possible?

I recently won an OKdo ROCK 4 C+ SbC in OKdos design competition (using their SbC tech to run a combined Chart Plotter/NMEA device monitor/control system with OpenCPN as the OS for use in boats) and have tried running RISC OS on it, both RO Direct and the one aimed at Raspberry Pi boards, but neither will boot and the monitor goes into a “HDMI no signal” state and then sleep mode. OKdos Debian-based OS* runs fine, and a blue LED is blinking which does not happen atall using RISC OS, that is it finds nothing to boot.

The ROCK 4 C+ ises a Rockship RK3399-T SoC which I notice were discussed a few years back on this forum with no firm conclusion reached back then.

Is this a matter of RISC OS being “too retro” to run on this SoC/SbC or can it be tweaked to boot and run in a snappy manner? I certainly hope for the latter since RISC OS is the most productive OS I have ever used.

• See https://github.com/radxa-build/rock-4c-plus/releases/download/20230312-1521/rock-4c-plus_debian_bullseye_kde_b55.img.xz

The Pinebook Pro is based on the Rockchip RK3399 cpu and works well with RISC OS. I understand that R-COMP are working on various other ports of RISC OS to some SBC’s with the RK3399 chip and I believe that OKdo ROCK 4 range is part of the port. You should contact Andrew Rawnsley to see if the ROCK C+ is one of the targets.

In case it’s confusing, the PineA64 that you can find in downloads is for the Allwinner A64 as found on the discontinued non-Pro Pinebook, not the Rockchip. The Pinebook Pro port uses the RK3399 but the port isn’t open source, so RComp are the people to talk to in terms of getting hold of it. They do have a ‘Support Scheme’ where they provide software for hardware you already have, and maybe they offer that for the RK3399 – you would have to confirm with them.

How would you search for Pinebook but not the Pro version?

I’m not sure if it matters, but the OKdo ROCK 4 C+ SbC has a Rockship RK3399-T – note the T – as its SoC. Anyway, if it’s supposed to support old-style 32-bit Arm CPUs it should boot and run “vanilla” RISC OS with no hickups. The fact that there were no blue-LED activity (indicating SD card access) is an indication something is fundamentally wrong (I used Balena Etcher to write it to the card and the verification process reported a successful write).

Just checked the RPi Imager app, RISC OS isn’t even there in the menu any more under “Other General-purpose OSes” which should cause some concern in the shrinking RISC OS user base. I started a thread some months ago stating that for RISC OS to survive in the long run, it has to go 64-bit. A prolific and much respected RISC OS programmer said it would take around 100 man-years (or 10 programmers working for a year) to get there. The GUI may be kept intact, but old-style RISC OS software would need a “26-32” relocatable module or such to run transparently. A brand new 64-bit capable SDK would also have to be developed to enable porting/writing compatible software.

As things stand, at least 3 separate companies are developing their own versions of RISC OS which would make sense with a big and growing userbase, but is detrimental to RISC OS survival and growth since the userbase is shrinking. Is it a lack of Hauser/Curry-caliber management skills and Furber/Wilson-caliber development skills which has held back a unification of skilled resources? I truly believe that this is a prerequisite if RISC OS is to survive and thrive in the 21st millennium. Just my tuppence. :)

Apart from servers (which use UEFI), there is no such thing as a ‘vanilla’ SD image for Arm machines. You need an image for your specific board – this applies just as much for Linux as it does RISC OS. I’m not sure which image you’re trying to boot, but none of them will work.

Since RComp is the only source of support for the RK3399 under RISC OS you would have to ask them for their image. Since RISC OS is under a permissive licence, not the GPL, companies are free to take it and produce their own forks without being compelled to give back the source.

Do you know what the meaning of the -T suffix on the RK3399 is? I couldn’t find anything that shows the difference, and whether it would affect booting an RK3399 image on a -T, or whether it’s something immaterial.

Do you know what the meaning of the -T suffix on the RK3399 is?

I grabbed a copy of each of the datasheets and looked at the specs/limits and diagrams.
It’s… weird. You’d have thought a newer chip, later revision, would be better, right?

The original RK3399 was made in 2016 as a 28nm part. It has an A72 dual-core and an A53 quad-core, clocking a maximum of 1.8GHz and 1.4GHz respectively. Or 2GHz/1.6GHz if it’s the K suffix part. There’s also a dual-core M0, but that’s not useful for RISC OS. ;)
The Mali-T860MP4 GPU max freq is 800MHz.

The RK3399-T is a newer part, 2019 IIRC, made to a 22nm process. As above, there’s an A72 and an A53, but their max speeds are 1.5GHz and 1GHz respectively, and the GPU’s max is 600MHz. It looks also as if the T part lacks the PCIe2.1 support.

So the T part looks like being a slightly reduced version, perhaps for cheaper shovelware to compete with the Allwinner chips?

Or is it perhaps for reduced power consumption?

Well, that’s a fair point, but at what cost? Especially given as systems like Android are quite aggressive with their power management. The cores don’t run flat out all the time.

Not sure what the intended application is. It’s possible they’ve made some other mods to reduce power consumption, apart from reducing the frequency – the smaller process is what makes me wonder about that.

I miss the fact that Acorn’s RISC OS came on physical ROM chips. Impervious to virii (can recall I tried to get one, unsucessfully..;) and rock stable running “professional” DTP software. Only, what other ehrm modern operating system is still 32-bit in 2023..? After ARM slashed support for 32-bit mode in their latest CPU/GPU architecture revision one should think everything RISC OS centered around going state-of-the-art ARM (or any other CPU architecture if OS is written in C) which can ensure the survival of a very productive user interface. Have fun with funding it. :)

Woops, forgot to bark about the disappearance of the multi-lingual font collection created by Edward Detyna and The Electronic Font Foundry – that’s a high-quality treasure of primary importance in case RISC OS goes 64-bit in the near future and has ambitions on going international. It’d perform better on (Arm-based) mobile phones than Android and not be tied to No Such Agency’s “Prism” spyware program.

For reference, the Okdo Rock 4C+ board with 3399T is supported, and has its own specific ROM, as part of our (R-Comp) RK3399 support scheme. Indeed, I have one sat on a bench behind me. However, it isn’t formally announced because some parts of the port are still incomplete. For example, the ethernet port is still in a beta state.

The RK3399 project now supports a range of boards and devices (Pinebook Pro, RockPro64, RockPi 4 B/B+/C/C+ and so on).

However, because RISC OS is my day job, and porting the OS to new platforms is a time consuming job, there are costs involved in joining the support schemes.

We do feed back source to ROOL periodically, by the way, but not everything is accepted (right away) because build systems and house styles do vary.

Incidentally, since RockPi devices can have eMMC, you can use the sd card like a ROM, if you wish. Just install the OS as read-only to the boot sector of the micro SD, then use the eMMC module as your “harddisc4”, just like an old Acorn :)

Hi Andrew I have two or three 3399 boards Khalsa edge v5 with the rockchip will have join the project to see if they work.
Do I need to join the project or will the Pinebook pro rom work let me know by email I will send some funds.
Not sure if you got my mail today to join the testing on cachefs will you add me to the list please.