RISC OS Open
Safeguarding the past, present and future of RISC OS for everyone
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Code review →

Linux Port

Subscribe to Linux Port 415 posts, 54 voices

Posts per page:

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... 17

 
Apr 10, 2017 11:21pm
Avatar Tristan M. (2946) 1034 posts

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.

 
Apr 11, 2017 5:42pm
Avatar Chris Gransden (337) 1098 posts

‘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.

 
Apr 12, 2017 9:48pm
Avatar Tristan M. (2946) 1034 posts

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.

 
Apr 12, 2017 11:39pm
Avatar Ronald May (387) 407 posts
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/

 
Apr 13, 2017 12:58am
Avatar Tristan M. (2946) 1034 posts

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.

 
Apr 13, 2017 2:31am
Avatar Ronald May (387) 407 posts
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.

 
Apr 13, 2017 9:41am
Avatar Tristan M. (2946) 1034 posts

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.

 
Apr 14, 2017 9:19am
Avatar Tristan M. (2946) 1034 posts

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


 
Apr 14, 2017 9:59am
Avatar Jeffrey Lee (213) 6017 posts

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.

 
Apr 14, 2017 10:30pm
Avatar Ronald May (387) 407 posts
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.
and about the Plus 2
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)
Looks like the 2E is the current model with work towards full linux support, but IMO sunxi products support probably should be studied carefully before buying, and be ready to use them in a more realistic fashion than what they advertise.
Edit: The Plus 2E boards currently for sale at alibaba have no sata ports or anything much over and above the PC2.

 
Apr 14, 2017 11:52pm
Avatar Tristan M. (2946) 1034 posts

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.

 
Apr 16, 2017 11:52am
Avatar Timothy Baldwin (184) 242 posts
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.

 
Apr 16, 2017 12:10pm
Avatar Steve Pampling (1551) 7334 posts

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.

 
Apr 16, 2017 1:10pm
Avatar Tristan M. (2946) 1034 posts

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

 
Apr 16, 2017 3:49pm
Avatar Timothy Baldwin (184) 242 posts

__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.

 
Apr 16, 2017 10:06pm
Avatar Tristan M. (2946) 1034 posts

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?

 
Apr 16, 2017 10:57pm
Avatar Timothy Baldwin (184) 242 posts

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.

 
Apr 18, 2017 5:14pm
Avatar Timothy Baldwin (184) 242 posts

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

 
Apr 19, 2017 11:44am
Avatar Tristan M. (2946) 1034 posts

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.

 
Apr 19, 2017 6:53pm
Avatar Chris Gransden (337) 1098 posts

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



 
Apr 20, 2017 11:19am
Avatar Matthew Phillips (473) 603 posts

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.

 
Apr 20, 2017 9:20pm
Avatar Tristan M. (2946) 1034 posts

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.

 
Apr 21, 2017 3:14pm
Avatar George T. Greenfield (154) 650 posts

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?

 
Apr 21, 2017 10:52pm
Avatar Tristan M. (2946) 1034 posts

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.

 
Apr 21, 2017 11:08pm
Avatar Timothy Baldwin (184) 242 posts

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.

Next page

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... 17

Reply

To post replies, please first log in.

Forums → Code review →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

Developer peer review of proposed code alterations.

Voices

  • Tristan M. (2946)
  • Chris Gransden (337)
  • Ronald May (387)
  • Jeffrey Lee (213)
  • Timothy Baldwin (184)
  • Steve Pampling (1551)
  • Matthew Phillips (473)
  • George T. Greenfield (154)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys