Enable harddisk devices via the expansion bay

[frno7]

Enable harddisk devices via the PlayStation 2 expansion bay. A starting point is drivers/ata/pata_ps2.c. DMA via the subsystem interface (SIF) is needed for reasonable performance. Plan:

• initialise expansion bay and parallel ATA hardware;
• register kernel block device file;
• mount file systems for reading;
• unaligned transfer via bounce buffer;
• interrupt optimisation;
• reading via DMA;
• writing via DMA;
• performance tuning.

See also #11 and #17.

[motolav]

I'm waiting on a ABitTop SATA upgrade board and I'd be willing to test out compatibility with it when there's progress with this.

[frno7]

Thanks, @motolav! I believe the most complex issue when making a good driver will be efficient use of DMA, especially when sharing DMA with other IOP drivers, for example networking.

[rickgaiser]

There's already a highly optimized (P)ATA driver for linux v3.8. Fully using linux scatter-gather DMA, and reaching speeds close to the theoretical maximum of UDMA66. The IOP drivers needed can be found here:
https://gitlab.com/ps2max/linux/linux-firmware

It consists of:

• dev9_dma module for sharing DMA between multiple devices. State: finished
• pata_ps2 driver for pata. State: finished
• smaprpc driver for ethernet. State: working, but can be cleaned up and optimized. It uses the MDIO/PHY drivers from linux to setup the physical connections and speeds/duplex.

Also essential for debugging IOP modules, is the eedebug/iopdebug (name is confusing...) driver:
https://gitlab.com/ps2max/linux/linux-firmware/tree/master/eedebug
https://gitlab.com/ps2max/linux/linux/blob/ps2-v3.8/arch/mips/ps2/iopdebug.c
This helps to seend all print/debug messages from the IOP to the EE, so they can then be printed to the default debug output (screen or serial port)

The serial port output is IMO a valabl tool when debugging the kernel. It's been extended to also accept input, so you can start a tty console over serial:
https://gitlab.com/ps2max/linux/linux/blob/ps2-v3.8/drivers/tty/serial/ps2_uart.c

The linux implementation for pata can be found here:
https://gitlab.com/ps2max/linux/linux/blob/ps2-v3.8/drivers/ata/pata_ps2.c

The linux implementation for ethernet can be found here (files: smap*):
https://gitlab.com/ps2max/linux/linux/tree/ps2-v3.8/drivers/ps2

I would like to help out on getting these drivers to work with mailine linux, but I'm not sure if I can get a decent development environment anytime soon since I'm in the middle of moving to another country.

EDIT: For testing I have multiple PATA adapters, a SATA upgraded adapter and a sata clone adapter.

[frno7]

Great, @rickgaiser! Your contributions are most welcome. Take your time, we’ll get there.

This helps to seend all print/debug messages from the IOP to the EE, so they can then be printed to the default debug output (screen or serial port)

I have a similar printk IOP module here: https://github.com/frno7/iopmod/blob/master/module/printk.c

The serial port output is IMO a valabl tool when debugging the kernel. It's been extended to also accept input, so you can start a tty console over serial:

I’m unable to test this serial driver myself, since I haven’t soldered a serial port. As an alternative, one can use an early putc with the Graphics Synthesizer, as described in #9. It’s practically equivalent to a true serial port when debugging unmodified hardware, because it will print the same things on the video screen, although it doesn’t accept any input for obvious reasons.

[frno7]

@rickgaiser, I have started reviewing your ATA driver and the links you supplied. This will obviously take some time, as there are significant changes between the 3.8 and 5.4 Linux kernels as well as their corresponding IOP module structures. Nevertheless your driver looks like an excellent starting point.

[frno7]

@rickgaiser, I get a bus error when reading the ATA registers (from the EE), which I suspect is caused by the DEV9 not being powered on properly. So I have a iop-dev9 module that is supposed to power it on, but it seems something is amiss. It follows the steps of ps2dev9 (expbay_init) of the PS2SDK. And not entirely wrong either, I assume, because it properly detects the expansion device by printing dev9: Expansion device interface during initialisation. It also claims that the DEV9 is already powered on, by printing dev9: Expansion device already powered on, which might be wrong, because reading the registers corresponding to SPD_R_REV_1 and SPD_R_REV_3 in the PS2SDK, for example, give bus errors too.

Any ideas on what might be wrong?

There’s quite a bit of obscure hardware poking going on, as can be seen, during expansion device initialisation:

linux/drivers/ps2/iop-dev9.c

