Linux/Android ARM-hosted RISC OS?

I am wondering if a “hosted” version of RISC OS, running in a sandbox on top of Linux/ARM and/or Android/ARM, would be feasible to create?

The AmigaOS-like AROS project has a similar approach on ARM: http://en.wikibooks.org/wiki/Aros/Platforms/ARM_support

I thought a Linux/ARM and Android/ARM would be able to open up RISC OS to many more platforms, including possibly platforms like nVidia Tegra, where a native RISC OS port would 1) be difficult, and 2) fail to utilise the multi-core CPU and GPU to its full potential. A “hosted” RISC OS could be multi-tasked with Linux or Android applications and include the possibility of integration features with the host OS (as seen with AROS, which can work as a Linux desktop replacement when running on X).

How difficult would it be to get RISC OS running in a sandbox on Linux/ARM (and Android/ARM) near-natively, without the overhead of emulation, similar to what the AROS project has achieved with their OS? (I think it would be preferable NOT to use an X server, personally, as performance can be poor on certain platforms – although this may be an option to add.)

Of course, lightweight platforms like Raspberry Pi still benefit greatly for a fully native RISC OS port (and a native AROS/ARM port is planned too, alongside the hosted versions), however the next generation of high-end ARM machines could potentially offer excellent performance with a hosted RISC OS (under Linux or Android), which would both provide an interesting alternative desktop experience to many users of these platforms, while also spreading the popularity of RISC OS.

Does RISC OS Open have any interest in pursuing this route for RISC OS?

I am wondering if a “hosted” version of RISC OS, running in a sandbox on top of Linux/ARM and/or Android/ARM, would be feasible to create?

Starting from the base of this? :- http://www.marutan.net/rpcemuspoon/

Sound more like http://ro-lookandfeel.blogspot.de/

It could work from the base of RPCEmu, but would ideally run as much of the hosted ARM machine code as possible natively on ARM (like AROS does), rather than using an interpreter or some kind of ARM-to-ARM dynarec.

The latter project is useful but not quite what I had in mind. I would like to see a full RISC OS userland sandboxed on Linux/ARM, highly optimised with virtually no emulation overhead. Preferably not dependent on X for graphics, and also with the possibility of an Android version (with touch-compatibility).

RISC OS available in every pocket? It could certainly widen the user base…

AIUI dynarec would be a big task. Did you see this answer from a Dec 2011 thread on the RPCEmu mailing list? Maybe there’s some more recent relevant discussion in the archives.

There’s also ROSE: http://www.stardot.org.uk/forums/viewtopic.php?f=30&t=3521
(Probably more a pipedream however)

By the way, is there any progress concerning GPU accleration? I remember some Mr. Kortink (is this you, “John K”?) who wrote a driver for graphics cards for the RiscPC and even added a X86 emulation to execute the ever-changing firmware supplied with the cards.

That genius approach should have been much more difficult than to find out what the Linux closed source drivers are doing.

To copy the idea of John, maybe it is even better to let these drivers do what they want under RiscOs as well – by writing a ‘Linux emulation’ for the parts the graphics driver needs to be provided with from outside.

I can imagine that there is

• some information needed about the system apart from the gpu,
• some kind of callback assignment in either one or both directions
• some kind of ticker for repeating tasks
• fast data path registration
• Memory (bandwidth + space sharing) should be mostly there
• Transfer routes for shader scripts and the like to be sent to the gpu

I suppose these needs are somewhat universal for all gpu units using GLES 2 and higher, and should somehow be visible when using a single step hardware debugger… Also, the kernel interaction should be visible from the kernel side (the open source parts of it)

Has anyone played around with a jtag debugger to confirm my thoughts? (some might have, I know :-).

Sorry if there is something obviously stupid, but my misknowledge of the Linux kernel is only challenged by my ignorance concerning graphics drivers 8-).

Ok, I found that these ideas have been stated already – using the linux binary blob by writing a layer…
But maybe we can start the discussion again now that we achieved quite a lot in the other fields?

The (Linux) Raspberry Pi GPU drivers are open source: http://www.raspberrypi.org/archives/2221. The closed source binary blob is to boot the GPU and CPU.

The closed source binary blob is to boot the GPU and CPU.

I was under the impression that the GPU ran a full (inaccessible) operating system of sorts; and the open sourced GPU drivers were not much more than a set of veneers to the GPU entry points. So, now, we’ll have descriptions of what the values and structs are instead of guesswork, but the GPU is still “a black box”, in common with most of the ARM SoC GPUs…

Yes, it looks as being only a wrapper. But this would be usable on its own. My point was about what that binary blob might need from the os. At least it needs the processor from time to time and maybe some interrupt resources/vectors. This now needs to be provided by riscos instead.

My point was about what that binary blob might need from the os.

I think the big question is “what does the binary blob actually do?”. My personal feeling, given that it loads in the boot-up prior to there even being an OS is that it will be all or part of the GPU firmware. This is loaded into the GPU/GPU memory and then it is no longer required (the blob is also the first stage of the bootloader, so it starts the ball rolling).

At least it needs the processor from time to time and maybe some interrupt resources/vectors. This now needs to be provided by riscos instead.

Given that RISC OS works on the RaspberryPi, either this does not happen, or support is already built in to RISC OS. It may be minimal support at this time, but it is there and it works.
Poke around in https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/Video/HWSupport/BCMVideo/s/ for more info. ;-)

At least it needs the processor from time to time and maybe some interrupt resources/vectors. This now needs to be provided by riscos instead.

