Linux Port

Does the Linux Port need updating now that RISC OS 5.28 is out?
I’ve tried downloading the binary version, but it looks like it’s looking for some 5.24 related downloads that have now been removed from this site.

Does the Linux Port require ARM with full 32-bit support like A72 or does it work also on ARM with only User Mode 32-bit support like A76?

Does the Linux Port require ARM with full 32-bit support like A72 or does it work also on ARM with only User Mode 32-bit support like A76?

See this forum topic.

A few things from testing a fresh build on the RPI4

- Often the desktop hangs for no apparent reason, requiring to restart the run_RISC_OS.

- The mouse arrow is a non-transparent block

- PlingStore can’t connect

- Backups of harddisk directory seems to lose the xattributes and are rendered useless.

- Build only works after fiddling with the make files to download the harddisk uitl file

- run_RISC_OS needlessly rebuilds the ROM at startup

Do we have a ‘stable’ checkout point in git which is know to work well?

On the RPI4:

RISCOSmark 2.04 (30-Dec-2015) by Richard Spencer 2003
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800x600,256
(HD benchmarks are in kilobytes/sec)

MOS Utilities   5.27 (25 Jul 2020)
FileSwitch      2.87 (12 Oct 2019)
C Library       6.07 (06 Jul 2020)
FileCore        3.75 (06 Jul 2017)
HAL-based system (Linux HAL PSR Manipulation) tested at Sat,14 Nov 2020.18:48:16
Filing system: IXFS$.HardDisc4.test
Graphics Resoloution: 1920x1080, 16M colours

Test                                                   Benchmark
Processor - Looped instructions (cache)                  4973286    2796%
Memory - Multiple register transfer                        60437   37306%
Rectangle Copy - Graphics acceleration test                 1530     632%
Icon Plotting - 16 colour sprite with mask                 27310    1365%
Draw Path - Stroke narrow line                             16176    1036%
Draw Fill - Plot filled shape                              16515    1131%
HD Read - Block load 8MB file                             626447   21007%
HD Write - Block save 8MB file                            124830    4104%
FS Read - Byte stream file in                                183      88%
FS Write - Byte stream file out                               94      48%

but on the Xavier AGX:

RISCOSmark 2.04 (30-Dec-2015) by Richard Spencer 2003
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800x600,256
(HD benchmarks are in kilobytes/sec)

MOS Utilities   5.27 (25 Jul 2020)
FileSwitch      2.87 (12 Oct 2019)
C Library       6.07 (06 Jul 2020)
FileCore        3.75 (06 Jul 2017)
HAL-based system (Linux HAL PSR Manipulation) tested at Sat,14 Nov 2020.18:47:37
Filing system: IXFS$.HardDisc4.Public
Graphics Resoloution: 1920x1200, 16M colours

Test                                                   Benchmark
Processor - Looped instructions (cache)               1120394577  629902%
Memory - Multiple register transfer                       120676   74491%
Rectangle Copy - Graphics acceleration test                11014    4551%
Icon Plotting - 16 colour sprite with mask                 48273    2413%
Draw Path - Stroke narrow line                             16589    1063%
Draw Fill - Plot filled shape                              18129    1242%
HD Read - Block load 8MB file                            4485322  150413%
HD Write - Block save 8MB file                            754312   24804%
FS Read - Byte stream file in                                187      90%
FS Write - Byte stream file out                              125      65%

which seems to be off.

The ‘hangs’ appear to be network related.

Is there a proper way to setup network on the Linux Port?
Perhaps a setting to debug the network related hangs?

Hi Jan, interesting machine that Xavier ! Off topic from your question…but could you run my three Fractal benchies if you got time ? How many MHz ist that thing running on ? Find them here

Benchmarks Xavier AGX @ 2265.6 MHz:

32 Bit Fixed Point Integer Fractal
using 64-Bit SMULL by M.Kuebel
-————————————————
Time taken in [s]…………: 0.73
Total Iterations………….: 179217040
Million Iterations per second: 245.502

