Working RISC iX IDE driver, "ecide"

[Mattmos]

Hi all,

I've been working on an IDE driver for RISC iX and wanted to share where it's up to, as it's now doing something. This will be missing crucial details I'm sure, but "ask if you wonder" and I'll follow up.

I'd been messing with RISC iX in emulation for a while, but until netbooting (viewtopic.php?f=29&t=18470) my Arc I'd never seen it on real hardware. No AKA31, no working ST-506 discs. So my goal was to enable using the much wider variety of IDE podules (including current cards like @ians's) -- we're not there yet but first steps taken: the driver is usefully working with Ian's 16-bit ZIDEFS IDE podule. Here's it booting:

Code: Select all

RISC iX (M) ME ecide kernel root #10 special: made Fri Jan  1 19:24:04 1999
ARM3 processor, cache enabled
real mem  = 4194304
avail mem = 3080192
30 buffers (240 Kbytes)
st[0-1]: internal controller
ecide0: Disk ID '1GB ATA Flash Disk', 977MB (2001888 sectors, CHS 1986/16/63)
        [revision 'AD B61FK', caps 0b00 (LBA)]
ecide0: 1 drive found, slot 1
ecide1, slot 2: no drives found
ecide0:0 Found RISCiX partition table at cyl 50 (abs sector 1072512)
ecide0:0 partitions:
  0:  1073520-1867824 (size 794304) 
  1:  1868832-2000880 (size 132048) 
  6:  1022112-1072512 (size 50400) 
  7:  1022112-2001888 (size 979776) 
et0: slot 3: iss 1, address 00:00:a4:00:09:33
Swap size = 66.0 Mb
root fstype  4.3, name /dev/id0a
swap fstype spec, name /dev/id0S
... (boot continues) ...
# df
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/id0a             372302  119963  215108    36%    /

Massive filesystem! Massive swap!

This version 0.1 only supports IanS's 16-bit ZIDEFS podule. It should be trivial to add support for the 8-bit version (if3 IIRC) -- if someone has one, and can test for me. (I have some code to try to distinguish 8b vs 16b, but it isn't in v0.1.)

It also theoretically supports the Castle IDE 16-bit podule, except it doesn't work on mine (It's using IMO the correct addresses but register writes simply don't work; I'm still debugging.) It can also support the Castle A3000 8-bit IDE podule.

Speaking of wishlist, it should be "relatively easy" to support A5000/A4000/A3020-style 82C711 IDE -- in theory at least. But, I don't have any of those either, so if you want to help test do shout.

(There's no current way to boot a raw RISC iX kernel directly from a RISC OS filesystem; it has to live on a BSD filesystem. So this testing would probably mean some amount of blatting filesystems to CF/disc/DOM using a PC, then trying to boot it on the Arc. One would need spare discs, a Linux machine, etc. Or some kind soul could hack the NetBSD acorn26 boot loader for RISC iX I can give some hints of what's required to boot the vmunix, have RE'd the boot parameters. The hard part is getting the kernel contiguous in RAM but I think that's a problem solved by Linux/NetBSD booters too.)

Kernel/driver

Sourcecode is here: https://github.com/evansm7/riscix_ide It can be built with rixrun (viewtopic.php?f=29&t=24296), but it's a little fiddly. Building on RISC iX is hard to do unless you're already running RISC iX ...

Here's a pre-built 1.21c kernel with v0.1 of this driver:

riscix-121c-kern-ecide-v01.zip

(393.11 KiB) Downloaded 35 times

Partitioning

The hilarious RISC OS aspect of per-card partition formats: ecide looks for a RISC iX partition table in an ADFS map (same as for a ST-506 disc, using the ST-506 partition table format/magic). For the ZIDEFS podule, it looks for /that/ in one of the 1-4 ZIDEFS partitions ("drives"). That is, there are RISC iX partitions plus one ADFS filesystem embedded within a ZIDEFS partition, of which there might be a few on a physical disc. Note ecide permits only one set of RISC iX partitions per physical disc -- it stops looking in other ZIDEFS partitions when it finds one RISC iX partition table.

Here's @timw's HFORM-iX patched to create RISC iX partitions inside ZIDEFS partitions:

hform-riscix-zidefs.zip

(12.56 KiB) Downloaded 34 times

