Linux Port

Now that RISC OS is Apache licensed, does this mean that it would be possible to produce a precompiled image of this for easy deployment?

I guess it depends on how the image is put together, what license the component parts are under, and how it interacts with the Linux kernel which I’m assuming would be installed separately. Timothy knows what he’s doing with all this, so he can fill us in once he’s updated his repository with the new license. :)

I sort of assumed it would be like a pre-built SD image that “would just run”?
If so, that’s not relevant to GPL – files on a filesystem don’t taint by proximity.

A more pertinent question may well be how it interacts with the kernel, but if that’s the case it would apply anyway regardless of how the software is started…

If so, that’s not relevant to GPL – files on a filesystem don’t taint by proximity.

There’s a chance that R.S might disagree ;)

files on a filesystem don’t taint by proximity.

There’s a chance that R.S might disagree ;)

[ https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html ]

Also relevant from Linux:

NOTE! This copyright does not cover user programs that use kernel services by normal system calls – this is merely considered normal use of the kernel, and does not fall under the heading of “derived work”.

Now that there is a RISC OS git client it’s possible to build the RISC OS Linux rom natively.

The git client is available here.

Clone the repository,

sgit clone https://github.com/TimothyEBaldwin/RISC_OS_Dev.git RISC_OS_Dev

or

sgit clone git://github.com/TimothyEBaldwin/RISC_OS_Dev.git RISC_OS_Dev

sgit makes no attempt to set file types at the moment. The file types can be set using !Rename available here.

Drag the folder RISC_OS_Dev to the ‘Smart Renamer’ window and set it up as below,

There is one file that needs copying manually otherwise the following error occurs building the rom,

LinuxSupport (mixed.Linux.Support)...
amu -E -f RAM::RamDisc0.$.RISC_OS_Dev.Env.CallMF  export PHASE=hdrs COMPONENT=LinuxSupport
do mkdir -p <CExport$dir>.ix.h
copy  SocketKVM_Protocol/h <CExport$dir>.ix.h.SocketKVM_Protocol FR~C~VN
AMU: *** File ':RamDisc0.$.RISC_OS_Dev.mixed.Linux.Support.SocketKVM_Protocol/h' not found ***

AMU: *** 'export' not re-made because of errors ***

Error running make export (hdrs) on module 'LinuxSupport'.

Copy the file RISC_OS_Dev.Linux.Support.h.SocketKVM_Protocol

to

RISC_OS_Dev.Linux.Support.SocketKVM_Protocol/h

Then build the rom using !Builder as normal.

Ever since switching to the ‘Linux2’ branch, running RISCOSMark5 causes an abort and gives a ZeroPain error in the Basic module.
The ZeroPain log is here.

Ever since switching to the ‘Linux2’ branch, running RISCOSMark5 causes an abort and gives a ZeroPain error in the Basic module.

I suspect that is because it tries identify the system by reading the name of the first HAL device, but currently the Linux Port has no HAL devices.

Looks interesting. May be a good enough reason to go to using Linux more. Just a little hesitant to try it (oddly enough considering one of my current projects).

Running on top of ARM Linux gets rid of the hardware support issues. I can not form a complete opinion yet, as I skipped a good part of this thread.

It fails to build using an lxc container (arm on arm) complaining that;

’Can’t mount proc on /newroot/proc: Operation not permitted’

It fails to build using an lxc container (arm on arm) complaining that;
’Can’t mount proc on /newroot/proc: Operation not permitted’

I read that by default LXC security settings prohibit mounting filesystems and other operations that are required create containers. Disabling these is may be unsafe for privileged containers, that is those that do not use user namespaces.

I suggest you ask on a Linux forum if you need help setting up LXC to support nested containers.

You can disable the sandbox using RISC_OS__INSECURE=YES ./run_RISC_OS when running RISC OS or make INSECURE=YES when compiling. This of exposes your user account to all RISC OS security flaws.

I have added instructions to the README.md file.

I suggest you ask on a Linux forum if you need help setting up LXC to support nested containers.

Thank you but it was just for your information. There was no nesting of containers here though, simply an lxc container running on an arm server, to prevent bloat of the host.

I have added instructions to the README.md file.

Cool.

Aemulor on the Linux environment would be nice to have.
Has anyone tried it and had any luck with that?
I am very curious because it would complement it much if we could use 26 bit apps.

Not sure if it’s documented. Attempting to change the mouse type from “Unrecognised” via the configuration screen results in some kind of lockup.

There was no nesting of containers here though,

No, there is, at least by some definition. The run_RISC-OS script does use container techniques to restrict what RISC OS can do, including creating user, PID and mount namespaces bind mount parts of the filesystem that should be accessible, calling pivot_root and mounting a new instance of procfs which is where it fails. It is prohibited to mount procfs unless the caller has procfs already mounted without anything mounted on top, or has CAP_SYS_ADMIN (is root) in the root user namespace.

