Tool to launch other OSes from RISC OS on Pi

I have been trying Raspian Linux and while a bit slow and a tad unfriendly (compared to an X86 debian machine, too much use of command line for configuration, and the only browser with really acceptable performance is Netsurf) it does offer access to software that RISC OS doesn’t. I suspect with development, it will improve, but currently it is very poor compared to an Iyonix (which is the minimum I would expect the Pi version of RISC OS to perform like, once proper drivers are written.)

There are also media players, and Android is close, too.

Currently the only way to switch is by swapping the SD Card, which I don’t want to do too often. (And certainly, when the machine moves to being a general use machine, rather than for testing new systems, I wouldn’t want to do it at all.)

There has been mention of using RISC OS for a Pi boot menu, has any work been done?

Could the normal softload tool for the Iyonix be modified?

What I would like is an app that gives the choice of various distributions, ideally using the same files as Pi normally would. (Whether they are in sub directories on the DOS section, or contained within the app.)

I’m reasonably sure this would make RISC OS far more attractive to new users. Within the limits of what it can do, it is certainly the best simple GUI based OS for normal use on a Pi. However, the limits are pretty big and require a second system to do all the things a typical user would want. (As is probably the situation with most RISC OS users already.) A loader would allow that second system to be used easily.

We’re working on it – here’s my source code

Currently it boots Linux successfully, but I need to sort out the Linux partition on SD so it can see it (which I think I’ve done, just not tested yet). There’s still loads of things to tidy up (and a UI to write) – just concentrating on making it work at the moment.

I asked Peter Naulls for the Iyonix Linux bootloader, but he seems to have misplaced the source (and I don’t have a binary). The existing LinLoader 0.35 is GPL (so awkward to include in a ROM) and full of Risc PC stuff (VRAM detection, double SIMM banks) so I started afresh.

I seem to have two LinLoader binaries on my Iyonix, one dated 06 Jan 2004 and the other 21 Oct 2004. I (apparently) renamed the first to LL 0-36 when the second became available, so I assume these two are more recent than 0.35. Let me know if you want them.

I’ve just had a quick look at some of your code Theo. Did you know that you can/should use Service_PreReset to tidy up all the hardware drivers (DMA, etc.) before killing the OS? It’s probably a better choice than disabling everything manually.

And rather than scanning the memory map for some free physically contiguous RAM and then hijacking it you should probably be using PCI_RAMAlloc to get the OS to do all the hard work for you.

Plus you don’t seem to be flushing/invalidating the cache before disabling the MMU.

Ah, interesting, thanks. There’s various bits of tidying up that I don’t do at the moment – Message_PreQuit, TaskManager_Shutdown, Service_Shutdown etc. The specific case of turning off all the DMA was to eliminate a problem I was having with the SD controller; I turn off interrupts, but don’t touch DMA. SDIODriver (which doesn’t use DMA) doesn’t currently reset the SD controller without then enumerating the devices so it doesn’t actually reset the hardware sufficiently even on Service_PreReset. As it turned out, the SD card problem was that Linux didn’t talk to my SD card with init_emmc_clock=100MHz, which is what RISC OS uses. I now use the GPU messaging interface to set this to 50MHz (the default) and it boots Linux fine. (Not Android yet, which seems to have a different kernel layout)

PCI_RAMAlloc – didn’t know about that, looks handy. Is the PCI module likely to be a standard component, or would it ever get thrown out on machines that don’t have PCI buses?

I turn off all the caches, so it isn’t strictly necessary to invalidate them. I suppose it’s probably safer to do that so they’re consistent when Linux turns them back on. I suspect Linux might do an invalidate anyway but better to be safe.

PCI_RAMAlloc – didn’t know about that, looks handy. Is the PCI module likely to be a standard component, or would it ever get thrown out on machines that don’t have PCI buses?

It’s fairly standard; the USB drivers use it to allocate the memory they need, so even PCI-less devices (like the Pi!) have the module present. At the moment the only ROM without it is the IOMD ROM, since there currently aren’t any USB drivers for IOMD hardware.

If you’re planning on this being a general tool for use on any RISC OS machine then you should probably create a dynamic area instead, specifying that you want to use the physical pages that you found earlier. This is what the RISC OS ROM softload tool does (sources here)

I turn off all the caches, so it isn’t strictly necessary to invalidate them.

