Linux Port

Also Make/AMU can detect if a change is in a file and act accordingly.

No, make/AMU checks if the timestamp is newer, not the contents. Which would cause more rebuilding, I copied the method the SharedCLibrary makefile.

The build was done on a clean checkout with no stray links since the directory was created during git checkout.

“git checkout” tries to preserve local changes and will not make a checkout pristine. I would not expect it create the directory in question unless you were switching from the first commit. To make it pristine use “git clean -fxd; git reset —hard”.

I also tried it on a Chromebook (debian Jessie) which has an aarch64 kernel but it doesn’t recognize ‘RISC_OS’ as being a valid executable.

I used an historic value for the ELF flags field which claimed it was using APCS and SWI numbers for system calls. Modern Linux uses R7 to indicate the system call number.

That should be fixed in the source code, and I have uploaded a separate binary .

Since RISC_OS.xz is supplied as a binary I don’t see why bisect will actually help me. There is only one change regarding that file.

Which should be due to the change in it’s source code.

If the file was generated with the Makefiles then I could probably bisect.

It was. So you can.

But binary files usually are built with a specific set of tools which may or may not be supported on other platforms.

The problem solved by including RISC_OS.xz is that you can’t build RISC OS without an already built RISC OS. The alternative is to use RPCEmu and IOMD RISC OS.

The RISC_OS.xz file, how is that generated?

I used:

git clean -fxd
git reset --hard
git checkout 9ce264a3649202aae595666fe338fc0d2d2c94f3 castle/RiscOS/BuildSys/Components/ROOL/Linux
make check METHOD=rpcemu
xz -9v < RISC_OS > mixed/Linux/Support/RISC_OS.xz

The “METHOD=rpcemu” setting causes the makefile to use IOMD RISC OS 5.22 in RPCEmu instead of mixed/Linux/Support/RISC_OS.xz but should not effect the result.

The new RISC_OS.xz still hangs. I managed to build the latest source with the old one on a Titanium. Then copied everything across to the Chromebook (Cortex-a72 @2.2GHz). Here’s the results from RISCOSMark5 using a ram disc. :-O

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.23 (09 Feb 2017)
FileSwitch      2.84 (08 May 2016)
C Library       5.92 (28 May 2016)
FileCore        3.71 (16 Dec 2016)
HAL-based system (Linux CLOCK_REALTIME) tested at Mon,01 Jan 1900.00:00:36
Filing system: RAM:RamDisc0.$
Graphics Resoloution: 1440x900, 16M colours

Test                                                   Benchmark
Processor - Looped instructions (cache)                  5158932    2900%
Memory - Multiple register transfer                        79224   48903%
Rectangle Copy - Graphics acceleration test                 5334    2204%
Icon Plotting - 16 colour sprite with mask                 44839    2241%
Draw Path - Stroke narrow line                             20367    1305%
Draw Fill - Plot filled shape                              21183    1451%
Draw Render - Render draw file                             11876    1310%
HD Read - Block load 8MB file                            5442407  182508%
HD Write - Block save 8MB file                           2749592   90417%
FS Read - Byte stream file in                                402     194%
FS Write - Byte stream file out                              405     210%

Okay, I found the cause.
reverting b08c44c873c69fb22762c659a3911a83cd4d439d ‘Linux HAL: Enable SIGIO on standard input.’ will make it work again.
Somehow that patch causes it to hang on the terminal.

Nice results with the Cortex-A72.

P.S. My laptop runs kernel 3.10.18 and that might be the cause of the incompatibility.

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.23 (09 Feb 2017)
FileSwitch      2.84 (08 May 2016)
C Library       5.92 (28 May 2016)
FileCore        3.71 (16 Dec 2016)
HAL-based system (Linux CLOCK_REALTIME) tested at Mon,01 Jan 1900.00:09:34
Filing system: RAM:RamDisc0.$
Graphics Resoloution: 800x600, 16M colours

Test                                                   Benchmark
Processor - Looped instructions (cache)                  4907863    2759%
Memory - Multiple register transfer                        36536   22553%
Rectangle Copy - Graphics acceleration test                 5846    2415%
Icon Plotting - 16 colour sprite with mask                 32272    1613%
Draw Path - Stroke narrow line                             12863     824%
Draw Fill - Plot filled shape                              13438     921%
Draw Render - Render draw file                              7164     790%
HD Read - Block load 8MB file                             681314   22847%
HD Write - Block save 8MB file                            705647   23204%
FS Read - Byte stream file in                                227     109%
FS Write - Byte stream file out                              226     117%

It shows that the Cortex A72 really shines at memory access compared to the Cortex A15 results shown above.

