Linux Port
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... 20
Tristan M. (2946) 1039 posts |
I swear this hates me. Getting closer at least.
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. |
Chris Gransden (337) 1202 posts |
‘sed’ is one of the commands that contains the ‘SWP’ instruction. If you use !PatchSWP the build should get further. |
Tristan M. (2946) 1039 posts |
Hi Chris. You just named 3/3 of things that have been giving me issue! 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. |
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. |
Tristan M. (2946) 1039 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. 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. |
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. |
Tristan M. (2946) 1039 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. |
Tristan M. (2946) 1039 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.
|
Jeffrey Lee (213) 6048 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. |
Ronald May (387) 407 posts |
Blergh. They need to slow down! The linux-sunxi.org site has some eye opening facts. 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. |
Tristan M. (2946) 1039 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. Support and being the “Original” SBC of the current wave are why Raspberry Pi is so popular. I have three myself. 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. |
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 I’ve also added UnSqueezeAIF which stops SparkFS randomly crashing on loading due to it being squeezed with a broken version of squeeze. |
Steve Pampling (1551) 8154 posts |
I assume you’ve emailed Mr. Pilling about the issue. |
Tristan M. (2946) 1039 posts |
Ever closer on my aarch64. Error of the day:
Today it’s an undefined symbol in Tests.s |
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. |
Tristan M. (2946) 1039 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? |
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. |
Timothy Baldwin (184) 242 posts |
I’ve updated the binaries in my GIT repository to the new ARMv8 binaries. |
Tristan M. (2946) 1039 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. 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. |
Chris Gransden (337) 1202 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 |
Matthew Phillips (473) 719 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. |
Tristan M. (2946) 1039 posts |
Broadly speaking from a user perspective it’s like rpcemu but not. It allows the use of RO on as yet unsupported platforms. |
George T. Greenfield (154) 748 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? 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? |
Tristan M. (2946) 1039 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. 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. 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. |
Timothy Baldwin (184) 242 posts |
It is unfinished, there is no network or sound. However NetSurf works with local files, and I would expect Photodesk and OvPro to work.
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:
No more than Rpcemu, except that programs can make Linux system calls.
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. |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... 20