From the ARM1176JZF-S TRM:

If the cache is disabled, then the cache is not accessed for reads or for writes. This ensures that maximum power savings can be achieved. It is therefore important that before the cache is disabled, all of the entries are cleaned to ensure that the external memory has been updated. In addition, if the cache is enabled with valid entries in it, then it is possible that the entries in the cache contain old data. Therefore, the cache must be disabled with clean and invalid entries.

Cache maintenance operations can be performed even if the cache is disabled. The system can disable the cache in Secure state when it is enabled in Non-secure state and enable the cache in Secure state when it is disabled in Non-secure state.

Um…

If the cache is disabled, then the cache is not accessed for reads or for writes. [my emphasis]

It worries me that this needed to be specified in a processor technical document. I get the need to talk about flushing so everything is tidy and consistent; but to define “disabled”? Is there some alternative definition, such as perhaps “when the cache is disabled, every third read during the vernal equinox will be from the cache”?

More on-topic, I have a little Linux system (my PVR, little as in Busybox), logged in as root, that would be nice to softload RISC OS on. Is there a tool similar to the softloader for Linux systems? So far it seems my best idea (totally untested) is to “killall”, then force close any files still open (need to trap stdio etc), then attempt to use /dev/mem to redirect the SWI vector to my own code. If that actually works, I will be in SVC mode, so ought to be able to discard the SWI and do the OS init.

One of these days I’ll get around to writing some code to see how long it takes before blowing up in my face. (^_^) Unless, of course, any Linux gurus know a less insane way (though, note, as an embedded device, it is a little less featureful than a desktop machine).

It worries me that this needed to be specified in a processor technical document. I get the need to talk about flushing so everything is tidy and consistent; but to define “disabled”? Is there some alternative definition, such as perhaps “when the cache is disabled, every third read during the vernal equinox will be from the cache”?

The ARMv7 ARM states:

It is IMPLEMENTATION DEFINED whether an access can generate a cache hit when the cache is disabled.

So yes, it’s important to specify whether a certain implementation allows cache hits or not when the cache is disabled. For example, a quick check of the XScale developers manual reveals that reads can score hits from both the instruction & data caches, and writes to a cached location will update the cache instead of writing to memory. Disabling the caches merely disables the automatic load/store of cache lines.

Fair point about not assuming what ‘disabling’ means…

More on-topic, I have a little Linux system (my PVR, little as in Busybox), logged in as root, that would be nice to softload RISC OS on. Is there a tool similar to the softloader for Linux systems? So far it seems my best idea (totally untested) is to “killall”, then force close any files still open (need to trap stdio etc), then attempt to use /dev/mem to redirect the SWI vector to my own code. If that actually works, I will be in SVC mode, so ought to be able to discard the SWI and do the OS init.

Rick, have a look at kexec. It does exactly what you want. The main issue is dressing up RISC OS to look enough like a Linux kernel (and possibly a thousand related assumptions). Also you need to compile your ‘before’ Linux kernel with CONFIG_KEXEC to support it (suspect your PVR won’t by default, but there’s probably a hack project to allow you to build your own kernel for it).

The /dev/mem hack might work, but be aware that you’ll need to get your code in permanently resident memory – if it’s in a normal process it may get paged out between installing the SWI redirect and your code calling a syscall (ie SWI). Possibly redirecting the interrupt vector might be better – the paging mechanism probably happens by a timer interrupt going off, so you’ll still be threaded in at that point. There’s a config option CONFIG_STRICT_DEVMEM that needs to be off, otherwise you can’t poke anything but MMIO through that interface.

To tidy up a Unix/Linux system, have a look at the various runlevels provided by ‘init’. For example, ‘init 5’ is a full GUI mode while ‘init 6’ executes a shutdown. I don’t know if there’s a way to get a last command executed before the power is actually pulled, but there might be. Alternatively something like ‘init 2’ or ‘init 3’ will go to single user mode (not sure on the numbers, but there will be a guide somewhere).

Booting RISC OS from Linux via kexec (or your /dev/mem hack) would be very nice :)

As a side note, Peter sent me the sources to LinLoader 0.40 (Iyonix version). I’ve merged all the available sources into a tree on github including the version history back to 0.20 (A5000) and Vincent Sanders’ 0.35a (Bush STB). That includes executables. If you just want to download a version, click on Tags and then you can download a zip or tar.gz.