Linux Port

I have uploaded a fixed version.

Latest linux rom is now working RPi 4. Thanks.

ARMv8 patch only works for me if I do a fresh clone. No idea what’s up with that.

I had to add DBUS_FATAL_WARNINGS=0 to work around some form of D-BUS error bug during kernel startup.

OpenGL mouse is inverted on the Y axis.

OpenGL screen looks like Win3.1 Hotdog Stand theme. Probably just due to default 8 bit colour depth.

Is there an SD image for RISC OS Linux on a Raspberry Pi 4 available anywhere to download?

Is there an SD image for RISC OS Linux on a Raspberry Pi 4 available anywhere to download?

Download the Linux Binary and extract.

Open folder RISC_OS_Linux_Binary-master in the terminal.

Get the Debian dependencies listed on the site above.

./run_RISC_OS creates the environment and start the Desktop.

It does start on the Raspberry Pi 4 but does not last long, it slows up then seizes up completely. OTOH no one else has reported anything of the sort. I will try another Pi.

P.S. It looks as if the Pi’s default VNC server is a problem. I am editing this with the Linux port on the RPi4, something not possible previously.

P.P.S Except that it seized up after that post.

ARMv8 patch only works for me if I do a fresh clone. No idea what’s up with that.

If you are trying to build the source, did you update the binary submodule using “git submodule update” or equivalent?

I had to add DBUS_FATAL_WARNINGS=0 to work around some form of D-BUS error bug during kernel startup.

There is no reference to dbus in this project so it must be somewhere in SDL (or OpenGL if you tried that frontend).

It does start on the Raspberry Pi 4 but does not last long, it slows up then seizes up completely. OTOH no one else has reported anything of the sort. I will try another Pi.

P.S. It looks as if the Pi’s default VNC server is a problem. I am editing this with the Linux port on the RPi4, something not possible previously.

I have observed the same when trying to use X over SSH over WiFi. The SDL event queue was being filled with requests to redraw the the RISC OS screen which was being done before send input to RISC OS. Fix uploaded.

It is rather dumb and just updates the window every 50ms. I’ve tried using OS_ChangedBox to track screen changes but this does not work with NetSurf or Zap (see the ChangedBox branch).

I think the D-BUS issue is an SDL bug.

I tried git clean -f and git reset —hard

Re above: The RISC OS VNC server works in the Linux port. I know I said a while back but I have a setup where it runs RO Linux with networking and its VNC server, and no frontend on the host. Ie no sdl or opengl.
Depending on configuration it can perform better on the local host than using the local renderer (albeit at a loss of quality). I feel this is because the VNC server can be configured to refresh only when something happens.

I’ve tried using OS_ChangedBox to track screen changes but this does not work with NetSurf or Zap

Thanks for that pointer. Using the latest binary build, 22-Aug-19, and not using NetSurf there have been no further freezes.

Using the Raspberry Pi’s default VNC server was not part of the problem, the Linux port on the headless RPi4 is fine.

I’ve tried using OS_ChangedBox to track screen changes but this does not work with NetSurf or Zap

You could add a PostRectangle filter that does a GCOL5,0:PLOT69,x0,y0:PLOT69,x1,y1 to cover all such cases. You’d need to use OS_SetColour front and back to read and restore the current colour.

Easiest is to manipulate the changed box direct – ChangedBox returns the address of the block. It’s in internal coordinates.

For high vector builds, memory is currently laid out as:

For low vector builds:

For the Linux port it is significantly rearranged:

Any reason not reorder the memory layout of other RISC OS builds to match the Linux port? It would save some conditionals in the source.

Any reason not reorder the memory layout of other RISC OS builds to match the Linux port?

Three reasons come to mind…

Firstly, the location of zero page (&00000000 or &FFFF0000) is defined by hardware and is set up as one of the first things in the system startup. It’s where the processor vectors go, so it’s only up to the OS in as far as “here or here”.

And secondly, our memory locations have evolved since early 32 bit RISC OS and work on a large number of existing ARM boards. I don’t see any justification for changing all of that to support the peculiarities of one specific port, especially considering that…

In your memory layout, what exists between &C0000000 and &FFFFFFF? An entirely different operating system is what. It’s something that doesn’t exist on any native version of RISC OS. So in effect you’re asking if it’s okay for us to mask off a gigabyte (of a 4GiB address range)? Uh, no. Plus, it conflicts with the first point…

Any reason not reorder the memory layout of other RISC OS builds to match the Linux port?

As I mentioned in the other thread, moving the ROM and other fixed/kernel areas down low would make it difficult to dynamically support larger wimpslots in the future (e.g. CMOS setting for 512MB, 1GB, or 2GB wimpslot max size).

