Linux Port

Apologies if this question has already been answered. Would it be possible for an ELF executable in RISC OS (within Linux) to be linked with libraries in the ambient Linux? I ask this because RISC OS lacks so many of the software-creation tools to be found in Linux. It would be a big plus if the fruits of these tools could be enjoyed in RISC OS without having to port the tools themselves.

Disregard results for #2 and #3. Deleted. For some reason libseccomp2 and libseccomp-dev were installed but not seccomp. I guess something happened during the apt update I did before starting testing yesterday, because I swear it used to be there. After all I have been running the Linux2 branch.
Going to test all 3 again.

For some reason libseccomp2 and libseccomp-dev were installed but not seccomp.

The “seccomp” Debian package is irrelevant.

Is there a perchance of a demo at the London show?

Now for API review:

OS_DynamicArea TBD – Change or set Linux file dynamic area refers to.

(SWI &66)

Any preferences? The current use is sharing the screen memory with the front end process.

Would an option for the RISC OS kernel to create an unnamed file be useful? It would be simplest to specify this when creating a dynamic area.

The “seccomp” Debian package is irrelevant.

I thought as much, but then I’m not sure why it’s choking.
The nasty DDE corruption issue struck so I have to copy it across again before another attempt. Not entirely sure what happens but it prevents things from DDE working with a build.

I set up the Pi Zero to test it with real peripherals. Quickest way to get around the xrandr issue. Something went wrong with the updates for Raspbian that I pulled this morning. The zero is now stupidly slow. Like taking minutes to boot. Being able to see it drawing every character on the screen etc. There don’t appear to be any rogue processes either. So not related but be careful about current updates.

The TF700T is flatly being ruled out as a test case. It can run the binaries but can’t build them. Too many things are too old.

Could the seccomp failure on the OPiPC2 be because of the OS being aarch64 maybe? I’m just guessing. Runs great in insecure mode.

What causes the corrupt icons when dragging? Is it an archaic RISC OS quirk? My only guess is something to do with colour depth and bit packing but that’s completely uneducated.

If it wasn’t for RISC OS having nice NFS support I’d probably just be using an ARM based thing running this port to work on my port. I mean, I could set up a tftp server on said device for serving the ROM and use something like PuTTY for the serial terminal but… maybe there is no “but” actually.

I’m giving it a try on a RPi3 with Raspbian Stretch because it’s a bit more common.

Brief summary. If bubblewrap isn’t installed the build process goes groping for QEMU then fails with just “make” unless INSECURE=YES is used. Works fine otherwise.

“make QEMU=/usr/bin/env” doesn’t work so well. Here’s the last couple of lines.

Support/common.mk:93: Building comma2attr
+ ln -sf Built/comma2attr comma2attr
make: *** No rule to make target 'usr/bin/env', needed by 'Built/qemu_sandbox'.  Stop.

make INSECURE=YES seems to work fine.

Brief summary. If bubblewrap isn’t installed the build process goes groping for QEMU then fails with just “make”

Expected if you mean something like:

Support/common.mk:64: Built/qemu_path: No such file or directory
Support/common.mk:115: Building Built/gen_seccomp
+ gcc -std=c99 -Wall -Os Support/gen_seccomp.c -o Built/gen_seccomp -lseccomp
Support/common.mk:207: Building Built/qemu_path
+ set -o pipefail
+ /usr/bin/bwrap --ro-bind / / true
Support/common.mk:207: recipe for target 'Built/qemu_path' failed
make: *** [Built/qemu_path] Error 1

make: *** No rule to make target 'usr/bin/env', needed by 'Built/qemu_sandbox'.

Are you sure you didn’t miss the first slash and typed “make QEMU=usr/bin/env” instead? No point carrying out this test if plain “make” works or if Bubblewrap is not installed.

What causes the corrupt icons when dragging?

Good question. Fails for me in 256 colour modes, but works full colour modes.

Are you sure you didn’t miss the first slash and typed “make QEMU=usr/bin/env” instead?

I believe you are correct. I re-ran it today without issue.

btw doing things first time round without bubblewrap was just an omission on my part. After running it the first time I realised I hadn’t installed it yet.

Is it possible to change the colour depth while retaining using the Auto monitor still? Or whatever the mechanism is that allows dynamic resizing of the desktop window.

e: Using the same USB HDD to build RO Linux on both the OPiPC2 and RPi3 has led me to believe that the OPiPC2 is way faster at it.
I did my RO source hacking today in RO Linux. Something I’m curious about. Are there any case sensitivity issues, or are they dealt with?

bq.Could the seccomp failure on the OPiPC2 be because of the OS being aarch64 maybe? I’m just guessing. Runs great in insecure mode.