NEON Single Precision
Fractal by M.Kuebel
-—————————
Time [s]…………………: 0.26
Iterations……………….: 177944574
Million Iterations per second: 684.402

VFP Double Precision
Fractal by M.Kuebel
-—————————
Time [s]…………………: 0.93
Iterations……………….: 177936814
Million Iterations per second: 191.329

VFP Single Precision
Fractal by M.Kuebel
-—————————
Time [s]…………………: 0.96
Iterations……………….: 177944574
Million Iterations per second: 185.358

see also https://www.riscosopen.org/forum/forums/9/topics/15359?page=1#posts-110160

Mouse, screen and keyboard are supported, sound and network are not yet supported.

From the first post suggests to me that it works. But no answer…

Is there a proper way to setup network on the Linux Port?

Is there a way? I have no answer/todo found.

Thanks a lot!

Does the Linux Port need updating now that RISC OS 5.28 is out?

I’ve done that.

Does the Linux Port require ARM with full 32-bit support like A72 or does it work also on ARM with only User Mode 32-bit support like A76?

Just requires user mode.

Often the desktop hangs for no apparent reason, requiring to restart the run_RISC_OS.

I haven’t seen that.

The mouse arrow is a non-transparent block

This is SDL bug #5037, which affects version 2.0.12. It’s fixed in version 2.0.14, but there 2 other bugs, when resizing the window it often terminates with an X11 error, and it fails to start if accessed over ssh.

I’ve tried to modify the Makefiles to download and build working SDL source if necessary, however it fails to build on 32-bit ARM for me. Commit 13430:c32f98490438 does appear to work

PlingStore can’t connect

Works for me.

Backups of harddisk directory seems to lose the xattributes and are rendered useless.

It you use a backup program that handles extended attributes it works. :-) Perhaps an easy option to use ,xxx extenstions for HardDisc4 is needed.

The ‘hangs’ appear to be network related.

Is there a proper way to setup network on the Linux Port?
Perhaps a setting to debug the network related hangs?

Apart from setting the DNS server address there is nothing to set. For debugging try using strace to check if it is stuck in system call.

Hi Timothy. Do you advice on good hardware to test it (Chromebook, SBC…)?

Hi Timothy. Do you advice on good hardware to test it (Chromebook, SBC…)?

I was wondering about this too. In terms of modern ARM chipsets for laptops/desktops the most up to date/powerful are the boards in the M1 Macs and Qualcomm Snapdragon 8CX-based Windows laptops (both of which are customised Cortex A76 designs). As far as I’m aware, Linux has yet to be ported on to any of these devices.

I think the fastest ARM-based laptop to run Linux would be something like the Lenovo Chromebook Duet or the HP Chromebook 11a, both of which use the (A73-based) Mediatek MT8183 chipset. I don’t know whether anyone has tried the RISC OS port on either of these. Below that you’re down to Pi 4/Pinebook Pro level hardware.

Do we have a step-by-step guide to installing this on the Raspberry Pi 4 (assuming standard Raspberry Pi OS)?

Hi Timothy. Do you advice on good hardware to test it (Chromebook, SBC…)?

Whatever you run it on, you may need root privileges to adjust the vm.mmap_min_addr sysctl value, which sets the lowest virtual address available, which currently needs to be 12288 (&3000) or lower to fit in the debugger workspace and scratch space.

I have some changes that move the scratch space, and doesn’t fail to boot if virtual addresses below 32768 (&8000) aren’t usable. However this breaks the Debugger module, Zap and probably some other programs.

I think I found out why !Store doesn’t work reliably, Linux select() is edge triggered and will not report a socket is ready again until until after it becomes non-ready, whereas I think RISC OS and BSD are level triggered.

It appears I will have to write an implementation of select.

@Tim it was things like that which caught me out when making the Red Squirrel to Windows network pass through. Windows was much less BSD like than Linux.

Would it be possible to give modules the option of retuning in ‘user mode’ stack set up for user mode – say by indicating to the OS – by adding a extra flag.