The “binary blob” probably uses (one of) the 48 processors that form the GPU and the GPU memory for what it has to do. So it might need nothing from the os.

the GPU is still “a black box”

Does it matter? All the “tools” are available to get the highest possible speed out of the GPU.

the GPU is still “a black box”
Does it matter? All the “tools” are available to get the highest possible speed out of the GPU.

That’s pretty much my point – the GPU is a “thing” and now we know how to better talk to it… The blob, however, isn’t/shouldn’t be particularly relevant to RISC OS. We come along after that’s done with.

Pedantic: obtaining the highest possible speed from the GPU requires more than tools, it requires knowledge…not something you’ll be able to obtain from the current datasheets! The official datasheet mentions in a single line note that the video output can be GPU accelerated or a dumb framestore; but it doesn’t even describe the operation of the dumb framestore (location in memory, pixel format(s), initialisation…). These things can be gleaned by examining the various source code(s), but that’s a somewhat unfriendly way to do things, which renders the datasheet less than useful for people wanting to play around and write their own toy OS, for surely one of your first jobs at startup would be to display some rubbish on the screen…
Oh course, something is better than nothing for sure; it just could have been a little more useful.

Given that RISC OS works on the RaspberryPi, either this does not happen, or support is already built in to RISC OS.

Well, the basic support for the normal video behaviour is there, and the processor is not needed for this after boot. I was thinking on e.g. something like shaders – those shader scripts need to be pushed into the GPU during runtime – or synchronised things in interrupts. AFAIK the video hardware acceleration is currently not done by the gpu, but by one of the arm extensions (was it NEON?).

Does it matter?

I too think it does matter, but if we can’t get the docs we can’t help it.

If the ‘blob’ is started at boot-time, before the os, and does not need to register at all, we should be able to use the blob just like in the wrapper classes. Does anybody know how that is done in linux (better say for linux)? I think it needed to be completely in u-boot, so with some luck and minimally changed u-boot it should already be there?

For accessing the blob, at least some header file with base addresses of the calls need to be there. Hmmm..

I am wondering if a “hosted” version of RISC OS, running in a sandbox on top of Linux/ARM and/or Android/ARM, would be feasible to create?

This thread is quite old, but now multi-core powerful Android devices are the norm.

Would it be possible for RISC OS to have complete control of one core, and use the host for sound, graphics, networking, filesystems etc?

Now, Qemu/KVM has a partial Raspberry Pi emulation. The best is simply to make a KVM port of RISC OS. It’ll run at almost native speed on any Cortex-A15/A17/A53/A57/A72 Linux computer. One could even create a minimal Linux OS just for RISC OS virtualization.

I would think Android would be a far more sensible target. Millions of suitable devices, as opposed to thousands. (Unless of course it were to also run on x86 computers)

Android will also have hypervisors. Just a question of time. Nota: Android IS Linux.

To say ‘one core for Android/Linux and one for RISC OS’ can’t be done anyway: Android is an SMP system, not an AMP one.
Virtualization is the answer: RISC OS will be the guest, Linux/Android/whatever the host.

Nota: Android IS Linux.

Correction: Android uses the Linux kernel.

It does not include glibc, or most of the GNU Libraries. It does not contain an X server, the GUI is something different, aimed at specifics of mobile devices. Pretty much all of the application API is based upon Java for the Dalvik/ART runtime systems for running apps.

That’s why you won’t be able to run Linux software on a phone, or Android apps on your Linux box (assuming both use the same sort of ARM inside). There are solutions (emulation, ported software, etc) but generally speaking it is misleading to say that Android is Linux, as there is an awful lot of “Linux” that Android isn’t.

But it is the Linux kernel. ;-)

As RHEL, CentOS, Debian, Ubuntu.
Level 0 hypervisors don’t really care of X, etc. They just need the kernel.

Anyway, RISC OS on a generic smartphone or tablet is no use. The good point would be to have RISC OS working on an ARM server, and so accessible from anywhere (even from a mobile device) with a Spice client. RISC OS as a Service :).

To say ‘one core for Android/Linux and one for RISC OS’ can’t be done anyway: Android is an SMP system, not an AMP one.

So you’d need a custom kernel to do it this way? Which would then remove the millions of devices advantage.

RISC OS on a generic smartphone or tablet is no use.

I don’t see that. Providing it has access to the host’s networking, filesystem and keyboard and mouse (if provided by bluetooth keyboard/mouse), it would be very useful on a tablet. (It would be more of a novelty on a regular phone.)

However to be worth the effort it would need to run pretty much the same speed as native RISC OS on the device would, (the host providing services using all the cores would help.) And it would need to be in an app store.

It could be “interesting” to adapt RISC OS (that makes extensive use of three buttoned mice and pop up menus) to a finger prodded device.

It doesn’t need to be in an app store – this isn’t Apple. ;-)

It could be “interesting” to adapt RISC OS (that makes extensive use of three buttoned mice and pop up menus) to a finger prodded device.

Hmm, you haven’t got around to watching the video Raik posted showing his PiTab in use then.
Pi + touch screen + some driver stuff from Thomas. No “gestures” involved.

It doesn’t need to be in an app store – this isn’t Apple. ;-)

To be worth the effort, it would want to be exposed to as many potential new users as possible.

Hmm, you haven’t got around to watching the video Raik posted showing his PiTab in use then.
Pi + touch screen + some driver stuff from Thomas. No “gestures” involved.

Primarily it would need to work with a mouse and keyboard, any additional tablet mode support would be a bonus.