Linux Port

Hi Timothy and Tristan.

Are either of you based anywhere near London, as we’d love to have a demo of this at a ROUGOL meeting. Drop me an email – http://rougol.jellybaby.net/contacts/index.html

If you’re not near London, contact your local user group and go give them a demo! See here for a list – http://www.riscository.com/calendar/

I’m on the way to the Wakefield Show, and I shall be wearing a name badge I’ve made so you can identify me.

Sorry. I’m just a filthy Colonial. Wrong landmass. Thanks for the offer though!

Last night after beating some sense into my fileserver I tried building the Linux port on it. Like most of my other devices RISC_OS built fine, but the SDL stage fails. Still trying to work out why most (but not all) devices just keep spitting out undefined references to the functions. Everything seems right in the makefiles and the libraries and headers are definitely where they need to be.
So anyway I’m reporting that RISC_OS builds fine on the arm71 toolchain.

Built and functional on Raspberry Pi 3 running Raspbian. SDL also compiles correctly. It uses ptrace which is no surprise.

The systems that built sdl with no issue were both Jessie based. I’m not totally sure but I think later versions of linux need -lSDL2 or whatever explicitly added. I haven’t tried it yet, but I have found some info on the web which hints at it.

Performance is reasonable as long as the window isn’t made too big. That’s really no surprise. It’s probably a silly question but IIRC the bottleneck is because the RO framebuffer is being copied to an SDL surface.

I hate to ask again, but is it possible to use !boot with the Linux port? If so, how? So many things I try just explode in a confetti of text files on the desktop.

I don’t know if it’s a manually configured setting but the build of RISC_OS at the end of it’s boot reports “RISC OS 1024MB” on my H2+ fileserver that has 512MiB RAM.

I was lucky enough to get a demo from Tim at the Wakefield show and it is looking really impressive. It all runs (and fast).

I also got a demo at Wakefield: RiscOSM rendering maps of the Isle of Man. Timothy was running Debian on a Chromebook with RISC OS in a window on that.

I hate to ask again, but is it possible to use !boot with the Linux port? If so, how? So many things I try just explode in a confetti of text files on the desktop.

The Test_Boot script should do everything needed. (currently it boots once in RPCEmu)

It appears from your description the filetypes are not set, as of 18:50 UTC today it can read filetypes of the ,xxx extension style, earlier versions required filetypes in POSIX extended attributes.

If you extract HardDisc4 zip file outside RISC OS you need give the -F to unzip to extract filetypes, and then for older versions use comma2attr convert the filetypes:

unzip -F HardDisc4.5.22.zip 'HardDisc4/*'
find HardDisc4 -depth -exec ./comma2attr -- '{}' +
RISC_OS_Alias_IXFSBoot='/IXFS:$.dev.fd.4.!Boot' ./sdl ./RISC_OS --nvram HardDisc4/CMOS 4</HardDisc4

I don’t know if it’s a manually configured setting but the build of RISC_OS at the end of it’s boot reports “RISC OS 1024MB” on my H2+ fileserver that has 512MiB RAM.

Reported free and total memory is fixed at 1024MiB, it’s not clear what counts as free memory and total memory.

