Building on ARMv8

Can anyone confirm that RISC OS builds successfully on ARMv8 hardware? (not using my Linux port)

The build system contains many programs that are statically linked with a version of Unixlib that contains unguarded SWP instructions, which I would expect to cause it to fail.

On the other hand I would have expected someone would have fixed it if it was broken.

Does this help, https://www.riscosopen.org/forum/forums/5/topics/8985

A suitable bunzip2 is here

I don’t have a RPI3 but after reading the PatchSWP details, it looks like there will be a branch in RISC OS software, as the newly installed instructions are not compatible with Arm < V8. I guess the same thing exists for VPF/neon.
So now we have 26bit, Strongarm, Plain 32bit, VFP/Neon and V8/VFP/Neon, however the latter two are not backward compatible as in previous changes.
The Linux Port project looked very promising, if it uses native processor instructions, I guess it will have similar software branch requirements?

ISTR that ROOL uses faster hardware for building ROMS.

If the Linux Port project becomes a viable alternative to compatibility issues, The Tinker board from ASUS appears very capable. There is no SATA, but a true GBit ethernet port. Not as portable as a chromebook but with a NAS and plenty of memory could be fine for at home. The features like serial with cts etc, and 192/24bit audio, maybe even the 4K HDMI give quite a good performance/price ratio.

I don’t have a RPI3 but after reading the PatchSWP details, it looks like there will be a branch in RISC OS software, as the newly installed instructions are not compatible with Arm < V8.

“A branch in RISC OS software” – Yes, a branch instruction ;-)

The preferred way of dealing with the SWP removal is for software to have two sets of its atomic routines, one set which uses SWP and one which uses the newer LDREX/STREX instructions. Then on startup it can check with OS_PlatformFeatures 0 to see which it should use, and store a flag in workspace or some pointers to the appropriate routines. The LDREX/STREX instructions actually started appearing in ARMv6, and should generally be used in preference to SWP, we just haven’t had much of a reason to update code to use them until now.

I guess the same thing exists for VPF/neon.

VFP is relatively easy to support on old machines – we can create a version of VFPSupport which provides a full software emulation of the instruction set.

NEON is harder. It makes use of instructions in the NV condition code space, so you wouldn’t be able to emulate it on anything before ARMv5 (ARMv4?) simply because the older CPUs treated NV instructions as no-ops. But you probably wouldn’t want to emulate NEON anyway, the overhead of the emulation would make it far slower than even a trivial ARM version of the equivalent code.

The Linux Port project looked very promising, if it uses native processor instructions, I guess it will have similar software branch requirements?

Yes, the Linux port runs the RISC OS programs directly on the CPU, so it will be subject to all the same compatibility issues that we currently have to deal with.

VFP is relatively easy to support on old machines – we can create a version of VFPSupport which provides a full software emulation of the instruction set.

That sounds promising, at least all programs can be built with VFP then.
Having the VFP issue sorted might allow simpler porting of secure connection and compression applications, given that quote:

NEON technology can accelerate multimedia and signal processing algorithms such as video encode/decode, 2D/3D graphics, gaming, audio and speech processing, image processing, telephony, and sound synthesis

Can anyone confirm that RISC OS builds successfully on ARMv8 hardware?

As mentioned in another topic. It does on the RPi 3 but only after patching,

Library.GNU.diff
Library.GNU.gawk
Library.Unix.grep

Library.Misc.decgen.decgen needed rebuilding. !PatchSWP didn’t find any SWP instructions.

These also need patching.

Library.Unix.Sed
Library.Unix.wc

If the Linux Port project becomes a viable alternative to compatibility issues, The Tinker board from ASUS appears very capable. There is no SATA, but a true GBit ethernet port. Not as portable as a chromebook but with a NAS and plenty of memory could be fine for at home. The features like serial with cts etc, and 192/24bit audio, maybe even the 4K HDMI give quite a good performance/price ratio.

My Orange Pi PC2 can do most of that, possibly all. Curious about the audio aspect I found the datasheet. 8 to 192KHz, and 8 to 32 bit resolution. For what it is it’s very cheap but comes along with a lot of “if’s and but’s”.
My personal thought on the Linux userspace port of RISC OS is that it’s a positive thing mostly for people that want to use RISC OS on something portable.
As said, no matter what it doesn’t help with the diversity of ARM devices. I don’t mind recompiling but not everything is open source.

My Orange Pi PC2 can do most of that, possibly all.

Sorry the home website uses javascript to just navigate to another page, so could only read the general info.
No WiFi, is the first thing, I guess it gets down to the price, but the Orange Pi looks to be cheap and nasty in comparison, the ASUS offering has a UK site, with a very informative homepage. Buying ASUS product versus unknown company? no contest there either.

Ronald, that’s not my point. Besides you didn’t mention WiFi. It wasn’t on my list of desired features so I went for a model without WiFi.
My point was more if you are after a set of features to run a RISC OS userland Linux version on there are options because Linux is acting as the HAL.

The Tinker Board looks like a nice bit of kit, and has a RockChip SoC which is a plus. I couldn’t find info on a release price though.

I paid roughly between AUD$10 and AUD$25 for the Orange Pis I have. They work well and serve my purposes. They are well constructed but support for the SoC is the big issue.
AmLogic is supposedly working towards providing better, updated support for their SoCs, but I’ll believe that when (if) I see the end result.

support for the SoC is the big issue

I dont think the Tinker Board would be any better in that respect.
One thing the Tinker board has going for it is it is the same Rockchip that is used in Timothy’s Asus Flip. I researched these and found they are popular, and can still be bought new.
Sadly the only one I spotted for sale in NZ was one that was brought in from the UK by someone and the bidding went to over $400. Chromebooks here seem to be all intel etc.
I think the Orange Pi is a fraction of the price of the tinker board or RPI3 for that matter, and I can see for Linux Port/RISC OS use you may not miss the extras. I like the look of the tinkerboard for a fully fledged home computer capable of running linux at a good rate, and no shortage of high performance i/o (excepting sata, but we know how dear those boards are).

Linux is acting as the HAL.

Library.Misc.decgen.decgen needed rebuilding. !PatchSWP didn’t find any SWP instructions.

decgen is squeezed, xpand first, the SWPs are then revealed.

I tried the latest source and replaced the rebuilt files in GNU and UNIX but still failed building the debugger module at the decgen.encoding.ARM8_AArch32 section
just froze this same source built without a problem on OMAP5432EVM and ran on the Pi3 without errors.

update managed to build my first rom on Pi3 today downloaded the changed files in GNU,UNIX, Misc downloaded current source for BCM2835Dev replaced
files in library, ran prepare to builder on iconbar first build failed same place as before so checked all new files to see if they where the same as new
downloads the only one that was different was decgen so deleted decgen and repleced with new copy rechecked that they where identical all good, then re ran the build
and built my first Rom on Pi3. my Question now is what changed the decgen app when i ran prepare to get ready for the build???

Update
to answer my own question i checked the source again and it only had 1.89 of the library files so re-downloaded and all is good now
built a rom without errors,
Well done again Jeffrey