Patching RISCixFS for automatic booting

[rhalkyard]

I've been poking around inside RISCiXfs and I have worked out a patch to allow 'automatic' booting (i.e. *Boot with no arguments, or through the Desktop) with IDE.

Simply overwrite the characters st at offset 0x10514 with id, then *Configure Device id0. RISCiXfs will then map id0 to ADFS/whatever else, AND send the correct parameters to the kernel. This will, of course, break ST506 booting, and likely only work for the first IDE card, but it makes the experience feel a bit more like it was meant to (and allow the system to come up into multi-user mode). I also had trouble with *Boot causing the system to hang with a black screen unless I booted without the Desktop while the boot GUI worked fine, so this gets around that issue too.

On that note, in the absence of real raw devices, I created symlinks from /dev/rid* to their block equivalents, otherwise fsck would get upset on every boot about being unable to find the raw devices. Probably a bit naughty, but it does the job.

[evansm7]

This is nice! I'll give it a go (have you mentioned this on the start dot thread BTW?). I've found various pickiness with RISCiXfs:

• If it's not run either pre-desktop or after only very minimal desktop, it'll often lock up
• The annoying "disable ctrl-break" kicks in on boot crashes too
• And of course *configure sync auto will just die on boot (it does some VIDC enhancer detection, maybe it's that).

A couple of years ago I dug out the early acorn26 bootloader and it looks doable to modify that to boot the RISCiX kernel. I've some Ghidra project somewhere that has some of the RISCiXfs boot code reverse-engineered; I think I got as far as the parameters struct (so: load kernel at the start of physical RAM, pass in parameters block in a reg, jump to it) but didn't get all the values. Anyway – this might be viable!

I've found network booting particularly useful for doing driver dev, and it'd be cool to be able to netboot with custom network drivers too.

[rhalkyard]

Yeah, I definitely got the impression that RISCiXfs is a finicky beast! I've got a similar ghidra project going on - it's rather handy that they left most of the debug symbols in! I'm pretty sure the location that I'm patching is where it maps the device string stored in the CMOS to whichever code path it uses to mount the filesystem - so this way it maps id to the 'ADFS' path, but also still supplies id0 to the kernel boot parameters.

Oddly enough, booting from the Desktop has worked quite nicely for me, so long as I boot with the !RISCiX application rather than the Boot command. Even with a fairly heavily-loaded Universal Boot environment, it's worked a solid 'most of the time.' I wonder if the application is doing some cleanup before it calls the RISCiXfs boot SWI.

As far as netbooting goes, I'm VERY interested in the custom network driver bit of that :). I've actually just received the first set of boards for a new ethernet podule that I've been cooking up. Haven't even started on the RISC OS driver yet, but writing one for RISC iX is definitely on the to-do list!

[evansm7]

:) I saw the boards on Twitter, very cool. Fortunately writing a RISC iX net driver is loads easier than for RISC OS...