Linux Port

To get a more simple way of starting it’s better to have a ‘new’ script.

The existing run_RISC_OS works fine. Sets everything up for you already.

janrinze@Xavier1:~/temp/DEMO$ git clone <a href="https://github.com/TimothyEBaldwin/RISC_OS_Linux_Source.git">https://github.com/TimothyEBaldwin/RISC_OS_Linux_Source.git</a>
Cloning into 'RISC_OS_Linux_Source'...
remote: Enumerating objects: 90739, done.
remote: Counting objects: 100% (10705/10705), done.
remote: Compressing objects: 100% (3930/3930), done.
remote: Total 90739 (delta 7320), reused 8871 (delta 6033), pack-reused 80034
Receiving objects: 100% (90739/90739), 50.23 MiB | 17.56 MiB/s, done.
Resolving deltas: 100% (53941/53941), done.
Checking out files: 100% (8981/8981), done.
janrinze@Xavier1:~/temp/DEMO$ ls
RISC_OS_Linux_Source
janrinze@Xavier1:~/temp/DEMO$ cd RISC_OS_Linux_Source/
janrinze@Xavier1:~/temp/DEMO/RISC_OS_Linux_Source$ ./run_RISC_OS 
Unix/SocketKVMFrontends/build.mk:20: Built/SDL_flags: No such file or directory
Unix/SocketKVMFrontends/build.mk:41: Building Built/SDL_flags
Unix/LinuxSupport/build.mk:38: Building Build2/src-stamp
Unix/LinuxSupport/common.mk:78: Building Built/gen_seccomp
Unix/LinuxSupport/build.mk:151: Building Unix/RISC_OS/Unix/RISCOS.IMG
Unix/LinuxSupport/common.mk:149: Building Built/qemu-link
Unix/LinuxSupport/common.mk:75: Building Built/wrapper
Unix/LinuxSupport/common.mk:72: Building Built/wait_stdin
Unix/SocketKVMFrontends/build.mk:37: Building Built/sdlkey.h
Submodule 'mixed/Linux/Support/bin' (<a href="https://github.com/TimothyEBaldwin/RISC_OS_Linux_Binary.git">https://github.com/TimothyEBaldwin/RISC_OS_Linux_Binary.git</a>) registered for path 'Unix/RISC_OS'
Unix/LinuxSupport/wrapper.c: In function ‘main’:
Unix/LinuxSupport/wrapper.c:233:11: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
           write(sockets[0], &e, 4);
           ^~~~~~~~~~~~~~~~~~~~~~~~
Unix/LinuxSupport/wrapper.c:266:20: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
     if (isatty(1)) write(1, "\n", 1);
                    ^~~~~~~~~~~~~~~~~
Cloning into '/home/janrinze/temp/DEMO/RISC_OS_Linux_Source/Unix/RISC_OS'...
Unix/LinuxSupport/common.mk:81: Building Built/seccomp-
Unix/SocketKVMFrontends/build.mk:31: Building Built/sdl
In file included from Unix/SocketKVMFrontends/sdl.cpp:22:0:
Unix/SocketKVMFrontends/frontend_common.h: In function ‘int read_msg(command&)’:
Unix/SocketKVMFrontends/frontend_common.h:98:24: warning: narrowing conversion of ‘(msg.msghdr::msg_controllen = sizeof (buf))’ from ‘size_t {aka long unsigned int}’ to ‘socklen_t {aka unsigned int}’ inside { } [-Wnarrowing]
     msg.msg_controllen = sizeof(buf),
     ~~~~~~~~~~~~~~~~~~~^~~~~~~~~
Unix/SocketKVMFrontends/sdl.cpp: In function ‘void {anonymous}::update_screen()’:
Unix/SocketKVMFrontends/sdl.cpp:60:51: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
   if (no_updates <= 0 && get_file_size(screen_fd) >= s && std::memcmp(old, pixels, s)) {
                          ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
Unix/SocketKVMFrontends/sdl.cpp: In function ‘int main(int, char**)’:
Unix/SocketKVMFrontends/sdl.cpp:144:14: warning: enumeration value ‘c_activescreen’ not handled in switch [-Wswitch]
       switch (c.reason) {
              ^
Unix/SocketKVMFrontends/sdl.cpp:144:14: warning: enumeration value ‘c_startscreen’ not handled in switch [-Wswitch]
In file included from Unix/SocketKVMFrontends/sdl.cpp:22:0:
Unix/SocketKVMFrontends/frontend_common.h: In function ‘void send_report(const report&)’:
Unix/SocketKVMFrontends/frontend_common.h:117:8: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
   write(sockets[0], &r, sizeof(r));
   ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
Unix/SocketKVMFrontends/sdl.cpp: In function ‘int main(int, char**)’:
Unix/SocketKVMFrontends/sdl.cpp:167:16: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
           write(sockets[0], &r.reason, sizeof(r.reason));
           ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unix/SocketKVMFrontends/sdl.cpp: At global scope:
Unix/SocketKVMFrontends/sdl.cpp:67:6: warning: ‘void {anonymous}::watcher()’ defined but not used [-Wunused-function]
 void watcher() {
      ^~~~~~~
Submodule path 'Unix/RISC_OS': checked out 'd24d3c7693490b5bc70f7c73c5ff49f97e80133e'
Unix/LinuxSupport/build.mk:49: Building Build2/Linux/RiscOS/Images/rom
Unix/LinuxSupport/common.mk:153: Building HardDisc4
Linux Xavier1 4.9.140-tegra-virt #1 SMP PREEMPT Sun Dec 6 21:01:28 CET 2020 aarch64 aarch64 aarch64 GNU/Linux
Building GIT commit: 9b5713cdb0a7c1530d803f2f8e0fce7fe5cf3db5
bwrap: Can't find source path ../DDE/AcornC.C++: No such file or directory
Unix/LinuxSupport/build.mk:49: recipe for target 'Build2/Linux/RiscOS/Images/rom' failed
make: *** [Build2/Linux/RiscOS/Images/rom] Error 1
make: *** Waiting for unfinished jobs....
HardDisc4_files/hd4,ffc: OK
Seccomp-bpf filter installed.
Hello World
...............
...............
14 of 14 interrupts counted.
Starting kernel...
HAL initialised
IICInit
IMB_Full done
InitCMOSCache entry
InitCMOSCache done
InitDynamicAreas
InitVectors
InitIRQ1
IMB_Full
VduInit
ExecuteInit
Machine ID duff,zero substituted
KeyInit
OscliInit
Enabling IRQs
IRQs on
Debug terminal on
HAL_InitDevices
InitVariables
AMBControl_Init
ModuleInitForKbdScan
init mod UtilityModule
init mod FileSwitch
init mod ResourceFS
init mod TerritoryManager
init mod Messages
init mod MessageTrans
init mod UK
init mod WindowManager
init mod SharedCLibrary
init mod IXSupport
init mod SocketKVM
init mod InternationalKeyboard
mod init (kbdscan) done
KbdFlag_Present
Reset CMOS
ReadDefaults
InitHostedDAs
MouseInit
ModuleInit
init mod TaskManager
init mod Desktop
init mod ScreenModes
init mod BASIC
init mod BASIC64
init mod BlendTable
init mod BufferManager
init mod ColourTrans
init mod Debugger
init mod DeviceFS
init mod DisplayManager
init mod DragASprite
init mod DragAnObject
init mod Draw
init mod FileCore
init mod RamFS => error: RAM disc size too small
init mod Filer
init mod FilerSWIs
init mod FSLock
init mod FontManager
init mod FPEmulator
init mod Free
init mod Hourglass
init mod International
init mod InverseTable
init mod Obey
init mod Portable
init mod Pinboard
init mod PipeFS
init mod RAMFSFiler
init mod ResourceFiler
init mod ROMFonts
init mod ScreenBlanker
init mod ScrSaver
init mod ShellCLI
init mod SoundDMA => error: HeapBadReason:Bad reason code
init mod SoundChannels
init mod SoundScheduler
init mod SpriteExtend
init mod SpriteUtils
init mod Squash
init mod SuperSample
init mod SystemDevices
init mod TaskWindow
init mod WindowUtils
init mod FilterManager
init mod WaveSynth
init mod StringLib
init mod Percussion
init mod Filer_Action
init mod DOSFS
init mod ColourPicker
init mod DrawFile
init mod BootCommands
init mod Internet
init mod Resolver
init mod MimeMap
init mod !Edit
init mod !Draw
init mod !Paint
init mod !Alarm
init mod !Chars
init mod !Help
init mod Toolbox
init mod Window
init mod ToolAction
init mod Menu
init mod Iconbar
init mod ColourDbox
init mod ColourMenu
init mod DCS
init mod FileInfo
init mod FontDbox
init mod FontMenu
init mod PrintDbox
init mod ProgInfo
init mod SaveAs
init mod Scale
init mod TextGadgets
init mod UnSqueezeAIF
init mod ZeroPain
init mod CryptRandom
mod init done
Service_PostInit
callbacks

RISC OS 4194304MB

IXFS

Extracting HardDisc4

Finished extracting HardDisc4
janrinze@Xavier1:~/temp/DEMO/RISC_OS_Linux_Source$ ./run_RISC_OS 
Unix/LinuxSupport/build.mk:49: Building Build2/Linux/RiscOS/Images/rom
Linux Xavier1 4.9.140-tegra-virt #1 SMP PREEMPT Sun Dec 6 21:01:28 CET 2020 aarch64 aarch64 aarch64 GNU/Linux
Building GIT commit: 9b5713cdb0a7c1530d803f2f8e0fce7fe5cf3db5
bwrap: Can't find source path ../DDE/AcornC.C++: No such file or directory
Unix/LinuxSupport/build.mk:49: recipe for target 'Build2/Linux/RiscOS/Images/rom' failed
make: *** [Build2/Linux/RiscOS/Images/rom] Error 1
janrinze@Xavier1:~/temp/DEMO/RISC_OS_Linux_Source$ 

Perhaps this is what you are seeing..
It’s clear that run_RISC_OS wants to build a new RISC OS ROM. Would be a lot more sensible to have separate build and run scripts..

To make the magic happen with the supplied rom:

 cp ./Unix/RISC_OS/Unix/RISCOS.IMG HardDisc4/\!Boot/Loader/RISC_OSRISC_OS_IXFS_HardDisc4='IXFS#X:$' RISC_OS_Alias_IXFSBoot='/!Boot' 

Built/sdl Built/wrapper --network --handle-reboots bwrap -- --bind ./HardDisc4 / --proc /proc --chdir / ./\!Boot/Loader/RISC_OS --nvram ./\!Boot/Loader/CMOS

should get you the RISC OS Desktop in a nice window.

(textile formatting is not my friend..)

Ok – thanks for your time – it has the basic desktop running
- I’ll work on it some more
- it looks to be some sort of build envirnment problem

Do you guys have DDE installed?

RISC OS is only buildable with the DDE

It’s clear that run_RISC_OS wants to build a new RISC OS ROM. Would be a lot more sensible to have separate build and run scripts…

I think the build before run is because the whole thing is a development test that hasn’t had a formal user release.
Which probably factors into any answer that you could put to the question of why we aren’t all running that build.

If I do ‘./run_RISC_OS’ it seems to try to build it and fails fairly early..

That does not sound entirely correct for the Binary Master download, the ROM image is already built. What is seen is the modules init list as the ROM starts. It works here and boots to the Desktop.

The DEV download does build the ROM which requires the DDE to be present in extended attribute form, comma separated filetypes that is. The ROM is only built once here, on subsequent starts the ROM init is seen promptly.

The only start command used here is ./run_RISC_OS.

Plus thanks for the null device redirect tip ./run_RISC_OS >/dev/null to loose the unwanted debug to the terminal

Got it going on a Pi4
- just needed to install libseccomp-dev

On a TX2, after installing libseccomp-dev, it has trouble building SDL
- due to a problem with libsndio
- but works ok with the opengl front-end (but I had to reverse the mouse y direction in opengl.c)

What’s next for the Linux Port?

Will we see sound support? (or rather: hear?)
Will we get Aemulor support? (My no.1 request)
Should we port parts of RPCemu for better network/sound/hostfs/diskimage support etc?
Will we see OpenGL pass-trough like some other project did for RISC OS?

I would love to see this thread split in a Dev thread and a Users thread.
At the moment I have no idea who else is working on this besides Timothy.
And i can imagine that Timothy does not have the time/energy/funds/.. to do all the work.

It would be good to see this move forward – but TB hasn’t updated github since June and hasn’t been on these forums since Feb
- so I hope he’s ok and still interested!

I also hope he’s ok and still interested! But TB has in the past not posted things for months at a time i.e. nothing last year after Aug 13, 2020 so I don’t think too much can be read into his current silence.

There has now been an update, four days ago. The current beta ROM is running here.

With thanks to the developer.

Good to see an update!

https://github.com/TimothyEBaldwin/RISC_OS_Linux_Binary

https://github.com/TimothyEBaldwin/RISC_OS_Linux_Source/issues/8

Looks like it’s possible to update QEMU to version 7.0 and use that in the build process.
I have successfully used this version to run the built RISC OS ROM. Not yet found any specific issues nor benefits though.

small side note: SpecialFX module will slow down the QEMU arm32 emulator significantly. The result being as fast as rpcemu in interpret mode. rmkill specialfx will be sufficient to restore the fast JIT speeds.
Some other observations:
- !Doom only runs when you copy it to the ramdisk. IXFS apparently gets stuck somehow.
- we can’t build the user space qemu-arm on OSX, it’s not supported.
- in UTM we can setup a small ARM64 Linux install and run everything from there. (is even a bit faster since it is has OpenGL acceleration)

The term “Lipstick on a Pig” doesn’t quite describe putting the nimble RISC OS desktop on the dinosaur known as Linux built with more than half a million lines of code. The “Save RISC OS as a unique operating system”-movement is more concerned with that currently there are at least 3 separate companies developing their own RISC OS’es which would be appropriate if RISC OS is a state-of-the-art operating system or moribund with a dwindling user base.

Acorn Computers who both designed the Arm architecture and RISC OS were killed because their 47% holdings of Arm Ltd. stock were “much more worth” than their dwindling hardware business. Point here is Acorn was a single company with a single vision and to think that our favourite Desktop/OS will do better when 3 underfunded companies are supposed to “save us” cooperated on developing the core, modules etc so that it can continue as a unique Operating System. 64-bit or toast, that’s the only long-term solution. Be ArmV9-compatible.
Even running 26/32-bit applications under emulation would still be Very Fast.

Compared to a StronARM’ed Risc PC-performance with 16MB RAM.

Here’s a couple of benchmarks running RISCOSMark on a Devkit2023. It has 4x cortex-a78 @2.4GHz and 4x Cortex-X1 at 3GHz.
OS is Ubuntu 23.04 aarch64. RISC OS Linux runs OK in user mode on both CPUs.

For Cortex-a78 @2.4GHz,

Test                                                   Benchmark
Processor - Looped instructions (cache)                  9848448    5536%
Memory - Multiple register transfer                       147643   91137%
Rectangle Copy - Graphics acceleration test                18675    7716%
Icon Plotting - 16 colour sprite with mask                101869    5093%
Draw Path - Stroke narrow line                             31139    1996%
Draw Fill - Plot filled shape                              38556    2642%
Draw Render - Render draw file                             23176    2558%
HD Read - Block load 8MB file                            4096000  137357%
HD Write - Block save 8MB file                             64250    2112%
FS Read - Byte stream file in                                520     251%
FS Write - Byte stream file out                              350     182%

For Cortex-x1 @3GHz,

Test                                                   Benchmark
Processor - Looped instructions (cache)                 11980961    6735%
Memory - Multiple register transfer                       183793  113452%
Rectangle Copy - Graphics acceleration test                32937   13610%
Icon Plotting - 16 colour sprite with mask                140751    7037%
Draw Path - Stroke narrow line                             40389    2589%
Draw Fill - Plot filled shape                              49913    3421%
Draw Render - Render draw file                             28414    3136%
HD Read - Block load 8MB file                            5758732  193116%
HD Write - Block save 8MB file                             63015    2072%
FS Read - Byte stream file in                                669     323%
FS Write - Byte stream file out                              485     252%

Here’s a couple of benchmarks running RISCOSMark on a Devkit2023

Remarkable performance – cpu and memory are nearly 3x, graphics acceleration over 6x and disc reads over 100x faster than my overclocked Pi4 running RO natively. So where’s the catch?

So where’s the catch?

There are three points:

• 1st: the port needs to be finished
• 2nd: it needs some packaging efforts, as compiling your owm qemu is not so easy
• 3rd: it will work up to Cortex-A78/Cortex-X1. Then it’ll be finished

So it could be a very good solution for RPI5 support (with a minimal Linux + Qemu + framebuffer OR with a full Linux system). Then we’ll need to switch to emulation and wait a very long time before having systems where RISC OS can be runned so fast. Nota: since developments are more around multiplication of cores or side car accelerators than on IPC, I think emulated systems will NEVER give the same CPU power than a native port of RISC OS on the fastest current boards. But they could be better on other aspects (I/O, GFX…).

1st: the port needs to be finished

The two main things missing are sound and vfpsupport. There’s also an issue where it hangs after a certain amount of time.

2nd: it needs some packaging efforts, as compiling your own qemu is not so easy

Qemu is only needed when running on a CPU without aarch32 user mode support. The binary download is available from here.
Just needs a few packages to be installed. (bash bubblewrap gcc g++ make libattr1-dev libseccomp-dev libsdl2-dev).
Then run ./run_RISC_OS.

3rd: it will work up to Cortex-A78/Cortex-X1. Then it’ll be finished

There’s also the cortex-a710 armv9 cpu that has aarch32 user mode. SOC’s that still have this only became available this year. e.g snapdragon 8 gen 2. Qemu is used on CPU’s that don’t support aarch32 user mode so will still run on e.g x64 but will be slower due to using emulation of the CPU.

So it could be a very good solution for RPI5 support (with a minimal Linux + Qemu + framebuffer OR

The cortex-a76 has aarch32 user mode so Qemu is not needed to run RISC OS Linux on the RPi 5.

Qemu is only needed when running on a CPU without aarch32 user mode support.

That sounds like reasoning for planning for what is happening right now, rather than planning for what will happen in the relatively near future.
Given the development rate in the RO world, the future is already way too close.

Excellent, So It’s a good mid term solution.
Eventually packaged with a small Linux distro (kernel + framebuffer + basic configuration tools) for purists.

Qemu is only needed when running on a CPU without aarch32 user mode support.

Ah. OK. But I can remember that for Qemu, a small patch is needed, so a specific version, where a native use of Qemu user mode would be – IMHO – a safer approach. But, clearly, the Qemu user mode approach can be great in term of integration possibilities.

Here’s RISCOSMark running on a RPi 5 @2.4GHz

Test                                                   Benchmark
Processor - Looped instructions (cache)                  6911953    3886%
Memory - Multiple register transfer                       140827   86930%
Rectangle Copy - Graphics acceleration test                 8858    3660%
Icon Plotting - 16 colour sprite with mask                 51505    2575%
Draw Path - Stroke narrow line                             23112    1481%
Draw Fill - Plot filled shape                              25945    1778%
Draw Render - Render draw file                             13060    1441%

@Chris: Nice results! It seems the 64Bit platform doesn’t slow it down much. I still wonder how this works, is there a layer that translates every 32Bit ARM instruction somehow to a 64Bit equivalent one on the fly ? Or is there still an application support for 32Bit but not for the OS ?