• Uses ZIDEFS_DiscOp instead of ADFS_DiscOp
• Internally uses a sector size of 512 bytes (like IDE)
• Specifies "other partition table offset" to RISC iX PT, and that PT's contents, in units of cylinders based on 256-byte sectors

The sector size thing is gross but should be largely hidden from the user. In short, RISCiXFS thinks it's an ST-506 disc with 256-byte sectors, so the cylinders given in the ADFS map/RISC iX table are half the size (i.e. 2x as many of them).

Assuming you're starting with an existing partitioned ZIDEFS drive, run the ZIDEFS tools Partition program again to dump the size (in 512 byte "IDE cylinders") of the drive/partition you want to ADFS-and-RISCiX-ize. It will also dump the IDE drive's geometry (e.g. C cylinders, H heads, S sectors/track). Write this info down. Run HFORM-iXz and enter:

• New shape, e.g. 63 sectors/t, 16 heads.
• For cylinders, enter number of cylinders on the *drive*/partition (as in :4, :5, not the physical disc total)
• The usual I-initialise, A-no more defects, no soak test, etc.
• Then, give your RISC iX partition info as per other threads.

I found some ADFS sizes just refused to create a useful filesystem. I'm guessing this is to do with HFORM creating something that isn't 512-byte sector-aligned. Smaller seemed worse, so I tended to always choose something like 40-50 cylinders.

Booting

The RISCiXFS module in the !RISCiX application needs to be able to "see" the disc the BSD filesystem is on. When *configured with "Device" as st0 (as opposed to sd0 for SCSI) the module uses ADFS_DiscOp to access the ADFS disc map, the RISC iX partition table, and the filesystem itself (to load the kernel file). This does mean it can be patched to be able to see filesystems on any filesystem with a BLAH_DiscOp SWI, though.

On RISCiXFS v1.22, two instructions at offsets 0x10ce0 and 0x10ce4 construct the value "0x40240" in R0. This number is SWI "ADFS_DiscOp", and can be changed to another filesystem's _DiscOp SWI. Here's a RISCiXFS module patched to read a kernel from a RISC iX filesystem within a ZIDEFS partition:

riscixfs-zidefs.zip

(53.07 KiB) Downloaded 33 times

For ZIDEFS or indeed ADFS IDE, configuring RISCiXFS is a bit of a lie. It must be told it's reading a kernel from ST-506 by *configure Device st0. Configure Unit with the "drive" (e.g. :4 -> 0, :5 -> 1). It all gets more complicated if you have >1 podule; I think Device would be "st1" for the second?

I haven't tried the GUI to boot. There are 3 args to *boot, the kernel, the root and the swap partitions. These are the real "id" driver partitions, and given like this: WWX(Y,Z) where Z is the partition on drive Y on card X of interface type WW, where cards are numbered in order of discovery from lowest to highest podule slot order. Interface type is 'sd' for AKA31 SCSI, 'st' for ST-506, 'fd' for floppy and now 'id' for ecide.

Code: Select all

 *boot vmunix id0(0,0) id0(0,1)

Anyone want to try it out? Would also like to know if anyone is interested in other cards/machines, and whether anyone can help!


Matt

[IanS]

This version 0.1 only supports IanS's 16-bit ZIDEFS podule. It should be trivial to add support for the 8-bit version (if3 IIRC) -- if someone has one, and can test for me. (I have some code to try to distinguish 8b vs 16b, but it isn't in v0.1.)

I can give that a try at the weekend. I can also supply you with an 8-bit card and an adapter to use it in a big-box arc - viewtopic.php?p=203476#p203476 If you want to do some testing.

For ZIDEFS or indeed ADFS IDE, configuring RISCiXFS is a bit of a lie. It must be told it's reading a kernel from ST-506 by *configure Device st0. Configure Unit with the "drive" (e.g. :4 -> 0, :5 -> 1). It all gets more complicated if you have >1 podule; I think Device would be "st1" for the second?

Multiple cards with the same filing system won't work (in RISC OS), but you can have multiple podules with different filing systems (e.g. IDEFS,SIDEFS, hardware is the same, just different filing system numbers, SWI's etc.). Unlikely to be many people with multiple cards fitted.

Looks like you have made impressive progress.

[davidb]

Nice work!

The hard part is getting the kernel contiguous in RAM but I think that's a problem solved by Linux/NetBSD booters too.)

From memory, NetBSD does the necessary trickery to work back to the physical/unmapped layout from the current mapping. I looked at the acorn32 port, but I expect the acorn26 port will probably be similar.

