Porting RISC OS to Linux

unix_ or ix_, as prefixes?

I’d be interested in your eventual goal, as well.

2 SWI names and numbers need allocating:

…err…that’s not how the allocations system works.

You should contact the allocate@ address to request a SWI chunk. You will then be informed of what chunk has been allocated to you. Given the ROOL guys read this, you may get a nod to claiming &C0000 if it has not already been claimed but then again you might get the next allocation off the pile, because it is irregular to say that you want specific SWIs.
The allocation permits you to “own” 64 SWIs, which can be called _. So you will want to register the module name, and the SWI prefix. Will you have a need for *commands or error numbers? You might want to request them at the same time.

More details at https://www.riscosopen.org/content/allocate

@Timothy
You mention using Qemu. Did you modify both qemu and the linux kernel to get this working?
Also the base config of RISC OS you use is the IOMD version. What if i want to try this on real hardware like XScale PXA270 or Cortex A9/A15 ?
A modified kernel would automatically except using a ‘normal’ linux distribution since that will use SWI 0 for kernel system calls.

@Timothy: interestingly both the XScale and the Cortex A15 will print:
‘Personality not available so using ptrace – This may be slow’
‘Hello’

The Xscale will loop this but the A15 stops after this.

the arthur module (PER_RISCOS) is not enabled when compiling for EABI. did you compile in OABI? I could just enable it in EABI though (will try anyway.)

Using kernel 2.6.33.1 on my XScale laptop with PER_RISCOS enabled in EABI yields one empty line printed.
There must be a better way to do the SWI juggling.

The arthur module will pass on all SWI’s except for SWI 0.
I am investigating a scheme to make it pass on SWI 0 too by stting a flag in the task_info.

Though I do hope that nothing actualy comes of this projecct as it would take away from RISC OS greately.

Since it all appears to be based on source from the ROOL repository it all has to be fed back to Castle under the terms of the licence. “derivative work” is the operative bit.

NB. GPL does not and cannot override the open, but commercial, nature of licence of the original code.

For testing purposes 0×0C0000 seems right then. OABI an EABI not only differ in SWI base number, they also differ in the calling standard. So remapping to 0×900000 won’t be correct and possibly breaks things.
I am still working on getting a flag in the SWI handler to switch between RISC OS SWI’s and Linux SWI’s.
That way EABI and RISC OS SWI can coexist. It will handle SWI 0 as EABI if the flag is clear.
To switch a special RISC OS SWI needs to be allocated. For testing purposes 0xC0000 seems fine.

@David: this is like running RPCemu on Linux with code running directly on the CPU. In fact I plan to use this to get RPCemu on ARM linux with decent performance. Currently RPCemu runs at 30 MIPS on a 1.7 GHz ARM..

This also might provide a route to enable RISC OS on more ARM platforms. a HAL that can delegate work to a Linux kernel will alleviate the burden of porting to newer hardware. Next to that it won’t violate GPL since using Linux syscalls from RISC OS is no different from running closed source software on Linux. Even if we would create a special Linux module to handle special activities, that would not cause any problems.

Dreaded licences again heres my 2p

Since it all appears to be based on source from the ROOL repository it all has to be fed back to Castle under the terms of the licence.

No it doesn’t there can be as many forks as you like. Castle have the right to use any of the changes they find but don’t have to be informed at all or use any changes.

Castle licence

NB. GPL does not and cannot override the open, but commercial, nature of licence of the original code.

GPL can’t be used with the Castle code either

there are many other threads discussing license details. this thread is looking into cooperation between RISC OS and Linux…

Ok last word. There can be no ‘cooperation’ between riscos and linux. If I was ROOL I would have nothing to do with any code produced as it would be debatable if it was legal as it would for you to distribute it. You could have ported to NetBSD without the legal problems.

Just trying to save the effort of coding something you can never distribute.

This also might provide a route to enable RISC OS on more ARM platforms. a HAL that can delegate work to a Linux kernel will alleviate the burden of porting to newer hardware.

Hence my questions to Timothy about whether this is a passing fancy or something more significant.

If we’re aiming for a proper solution for running RISC OS on Linux then we should probably be focusing on using a modified Linux kernel instead of a stock one – so that things like SWIs, PSR manipulation, etc. will just work instead of having to heavily modify RISC OS and its programs in order to fit with how Linux expects things. Otherwise you could end up with heavy resistance from developers and users – developers won’t want to spend ages patching and fixing their code (and may be opposed to the idea entirely), and users won’t want to use the system because all of their old apps won’t work.

