On Sun, 31 May 2020, Brad Boyer wrote:
The swim_iop driver was never completed. As far as I know, the data transfer code was never written. I remember testing the driver, and all it could do was detect the drives and do eject. Read and write were not working. I looked into it at the time, but it's a little messy and is much more complicated than the ADB driver. For ADB, the data is small enough that it's packed in the IOP message. That's not possible for SWIM, so it has a more complex data handling method. If you look at the code of that driver and the messages, it looks like the IOP can do DMA but it can't. The SWIM IOP message includes a buffer pointer, but the IOP chip isn't connected in a way that it can just access it (and it's getting passed a virtual address anyway). Based on some of the other information I was given, there's a separate message protocol on channel 0 (on each IOP) for bulk data transfer. At the time, I had a diff to fix some bugs in the detection and handle the status update messages. However, it hardly seemed worth submitting that as a fix since the driver still wasn't useful without the bulk data transfer working. I can pass my diff along if you intend to make an attempt at a working swim_iop driver.
I'm hoping that the SWIM IOP can be used in bypass mode, so it could be used with the swim.c driver. I haven't been able to make that work yet. You may want to send the patch to the mailing list anyway. Or maybe send it to the linux-mac68k bug tracker on sourceforge.