[Mattmos]

Hi Ian,

This version 0.1 only supports IanS's 16-bit ZIDEFS podule. It should be trivial to add support for the 8-bit version (if3 IIRC) -- if someone has one, and can test for me. (I have some code to try to distinguish 8b vs 16b, but it isn't in v0.1.)

I can give that a try at the weekend. I can also supply you with an 8-bit card and an adapter to use it in a big-box arc - viewtopic.php?p=203476#p203476 If you want to do some testing.

Thanks for both offers I'll be in touch. That adapter is a great idea for development, I hadn't seen it.

(edit) And it seems I forgot to say in the original post -- thank you (publicly) for supplying the 16-bit IanS ZIDEFS card that enabled this work!

For ZIDEFS or indeed ADFS IDE, configuring RISCiXFS is a bit of a lie. It must be told it's reading a kernel from ST-506 by *configure Device st0. Configure Unit with the "drive" (e.g. :4 -> 0, :5 -> 1). It all gets more complicated if you have >1 podule; I think Device would be "st1" for the second?

Multiple cards with the same filing system won't work (in RISC OS), but you can have multiple podules with different filing systems (e.g. IDEFS,SIDEFS, hardware is the same, just different filing system numbers, SWI's etc.). Unlikely to be many people with multiple cards fitted.

Ahh, that's good to know, thanks! I didn't realise. FWIW my Castle card becomes very "weird" when it shares a machine with the ZIDEFS card (unreliable/disc errors) whereas the ZIDEFS card is fine with this arrangement. Both use different FS/SWI base etc. :shrug: At any rate, makes things simpler for the RISC iX story I think it'll just be a matter of choosing a flavour of hacked RISCiXFS for whatever drive you need to boot from.

Matt

[Mattmos]

Nice work!

The hard part is getting the kernel contiguous in RAM but I think that's a problem solved by Linux/NetBSD booters too.)

From memory, NetBSD does the necessary trickery to work back to the physical/unmapped layout from the current mapping. I looked at the acorn32 port, but I expect the acorn26 port will probably be similar.

Cheers David I was digging through ancient times and saw BenH's acorn26 bootloader, in BASIC, and figured that would be a good place for someone to start. Someone else.

[Mattmos]

Just pushed v0.2 to https://github.com/evansm7/riscix_ide/, which:

• Supports the IanS 8-bit podule
• Supports Castle 16-bit "EuroIDE" podule

(It turned out the Castle code Just Worked, but I typoed in v0.1 and didn't initialise it properly. )

Off the top of my head, the 8-bit podule is about 770KB/s (better than I thought!). There's a funky heuristic to differentiate an IanS 8b card from the 16b card, by looking for aliasing registers/differences in decode. The aliasing isn't emulated (currently) in Arculator 2.1 so a zidefs_ide podule isn't detected correctly -- but using zidefs_a3k does work.

Here's a pre-built kernel with this driver:

vmunix-ecide-v02.bz2

(409.65 KiB) Downloaded 34 times

I'll have a look at interrupts next, now that the Castle card (which supports IRQs) is a go-er.

It's still a bit of a faff to create a disc installation without netbooting RISC iX or an already-working install. I'm experimenting with extracting the rootfs from the 4corn RISC iX (SCSI) disc image and inserting that into a partitioned ADFS+partition table image (and somehow booting/inserting this custom kernel). (It'd be nice to have one image/source.) Anyone got any ideas (edit: and want to give it a go? ) how to make this as easy as possible? Ideally something people can dd to a CF, etc.

[Simon]

Hi Mattmos,

I've been attempting to get this to boot on my 4MB A3000 with a 8bit IanS card. I used Arculator to make the HDD image then used DD to put it on a DOM.

After doing the config options rebooting *boot vmunix id0(0,0) id0(0,1) it loads the kernel then the screen just goes blank or I get stripy lines, if you reset from this point the HardDisc4 icon is unresponsive, a power cycle is needed to get it alive again

I get the same result in Arculator 2.2. if I add a SCSI podule and boot off that I can see all the files on the ide volume. if I do the *boot id0(0,0) etc with *configure device sd0 ie load the kernel off the scsi disk it does the same as loading from ide - if you reset from this point the podule doesn't show up in *podules.

Were you able to get this booting in Arculator using the 8bit card? I'm going to try get my 440 working at the weekend and test on that.

Cheers!

Simon