Lines 153 to 216 in f6ec831

	static int __init exp_dev_init(void)
	{
	bool power;
	int err;
	err = iop_ssbus_write_1420(0x51011);
	if (err < 0)
	return err;
	err = iop_ssbus_write_1418(0xe01a3043);
	if (err < 0)
	return err;
	err = iop_ssbus_write_141c(0xef1a3043);
	if (err < 0)
	return err;
	err = iop_dev9_power(&power);
	if (err < 0)
	return err;
	if (!power)
	{
	u16 reg_1464;
	printk("dev9: Expansion device power on\n"); /* FIXME */
	err = iop_dev9_write_1466(1);
	if (err < 0)
	return err;
	err = iop_dev9_write_1464(0);
	if (err < 0)
	return err;
	err = iop_dev9_read_1464(&reg_1464);
	if (err < 0)
	return err;
	err = iop_dev9_write_1460(reg_1464);
	if (err < 0)
	return err;
	err = exp_dev_reset();
	if (err < 0)
	return err;
	} else {
	printk("dev9: Expansion device already powered on\n"); /* FIXME */
	}
	#if 0
	err = iop_dev9_write_1464(0x103 & 0x3f); /* ??? */
	if (err < 0)
	return err;
	#endif
	err = iop_dev9_write_1466(0);
	if (err < 0)
	return err;
	iop_set_dma_dpcr2(IOP_DMA_DPCR2_DEV9);
	return 0;
	}

[frno7]

I wrote a minimal dev9 IOP module replacement, and then the initialisation works. It prints

iop: dev9: init start
iop: dev9: rev 31
iop: dev9: power is already on
iop: dev9: spdrev 11
iop: dev9: init exit

in the kernel log, as one would hope for. And then the ATA driver proceeds with

scsi host1: pata-ps2
ata1: PATA max PIO3 irq 77
ata1.00: qc timeout (cmd 0x27)
ata1.00: failed to read native max address (err_mask=0x4)
ata1.00: HPA support seems broken, skipping HPA handling
ata1.00: ATA-11: KINGSTON SA400S37120G, SBFK71E0, max UDMA/133
ata1.00: 234441648 sectors, multi 16: LBA48 
scsi 1:0:0:0: Direct-Access     ATA      KINGSTON SA400S3 71E0 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 234441648 512-byte logical blocks: (120 GB/112 GiB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

which is to be expected, at the moment, because it’s not fully implemented. Although I started out on the EE, it probably is best to do most things on the IOP instead, since it can offload a lot of work for the benefit of the EE. Interesting things can be done if IOP would stream all data through the SIF.

[frno7]

It’s easy to get the driver to work with polling, that is without interrtupts, by ap->flags |= ATA_FLAG_PIO_POLLING:

ata1: PATA max PIO3 irq 77
ata1.00: ATA-11: KINGSTON SA400S37120G, SBFK71E0, max UDMA/133
ata1.00: 234441648 sectors, multi 16: LBA48 
scsi 1:0:0:0: Direct-Access     ATA      KINGSTON SA400S3 71E0 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 234441648 512-byte logical blocks: (120 GB/112 GiB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sdb: sdb1 sdb2
sd 1:0:0:0: [sdb] Attached SCSI disk

I’ve prepared two partitions that are now detected properly:

# fdisk -l /dev/sdb
Disk /dev/sdb: 112 GB, 120034123776 bytes, 234441648 sectors
14593 cylinders, 255 heads, 63 sectors/track
Units: cylinders of 16065 * 512 = 8225280 bytes

Device  Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
/dev/sdb1    0,0,2       124,254,63           1    2008124    2008124  980M 82 Linux swap
/dev/sdb2    125,0,1     256,254,63     2008125  234436544  232428420  110G 83 Linux

Mounting an EXT4 file system works too:

# mount /dev/sdb2 /mnt
# ls /mnt
lost+found

Of course, with its polling mode, it’s very slow at the moment, as seen with the dd command:

# dd if=/dev/sdb of=/dev/null bs=4096 count=4096
4096+0 records in
4096+0 records out
16777216 bytes (16.0MB) copied, 9.129766 seconds, 1.8MB/s

@rickgaiser mentioned UDMA/66, which is more than 30× faster than this. The device itself advertises UDMA/133, as shown above. The next task is to get interrupts working. Somehow the registered IRQ_IOP_DEV9 isn’t asserted. Perhaps some part of the DEV9 hardware isn’t enabled, or some special quirk is needed somewhere?