Linux Port

The strategy for triple buffering I use is similar.
Since the code already uses a shared memory segment, copying the screen data is done in a separate process but with a shared pointer. That reduces it to one fast copy per screen update.
It is a lot faster than the SDL and because it also runs in a separate process there is (hardly) no impact on the RISCOS process.

It seems that SDL needs two copy actions. One to copy it to SDL space and one when X updates.

Triple buffering is simple in either setup, indeed just a pointer.

on the samsung chromebook. not bad score for this old lappie.

Ooh. Nice! Battery life?

I have updated my repository to the current RISC OS 5.25, and included Jan Rinze’s OpenGL front end. The OpenGL frontend does not support palettes in 256 colour modes (yet). Surprisingly it scales the RISC OS screen when the window is resized, unlike my SDL frontend which resizes the RISC OS desktop.

An addition to protocol to report the supported modes is possible. There is currently a race condition in that the screen memory may be shrunk whilst the frontend process is reading it, there is already synchronisation for mode changes. Perhaps coping with errors from Linux system calls and mapping some zeros in a signal handler for SIGBUS will suffice.

Credit should go to Jan for working out the GraphicsV provides the addresses as offsets into the screen memory.

I am working on exporting various interfaces for the HAL as HAL devices. I plan on following HAL devices:

• Banked registers and PSR manipulation
• Atomic operations (Linux compatible)
• Linux specific interfaces such as making Linux system calls, and reading environment variables.

GraphicsV provides the addresses as offsets into the screen memory.

It’s more likely to be the physical address, which just happens to be 0 if it’s the IOMD driver.

It’s more likely to be the physical address, which just happens to be 0 if it’s the IOMD driver.

GraphicsV certainly does use physical addresses, but on IOMD zero would be ROM, not RAM/VRAM.

Internally the kernel tracks them as logical addresses: https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/vdu/vduwrch?rev=4.9#l2199

That is not the case for the Linux port, physical addresses are an alien concept to it. I have conditioned out all code that deals with them.

There are talks about the future of RISC OS on incompatible ARM processors and motherboards. The Linux port is definitively a solution. I hope it will be one day an official platform.

on IOMD zero would be ROM, not RAM/VRAM

Are you sure? DA2 translated from logical to physical is always 0 (tested on a Pi):

DIM block% 12
SYS "OS_ReadDynamicArea",2 TO A%
block%!0=0
block%!4=A%
block%!8=0
SYS "OS_Memory",0+(1<<9)+(1<<13),block%,1
PRINT "Physical Address of DA2: ";~block%!8;" logical address: ";~A%

It way my understanding that on a RiscPC, VRAM is always at physical page 0, so DA2 is always mapped to physical page 0 and up, all other pages are mapped top down.

You’re confusing physical page numbers and physical addresses.

The physical address is a property of the hardware. Physical page numbering is an abstract numbering scheme created by the OS to help it keep track of “general purpose” memory (which includes VRAM on IOMD). Pages are numbered sequentially so the OS can just use a big array (the “CAM”) to track their state.

It way my understanding that on a RiscPC, VRAM is always at physical page 0

Yes, RISC OS 5 and its predecessors set up the physical page numbering such that video memory starts at physical page 0.

However GraphicsV uses physical addresses in its API, so on a real IOMD machine you wouldn’t expect to see addresses of zero being passed across the API. On IOMD, VRAM starts at &02000000, and the first DRAM bank is at &10000000.

You’re confusing physical page numbers and physical addresses.

I’m just going by what the documentation says, both OS_Memory 0 (as in the example above) and GraphicsV 6 state physical addresses.

I’ve just tested on a Pi for DA2, OS_Memory 0 returns 0 and GraphicsV 6 (leaving the call unclaimed so it hits the IOMD driver) gets given the logical address of DA2 – which has now totally confused me as I’d expect it to get an address between 0 and the size of DA2 as noted by Tim above.

I’ve just tested on a Pi for DA2, OS_Memory 0 returns 0

