Linux Port

I swear this hates me. Getting closer at least.

blah blah...
linux.netfilter_arp
linux.hdlc
linux.netfilter_bridge
linux.dvb
asm
asm-generic
Dir ^

LinuxSyscalls (mixed.Linux.Syscalls)...
CDir h
do <Perl$Dir>.perl GenSyscall > h.syscalls
CDir h
do sed -n -e 's/^\(.\)define \(_\(_ARM\)\?_NR_[_a-z0-9]*\)[ \t].*$/\1ifdef \2\nDEF(\2)\n\1endif/p' < <Lib$Dir>.Linux.asm.h.unistd > h.syscall_list

It’s hung up on the last bit with a core pegged at 100% with no signs of life. Used memory size hasn’t changed. This is in aarch64. The kernel build is maybe two days old. It’s 4.10.0-sun50iw2 running on an AllWinner H5.

Things aren’t completely broken because it made it further than usual. I managed to build a “normal” version of rpcemu this morning on it. I used it to extract DDE for this build attempt.

‘sed’ is one of the commands that contains the ‘SWP’ instruction. If you use !PatchSWP the build should get further.
It looks like the later aarch64 kernels don’t have ‘SWP’ emulation enabled. diff, gawk and grep will also need patching.

Hi Chris. You just named 3/3 of things that have been giving me issue!
I don’t have the OPi PC2 plugged in right now so I haven’t tried it but I did have success finally last night building the Linux port with desktop on the OPi PC (ARMv7, legacy kernel needing ptrace).

I can’t give any speed estimates because I have nothing to compare it with. “Meteors” seemed to run at full speed without artefacts, but I don’t know how to control it or even if I could.

I also compiled a “Hello World” with DDE which worked fine as expected.

success finally last night building the Linux port with desktop on the OPi PC

Good news, I just noticed the Orange Pi Plus2 $49US has sata and wireless. it will be interesting to see what the audio output is like.
http://www.orangepi.org/orangepiplus2/

Ronald, I had to look that one up. They’ve squeezed so many models out. Looks like the price almost doubles for that SATA port. The Orange Pi Plus2E is AUD$47.38 which has a TF slot in the place of the SATA data and power port.
Looks like the Orange Pi Plus2 packs a lot of punch for an ARMv7 board. It has a USB hub chip though. I have to wonder what they are shunting through it because the PC, PC2 and I think the Zero that I have just use the direct to SoC USB lines. Hopefully the SATA chip is a direct connected one, because it’d have to be USB → SATA surely. If you don’t mind schematics the board designs are open so they are available to download on the product page.

When I went to look I saw yet another new model (This week?) The Orange Pi Win. Looks like they are aiming to fill every permutation of ARM board! Looking at the specs it’s kind of an alternate universe RPi 3, except it has 1000MBit ethernet, an SPI boot rom and optional eMMC flash. It also has a USB hub chip. Blergh. They need to slow down!

I tried the sound on my OPi PC2 out of curiosity. It’s okay. Definitely needs a preamp or amplified headphones and maybe some equalizer twiddling. My DAC board on the Pi3 is still better but the PC2 is pretty good.

Anyway back on topic. I’ve separated out the files I need for the Linux RISC OS port and I’m going to start throwing programs at it to see what functions.

Hopefully the SATA chip is a direct connected one, because it’d have to be USB → SATA surely.

The picture has a sata chip on the (larger sized than most) board.
I think for your board
http://linux-sunxi.org/File:ORANGE_PI-PC2-V1_2_schematic.pdf
They have spdif out on the gpio which saves breaking out from HDMI.
On a different site I2S is also available for audio, Never done it but I think allows direct connect to a DAC chip.
My guess it would cover 44100/48000 at a minimum which over the spdif should guarantee clear audio for 99% of audio/video audio playback. I’m leaning towards higher rates being more important for recording, so it wouldn’t be a calamity if it couldnt play them back.

Ehhh.I picked up an odd thingy at a garage sale last weekend which does the HDMI breakout and input via digital and analog.

The DAC I use on my Raspberry Pi 3 is I2S. Works great.

I played some more with the Linux port and realised I’m a spaz that has no idea what I’m doing. I had a quick attempt at using a HardDisk4 image to flesh it out a bit. Didn’t exactly work so I deleted it.

You’ll be pleased to know that it passed one of the most important metrics of any system with some qualifications. I got DooM running in it. Trying to run !DOOM just yeilds an SWI error but if !RunImage is run directly it runs. Problem was it was at the wrong colour depth and messed up the colours in RISC OS afterward. However it did run at a good framerate and keyboard worked properly.

