Skip to content

MIPS: PS2: IOP: Fix iop_write*() and actually initialise the DEV9 expansion bay #94

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hubix94 wants to merge 2 commits into from
Closed

MIPS: PS2: IOP: Fix iop_write*() and actually initialise the DEV9 expansion bay #94

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
13aa36a
MIPS: PS2: IOP: Fix iop_write{b,w,l}() issuing the LOADFILE read RPC
Sep 5, 2026
7ed4ab5
MIPS: PS2: IOP: Actually initialise the DEV9 expansion bay
Sep 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 0 additions & 2 deletions drivers/ps2/iop-dev9.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -252,8 +252,6 @@ static int __init iop_dev9_init(void)
if (err < 0)
return err;

return 0;

@frno7 frno7 Sep 5, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this module was mostly abandoned, because it wasn’t clear what it was supposed to do. The drivers/ata/pata_ps2.c driver, for example, uses iopmod/module/dev9.c instead.

What are you trying to do with the expansion bay?

@hubix94 hubix94 Sep 5, 2026 •
edited
Loading

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the expansion bay, I just wanted to plug in an Ethernet cable and connect to the console over SSH. I know there aren’t any drivers yet, but I downloaded the PS2 Linux DVD ISO and extracted the drivers from there. After 2–3 attempts, Claude managed to get it working - I was able to assign an IP address and connect to the PS2 over SSH :)

I know you can also get a USB-to-Ethernet adapter, but I didn’t want to buy anything extra for the PS2.

@hubix94 hubix94 Sep 5, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

obraz :D

@frno7 frno7 Sep 6, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that’s nice. :-) I’m thinking it might be best to postpone pull requests until this network driver is functional and ready to be merged by itself. Does your driver work with the SCPH-700xx models as well? Does it use DMA efficiently, and work with other expansion bay drivers such as the ATA driver?

@hubix94 hubix94 Sep 6, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Answers to your three questions, plus where the driver stands.

SCPH-700xx: untested. I have one console, an SCPH-30004 with the adapter in the bay. Nothing in the driver is model-aware - the PHY is hardwired to MDIO address 1 and the register map is the adapter's. Probe does refuse cleanly on unexpected hardware: it bails out if SPEED rev1 reads 0000/ffff or rev3 lacks the SMAP capability bit.

DMA: none. Data moves by PIO from the EE through a bounce buffer, where Sony's driver used SmapDmaWrite/SmapDmaRead on the IOP side. Measured over TCP with SSH on top: 2.4 MB/s (~19 Mbit/s) transmit, 1.4 MB/s (~11 Mbit/s) receive, sustained over 300 MB without a stall. Porting the DMA path is the obvious next step for throughput.

Coexistence with pata_ps2: yes. With SMAP up and an SSH session running, modprobe pata_ps2 returns 0 and ata1: PATA max UDMA/66 irq 110 appears; the network keeps running and throughput does not change. ata.irx finds the bay already powered and skips its own power-up sequence, and the interrupts are disjoint - 110 for ATA against 114/115/116 for SMAP.

What the driver is: an EE-side port of Sony's 2.4.17 smap.c onto 5.4 - net_device_ops, NAPI, phylib with its own MDIO bus, the three SPEED interrupts taken through the IOP relay, MAC read from the EEPROM. It survives module reload without a reboot, and it loads from the initramfs at boot, so the console takes a DHCP lease and starts SSH on its own.

One question where your view would save me guessing. The SPEED interrupt mask at offset 0x2a belongs to the IOP (spd_enable_irq/spd_disable_irq), and drivers/ps2/iop-irq.c implements only irq_startup/irq_shutdown, no irq_mask/irq_unmask. An EE-side driver therefore cannot mask its own interrupt for the duration of a NAPI poll without racing the IOP. Is the relay meant to be the long-term path for a bay device, or should a SMAP driver carry an IOP-side counterpart the way Sony's did?

The driver sits on a branch in my fork with the in-tree plumbing done: drivers/net/ethernet/ps2/ with its own Kconfig entry, and the platform device with the register window and three named interrupts in arch/mips/ps2/devices.c. It stays there until you say otherwise - say the word and I turn it into an RFC pull request. The iop_rpc_write() typo fix can go separately as a one-liner.