Which is to be expected, since the Pi does contain RAM at physical address zero (and since the RAM is all in one physically contiguous chunk, the start of that chunk will get used by DA 2).

GraphicsV 9 (leaving the call unclaimed so it hits the IOMD driver) gets given the logical address of DA2

Say what? There’s no IOMD driver on Pi, and GraphicsV 9 doesn’t accept an address – it returns one.

Say what?

My mistake, GraphicsV 6 – now corrected.

There’s no IOMD driver on Pi

It falls back to DA2 if there’s no other driver – I presumed that was an inbuilt IOMD throwback.

It falls back to DA2 if there’s no other driver – I presumed that was an inbuilt IOMD throwback.

Yeah, the OS basically just “muddles through” and uses DA 2 for a framebuffer if there’s no GraphicsV driver present. But that’s really just an indication of the hap-hazard way in which the HAL/GraphicsV video support was introduced, rather than an intentional design feature (I believe RISC OS 6 is more sensible, in that the VDU system will shut down completely if there’s no video driver).

Not sure why you’d see logical addresses being passed into GraphicsV 6. Unless it’s just a coincidence that the logical and physical addresses are very similar on a Pi 2? Under current RISC OS versions I’d expect the start address of DA 2 to be somewhere between &34000000 and &32000000 (depending on the current size of the area). Treated as a physical address, that would correspond to a 1GB Pi with 192MB-224MB (or more) reserved for the GPU.

Can someone help me out on this?

The Linux2 branch has been a little problematic for me, especially with the QEMU and bubblewrap dependencies. Long, long story short I’ve got working ARM RISC_OS and sdl executables now.

There is an ARM Linux platform I wanted to use RO linux on, but haven’t been able to build on it. However I found that the two executables run fine on it.

I have two problems.

1: Setting up a simple shell script which loads RO, any IXFS entries and whatever else is needed.

2: The keymapping is weird. Non alphanumeric keys don’t seem to be mapped correctly. Changing region or keyboard via TaskWindow didn’t change anything. Because of this I can’t even try to add a TinyDir because there is no ‘\’ that I can find in the keymapping!

So what I have is a ROM only Linux RO which I have to manually start the desktop, with no filesystem access. On the bright side it seems to be very fast and can run fullscreen or windowed. It’s also running on a 6+ year old Chinese tablet :)

e: I forgot the question!

Could I please get some input on a bare minimum script to get the desktop loaded, and a couple of IXFS entries so I can use a self extracting HD4 file?

Any suggestions on what’s going on with the keyboard? This is only in RO linux. Key mapping seems fine outside it.

e again:

Terrible picture!
https://i.imgur.com/FFeJZInl.jpg?2

There is a script Test_Boot
The script has info on how to start the RISCOS executable with the right environment variables.

export RISC_OS_Alias_IXFSBoot='/IXFS:$.HardDisc4.!Boot'
bwrap --seccomp 9 9< <(Built/gen_seccomp) --unshare-user-try --unshare-ipc \
--unshare-pid --tmpfs / --tmpfs /tmp --proc /proc --dev /dev --ro-bind RISC_OS \
/RISC_OS --bind HardDisc4 /HardDisc4 --chdir /HardDisc4 \
--remount-ro /dev --remount-ro / /RISC_OS --nvram '!Boot/CMOS'

My preference is a less complicated setup.
To facilitate that I used a patch to set the IXFS to default at /RISCOS and place all the Hardisk4 files in that directory.

bwrap is intended to ensure a more secure environment.

chroot could be used if the RISC_OS executable is fully static compiled.

chroot in userspace is allowed when using Linux kernel namespaces.
Mounting /proc and /dev unfortunately is not allowed as non-root.
The accessing both the proc and dev directories from the RISC_OS binary could be changed in more conventional ways. Filedescriptors and dev entries can easily be passed on in the GUI before execvpe().

I’ll take a peek in the bwrap code to see if i can borrow some code to do everything in userspace.

userspace chroot:

int user_chroot(int argc , char** argv, char ** env) {
	// first arg is the directory for chroot.
	// subsequent args are the command to run.
	
    if(argc < 2) {
        return 1;
    }

    int uid = getuid();
    int gid = getgid();
    printf("Before unshare, uid=%d, gid=%d\n", uid, gid);

    // First, unshare the user namespace and assume admin capability
    // in the new namespace
    
    int err = unshare(CLONE_NEWUSER|CLONE_NEWNS);
    if(err) {
        printf("Failed to unshare user namespace\n");
        return 1;
    }

    // write a uid/gid map
    char file_path_buf[100];
    int pid = getpid();
    printf("My pid: %d\n", pid);

    sprintf(file_path_buf, "/proc/%d/uid_map", pid);
    int fd = open(file_path_buf, O_WRONLY);
    if(fd == -1) {
        printf("Failed to open %s for write [%d] %s\n", file_path_buf, errno, 
               strerror(errno));
    } else {
        printf("Writing : %s (fd=%d)\n", file_path_buf, fd);
        err = dprintf(fd, "%d %d 1\n", uid, uid);
        if(err == -1) {
            printf("Failed to write contents [%d]: %s\n", errno, 
                   strerror(errno));
        }
        close(fd);
    }

    sprintf(file_path_buf, "/proc/%d/setgroups", pid);
    fd = open(file_path_buf, O_WRONLY);
    if(fd == -1) {
        printf("Failed to open %s for write [%d] %s\n", file_path_buf, errno, 
               strerror(errno));
    } else {
        dprintf(fd, "deny\n");
        close(fd);
    }

    sprintf(file_path_buf, "/proc/%d/gid_map", pid);
    fd = open(file_path_buf, O_WRONLY);
    if(fd == -1) {
        printf("Failed to open %s for write [%d] %s\n", file_path_buf, errno, 
               strerror(errno));
    } else {
        printf("Writing : %s (fd=%d)\n", file_path_buf, fd);
        err = dprintf(fd, "%d %d 1\n", gid, gid);
        if(err == -1) {
            printf("Failed to write contents [%d]: %s\n", errno, 
                   strerror(errno));
        }
        close(fd);
    }

    // ensure proc and dev are mounted in the new namespace.
    
    // full path here is for example

    if (mount("/proc",
               "/home/janrinze/tmp/RISC_OS_Dev/HardDisc4/proc",
               "proc",
               MS_RELATIME|MS_REC|MS_BIND,
               NULL
               )<0)
	{
        perror("Failed to mount proc");
        return -1;
	};
    
    if (mount("/dev",
               "/home/janrinze/tmp/RISC_OS_Dev/HardDisc4/dev",
               NULL,
               MS_RELATIME|MS_REC|MS_BIND,
               NULL
               )<0)
	{
        perror("Failed to mount dev");
        return -1;
	};
	
    // Now chroot into the desired directory
    err = chroot(argv[0]);
    if(err) {
        printf("Failed to chroot\n");
        return 1;
    }
    
    chdir("/");

    argv++;
    
    // Now drop admin in our namespace
    err = setresuid(uid, uid, uid);
    if(err) {
        printf("Failed to set uid\n");
    }

    err = setresgid(gid, gid, gid);
    if(err) {
        printf("Failed to set gid\n");
    }
    err = execvpe(argv[0], argv,env);
    if(err) {
	printf("Attempt to start %s failed:\n",argv[0]);
        perror("Failed to start command");
        return -1;
    }
}

And the fork code in the GUI:

  pid_t pid = fork();
  if (!pid) {
    prctl(PR_SET_PDEATHSIG, SIGTERM, 0, 0, 0);
    int socket = fcntl(sockets[1], F_DUPFD, 31); // 31 for compatibilty with early RISC OS
    char s[40];
    char *envi[4];
    
    std::cerr << "STARTING RISCOS\n" << "RISC_OS_SocketKVM_Socket=" <<socket<<"\n" ;
    sprintf(s, "RISC_OS_SocketKVM_Socket=%i", socket);
    
    putenv(s);

    envi[0]=s;
    envi[1]="RISC_OS_Alias_IXFSBoot=/IXFS:$.!Boot";
    envi[2]=0;

    sigset_t sigset;
    sigemptyset(&sigset);
    sigprocmask(SIG_SETMASK, &sigset, nullptr);
    
    if (getppid() == self) user_chroot(argc-optind,argv+optind,envi);
    _exit(1);
  }