I tried aarch64 again on a mainline kernel after patching the suggested programs and a few others.

Still didn’t finish building but it’s the furthest I’ve made it on aarch64 so far.

FileCore (castle.RiscOS.Sources.FileSys.FileCore)...
do mkdir -p o
objasm -o o.FileCoreErr s.FileCoreErr -I<Hdr$Dir>.Global,<Hdr$Dir>.Interface
ARM AOF Macro Assembler 4.03 (Acorn Computers Ltd) [15 Oct 2015]

Internal error: undefined instruction at &33140F10

Postmortem requested
33140f0c in unknown procedure
cc50 in anonymous function
33141c84 in unknown procedure
8bc4 in anonymous function
  Arg2: 0x00008b34 35636 -> [0xe1a0c00d 0xe92dd870 0xe24cb004 0xe15d000a]
  Arg1: 0x00073ba8 474024 -> [0x416a624f 0x2d206d73 0x53435041 0x332f3320]
3311355c in shared library function
4a9f0 in anonymous function
AMU: *** exit (1) ***

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

Error running make export (hdrs) on module 'FileCore'.
Fatal error running make export (hdrs) on module 'FileCore'.
Batched errors...
Error running make export (hdrs) on module 'FileCore'.
------------------------------------------------------------------------------
ARM BBC BASIC V (C) Acorn 1989

Starting with 33550588 bytes free

Program renumbered

RISC OS terminating with exit code 1

Makefile:55: recipe for target 'build' failed
make: *** [build] Error 1

FWIW I’m currently working on rebuilding all of the UnixLib/GCC based tools to use GCC 4.7.4r3. So in a day or two there shouldn’t be any SWP patching required.

Blergh. They need to slow down!

The linux-sunxi.org site has some eye opening facts.
Apparently the Plus 2 was overated at 1.6Mhz and the boards are a disaster support-wise. You are right about the USB/SATA
quote

Named pretty similar the cheaper Orange Pi Plus 2E adds Realtek RTL8189FTV SDIO-based WiFi directly on the board (as opposed to a soldered-on module), exposes all USB host ports without an internal hub and saves the slow GL830 USB-to-SATA bridge.

Named almost similar the more expensive Orange Pi Plus 2 is rather different due to another USB setup (using a slow onboard USB-to-SATA bridge and an internal USB hub leading to shared USB bandwidth) and an older WiFi implementation (RTL8189ETV instead of RTL8189FTV now used)

Jeffrey, I look forward to attempting to build your port on ARMv8 devices once your 4.7.x rebuild is done. Now I have it working on the OPi PC and have given it a good try I’m even more amazed with what has been achieved.

Ronald. Nothing I run has the 1.6GHz clocking. Usually they are run at 1.2GHz maximum.
One of the reasons I got the OPi PC2 is because it is very similar to the Pine64 and there was talk about the PineBook(?) on this forum. As said I also wanted something that was aarch64 that actually had an aarch64 OS.

Support and being the “Original” SBC of the current wave are why Raspberry Pi is so popular. I have three myself.
However I’ve only played around with the included software in Raspbian a few times, and find their backported custom OS infuriating at times. On the other hand RISC OS is a great OS for the RPi.
I don’t think I’ve ventured much to linux-sunxi.org. Mostly to the Orange Pi forum and the Armbian forum.
All three of my OPis use Armbian. The Zero and the PC2 use the mainline kernel and the PC uses a Jessie build of Armbian with the legacy kernel.
I totally agree about careful research before purchasing. I still want to try a native RISC OS port to the OPi PC because it’s hardware seems relatively easy, especially with U-Boot doing the initial housekeeping.

I actually prefer the OPi PC and PC2 for coding over the RPi3 so I use them more. If networking gets added to the linux port at some point it’ll make a great platform for compiling, crosscompiling and testing all in one package.

Speaking of crosscompiling. GCCSDK 4.7.x can be compiled for aarch64. It’s what I use. It’s just all the copies of config.guess and config.sub (and configfsf.guess and sub) that it pulls from the aether need to be replaced by fresh versions. So build, fail, copypaste, repeat. Just thought I’d mention that because it’s useful.

e: Forgot to say, the OPi SBCs run a faster generation of RAM than the RPIs. Combined with the hubless USB (on the ones I have) the system is noticably more responsive and handles heavy disk / network IO better than the RPIs, IMHO anyway.