Could be, there is a special case in gen_seccomp that adds ARM 32-bit seccomp rules in addition to the ABI it is compiled to. Could you check if the use of the predfined macro is correct?

A reasonable test approach to see if it’s output works would be:

1. Save the output of 32-bit and 64-bit builds of gen_seccomp:
   Built/gen_seccomp > rules
2. Test running without seccomp:
   bwrap --unshare-all --proc /proc --dev /dev --ro-bind RISC_OS /r /r
3. Try with saved output :
   bwrap --unshare-all --proc /proc --dev /dev --ro-bind RISC_OS /r --seccomp 9 9<rules /r

I don’t have a 32-bit capable ARMv8 system to test with.

The TF700T is flatly being ruled out as a test case. It can run the binaries but can’t build them.

That is a mystery, the build process should use any interfaces that running the binaries does, though (based only your comment) it could be a filesystem problem that wasn’t exposed your testing. You could try the ChangedBox branch to address the screen performance problem, however Zap doesn’t work.

Is it possible to change the colour depth while retaining using the Auto monitor still? Or whatever the mechanism is that allows dynamic resizing of the desktop window.

Just choose any monitor type. Or you could specify the mode on the command line or in the “Mode” option of the Display Manager menu.

I did my RO source hacking today in RO Linux. Something I’m curious about. Are there any case sensitivity issues, or are they dealt with?

IXFS is by default case insensitive if the directory is readable, though it will prefer an case sensitive exact match and be faster if one exists, if there is no exact match the first match (in getdents order) will be used. A potential gotcha is that filetype extensions will not be written if the underling filesystem supports extended attributes, I recommend a special field of “W”, for example “IXFS#W:$.path.to.source”.

On another thread Tristan wrote:

My Netbook just can’t seem to handle RO Linux. It just gives a mysterious “Unable to allocate memory” error.

If that is a non-ARM 32 bit system an address space conflict between RISC OS and QEMU and the shared libraries it uses is possible.

There’s a lot to get through there.

If that is a non-ARM 32 bit system…

x86 Atom based netbook. So that’s what the issue could be. It would have been atrociously slow anyway but at least I tried.

Regarding case sensitivity, I was just clutching at straws as to why FPEmulator stopped building in my porting work. It’s breaking because it can’t find a file which it should be able to.

Resolution change: Everything is greyed out for the auto monitor in !Boot configuration. IIRC the selector on the bar is too. I believe it also lists mode 28.

I’ll just try changing the monitor type then.

Related, it’s probably not news but programs crash when they want to use space to the right of the visible screen, and possibly below. For example if the resolution is fairly low and I have a StrongEd window open. I want to use a menu and bring it up near the right of the screen. That will crash it. I can’t remember if I observed this with other programs.

I’ll have to connect the OPiPC up again to have a look at the bwrap and gen_seccomp stuff.

Related, it’s probably not news but programs crash when they want to use space to the right of the visible screen, and possibly below.

It is to me. It works in 32-bit modes. When changing the implementation of Double mapped dynamic areas I neglected to map the second mapping. I have uploaded a fix.

The fix seems to work fine. I just tried it.

Apparently I didn’t say before. I just typed in an arbitrary resolution and higher colour depth. Works fine. Thanks.

Although I just point out problems, usually with edge cases I want to say that it is an amazing piece of work and an extremely useful tool. It’s now as easy to build as the original Linux branch if not easier too.

I haven’t reconnected the PC2 yet. I found a couple more Allwinner related documents yesterday so I spent my “free time” looking through them.

Re testing gen_seccomp, the output of 32-bit gen_seccomp will not work in 64-bit bwrap.

That’ll do it.

I just want to add that most platforms will require “sudo sysctl vm.mmap_min_addr=8192” to allow RO Linux to run. Usually there’s a prompt when the execution fails, but not always. So I’m just putting it on here for whoever needs it.

Would it be possible for an ELF executable in RISC OS (within Linux) to be linked with libraries in the ambient Linux?

This would result in a large mess, for example:

• EABI requires 8-byte alignment of the stack and 8 byte types, RISC OS uses 4 byte alignment.
• Is SWI 0 OS_WriteC or a Linux system call?
• When the desktop is running the RISC OS heap and stack is in the wimp slot which is a shared mapping, which will not be copied on calls to Linux fork(), as Linux programs expect.
• Linux threads lose access to the wimp slot on any wimp task switch.
• Linux threads don’t work with Unixlib locks and vice-versa.
• RISC OS shared libraries require a register to point to their data, Linux shared libraries access data via a fixed logical address offset.
• Possible logical address exhaustion.