the proc and dev directory need to be created in the HardDisc4 directory for this to work.

running the GUI and RISC OS:

./Built/opengl ./HardDisc4 ./RISC_OS —nvram /\!Boot/CMOS > /dev/null

To start RISC OS without sandboxing (so rogue RISC OS programs can mess up the Linux environment) and with a GUI you can use ./sdl ./RISC_OS, or the Jan Rinze’s OpenGL front end ./opengl ./RISC_OS

RISC OS will except input on standard input so you can workaround broken key-mapping by running it in a terminal and typing in the terminal.

You can then open a RISC OS filer window with the RISC OS star command Filer_OpenDir IXFS::$.

To start RISC OS with auto-booting and NVRAM use something like:

RISC_OS_Alias_IXFSBoot='/IXFS:$.home.someuser.HardDisc4.!Boot' ./sdl ./RISC_OS --nvram '/home/someuser/HardDisc4/!Boot/CMOS'

chroot in userspace is allowed when using Linux kernel namespaces.

You mean without system-wide root privileges. “In userspace” means from software running in USR mode, as opposed to the kernel or kernel modules which run in SVC mode.

Mounting /proc and /dev unfortunately is not allowed as non-root.

You need your own PID and mount namespace to mount proc. /dev is typically a tmpfs and you can mount fresh instances as long as you have your own mount namespace. You can not however create device nodes, but you can bind mount them onto regular files.

RISC OS only uses /dev on Linux versions before 3.17 (a clone of CryptRandom reads random numbers from /dev/urandom, after 3.17 the getrandom system call is used).

so rouge RISC OS programs can mess up the Linux environment

So is this the common typo for “rogue” which appears in many of [substitute favourite dyslexic poster)’s postings originator?

No criticism,just to be clear! We can all FU! Me, often!

John

 RISC OS only uses /dev on Linux versions before 3.17 (a clone of CryptRandom reads random numbers from /dev/urandom, after 3.17 the getrandom system call is used). 

 
mixed/Linux/CryptRandom/s/Main:135:	DCB	"/dev/urandom", 0

running with kernel 3.10.18 so it makes sense.

The code in my previous post mounts both proc and dev. The latter could be made optional on a check for the kernel version number.

Unpriviledged users can run this and have improved security. There should be some more nice checks and possibly fail-overs to make the code reliable and work on various kernel versions.

Preferably the RISC_OS binary should not need either to be fully functional.

I find the idea of using Linux as some kind of HAL for RISC OS very interesting. I would like to try it out by myself but the fastest ARM device I have is a Raspberry 3. I know that there is a “real” RISC OS version for it but would it still be possible to try it out on this device? Is there a description on how to get started? I know that there are some limitations e.g. networking etc.

thanks,
Michael

Michael Gerbracht, I can’t comment with any certainty on the current “Linux2” branch of the RO Linux port on Raspberry Pi 3, however I have built it on an Orange Pi Zero running Armbian based on Ubuntu 16.04.4.
I’ve built the old “Linux” branch on various aarch32 platforms and aarch64 and it performed rather well on both when running “Natively” ie without the interference of sandboxing.
I can only assume that the current branch works even better. Truthfully I’ve had horrible issues trying to build it to function without all the QEMU stuff, but I haven’t tried in at least a couple of weeks.

I have two Rpi3 sitting on my desk; one with RISC OS, one with Raspbian. At the moment I transfer data between the two by unplugging and plugging a memory stick. It would be wonderful to have RISC OS running as a process under Raspbian and to be able to use ShareFS. I use Raspbian for printing and browsing, RISC OS for email. One gets set in one’s ways.