Although the sdl isn’t smooth with updates my small VFP demo !Teapot does neat.
That demo will do gouraud shaded triangles with a zbuffer. The teapot is rendered directly from its bezier patches.

Jan Rinze wrote:

The new RISC_OS.xz still hangs.

That was a fix for a different bug.

Here’s the results from RISCOSMark5 using a ram disc. :-O

Interesting program, where can I get it?

reverting b08c44c873c69fb22762c659a3911a83cd4d439d ‘Linux HAL: Enable SIGIO on standard input.’ will make it work again.

Thanks. Somehow on your system writing to STDOUT causes SIGIO which raises a erroneously enabled interrupt. The HAL should enter the RISC OS kernel with virtual interrupts disabled. Fixed source uploaded. I will upload a binary later.

I suspect the desktop was working because STDOUT is redirected to /dev/null by ./Test_Boot. Redirecting STDIN to /dev/null should also workaround the problem.

@Timothy: Your latest patch has fixed it for me.

Thanks for the swift actions!

benchmark tools RISCOSMARK

Now trying to find out why gcc complains in a taskwindow.

*gcc
Internal error: abort on data transfer at &200D8214
*wimpslot 8M
*gcc
Internal error: abort on data transfer at &9D70D0E0
*

Now trying to find out why gcc complains in a taskwindow.

That’s because Unixlib contains a OS_EnterOS/MSR pair. If it was statically linked it would be patched by IXSupport.

@Timothy

From the description of SharedUnixLibrary:
“This package provides the SharedULib module, which provides essential
services to UnixLib that are not possible in a user space application.”

Intercepting OS_EnterOS and doing run time patching could be a solution. Most of the calls after OS_EnterOS are used to fiddle with CPSR and an appropriate work-around could help out. In the past I have written some stuff to switch to emulation (like RPCemu) for the parts that would interfere with the Linux layer. It wasn’t fast not beautiful but it worked somewhat. That was years ago in ‘rose’ or RISC OS emulation for Linux. We didn’t get far then since my knowledge of how Shared Clib etc. worked was far too little to get things going. Digging deeper into that never happened. So even today I still have very little knowledge of how RISC OS starts up code. Some other people did more and that ended up in ‘riscose’ but was abandoned too.

In all you can imagine my enthusiasm seeing the results of your work.

An adapted version of SharedULib should be possible too but (of course) I have no idea where to start.

An adapted version of SharedULib should be possible too but (of course) I have no idea where to start.

Think it would be in an ELF shared library, not the SharedULib module which is still used by statically linked UnixLib.

I will upload a binary later.

I did so on Tuesday. The reported bugs that cause it to fail should be fixed, and it should work out of the box given ROOL DDE.

It now support parallel builds, to use N cores add “JOBS=N” to make command line. “JOBS=1” activates parallel build support but is sequential. “JOBS=0” or leaving it unset results in an traditional single process build. I find using 4 cores builds RISC OS in half the time.

Wimp slots are however even more broken, “*WimpSlot 2G 2G” causes RISC OS to slowly crash. It appear OS_AMBControl should return an error.

Why does the RTC device in the HAL not work? Here it is so far:

struct rtctime {
  uint8_t Centiseconds; // BCD centiseconds (00-99)
  uint8_t Seconds; // BCD seconds (00-59)
  uint8_t Minutes; // BCD minutes (00-59)
  uint8_t Hours; // BCD hours (00-23)
  uint8_t DayOfMonth; // BCD day of month (0- or 1- based)
  uint8_t Month; // BCD month (0- or 1- based)
  uint8_t YearLO; // BCD year low value (00-99)
  uint8_t YearHI; // BCD year high value (19-22 due to 5-byte time limits)
};

struct rtcdevice {

  struct device dev;

  uint8_t timeformat;

  uint8_t formatflags;

  uint8_t padding2;

  int (readtime)(struct rtcdevice *rtc, struct rtctime *time);

  int (writetime)(struct rtcdevice *rtc, const struct rtctime *time);

};
static inline uint8_t bcd(uint8_t x) {

  return x % 10 + ((x / 10) << 4);

}
static int read_rtc(struct rtcdevice *rtc, struct rtctime *time) {

  time→Centiseconds = bcd(0);

  time→Seconds = bcd(0);

  time→Minutes = bcd(0);

  time→Hours = bcd(7);

  time→DayOfMonth = bcd(8);

  time→Month = bcd(8);

  time→YearLO = bcd(16);

  time→YearHI = bcd(20);

  message(“RTC read\n”);

  return 0;

}
static int write_rtc(struct rtcdevice *rtc, const struct rtctime *time) {

  message(“RTC write\n”);

  return 0;

}
static bool rtc_activate(struct device *d) {

  return true;

}
static void rtc_deactivate(struct device *d) {

}
static int32_t rtc_sleep(struct device *d, int32_t state) {

  return 0;

}
struct rtcdevice rtc_device = {