A solution I have found is to bind mount /proc/self instead of mounting a fresh procfs instance, however this breaks my parallel build modifications to srcbuild. I think that can be fixed by sharing the file descriptor table between processes.

It works on ARM64 virtual servers running Ubuntu from Amazon Web Services, at last the search for cloud servers that can run RISC OS without CPU emulation is over.

Unlike other cloud providers (eg Packet and Scaleway) who have brought 64-bit only processors they designed their own chips based on ARM’s 32/64-bit design. I haven’t tested the other Linux distributions, please note that it is possible to compile Linux without support for 32-bit programs.

I discovered and fixed a few bugs:

• ARM64 Linux ptrace behaves differently when an SWI is called with r7 = -1, which was breaking the ptrace SWI interceptor (only used if Linux does not support seccomp mode 2)
• The QEMU decision script code was inappropriately choosing to use QEMU if RISC OS failed due to the vm.mmap_min_addr setting, it now just uses the HAL —help option as test if 32-bit ARM programs run, and then checks and fails it RISC OS will not work.
• The checksum for the HardDisc4 zip file was out of date. I changed to using the current self-extracting archive instead.

I decided to make some benchmarks comparing Amazon’s smallest ARM virtual server to my desktop and laptop building RISC OS and running the following BASIC loop:

TIME=0:I=0:REPEAT:I+=1:UNTIL TIME>2000:PRINT I/20; " BASIC loops per second"

Amazon Web Services a1.medium

51904.9 BASIC loops per second

RISC OS build:

AMD A8-5600K on ASRock FM2A75 Pro4 with 2 × 4GB DDR3 CL9 1333MHz DIMMs

122534.55 BASIC loops per second

RISC OS build:

ASUS Chromebook C100P

542202.75 BASIC loops per second

RISC OS build:

Those found and fixed bugs… Those have been plaguing me forever. Thank you so much for fixing them!

I came here today for another reason. Keymapping. I want to map the menu key on the keyboard to the menu mouse button. StrongKey doesn’t work in the Linux port. It thinks Toolbox is missing for some reason. Using StrongKey and Keymapper feels like it wouldn’t work anyway.

What is the right way to do it? I cosidered altering keyboard.h but that may not yield the result I need. The trouble I have is that it’s a notebook keyboard so I can’t plug it into an RO system to work out if the scancode is mapped or as what. I tried trial and error with keymapper last night with no success.

What is the right way to do it? I considered altering keyboard.h but that may not yield the result I need.

Whilst you might be able do it by altering Keyboard.h you shouldn’t as that is the list of RISC OS key numbers.

For the SDL frontend the standard key mapping is specified in sdlkey.c and altered in sdl.cpp if the —chromebook option is given. It’s best add another option to sdl.cpp.

You can find the list of SDL key names in the SDL header file. If you get stuck add "cerr << "Key down: " << e.key.keysym.scancode << endl;" after “case SDL_KEYDOWN:” in sdl.cpp.

Thanks. I’ll give that a try later. StrongKey is adamant that Toolbox is missing for some reason so that’s a dead end.

I tried adding an option for pinebook. Haven’t got that working yet for some reason. Added “{SDL_SCANCODE_APPLICATION, KeyNo_LeftMouse + 1},” to the scancodes in sdlkey.c and it appears to function. So at least it works the wrong way for now.

StrongKey is adamant that Toolbox is missing for some reason so that’s a dead end.

It works for me once I load the tabs module, which is not part of the RISC OS distribution.

Where are you getting the modules from? The versions I found bundled with something I can’t recall were too old for StrongKey.

What I meant before is that I added an option for Pinebook that should have been selectable. via the commandline args. I didn’ have much time so I didn’get to investigate what I’d done wrong. But adding to sdlkey.c confirmed that there are no actual issues with getting the Pinebook option working besides me.

Where are you getting the modules from? The versions I found bundled with something I can’t recall were too old for StrongKey.

See the announcement thread which states the Tabs module is available via PackMan. It just downloaded the linked zip file.

See the announcement thread which states the Tabs module is available via PackMan. It just downloaded the linked zip file.

I thought Tabs was an extension Toolbox module for the ROL originated Toolbox. Does it work with the standard release toolbox in RO5?

I’ve uploaded a new version of StrongKey that includes the Tabs module and RMEnsures it correctly.

I thought Tabs was an extension Toolbox module for the ROL originated Toolbox. Does it work with the standard release toolbox in RO5?

Yes, it works fine on RO5. I use it in several of my applications including one you should be familiar with, Transient (for its choices window). :-)