Would it be possible to give modules the option of retuning in ‘user mode’ stack set up for user mode – say by indicating to the OS – by adding a extra flag.

I don’t know what you mean by this.

To work towards rmodules running in User mode.

For testing purposes – I switched a rmodule to User mode when called.

By the way – does Linux RO run on the Pinebook Pro?
Thanks for your work :-)

To work towards rmodules running in User mode.

The Linux port runs with the CPU in 32-bit user mode.

For testing purposes – I switched a rmodule to User mode when called.

Is there something other than CPU mode you wish to test? Do you mean RISC OS state entered by OS_LeaveOS?

• Callbacks are enabled, so that can only be used where callbacks are safe, not for example within a non re-entrant filing system.
• Application code may not have a stack.
• The application stack might move (BBC BASIC does this during Service_Memory which may be called when allocating memory, except on the Linux Port)

By the way – does Linux RO run on the Pinebook Pro?

I’ve tested it on a Cortex A72 (specifically a AWS a1 with Graviton 1), not sure about Cortex A53. RISC OS does lots of thing that officially don’t work on ARMv8, and I would not be surprised if something the type of CPU it is running on changing. If it doesn’t like the A53s you could use taskset to force it onto the A53s.

By the way – does Linux RO run on the Pinebook Pro?

Works. Look here. ;-)
Very good in Debian, not so good in Manjaro.

I’ve added a RISC OS style select, and added Taskwindow support to the Internet module. !Store, NetSurf, WebJames, Packman and SimpleGit all work (at least partially).

I have worked around 2 SDL bugs (solid mouse pointer and crashing on windows resize ) by scripting the download of an older binary.

I have added the IXRun command which runs Linux Programs:

*IXRun ls -l /dev/fd/
total 0
lrwx------ 1 8897 2041 64 Feb 18 00:41 0 -> /dev/pts/0
lrwx------ 1 8897 2041 64 Feb 18 00:41 1 -> /dev/pts/0
lrwx------ 1 8897 2041 64 Feb 18 00:41 2 -> /dev/pts/0
lr-x------ 1 8897 2041 64 Feb 18 00:41 3 -> /proc/6/fd
lrwx------ 1 8897 2041 64 Feb 18 00:41 31 -> 'socket:[820038]'
lrwx------ 1 8897 2041 64 Feb 18 00:41 5 -> 'socket:[812929]'

It works well enough to run bash, dash and RISC OS:

*IXRun /usr/bin/env RISC_OS_Alias_IXFSBoot=BASIC /Built/wrapper /Built/qemu-link /RISC_OS

Quoting arguments works:

*IXRun echo "Don't" say '"Hello World"'.
Don't say "Hello World".

It needs some work doing on it:

• A proper blocking wait.
• Handle errors.
• Handle TaskWindow termination sensibly.
• Provide translation from RISC OS to Linux paths.
• Do something sensible with environment variables.
• Better handling of terminal / VDU codes.
• Better handling of Escape / SIGTERM?
• Deal with file descriptor leaks.
• Provide access to RISC OS filing systems.

Thanks a lot for the Linux Port.
Have try your latest binary.
*IXRun gives no error message but also no output and often the TaskWindow/RISCOS freeze and I have to kill the Terminal.

*IXRun gives no error message but also no output

Some Linux commands run.

*ixrun whoami
*
*
*ixrun date
Fri Mar 12 10:48:36 UTC 2021

*IXRun ifconfig -a
*
*ixrun which which
/usr/bin/which
*ixrun uname
Linux
*

TaskWindow/RISCOS freeze and I have to kill the Terminal.

I have not seen that. The only freeze previously seen was associated with networking and/or NetSurf, which I need to revisit. Otherwise it had been stable. This is a local build with DDE29c from the sources on an RPi400.

(But I have just found a way to freeze the Linux port, by running an app from within a zip. The apps run OK if copied out from the zip first. This was with SparkFS 1.46.)

By way of light entertainment I reproduced the Scale 0.17 bug on it thereby demonstrating the accuracy of the port.

Thanks for the port, apart from trivia, it’s looking good.