Linux Port

You could always have a VNC server running on Raspbian and access it that way from within RISC OS, then set up a Samba share to share files. I do that when I need to browse a website that NetSurf wont handle, edit ODT/DOC files or do my e-mail (currently in a webmail interface that NetSurf refuses to use and the firefox port to RISC OS displays in a weird way).

My Debian server is usually headless and I access it all via VNC from RISC OS now…

Much more interested in this if it can get RISC OS running on a netbook/chromebook device and then maybe a bit of software bridging to get WiFi on there too…? That would be awesome!

I just did a completely unscientific comparison.
In the past I’d noticed that the Linux port running on the H5 based Orange Pi PC2 seemed to build RO faster than running natively on my RPi3

I have a copy of my H3 port source tree on both the OPiPC2 and the RPi3. So I set both building at the same time.
There are so very many things that could influence the results. All of which I couldn’t be bothered eliminating.
The OPiPC2 is running some recent version of a mainline kernel’d Armbian. The RPi3 is running a recent ROM.
The RPI3 has a reasonably new 16GB Sandisk USB drive formatted with FileCore.
The OPiPC2 has a 2TB Seagate Backup+ formatted with ext4. They both have 1GB RAM.

Doing a build without doing the clean steps first resulted in this:
OPiPC2: 2:36
RPi3: 5:14

I didn’t clean first because my attention span is only so long. They were both in the same initial state anyway.

The difference could be media based, but I’d be surprised if a backup spinner was faster than a thumb drive.
I feel the difference is in the USB controller. Everything RO would be running in aarch32 anyway, and IIRC the OPiPC2 is clocked slower than the RPi3.
Just thought I’d comment on this because I had to check whether I was imagining the Linux version building so much faster.

Linux will aggressively cache filesystem contents, RISC OS will not. So it wouldn’t surprise me if a fair amount of the performance difference was the result of that. e.g. apart from the final link stage, each build pass will involve invoking amu ~100 times. RISC OS will read the binary from disc each time, Linux will likely just use a cached copy.

each build pass will involve invoking amu ~100 times.

Not to mention objasm, cc, a billion header files, etc etc.

It’s a shame a full installation of RISC OS (built) is ~590MB, otherwise one could try building it entirely on RAMdisc to see how much difference that would make [RAMFS can’t cope with “big” discs, so we’re limited to the half-gigabyte maximum].
Why? Because Untarbz2 unpacks the sources archive to a tar file in 32 seconds, then unpacks the eight and a half thousand files in sixteen seconds (on my Pi2). Compare that with hours to unpack to an SD card…

but I’d be surprised if a backup spinner was faster than a thumb drive

I wouldn’t. I don’t buy thumb drives any more. The majority of them can’t keep up with the MPEG stream coming out of my satellite receiver, unless I’m watching some really low bandwidth channel like horror or True Movies (about 840MB/hour MPEG-2), though some thumb drives can’t even manage to cope with that reliably.
Spinning rust is better, and a decent SD card in a USB adaptor can cope with the insanely over-the-top bitrate that NHK World puts out (~3.5GB/hour MPEG-4; roughly twice the bandwidth of BBC 1 HD!).

You’ll notice, perhaps, that harddiscs often quote seek times and data speeds; while SD cards often quote data speeds and burst speeds (those are the “10000x!!!” markings in bold, useless for sustained writing, mind you); but thumb drives? Just tell you their capacity. I believe that thumb drives are built to recycle all the crappy slow flash chips that won’t cut it in SD/CF/etc cards these days…

I was imagining the Linux version building so much faster.

So…

• Me – Thumb drives are rubbish
• Jeffrey – Linux caches while RISC OS doesn’t
• Everybody else – Linux probably uses all of the cores… ;-)

It’s a shame a full installation of RISC OS (built) is ~590MB

It’s about 305MB when compiled – about 117MB clean. It compiles ok on a ram disc. On an ArmX6 recompiling an already compiled rom on a ram disc takes 22secs and on an SSD it takes 39secs

I find the quickest way to download the sources and have a working copy is to download via CVS.