  .timeformat = 0,

  .formatflags = (1 << 3),

  .readtime = read_rtc,

  .writetime = write_rtc,

  .dev.type = HALDeviceType_SysPeri | HALDeviceSysPeri_RTC,

  .dev.id = HALDeviceID_RTC_Linux,

  .dev.description = “Linux CLOCK_REALTIME”,

  .dev.Activate = rtc_activate,

  .dev.Deactivate = rtc_deactivate,

  .dev.Reset = rtc_deactivate,

  .dev.Sleep = rtc_sleep,

  .dev.devicenumber = -1

};
void HAL_InitDevices(uint32_t flags) {

  OSHdr *h = (void *)(ADDRESS + HALSIZE);

  uint32_t *e = (void *)((char *)h + h→Entries);

  ((RISCOS_AddDevice_t)((char *)e + e[OS_AddDevice]))(0, &rtc_device.dev);

  message(“RTC added\n”);

}

Note that “RTC added” and “RTC read” are printed during boot, and RISCOS5Mark reads “Linux CLOCK_REALTIME”.

The reported bugs that cause it to fail should be fixed, and it should work out of the box given ROOL DDE.

A fresh rom build now completes successfully taking 1min 40s. I had to change one thing in the Makefile. The uname -m command returns aarch64 so it tries to use qemu instead. Changing it to uname -m | grep -q -E ‘arm|aarch64’ fixes it.

Quick builds, that’s great!

I’m trying to find out if I can persuade GCCSDK builder to build gcc with -mlibscl so that it runs without needing the shared unix lib.
The cross compiler already bombs out with error: ‘SUBTARGET_EXTRA_SPEC_FUNCTIONS’ undeclared
So i need to read up some more on how to get GCCSDK built.

I’m trying to find out if I can persuade GCCSDK builder to build gcc with -mlibscl so that it runs without needing the shared unix lib.

You can get the GGCSDK builder to complete successfully by changing line 2229 in srcdir.orig/gcc-trunk/gcc/config/arm/arm.h. Change it to ‘if !defined(arm)’.

I’m trying to find out if I can persuade GCCSDK builder to build gcc with -mlibscl so that it runs without needing the shared unix lib.

You can get the GGCSDK builder to complete successfully by changing line 2229 in srcdir.orig/gcc-trunk/gcc/config/arm/arm.h. Change it to ‘if !defined(arm)’.

will that build me a gcc executable that is linked with -mlibscl ? I use an ARM platform to build GCCSDK.

I just want to say this is an amazing project. I look forward to trying it.

…that is to say, I have been trying to but I can’t get it to build. Trying to build it on Armbian legacy on an Orange Pi PC. Something breaks after a page or so of stuff. Still trying to pinpoint what. The bootstrap userland RISC OS is working. It finds DDE. There’s not much error-y happening.

Trying QEMU SWI hack…/bin/bash: line 16: 2790 Illegal instruction

Is this an error or just a hack for platform detection?

…
bq. BASIC
SYS “IXSupport_LinuxSyscall”,2,,,,,,,1
END
Makefile:53: recipe for target ‘build’ failed
make: ** [build] Error 132

It just seems to work until it doesn’t.

These last few posts are of special interest to me because I haven’t been able to get GCCSDK to build on an ARM platfor because of the SUBTARGET_EXTRA_SPEC_FUNCTIONS problem.

Does this Linux port run properly on aarch64 linux as a native app? My Orange Pi PC2 arrived (H5 SoC). I was just curious because I don’t know how aarch64 handles switching between 32 and 64 bit modes.

Tristian M. wrote:

The bootstrap userland RISC OS is working.

The rest of your post seems to contradict that.

bq. Trying QEMU SWI hack…/bin/bash: line 16: 2790 Illegal instruction

Is this an error or just a hack for platform detection?

It’s a error. The output of “strace mixed/Linux/Support/RISC_OS” might be helpful. However I read that Armbian legacy uses Linux 3.4.113, and this port uses SECCOMP-BPF which was introduced in Linux 3.5, which if OABI support (which causes Linux to pay attention to the SWI number) is also enabled explains the crash.

I have rescued the ptrace SWI intercept code, which allow RISC OS to runs slowly, however there is bug that causes a crash when building RISC OS. Source is on github, and binary is here.

Does this Linux port run properly on aarch64 linux as a native app?

It should provided that 32-bit user code and SECCOMP filter/bpf mode are enabled in the Linux kernel configuration, and according to Chris Gransden it does. It appears from the Linux git commit messages that Linux 3.19 is required.

I’m using ChromeOS which has a 3.18.0 aarch64 kernel.