objasm -o o.FileCoreErr s.FileCoreErr -I<Hdr$Dir>.Global,<Hdr$Dir>.Interface
ARM AOF Macro Assembler 4.03 (Acorn Computers Ltd) [15 Oct 2015]

Internal error: undefined instruction at &33140F10

That’s a SWPB instruction in the shared C library, which is attempted because OS_PlatformFeatures was unfinished.

I fixed OS_PlatformFeatures yesterday hopefully (does it work on ARMv6?) and have just uploaded a fixed binary. You will need to run git submodule update to download it.

I’ve also added UnSqueezeAIF which stops SparkFS randomly crashing on loading due to it being squeezed with a broken version of squeeze.

I’ve also added UnSqueezeAIF which stops SparkFS randomly crashing on loading due to it being squeezed with a broken version of squeeze.

I assume you’ve emailed Mr. Pilling about the issue.

Ever closer on my aarch64.

Error of the day:

HAL_Linux (mixed.Linux.HAL)...
objasm -depend !Depend    -g -ihdr -i<Hdr$Dir>.Global -i<Hdr$Dir>.Interface -i<Hdr$Dir>.Interface2 -pd "APCS SETS \"APCS-32\"" -pd "Machine SETS \"Linux\"" -pd "UserIF SETS \"Sovereign\"" -APCS 3/nofp/noswst -pd "ro_size * 0x33004000 - 0x33000000" -o o.Tests s.Tests
ARM AOF Macro Assembler 4.03 (Acorn Computers Ltd) [15 Oct 2015]
Error: Undefined symbol at line 58 in file s.Tests
   58 00000014         MOV     r7, #__NR_write
Error: Undefined symbol at line 172 in file s.Tests
  172 00000660         MOV     r7, #__NR_write
Assembly terminated: 
2 Errors, 0 Warnings
AMU: *** exit (1) ***

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

Error running make export (libs) on module 'HAL_Linux'.
Fatal error running make export (libs) on module 'HAL_Linux'.

Today it’s an undefined symbol in Tests.s

__NR_write should be defined as 4 in Export/APCS-32/Hdr/Interface/LinuxSyscalls, which should be generated by mixed/Linux/Syscalls/Makefile using Export/APCS-32/Lib/Linux/asm/h/unistd and mixed/Linux/Syscalls/c/gen_header.

Something’s just not happening somewhere. Time to pipe the build output to a file I guess. LinuxSyscalls is generated but there’s no sign of __NR_write. The file including newline at the end is 46 lines long. I’m guessing it should be somewhat larger?

It looks like it’s failing at sed like in your post of 10th April, resulting in all the Linux system calls being missing.

There should be a log in BuildSys/Logs/Linux_rom.

I’ve updated the binaries in my GIT repository to the new ARMv8 binaries.

The binaries seem to work perfectly if not better!

I just did a flatten and reinstall of the repo I guess you could say, and tried building it on the OPi PC2 (The aarch64 thing). It eventually failed because it couldn’t find sdl.h etc. I’m too tired to work that out right now. I think I just symlinked to the apt installed header directory last time maybe. Besides that it seemed to build perfectly. It also did everything incredibly fast. I’m not sure if using the newer gcc branch does better optimization but it was building faster than the terminal could refresh.
Very nice job.

I should clarify it built RISC_OS fine. It just fell over with the Wimp stuff because I nuked the repository and haven’t set up the supporting files. I’m looking forward to playing with this some more after I get over today. It’s an amazing piece of work.

I managed to run a few benchmark programs. Gives an idea how much faster Cortex-a72 running RISC OS can be compared to Cortex-a15 in the Titanium.

                      Titanium @1.5Ghz  Cortex-a72 @2.11GHz
Dhrystones per Second:  4830918.0	7662835.0

CHAIN"CLOCKSP"
BBC BASIC CPU Timing Program

Real REPEAT loop     	19617.22MHz	45555.55MHz
Integer REPEAT loop  	12447.91MHz	26555.55MHz
Real FOR loop        	28131.86MHz	39384.61MHz
Integer FOR loop     	27812.50MHz	35600.00MHz
Trig/Log test       	105846.15MHz	172000.00MHz
String manipulation  	28088.80MHz	55961.53MHz
Procedure call       	16770.83MHz	35000.00MHz
GOSUB call           	20689.65MHz	69230.76MHz
Combined Average     	34015.69MHz	62778.68MHz

Compared to a 2.00MHz BBC B

Flops (Double Precision)

   MFLOPS(1)       =   518.7841		1623.4146
   MFLOPS(2)       =   406.3068		992.0204
   MFLOPS(3)       =   614.6358		1412.2804
   MFLOPS(4)       =   760.8099		1702.3018