@Jeffrey: to get somewhere we first need to experiment and learn.
If we get it right then there are very few or minor changes to the Linux kernel. However if we allow RISC OS to directly change hardware or memory mappings while on Linux it will certainly crash the machine.
RISC OS will become increasingly harder to port to newer hardware and the diversities of ARM SoC’s are piling up.
With the advent of Hypervisor mode it will become easier to have virtualized OS-es on ARM. However access to the hypervisor mode seems quite difficult. The bootloader usually prevents it.
The proper intermediate will remain an emulator that can facilitate all RISC OS requirements and run usermode code natively. If the HAL gets adapted to improve the interaction then that sound fair enough to me. Of course it should not break things from the RISC OS perspective.

My 2p – I’m not sure about the idea of running RISC OS on top of a Linux kernel. Where does Linux stop and RISC OS begin? As a project it is very interesting, however it seems to me that a lot of things you can do with the OS stand to be diminished with the use of Linux underneath, primarily for fear of mucking up the environment that the host expects.
A possible solution would be a custom Linux, but surely in this case we would be swapping one problem (porting RISC OS to new hardware) with another (porting the custom Linux)?

’tis a shame nobody is looking at faking a Linux environment under RISC OS – it would be nice to look to having dsp codecs and such that come as standard for Linux…

Above all, don’t let us put you off; it is an interesting concept and one worth following to see where it takes you.

Just trying to save the effort of coding something you can never distribute.

Interesting quirk. Quote: “If any part of any Derivative Work distributed by You can reasonably be considered an independent and separate work then this Licence shall not apply to any such part where You distribute such part as an independent and separate work;”.
How can something independent and separate and a part of any Derivative Work?
If I hacked WindowManager to look like Windows 3.1 (!), then I would expect that to be a derivative version of WindowManager, not my own “separate” work. It is stuff like that that can have commentards arguing hard and solicitors arguing harder! ;-)

but don’t have to be informed at all or use any changes.

Boolean logic fail. Quote: “by including a copy of the source code with Your distribution and/or by uploading the source code to the official RISC OS source code repository at […]” – in either case, derivative work that you distribute¹ is supposed to be uploaded to the repo. One could consider this an implicit notification of changes.

And here is the one for the GPL crowd: “2.3 If, […] or any other reason You are unable to comply fully with the terms and conditions of this Licence then You shall refrain from distributing RISC OS or such Derivative Works (as appropriate) for the duration of such non-compliance.”.

The modifications to the RISC OS code base are covered under the Castle licence. Modifications to any version of the Linux kernel are covered under GPLv2. They cannot clash, and more importantly, one cannot supplant the other.

¹ The implication here being that you can do what you want with code that is never intended to be distributed: gleefully mix Castle and GPL code, set all the copyright messages to say “Cookie Monster” and throw darts at a printed photo of RMS… whatever… problem is… code that is never intended to be distributed… kind of a waste of time, don’t’cha think?

Comment Deleted as thread I now see is in Aldershot and has moved on!

Just a bit of info on the Arthur module.

Long ago Philip Blundell was working on a method to run RISC OS binaries on Linux. This ran on the Risc PC and my Netwinder. I have helped to get it working and we worked on riscose at that time called ‘rose’. The Arthur module was conceived to allow SWI calls to be trapped and a switch from 32 to 26 bit mode. This kernel module still exists today.
With RISC OS now on 32 bit the module needs an update, also changes in newer kernels make it less functional.
So foremost my work a.t.m. is to fix the bugs in the Arthur module. I seem to be on the right track now.

With a patch the module will use the standard Linux personality settings and userspace will need to catch the SIGILL signal. That signal handler will receive info on the processor state at the point of the SWI.
During the SIGILL handler a flag is set so that normal Linux environment can be used.

In general it is not more than a plug to redirect software interrupts back to the user program.

What this means for RISC OS emulation, now 32 bit code is available, we can run 32 bit code that uses non-Linux SWI calls. Using the SIGILL signal handler to perform the requested SWI and return to the 32 bit code.

Trapping signals is a standard feature of Linux. Arthur makes it a bit easier to use that mechanism when working with binary ARM code that uses SWIs in the way that RISC OS does.