./Test_Boot 
checking build system type... armv7l-unknown-linux-gnueabihf
checking host system type... armv7l-unknown-linux-gnueabihf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable debugging... no
checking whether to use the dynamic recompiler... no
checking for Operating System... Linux
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/media/pi/massive/Coding/src/RO_Dev_RPi3/RISC_OS_Dev/rpcemu/src':
configure: error: C compiler cannot create executables
See `config.log' for more details
mixed/Linux/Support/common.mk:50: recipe for target 'rpcemu/src/Makefile' failed
make: *** [rpcemu/src/Makefile] Error 1
touch: cannot touch ‘HardDisc4/!Boot/Choices/Boot/Tasks/Pinboard’: No such file or directory
sort: cannot read: HardDisc4/!Boot/Choices/Boot/Tasks/Pinboard: No such file or directory
mv: cannot move ‘Pinboard’ to ‘HardDisc4/!Boot/Choices/Boot/Tasks/Pinboard’: No such file or directory
./Test_Boot: line 16: HardDisc4: No such file or directory

This is what happens when I run Test_Boot regardless of system. The path in Linux is different per computer of course but the rest is definitely the same. It downloads the files to ~/Downloads but everything just falls apart from there.

A bit later: I dug around a bit. I had the wrong version of Allegro installed on this device somehow (RPi3) but that wasn’t the issue. gcc was still breaking. This time with a segfault. I had to go build rpcemu from it’s makefile. After that Test_Boot worked. Was it supposed to dump some extra files from HardDisk4 somewhere? I think it copied Pinboard and a few other things but that was it.

I’m having another shot at it now after a git reset.

e: Much better. dev.fd.4 now exists! e: but not in Test_Wimp

last edit, I promise:
I made a script from Test_Boot and Test_Wimp to get everything happening. So far so good. Monitor and resolution change works though Configure. !Boot works fine. The filetype mapping seems to be fine too.
I’m going to start feeding it programs.

No such file

I have had this error from my standard linux gccsdk when the binary itself was corrupt, In my case it had been compiled in an earlier debian and copied over. I guess it could also be the path to the file you are creating not being valid as the error suggests though.

Ronald, all binaries were functioning as far as I could tell. It’s just an odd thing.

Good news! I got it all to build on the Orange Pi PC2 with mainline kernel.

This is from mixed/Linux/Support/common.mk

I added -lSDL2main -lSDL2
I think I mentioned that there were vague mumblings on the internet about the libs needing to be explicitly added with later versions of Linux. It built like this. Seems to work fine. Downside of the kernel / OS combo I’m using is there’s no hardware acceleration beyond the fbturbo X server.

sdl: mixed/Linux/Support/sdl.cpp mixed/Linux/SocketKVM/h/protocol mixed/Linux/Support/sdlkey.h
	g++ -Wall -pthread -g -O2 `sdl2-config --cflags --libs` --std=c++11 mixed/Linux/Support/sdl.cpp  -o sdl -lSDL2main -lSDL2
	setfattr -n user.RISC_OS.LoadExec -v 0x00e6ffff00000000 $@ || true

e: Something I’ve noticed with the port is opening a directory window pegs the CPU core. Not sure what’s happening there.

all binaries were functioning as far as I could tell. It’s just an odd thing.

If you can find where touch is being called in the makefile, maybe you could insert ‘touch —version’ just before to see if it is acting normally. Otherwise I wonder if the make utility or cd is up to scratch for changing directories.

Just as a matter of interest – are the arm tools like &FF8/Absolute ‘cc’ and ‘ObjAsm’ running directly in/on ARM Linux?

If so are are you using them to build a copy of RO ‘ROM’ that runs as a Linux program in User mode on a ARM chip?

Just as a matter of interest – are the arm tools like &FF8/Absolute ‘cc’ and ‘ObjAsm’ running directly in/on ARM Linux?

They are running on RISC OS on Linux.

If so are are you using them to build a copy of RO ‘ROM’ that runs as a Linux program in User mode on a ARM chip?

Yes.

If you can find where touch is being called in the makefile, maybe you could insert ‘touch —version’ just before to see if it is acting normally. Otherwise I wonder if the make utility or cd is up to scratch for changing directories.

Next time I have it plugged in, after it’s updated I’ll check it.
I was torturing the build on the H5 today. Got so close to building a BCM2835 ROM using it but it was failing on joining. egrep was dying with an unspecified illegal instruction. I even yanked a copy from the Linux Port and it didn’t change anything. Weird.

egrep was dying with an unspecified illegal instruction.

• That is an MRC instruction in __get_cpu_arch in UnixLib.
• Grep is linked with Unixlib.
• Grep works because it is patched at load time.
• EGrep loads Grep using OS_File and runs it, since it does not use OS_FSControl 4 Grep is not patched.

The fix I used was to replace calls to egrep to call “grep -E” instead.

I added -lSDL2main -lSDL2

Why -lSDL2main? That should only be needed on Windows, it does nothing on Linux.

I think I mentioned that there were vague mumblings on the internet about the libs needing to be explicitly added with later versions of Linux.

Where are these mumblings?

I am running Debian Stretch, and it works for me as is. What does “sdl2-config --cflags --libs” print?

I’ve added support for resizing the the RISC OS desktop by resizing SDL window. The SDL frontend passes a message to the SocketKVM module which causes the Wimp mode to be changed on the next poll. SocketKVM responds to all Service_ModeExtension calls, thereby allowing modes of any pixel size to be selected. To eliminate flicker the SDL frontend pauses updating it’s window until a null wimp poll occurs.

Alas this has exposed 4 bugs in Pinboard relating to backdrops, which I have fixed.

Why -lSDL2main? That should only be needed on Windows, it does nothing on Linux.

It probably isn’t needed. I was low on time. It seemed to be a common fix for the linking error I was encountering with SDL2. I thought it was a bit questionable but didn’t get to try without.

The mumblings are really just that when hunting for fixes I saw a few references of SDL working fine in Jessie but needing the explicit library in Xenial. I really have no idea why. Bug in sdl2-config maybe?
When I have one of the affected SBCs in front of me I’ll do “sdl2-config —cflags —libs” and post the result.

Alas this has exposed 4 bugs in Pinboard relating to backdrops, which I have fixed.

In the port or in RO? If it’s the latter especially I just want to remind you fixing bugs is a good thing.

In the port or in RO?

In RISC OS. I have sent patches to ROOL.

Results as requested. From the Orange Pi PC2 running Xenial with mainline kernel. Confirmed failure still existed before posting this.

$ sdl2-config --cflags --libs
-I/usr/include/SDL2 -D_REENTRANT
-L/usr/lib/aarch64-linux-gnu -lSDL2

I also just confirmed that sdl still won’t build without “-lSDL2”. Ignore -lSDL2main of course.
With -lSDL2 it builds and works fine. These tests are each after a git clean -f and git reset —hard

e: Unrelated to the SDL issue. How much has the IOMD ROM been tampered with?
I’ve been trying to work out how hard it would be to take a pre baked ROM and boot it using a HAL built using nonstandard means. It’d make porting to other platforms easier for sure.

So sdl-config works, and includes -lSDL2 in it’s output so maybe it’s an ordering issue. The way I had it it would not work with a statically linked library.

How is work going on this?

I’m revisiting trying to build it on the Orange Pi Zero with a mainline kernel. Previously the build would fail catastrophically with a system reboot which I believed was an insufficient power supply. It doesn’t seem to be the case.
I tried again a couple of times last night while watching a couple of terminal windows very carefully. The reboot actually happens a few seconds after the build fails with an SWI error and dumping back to the bash shell.

Currently I’m trying an RPCEmu build in the cruellest way again. Via an ssh X11 tunneled session. The eight hour mark just passed. It just finished compressing the ROM. It’s been chugging away at a whopping average 2.8MIPS.

Just rebuilt from scratch and everything runs well.
Are there some next steps we can take from here, like networking?
Also the gcc issues would be nice to get solved too.

Are there people working with Timothy to help out?

Sorry, I haven’t done much in the last few months but intend ro get back to it soon. I will be busy until next after next weekend.

It’s is just me it seems. I will be writing a proposal for how the low level routines for locking and virtual PSR manipulation are called.

If anyone would like to tackle networking or sound help will be appreciated. For networking both a high level approach replacing the Internet module with a stub that calls Linux system calls, or a low level approach writing a DCI4 driver that sends and receives packets to from a Linux file descriptor witch could be connected to a Linux tap device.

Not all that useful but I’ve given some thought to the network over the past few months. I think the higher level approach makes the most sense because the Linux port is more of an application than an emulation. Some people may find it a little restrictive but I see no reason why looking at it as an application would be a bad thing.

I agree that a stub of sorts makes the most sense. However I’m a little concerned at the potential complexity. I’m assuming that it would be utilising Linux’s network stack, and hopefully passing the configuration data for the network back through to RO.

Given the hushed whisperings which people use when referring to the RO network stack I’m guessing the interfaces aren’t so great either?