the insanely over-the-top bitrate that NHK World puts out

Bear in mind that this is the same NHK that began HD broadcasting way back in 1991!

the same NHK that began HD broadcasting way back in 1991!

Uh, they’re Japanese… at 5:3 aspect, they had a 1125 line 60 Hz system in 1972. Apparently their HD recording of the ‘84 Olympics gave Reagan a kick in the ass when he saw the difference between that and America’s NTSC.

Having HD in the early ‘90s wasn’t that big a deal. Remember D2-MAC on satellite? 1152 lines, 50Hz, 16:9.

Oh, by the way, back in the ’70s NHK also created a monochrome HD format that ran at 50Hz and gave a staggering 2125 lines at 4:3 aspect. But people in general preferred to trade off resolution for colour.

Wow, 1972?! I hadn’t heard of that one. Research time! :)

Reference from 1981 – https://books.google.fr/books?id=czq6dx0uvBYC&pg=PA40&lpg=PA40&source=bl&ots=5cvzxA-wQd#v=onepage&q&f=false Popular Electronics magazine. Starts at the bottom right of the page. Let me know if you find anything further that isn’t just copied from Wikipedia or NHK.

It’s about 305MB when compiled – about 117MB clean.

Yeah. I just realised. When I did a count of the directory… Uh… It would have included the source archive and the tar file…
<facepalm>

is to download via CVS.

It would be nice to have regular updates instead of periodically rebuilding from scratch, but CVS never seemed to want to work for me… It’s a shame the update archives (daily/weekly/monthly) are in CVS form and not just a nice draggy-droppy bunch of files.

Just a Test msg from WebsterXL

CVS never seemed to want to work for me

CVS is handy for fetching parts of the riscos source tree. For example to ensure I was using the latest LanManFS for the test module I made, I downloaded the sources for it with:

roolcvs export -r HEAD castle/RiscOS/Sources/Networking/Omni/Protocols/LanManFS

which downloaded to the current directory.

The !CVS app that is included with the CVS distribution sets up aliases ‘roolcvs’ to access the rool site, ‘bsdcvs’ to access the netbsd site and it has mycvs commented out if you want to use an alias for your own cvs repository. Using aliases just makes it easier to switch between different repositories.

If you use ‘checkout’ instead of ‘export’ then the directories have the CVS directories in them. If the current directory is changed to a directory containing a CVS directory then you only need use the ‘cvs’ command as it will use the repository named in the CVS directory. So in your own repository you would ‘checkout’ a project with ‘mycvs’ change the current directory to inside the checked out directory and then just use ‘cvs’ to manipulate the repository and ‘checkin’ your changes.

Just a Test msg from WebsterXL

A blast from the past!

Everybody else – Linux probably uses all of the cores… ;-)

I have hacked parallel build support into srcbuild, using Linux fork system call. I needed to work around a number of assumptions of sequential builds in the RISC OS source.
It enabled by default by my Linux Makefile.

I have add an insecure mode to the Linux2 branch so you can use it if Bubblewrap doesn’t work. For example:

RISC_OS__INSECURE=YES ./run_RISC_OS
make INSECURE=YES

Tristan, please can you test this?

I have joined up the history of the Linux and Linux2 branches, using replace refs. You can fetch them with:

git fetch origin Linux2 refs/replace/*:refs/replace/*

You can then use git bisect on it, for example automatically:

git bisect start Linux2 Linux
git bisect run sh -c 'git clean -fxd; git submodule update; make check'

I have bought my first Chromebook, an Asus C201PA (RK3288 4MB/16MB) If all else fails, it will still be a great portable internet machine, and I have ordered a car charger. My Blackberry Z30 does an effortless mobile hotspot and can possibly relay gps position via gpslink.
Boots/closes down the OS faster than anything too.
A bit of learning to do with hot keys, but much nicer than touch screen interface IMO.

I will be installing a dual boot debian for veyron speedy by the looks of things so far.
ISTR the kernel will be 4.x
Any advice on whether the install would be better on internal drive, sd card or usb stick?
Using the internal drive might require extra work/care, as doing a powerwash from ChromeOS wipes everything I think.
I’m looking forward to trying the Linux port, Thanks

You can override the decision to use QEMU by setting the QEMU make variable to /usr/bin/env:

make QEMU=/usr/bin/env

I’ll test it as soon as I can. Any preference regarding what I test it with?

I’ve had a couple of edge case failures. Not surprising but I might as well list them.

The old VIA chipset tablet couldn’t build because its old kernel doesn’t support SYS_renameat2 (I think that’s what it was) in comma2attr.

The OPiZero (H2+) could build it mostly. It just fell over because RDP doesn’t seem to support xrandr. So again, not the code’s fault. It did essentially build though.

Success on OPiPC2, I think. Running via just “run_RISC_OS” or the desktop script results in a failure. “Can’t remount readonly on /newroot/: Invalid Argument”. However it does boot fine with “RISC_OS__INSECURE=YES ./run_RISC_OS”. This is after building with “make INSECURE=YES”.

The old VIA chipset tablet couldn’t build because its old kernel doesn’t support SYS_renameat2 (I think that’s what it was) in comma2attr.

That’s now fixed, if SYS_renameat2 isn’t defined it just uses rename, with the risk of deleting your files if there are conflicting file names written concurrently. It already coped with the kernel not supporting renameat2, but not the definition being missing from the C library.

That’s now fixed

I’ll bring the tablet out again probably tomorrow and test it. I just finished doing a quick test on the OPiPC2 by doing a ROM build. Nothing seemed to break. It’s running kernel 4.14.70-sunxi64
I will also work out where I put the HDMI adapter so I can do a test with the RPi Zero, because of it’s odd behaviour with sometimes trying to use QEMU. Besides a little fiddling to get it optionally working as a network gadget, it’s just running stock Raspbian Stretch.

e: Bonus content. I tried !Doom on the OPiPC2. Last time I tried it it didn’t work. I still have to run !RunImage directly, because of a missing sound SWI IIRC, but it runs, and well at that.

e again: SOmething has bothered me for a while. in run_RISC_OS line 77 is it supposed to be eval “bwrap_extra=($RISC_OS__BWARP_EXTRA)”

Success on OPiPC2, I think. Running via just “run_RISC_OS” or the desktop script results in a failure. “Can’t remount readonly on /newroot/: Invalid Argument”.

Fixed. I was inadvertently relying on Bubblewrap 0.3.0 behaviour.

This is after building with “make INSECURE=YES”.

Was “INSECURE=YES” required? Or is “QEMU=/usr/bin/env” sufficent? Delete the “Built” directory to reset the detection logic.

Which order would you like me to try things in? I didn’t try “QEMU=/usr/bin/env” at all. The bubblewrap failure tended to flow through to QEMU, so I tried INSECURE=YES first.

I just noticed something. There is a “build” and a “Build” directory in the “RISC_OS_Dev” root. “Build” being new. I think I’ll completely delete the repository and re clone it before trying again.

To completely clean a Git work tree and reset to current branch it is sufficient to:

git clean -fxd
git reset --hard

And to rest to the upstream Linux2 branch:

 clean -fxd
git fetch origin -pt
git reset --hard origin/Linux2

You could do the tests in order from most likely to work to most features:

1. INSECURE mode
2. Then delete “Bulit”, and try “make QEMU=/usr/bin/env” (Bubblewrap, but no automatic QEMU).
3. Delete “Built” again, and test the automatic non-use of QEMU with “make”.

I suspect your problem is that you did not have a working copy of Bubblewrap and that this lead an earlier version to try to use QEMU and it remembered that decision. I have now fixed that bug and it will fail if Bubblewrap is not present unless you use INSECURE mode.

Due to the error message you quoted I believe you now have a working version of Bubblewrap and it will now work correctly.

It’s late so I just tested “RISC_OS__INSECURE=YES ./run_RISC_OS” on the OPiPC2. Builds and runs with no errors that I could see. I’ll try the other two tomorrow. That was by far the best result to date.