Why don’t you retain the current ordering of areas, and just shift the high bits a bit lower down so they’re clear of the Linux areas? That should result in less conditionals, especially if KernelWS is changed to specify the addresses of the high areas as being relative to one another (e.g. using # directives).

Firstly, the location of zero page (&00000000 or &FFFF0000) is defined by hardware and is set up as one of the first things in the system startup. It’s where the processor vectors go, so it’s only up to the OS in as far as “here or here”.

The Security Extensions allow the processor vectors to be placed at any 32 byte aligned logical address. It might also be fairly straightforward to decouple the processor vectors from the zero page workspace – allowing e.g. zero page to be hardcoded to &21900000, but decide the processor vectors location at runtime depending on the capabilities of the CPU.

In your memory layout, what exists between &C0000000 and &FFFFFFF? An entirely different operating system is what. It’s something that doesn’t exist on any native version of RISC OS. So in effect you’re asking if it’s okay for us to mask off a gigabyte (of a 4GiB address range)? Uh, no. Plus, it conflicts with the first point…

I’d assume that with Timothy’s proposal, in non-Linux builds we’d allow dynamic areas to use that spare space (plus the IO region, which isn’t listed at all).

Just removing the y inversion in the mouse function in opengl.cpp fixed my problem. The OpenGL version now seems to work fine.

The location of ZeroPage was an oversight in the question, my concern was with the ordering of Dynamic Areas < Static workspace < ROM versus Static workspace < ROM versus < Dynamic Areas.

I’d assume that with Timothy’s proposal, in non-Linux builds we’d allow dynamic areas to use that spare space (plus the IO region, which isn’t listed at all).

Yes, that was what I meant.

moving the ROM and other fixed/kernel areas down low would make it difficult to dynamically support larger wimpslots in the future (e.g. CMOS setting for 512MB, 1GB, or 2GB wimpslot max size).

That’s a good reason for it to stay as is.

Why don’t you retain the current ordering of areas, and just shift the high bits a bit lower down so they’re clear of the Linux areas?

• CheckMemoryAccess (upstream) requires dynamic areas to be in a continuous region.
• The VDU 5 mode character plotting code requires the ROM and workspace to be outside of the range &40000000 – &8000000.
• The Linux areas are not constant, for eaxplme if running under 32-bit QEMU user mod emulation the limit is about &60000000, and if rinning under 64-bit Linux almost 4GB is available.
  CheckMemoryAccess

CheckMemoryAccess (upstream) requires dynamic areas to be in a continuous region.

But you’d be able to keep all the dynamic areas below the ROM/etc., right? DAs from &20000000 to &B9000000, fixed areas + ROM from &B9000000 to &C0000000, Linux+atomics from &C0000000 to &FFFFFFFF

The VDU 5 mode character plotting code requires the ROM and workspace to be outside of the range &40000000 – &8000000.

Spaghetti assembler – yum.

The Linux areas are not constant, for eaxplme if running under 32-bit QEMU user mod emulation the limit is about &60000000, and if rinning under 64-bit Linux almost 4GB is available.

Do you know how much space the Linux areas are going to take at compile time? If so, it sounds like it’s only the VDU 5 plotting that’s stopping you from shuffling the high bits down. And I think the nastyness could be removed from there by changing it to something like the following:

• Get rid of the charptr address doubling
• change charmask to:
  • bits 0-7 are the pixel mask (as they are now)
  • bit 31 is 1 if single-height, 0 if double-height
  • bit 23 is 1 if double-height, 0 if single-height
• charbyte load & charptr advance changes to:

LDRB charbyte, [charptr], charmask, LSR #31
ADD charmask, charmask, charmask, LSL #8

That should cause bit 31 of charmask to toggle on & off for alternating scanlines when plotting double-height text, allowing it to be used to advance charptr.

Do you know how much space the Linux areas are going to take at compile time?

No.

I have compressed the address space it bit, but the order will stay.

Another problem is that the Wimp assumes that that RISC OS 5 ROM Images are 16MBytes long so if I put the RMA just above the ROM Task Manger fails to shut down the Desktop.

I also found there is at least one crash triggered by placing the the RMA above 2GB. Microsoft Windows restricts 32-bit programs to 2GB unless flagged to avoid similar bugs, 2GB wimp slots could pose many problems.

2GB wimp slots could pose many problems.

Could you not apply some restrictions? Just because a wimp slot could be 2GiB doesn’t mean that it can be. My Pi, for instance, only has 1GiB onboard…

The original Pi and many RiscPC are rather less endowed.

Do you know how much space the Linux areas are going to take at compile time?

No.

Ah, that’s a shame. So the best compromise is likely to be to place the ROM+etc at 2GB, with dynamic areas on either side.

I also found there is at least one crash triggered by placing the the RMA above 2GB.

Yes, there’s at least one known issue related to that (FileCore storing flags in pointers, I think?). Bugs like that are one reason why the larger wimpslot would be an opt-in thing (the other reason being that, as Rick points out, not all devices have enough memory for the larger size to be useful)

I have just tracked down a bug that was causing the Wimp to crash with “SWI &A01005 not known” errors after certain lengthy sequences of wimp mode changes.

Whilst I tried debugging, the bug vanished at the tick of midnight. Setting the previous days date in the !Alarm clock format restored the bug.

I searched the ROM for “SWI &A01005” but didn’t find it, so I instrumented the SWI signal handler, the offending instruction was apparently at 208FA748:

208fa744:       e1a00004        mov     r0, r4
208fa748:       e1a01005        mov     r1, r5
208fa74c:       ef020056        svc     0x00020056
208fa750:       e8bd03c0        pop     {r6, r7, r8, r9}

Which has the right SWI number, but is not a SWI instruction.

I modified the seccomp BPF filter to kill RISC OS on a SWI at 208FA748, that did not fire, however after careful examination I noticed that the return address had the wrong address, but the si_call_addr field had the corret address and the save r0 value was -ERESTARTSYS.

Linux sets the saved program counter value to point to the SWI instruction if r0 = -ERESTARTNOINTR (-513) or if the SA_RESTART flag is set and r0 = -ERESTARTSYS (-512). This is contrary to the documentation:

Results in the kernel sending a SIGSYS signal to the triggering task without executing the system call. siginfo→si_call_addr will show the address of the system call instruction, and siginfo→si_syscall and siginfo→si_arch will indicate which syscall was attempted. The program counter will be as though the syscall happened (i.e. it will not point to the syscall instruction).

I have uploaded a workaround, and will file a bug report against Linux. Let this be a lesson that extending SWIs with magic numbers risks creating hard to find bugs.

I have uploaded a workaround

There appears to be a snag. Try a desktop drag. The previous version, 22Aug19, was OK. This is on a Raspberry Pi 4.

There appears to be a snag. Try a desktop drag. The previous version, 22Aug19, was OK. This is on a Raspberry Pi 4.

I as far I know it’s always been broken in 256 colour modes.

I as far I know it’s always been broken in 256 colour modes.

Thanks, that was it.

And it is because the InverseTable module was missing, I have uploaded fixed source.

I have uploaded fixed source.

Unfortunately I have never been able to build from source.

git clone https://github.com/TimothyEBaldwin/RISC_OS_Dev.git
cd RISC_OS_Dev
git checkout Linux
make

The build hangs in the terminal.

Obey: X /Apps.!WinEdit.!Boot
Obey: 
Obey: /Env.ROOL.Linux
Error: Syntax: *Type [-File] <filename> [-TabExpand] (Error number &DC)
^Z
[2]+  Stopped                 make

That was resolved by removing the trailing ,feb from the Linux component file.

But then :-

 84 331AA514 20020B14  RamFS
Obey: srcbuild -s export_hdrs export_libs resources rom install_rom join
Error: File 'srcbuild' not found (Error number &D6)

This is where I got stuck previously.

The allegedly missing file is available twice at RISC_OS_Dev/Library/Acorn/srcbuild,feb and RISC_OS_Dev/Library/Build/srcbuild,ff8 but this time removing the trailing filetype does not help.

Obey: X /Apps.!WinEdit.!Boot
Obey: 
Obey: /Env.ROOL.Linux
Error: Syntax: *Type [-File] <filename> [-TabExpand] (Error number &DC)
^Z
[2]+  Stopped                 make

It would appear that filetype extensions are not being recognised, of which they are many.

 84 331AA514 20020B14  RamFS
Obey: srcbuild -s export_hdrs export_libs resources rom install_rom join
Error: File 'srcbuild' not found (Error number &D6)

That is an old version from December 2017, I suggest you upgrade it:

git fetch
git checkout Linux2
git pull --rebase
git submodule init
git submodule update

Also what filing system and Linux version are you trying?

I have updated to the latest git commands.

git fetch
git checkout Linux2
git pull --rebase
git submodule init
git submodule update

A build has resulted in the same filetype extension and ‘srcbuild’ not found errors.

Also what filing system and Linux version are you trying?

This is on a Raspberry Pi 4 running on a micro SD card, where gparted reports the root partition as ext4.

One oddity found earlier was that some filetyping had been lost on copying, under Raspbian, a working HardDrive4 folder to a new binary build. Odd indeed!