Linux Port

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.

Hi Timothy, I’ve just got to the point in setting up the RO port on my Chromebook where it fails with "Unable to map low address space, try “sudo sysctl vm.mmap_min_addr=12288”". As I understand it, it’s not possible to alter the vm.mmap_min_addr sysctl value from the Crostini terminal. Breaking Zap and the Debugger wouldn’t necessarily be a dealbreaker for me so I’d happily give the amended version a shot if you’ve still got it handy.

Otherwise, can anyone advise another course of action? Would rooting the Chromebook to adjust this variable be likely to cause issues with security/stability when using ChromeOS?

Otherwise, can anyone advise another course of action? Would rooting the Chromebook to adjust this variable be likely to cause issues with security/stability when using ChromeOS?

You can enable developer mode and install crouton.

You can enable developer mode and install crouton

You’ve convinced me. I’ll have a crack at that imminently, thanks for the suggestion!

I’ve had a few goes at getting this running via crouton and am now at the point where the build fails with the following message:

bwrap: No permissions to create new namespace, likely because the kernel does not allow non-privileged user namespaces. See <https://deb.li/bubblewrap> or <file:///usr/share/doc/bubblewrap/README.Debian.gz>.

I had a very similar message when I tried using Ubuntu rather than Debian. Anyone able to point me in the right direction?

Using the below make option should get the rom to build if bwrap doesn’t have permissions.

make INSECURE=YES

Thanks Chris, just tried this and have got a bit further. Now it fails with “Unable to open NVRAM file.” Is that a sign that I’m missing a dependency?

I think it’s failing as www.marutan.net is down so RPCEmu can’t be built.

marutan.net is back up now and it’s still failing with the same “Unable to open NVRAM file” message. It’s a bit perplexing

There doesn’t appear to be a way of building RPCEmu without the bwrap command working.

A workaround is to build RISC OS Linux on a Linux machine and transfer the HardDisc4 folder across.

tar --xattrs -cvf hd.tar HardDisc4

Transfer to Chrome OS machine and run in the RISC _OS_Linux folder,

tar --xattrs -xvf hd.tar

Then to run RISC OS Linux,

RISC_OS__INSECURE=YES ./run_RISC_OS

It’s weird that bwrap won’t create new namespaces. Maybe some incompatibility with being run in a chroot? Or could it be unhappy with my hardware?

I’ll have a go at your work around later on. Thanks again for your help

It looks like it’s to do with the Chrome OS Kernel. This is the error I get.

bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.

sudo sysctl kernel.unprivileged_userns_clone=1
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone


Got it working! Many thanks for your help, Chris. Doesn’t seem to like the window being resized in xfce – it goes black if you enlarge it. Might try a different UI to see if that’s any better.

Here are some benchmarks for an MT8183-based HP Chromebook 11a:

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

MOS Utilities 5.29 (28 Apr 2021)
FileSwitch 2.88 (30 Jan 2021)
C Library 6.09 (06 Feb 2021)
FileCore 3.77 (14 Dec 2020)
HAL-based system (Linux HAL PSR Manipulation) tested at Sun,08 Aug 2021.13:12:55
Filing system: IXFS – CSD not set
Graphics Resoloution: 1360×705, 256 colours

Test Benchmark
Processor – Looped instructions (cache) 4144218 2329%
Memory – Multiple register transfer 31365 19361%
Rectangle Copy – Graphics acceleration test 9766 4035%
Icon Plotting – 16 colour sprite with mask 34186 1709%
Draw Path – Stroke narrow line 19319 1238%
Draw Fill – Plot filled shape 21141 1449%
HD Read – Block load 8MB file 1605956 53854%
HD Write – Block save 8MB file 111709 3673%
FS Read – Byte stream file in 266 128%
FS Write – Byte stream file out 165 85%

To access the internet does it require the internet connection on the host machine to be via an ethernet cable? My Chromebook is connected via wi-fi and the Internet and Access icons are greyed out in the Configure box in RISC OS.

The networking is transparent. Just put,

set Inet$Resolvers <ip address of your DNS server>

in !Boot.Choices.Boot.Desktop.

Thank you! Typing this from Netsurf inside RISC OS.

When I try running the RISCOS.IMG on RPi4 in Raspian (or Twister)
- it runs ok up to the CLI prompt
- BASIC runs ok
- desktop – produced loads of random chars on the term
- a BASIC commands such as PLOT produces a few ‘random’ chars
- ixrun just returns ENOENT

I assume I’m not doing something I should be doing
- any suggestions?

Thanks!

I deleted my original message as a load of rubbish! Sorry.

When I try running the RISCOS.IMG on RPi4 in Raspian (or Twister)

Try,

./run_RISC_OS >/dev/null

- a BASIC commands such as PLOT produces a few ‘random’ chars

RISCOS.IMG has been built with debug enabled.

Ok – I got something…

I’m using the RISO_OS_Linus_Binary-master
- downloaded as a ZIP from github
- this contains not only the RISCOS.IMG binary, but also an sdl front end…
- so

Built/sdl Unix/RISCOS.IMG >/dev/null

- gets a CLI which can launch a RISCOS desktop…
:o)

Did you try,

./run_RISC_OS >/dev/null

I think he means that it doesn’t boot into the desktop.
Using the command he describes won’t mount the Harddisk4 directory nor will it use any CMOS file.

Playing around with the executables does work but the way everything is depending on both environment variables and wrappers it’s very limited without the extra stuff setup in run_RISC_OS.sh. The way the output is relayed to the console has baffled me for a long time but I have accepted it as just another quirk on how everything is setup.

I think he means that it doesn’t boot into the desktop.

It does if you run the command,

./run_RISC_OS

The way the output is relayed to the console has baffled me for a long time

That’s just debug turned on in the build.

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

Ah, i see. The run_RISC_OS script is checking several things and will start a build if it can’t find some parts.
To get a more simple way of starting it’s better to have a ‘new’ script.

The wrapper binary is required to get more secure split between RISC OS and Linux.

I have used this command in a script for most of the time:

RISC_OS_IXFS_HardDisc4='IXFS#X:$' RISC_OS_Alias_IXFSBoot='/!Boot' ./sdl ./wrapper --network --handle-reboots bwrap -- --bind ./Harddisc4 / --proc /proc --chdir / ./\!Boot/Loader/RISC_OS --nvram ./\!Boot/Loader/CMOS

it assumes that you have copied the RISC_OS executable to ./Harddisc4/\!Boot/Loader/RISC_OS and have a valid CMOS at ./Harddisc4/\!Boot/Loader/CMOS

Be aware that there won’t be a disk icon on your desktop per default.

To get that there as well I have a task obey in !Boot.Choices.Boot.Tasks called IXFSmount with the following line:

X AddTinyDir IXFS::Root.$