Latest: v2.0.0
The image builder for riscos
All the supported releases are here:
| Release | armv7 (ARM 32-bit, Cortex-A7) |
|---|---|
| 5.30 | ✅ (tar) |
Note: RISC OS support is a tech preview. Remote command execution and file sync both work, and the desktop comes up and is visible on the VNC console. There is no keyboard -- see below. Pointer input is untested: the ROM does carry a
usbmousedriver, but no USB mouse has been attached to this guest, so nothing here claims it works.
Nothing from RISC OS Open is redistributed here. The builder downloads the official Raspberry Pi SD card image from
riscosopen.orgat build time; this repository's release assets carry only its own work (the patched QEMU, the agent, the injector). Note that ROOL deletes superseded media -- the 5.30 zip answers 200 while the identically-shaped 5.28 URL answers 404 -- so a new release replaces this row rather than adding one.
Linux x86_64 hosts only. The patched QEMU below is published for that platform alone, and there is no system fallback -- no released QEMU can boot RISC OS on a raspi machine at all.
anyvm.pyfails fast with that message on any other host rather than starting an emulator that cannot work. macOS and Windows would need the same patched build produced on those runners; that is not done yet.
No working RISC OS port of QEMU existed, so this builder makes one.
files/qemu-riscos-raspi.patchis eight fixes plus a new USB NIC model, built byfiles/build-qemu-riscos.shand published as this repo's own release asset. Four of the eight are generic QEMU defects with nothing to do with RISC OS: three inhcd-dwc2.c(the frame counter divided elapsed time by the frame interval in PHY clocks rather than the frame time;GINTSTS_HCHINTwas raised but never lowered; the bus was started fromdwc2_attach()instead of on the HPRT0 port-enable edge), and one inbcm2835_dma.c, wherexlen -= 4on auint32_tbyte count wraps for any length that is not a multiple of four -- the loop then spins about 2^30 times, scribbling over guest memory as it goes. The RISC OS specific ones are a BCM2835 mailbox power channel, a VCHIQ mailbox peer, byte access on the interrupt controller and the BSC/I2C FIFO (RISC OS usesLDRB/STRBwhere the models demanded word access), andhw/usb/dev-smsc95xx.c, a model of the SMSC LAN9512 that is the real Pi 2's NIC -- the guest has a driver for it and for nothing else QEMU offers.
There is no keyboard, and that is a RISC OS limitation. The BCM2835 ROM ships no USB keyboard driver at all: its USB tree has
USBDriver/build/c/usbmouseand nothing for keyboards, the boot printsNo keyboard present - autobooting, and a whole boot's worth of USB traffic isep0control transfers with zero interrupt-endpoint packets. Every HID device is reported as[error &24425355], and&24425355is ASCII"USB$"-- USBDriver's "attached, no driver" tag. So there is no console to type an installer into, and the guest is prepared by patching the disc image offline instead (files/rofilecore.pyparses FileCore'sSBPr"BigDir" directories and overwrites one cosmetic boot script in place, at its existing length).Three things about that image will bite anyone who touches it. The live boot tree does not exist in a freshly downloaded image -- RISC OS copies
$.!Boot.RO530Hook.Bootinto$.!Boot.Choices.Booton first boot, so patching the pristine image patches a template that is never run, and patching a booted one lands somewhere else entirely. Every injected command must be prefixed withX(*X <cmd>runs it and discards any error), because one error stops the boot on a dialog waiting for a keypress that can never come. And injected scripts must print nothing: any console output from a Tasks hook opens the Wimp's single-tasking output screen, which waits for a keypress at the end -- same brick, different cause.
The agent. RISC OS ships no remote-access server of any kind -- checked in a running guest, where
*Moduleslists 137 modules whose only networking is the stack (Internet,Resolver,DHCP,EtherUSB) and clients (LanManFSfor SMB,ShareFS/Freewayfor Acorn Access). No telnetd, no sshd, no ftpd. So, like reactos-builder, this builder supplies the server:files/anyvmd.py, a small Python agent on port 23 (VM_TRANSPORT=telnet).The telnet is real, not a raw socket wearing the name: IAC is unescaped inbound and doubled outbound, and BINARY (RFC 856) is accepted both ways, which is what keeps the tar stream intact. Verified against the worst case it can meet -- 4096 bytes of
0xFF(the IAC byte itself) followed by all 256 byte values, round-tripped byte-identical. It is not a shell, though: RISC OS has no pipes to a child and no&&, so the agent parses the two tar one-liners itself, services them with Python'starfile, and prints the completion marker where a shell would have got it from the chained&& echo. It also holds a persistent session, several commands down one connection, because that is whattelnet_execdoes.It needs nothing installed -- ROOL's image already ships Python 2.7.2 at
$.Programming.Python.!Python27with a complete standard library. It runs inside aTaskWindowso the desktop stays interactive; single-tasking Python would freeze the machine for as long as it served, and*Shutdownwould then do nothing at all.Sync was settled on the running guest rather than assumed. There is no sshd and no ssh client (so no rsync / sshfs / scp) and no 9P client.
Fat32FS(1.63) is loaded and could in principle carry files on the FAT boot partition, but it serves removable media and cannot see the SD card's own boot partition --::0,::4and::PiBootall resolve to nothing, andFat32Map, despite the name, is a DOS-extension-to-filetype table rather than a disc mapping.
How to build:
-
Use the manual.yml to build manually.
Run the workflow manually, you will get a view-only webconsole from the output of the workflow, just open the link in your web browser.
You will also get an interactive VNC connection port from the output, you can connect to the vm by any vnc client.
-
Run the builder locally on your Ubuntu machine.
Just clone the repo. and run:
python3 build.py conf/riscos-5.30-armv7.conf