SciMark2

Composite Score:          416.44	662.77
FFT             Mflops:   387.61	755.08
SOR             Mflops:   344.10	591.09
MonteCarlo:     Mflops:   161.22	249.71
Sparse matmult  Mflops:   510.01	699.05
LU              Mflops:   679.27	1018.91

Whetstones (Single Precision)

MWIPS    		1082.179 	2128.779

povray -w1024 -h768 +a0.3 teapot.pov

			8.5secs		4.43secs

sdlquake 1024x768  (timedemo demo1)

fps			47.5		110.5

So what are you comparing, Chris? Are both machines running native RISC OS, or is one (or both) running RISC OS in Linux?

I hope someone is going to show this at Wakefield: I’m having trouble following what has been achieved by the Linux port.

I’m having trouble following what has been achieved by the Linux port.

Broadly speaking from a user perspective it’s like rpcemu but not.
RO is running kind of like a complex API layer. On an ARM based machine running linux with a newer kernel RO has the least degree of fudging and runs essentially as fast as any other application running in Linux.

It allows the use of RO on as yet unsupported platforms.

RO is running kind of like a complex API layer.

Sorry if I’m being thick, but does that mean you can run mainstream apps like Photodesk, OvPro, NetSurf etc on the RO Linux port, as is possible with RPCEmu? From the various benchmarks posted from time to time, it would appear that the Linux port (unlike RPCEmu) doesn’t suffer from any significant emulation overhead, and presumably can access hardware features currently unavailable to native RISC OS such as multiple cores and hardware acceleration. Sounds like the best of all worlds – is there a downside?

You’re not being thick. It’s an unusual concept. I just want to state straight off that I’m not involved in developing it. I just have a variety of ARM based SBCs that I can throw the builds at and see what sticks.
I can say currently it’s pretty incomplete. Many features and pieces of software don’t work at this point. I don’t think networking has been implemented yet so NetSurf would be pretty useless :)

You are correct in that an ARM based device with recent Linux kernel incurs very little overhead.

RISC OS Linux is still RISC OS so it’s only able to use a single core as far as I know. I don’t know if there are any plans to thread any of the lower level stuff, but the usual Wimp co-operative multitasking is a gigantic can of worms discussed elsewhere on the forum. RISC OS in general needs a lot of work to be able to take advantage of multiple cores.

Hardware acceleration is an interesting one. I have no idea. What manner of hardware acceleration are you thinking about? RPi can use Khronos for OpenGLES I think, but that’s a hardware specific thing working with the Broadcom blob I believe. I think if the Linux port had hardware acceleration at any point it would be hardware, or port specific too.
As for 2D acceleration, I’m a little curious about that. The Linux port uses SDL2 for IO including a render surface for the Desktop. I’m not sure if SDL can take advantage of any harware acceleration the host has.

There is another neat feature of the Linux port. The desktop runs in an SDL window. However just RISC OS without the desktop can be run as a Linux CLI program.

I haven’t as yet got RO Linux port working with desktop on my aarch64 SBC because of something weird with finding the SDL libs, but as a CLI program it absolutely flies. I couldn’t believe how fast it could do the ROM build.

Sorry if I’m being thick, but does that mean you can run mainstream apps like Photodesk, OvPro, NetSurf etc on the RO Linux port, as is possible with RPCEmu?

It is unfinished, there is no network or sound. However NetSurf works with local files, and I would expect Photodesk and OvPro to work.

From the various benchmarks posted from time to time, it would appear that the Linux port (unlike RPCEmu) doesn’t suffer from any significant emulation overhead,

People keep running the wrong sort of benchmarks and measure hardware performance instead of software performance, in particular SWI instructions are slow, when I removed most use of SWI instructions from the kernel, FileSwitch and the shared C library it compiled twice as fast. Also currently a lot of CPU time is used constantly copying the RISC OS screen memory to the screen,

What to benchmark:

• SWI Instructions
• Dynamic Areas
• OS_SynchroniseCodeAreas
• Filing System
• OS_ValidateAddress
• Interrupt Latency

and presumably can access hardware features currently unavailable to native RISC OS such as multiple cores and hardware acceleration.

No more than Rpcemu, except that programs can make Linux system calls.

Sounds like the best of all worlds – is there a downside?

Some compatibility problems, since it runs in user mode, any program that relies on privileged instructions won’t work properly. Also low level memory APIs don’t exist, and it’s unfinished. If you run it on qemu on x86-64, it may be slower than Rpcemu.