However running whole Linux programs from RISC OS with access to RISC OS standard input/output (and filing systems) is possible. One complication is that RISC OS can’t start Linux programs the usual way using fork() and exec(), due to the SECCOMP rules used to intercept RISC OS SWI calls.

That’ll do it.

What do you mean by this?

I just want to add that most platforms will require “sudo sysctl vm.mmap_min_addr=8192” to allow RO Linux to run.

I have increased the maximum of that vale a little to 12288 (12kiB) by moving the debugger space up 4kiB. An additional 16kiB can be gained by moving the scratch space (which is a published interface, see PRM Vol 5A page 41, and used by at least Zap) and 4kiB by eliminating the debugger space.

Usually there’s a prompt when the execution fails, but not always.

If vm.mmap_min_addr is set greater than 32kiB the failure will be in the HAL, which gives the error message “Failed to reserve address space.” I have now added the suggestion to set vm.mmap_min_addr there as well.

This thread has suddenly stopped — nothing for over a fortnight. Judging by the “Views”, there is massive interest in “Linux Port”, with currently the largest number of views apart from “Bounty proposal: Paint” and a sticky. Timothy, have you got stuck?

In contrast, I asked “RISC OS on a Smartphone?” in the General subforum and got no posts and very few views. Please see my post there for possible relevance to Tim Baldwin’s work. The (multicore) processor involved is an ARM one. I would love to know whether, if Tim’s work is successful, I could have RISC OS on a Fairphone 2. I have the original Fairphone 1, but am tempted to buy Fairphone 2 with Linux OS and say goodbye (more ‘F off’) to Google.

I asked “RISC OS on a Smartphone?” in the General subforum and got no posts and very few views.

Smartphones are usually:

• Closed boxes with the SoC barely documented (if at all)
• Difficult to interface with (many have only a single USB client socket – does RISC OS support OTG behaviour?)
• Zero network support (we don’t do WiFi yet)
• A user interface based upon touch and multiple touches attempting to be used with a UI that expects exactly one pointer position and three different mouse buttons.
• All the rubbish with bootloaders – how do you plan to get RISC OS on the device, especially during initial development?
• Not to mention potential side issues regarding the “security modules” present within the SoC (especially the radio stuff).

It would be cool to have RISC OS in a little handheld device. But unless CJE, RComp, etc etc get together and make a new device, it isn’t going to happen.

Example? Original Motorola Defy. It’s basically a waterproof mobile phone running an OMAP3. It’s like a Beagleboard. Only it isn’t… Add for the Fairphone 2, where’s the TRM for the Qualcomm MSM8974AB?

A user interface based upon touch and multiple touches attempting to be used with a UI that expects exactly one pointer position and three different mouse buttons.

Surely you just need to use different fingers. ;-)

It would be cool to have RISC OS in a little handheld device. But unless CJE, RComp, etc etc get together and make a new device, it isn’t going to happen.

Hence the running on Linux angle, then you don’t need any of the above to do it. You sidestep the problems with bootloaders – assuming you can unlock the bootloader for the phone. If the underlying architecture is too different from the ones that RISC OS supports then there are at least two efforts to make phones on ones it does (to some extent): i.MX6/8 and OMAP5.

Add for the Fairphone 2, where’s the TRM for the Qualcomm MSM8974AB?

It runs Linux, so the question is not of any interest. Linux does the hard work for us. That is the whole point of Timothy’s efforts.

Thanks for replies. David B. can you tell us anything more about

If the underlying architecture is too different from the ones that RISC OS supports then there are at least two efforts to make phones on ones it does (to some extent): i.MX6/8 and OMAP5.

I am still tempted to buy Fairphone 2 (has 2 SIM slots and is unlocked) with Ubuntu Linux if I can justify the expense given my little use of a mobile phone (for light users, try PhoneCoop PAYG from where you can buy Fairphone 2).

Necunos is using i.MX6 but there’s little information available about this phone at the moment.
Librem5 is using i.MX8 and is still being developed.
Of the OMAP5-based devices, the Pyra isn’t really a phone but it has been suggested that it could be used as one if a cellular module is fitted.

Of these three, the Pyra is arguably closest to completion, though there’s little information about the Necunos phone so it’s difficult to tell. However, I would have thought that if it was nearly ready then they would be more forthcoming about availability. ;-)

Thinking about use on existing phones, it would be interesting to know if the Linux port can actually run on Android, or if it relies on features in the kernel that are not typically enabled on Android systems.

Has anyone tried running it on Android, either rooted or with normal permissions?

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?

The context: I have an eldery Toshiba AC100 which is now really too slow to run a modern Linux on, but would run RISC OS beautifully. Likewise, RISC OS as an app on an old Android smartphone should work absolutely fine.