will that build me a gcc executable that is linked with -mlibscl ? I use an ARM platform to build GCCSDK.

I don’t think it’s possible to do this. Once you have the GCCSDK autobuilder working on ARM linux it will be easier and much faster to use this instead of running gcc natively.

I’m just going to come to the conclusion that it doesn’t like me.

Installing BufferWriteC, RISC OS screen disabled…done
**Obey -c mixed.Linux.Support.Build Linux Linux export_hdrs export_libs resources rom install_rom join
/bin/bash: line 16: 1909 Segmentation fault RISC_OS_Alias_IXFSBoot=‘Exec IXFS:$.dev.fd.4’ ./run mixed/Linux/Support/RISC_OS —nofork 8< . 9< ‘../DDE/AcornC.C++’ 4<<‘END’

Whitespace lines removed so bq sort of works.
That was on the Orange Pi PC2 with mainline kernel. “4.10.0-sun50iw2 #27 SMP Sat Mar 11 06:14:50 CET 2017 aarch64 aarch64 aarch64 GNU/Linux”.
It also fell over on the RPi3 with the illegal instruction issue. I tried dropping that binary in to see if it made a difference. Short answer is no.
Both original and replacement binary both work well as RISC OS Pico I guess you could call it. They work on the RPi3 and the OPi PC2. Haven’t tried the binary on the h2+ Armbian mainline based NAS because NTFS, and haven’t had another try with the OPi PC because it’s running the legacy kernel.

It also fell over on the RPi3 with the illegal instruction issue. I tried dropping that binary in to see if it made a difference. Short answer is no.

I changed the message to “Seccomp-bpf and ptrace not available so trying QEMU SWI hack…” so if you get the same message as before you are running the wrong binary.

Both original and replacement binary both work well as RISC OS Pico I guess you could call it. They work on the RPi3 and the OPi PC2.

Please clarify “well as RISC OS Pico”. So RISC OS works outside the makefile but crashes with an illegal instruction signal without printing “Hello World” in the makefile? Can you find the relevant difference?
The output of strace might be helpful.

I have put Export/APCS-32/C/Global/h/Keyboard in a zip file which should allow you run “make sdl” to build the sdl frontend. Then Test_Wimp and Test_Boot should work.

Installing BufferWriteC, RISC OS screen disabled…done
**Obey -c mixed.Linux.Support.Build Linux Linux export_hdrs export_libs resources rom install_rom join
/bin/bash: line 16: 1909 Segmentation fault RISC_OS_Alias_IXFSBoot=‘Exec IXFS:$.dev.fd.4’ ./run mixed/Linux/Support/RISC_OS —nofork 8< . 9< ‘../DDE/AcornC.C++’ 4<<‘END’

This is different bug. Is it using ptrace, RISC OS will mention it with “Seccomp-bpf not available so using ptrace – This is slow.”.

I still had the terminal open from before with the RPi3 attempt. I put it on pastebin.

This is with the tweaked binary.
http://pastebin.com/raw/tkwnQV1H

This is without. It fails before it loads.
http://pastebin.com/raw/2zHtyMER

Oh wow. I just tried the unpatched RISC_OS on Pi3.
bq. ./RISC_OS
Trying QEMU SWI hack…

That’s it. That’s all it outputs.

I can’t do the results of the different versions of RISC_OS in aarch64 mainline kernel on the H5 right now sorry. It’s doing the longest GCCSDK build in history right now. Pretty sure it really is building the world.

Whilst investigating why strace misbehaves I find that old Linux versions setting the system call number to -1 using ptrace raises SIGILL instead of just skipping the system call. However RISC OS could change the system into something else and arrange for r0 to be restored from the stack.

Unable to allocate logical address space (Error number &1C7)

That is a helpful error message.

To make it more verbose:

RISC_OS_Alias_Obey='If "%0"="-c" Then %Obey -v %*1 Else %Obey -v %*0' make

And to see the memory map:

RISC_OS_Alias_BASIC='Type IXFS:$.proc.self.maps
%BASIC %*0' make

I suspect Linux might be accounting reserved address space as memory.

e: aarch64

Verbose

http://pastebin.com/89QAHMnx page with bash highlighting
http://pastebin.com/raw/89QAHMnx raw

With memory map
http://pastebin.com/A1MNGEW6
http://pastebin.com/raw/A1MNGEW6

One thing that stands oyut to me straight away is:

init mod RamFS => error: RAM disc size too small

RPi3 Armbian with patched RISC_OS

Verbose
http://pastebin.com/XX8M5LjP
http://pastebin.com/raw/XX8M5LjP

Memory map
http://pastebin.com/mn23kGPt
http://pastebin.com/raw/mn23kGPt