I guess I'll just close this PR and create a new one with drivers working on SCPH-30004?

@frno7 frno7 Sep 7, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SCPH-700xx: untested. I have one console, an SCPH-30004 with the adapter in the bay. Nothing in the driver is model-aware - the PHY is hardwired to MDIO address 1 and the register map is the adapter's. Probe does refuse cleanly on unexpected hardware: it bails out if SPEED rev1 reads 0000/ffff or rev3 lacks the SMAP capability bit.

My understanding is that SCPH-700xx models have slightly different Ethernet hardware, and therefore there are two separate network drivers for Linux 2.6. I don’t know what the differences are. Having two similar network drivers is awkward, though, so if at all possible, I’m hoping we can combine both into a single driver, but there’s no rush: someone else can adapt it to include SCPH-700xx hardware support later on.

DMA: none. Data moves by PIO from the EE through a bounce buffer, where Sony's driver used SmapDmaWrite/SmapDmaRead on the IOP side. Measured over TCP with SSH on top: 2.4 MB/s (~19 Mbit/s) transmit, 1.4 MB/s (~11 Mbit/s) receive, sustained over 300 MB without a stall. Porting the DMA path is the obvious next step for throughput.

Nice. If the network driver doesn’t interfere with other drivers, I think it’s a great initial prototype, which can be extended with DMA etc. to improve performance later on. There’s great value in a simple driver, as long as it doesn’t cause problems for other drivers.

One question where your view would save me guessing. The SPEED interrupt mask at offset 0x2a belongs to the IOP (spd_enable_irq/spd_disable_irq), and drivers/ps2/iop-irq.c implements only irq_startup/irq_shutdown, no irq_mask/irq_unmask. An EE-side driver therefore cannot mask its own interrupt for the duration of a NAPI poll without racing the IOP. Is the relay meant to be the long-term path for a bay device, or should a SMAP driver carry an IOP-side counterpart the way Sony's did?

Long-term I think we should off-load as much driver work from the EE to the IOP as reasonably possible. So I definitely think it should have an IOP counterpart, that does DEV9 initialisation, similar to the ATA driver, handles interrupts as much as possible, and, eventually at a later time, perhaps other kinds of network processing (maybe network packet checksumming and so on?), and also DMA, to reduce the processing burden on the EE.

So, I think we should retire and remove linux/drivers/ps2/iop-dev9.c, which I assume the network driver won’t need once it has its own IOP module counterpart instead?

The IRQ relay module is mostly meant to simplify initial driver development (the USB driver, for example), to quickly and easily get something working, but as you’ve noticed, it has limitations, and for high-quality, high-performance drivers, it’s typically not the best alternative. We could retire and remove it as well, once all drivers have their own IOP modules.

The driver sits on a branch in my fork with the in-tree plumbing done: drivers/net/ethernet/ps2/ with its own Kconfig entry, and the platform device with the register window and three named interrupts in arch/mips/ps2/devices.c. It stays there until you say otherwise - say the word and I turn it into an RFC pull request. The iop_rpc_write() typo fix can go separately as a one-liner.

Great! At a first glance, I think it looks promising, but I think it should have its IOP module counterpart for DEV9 initialisation, proper interrupt handling, etc.

I guess I'll just close this PR and create a new one with drivers working on SCPH-30004?

Yes, thanks!


err = iop_dev9_read_rev(&dev9.rev);
if (err < 0) {
printk("iop_dev9_init: err %d\n", err);
Expand Down
2 changes: 1 addition & 1 deletion drivers/ps2/iop-module-request.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -932,7 +932,7 @@ static int iop_rpc_write(const u32 data,
s32 status;
int err;

err = sif_rpc(&load_file_rpc_client, rpo_get_addr,
err = sif_rpc(&load_file_rpc_client, rpo_set_addr,

@frno7 frno7 Sep 5, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a valid fix for a typo, in coded which isn’t used, as the commit message says.

&arg, sizeof(arg), &status, sizeof(status));

return err < 0 ? err : status;
Expand Down