i.Link on a Raspberry Pi

[tpimh]

This is probably a very niche topic, but still.

i.Link (aka FireWire 400 aka IEEE 1394) is a port found on early models of fat PS2: SCPH-390xx and earlier. It can be used to connect a hard drive to PS2, but there are multiple problems with it:

• not all IEEE1394->IDE or IEEE1394->SATA chips are supported (some good ones include Oxford OXUF934, JMicron JMB353)
• such adapters are not made anymore, and are becoming harder to find on a second-hand market
• byte-swapping functionality is seemingly not implemented in iLink controller, so IOP needs to be working really hard changing endianness of all the data that is going through it, thus the maximum speed is limited

It was suggested by @rickgaiser, that it's theoretically possible to use a Linux computer instead of a hard drive. What can be done:

• try to load games from a Linux computer equipped with a FireWire card using unmodified OPL
• design a HAT for RPi 5 or a motherboard for RPi CM4 using VT6315N (this is PCIe->IEEE1394, so older RPi can't be used, but something from Rockchip probably is an option), this would make it a nice portable solution
• do the byte-swapping on the Linux side, so the maximum speed can be achieved

Is iLink still a relevant when we have IDE, Ethernet, MX4SIO? Will such project be worth the effort?

[lwx16917]

I did exactly this on a laptop with i.Link port but no avail.(ThinkPad W700)

Here are the steps to do it:
For anyone interested in setting up firewire target with LIO(Linux-IO):
Backup your important data FIRST.
NO WARRANTY, NO SUPPORT and DIY ONLY.

You should have basic experience with Linux terminal as everything is command line only.

Prerequisite:
Firewire adapters or chipsets present in your Linux installed computer and a firewire to 4pin i.Link adapter cable(obviously for your PS2).
The firewire chipsets should be plug-and-play so I assume you already have a working firewire setup.

Load spb-target driver first, I did all these under sudo/root privileges(that is sudo -i):
modprobe sbp-target

Install targetcli-fb from your package manager and launch it, I'm using ubuntu at here:
apt update && apt install targetcli-fb -y
targetcli

Map device(block) or raw image(fileio) with a [custom_name] to create a backstore.
i.e. a USB stick had been tested to work directly on PS2's USB port with OPL reading the games.
May need unmounting if device is busy:
cd backstore
cd block
create [custom_name] [path_to_device]

Or you made a raw image of a working storage device:
cd fileio
create [custom_name] [path_to_image]

Enter sbp fabric configuration:
cd /sbp

Create target called eui.oooooooooooo (from Allowed WWNs list):
create eui.oooooooooooo
cd eui.oooooooooooo/luns
(My laptop only comes with 1 firewire port so I only have 1 available, I'm not sure about multiple firewire ports.)

Create lun from the previously mentioned block/fileio backstore, you should get a lun0 at here:
create /backstore/[block_or_fileio]/[custom_name]
cd ../..
eui.oooooooooooo enable

Type exit to quit targetcli, just type targetcli to bring the interface back.
You should see some activities from dmesg when the PS2 boots up, in addition to accessing OPL BDM feature with i.Link enabled.
This shows the last 15 events.
dmesg | tail -15

For removing luns and backstores:
/sbp> eui.oooooooooooo disable
/sbp/eui.oooooooooooo/luns> delete lun0
/sbp> delete eui.oooooooooooo

Do expect errors when removing backstores, IDK what the problem was:
/backstores/[block_or_fileio]/> delete [custom_name]

Although I was met with error, experts might find something useful at here. And possibly use this as a crude way to debug i.Link since 1884 was the last one reported to work.

LIO can be a good way for improved compatibility as SBP2 and sbp-target kernel drivers are open source. Plus there's no firmware level shenanigan like external enclosures do.

I was wondering if it's possible to debug the kernel modules from Linux side as a crude way to see what's going on...or are there anything that can be observed from using iLink on TOOL dev stations.

I tested various enclosures(924DSA, 944SE and 934SE 943SE) and none of those work, I have a 934SSA awaiting arrival, hopefully that will be the silver bullet.

Update: The 934SSA enclosure still doesn't work, tried 1880 and 1884.(A "METALLIC" branded U2FW-934SSA for 2.5 inch drives with 2 FW400 + 1 USB2.0.)

[tpimh]

I have checked W700 schematics, i.Link port seems to be connected to Ricoh R5C847. Can you mount the disk in the 924DSA/944SE/934SE enclosures that you have? Does it work?

The next step in testing is connecting two Linux computers with i.Link cable: setting up firewire target on one, mounting it on the other. If this works, then the problem can probably be fixed on the OPL side.

[lwx16917]

I have checked W700 schematics, i.Link port seems to be connected to Ricoh R5C847. Can you mount the disk in the 924DSA/944SE/934SE enclosures that you have? Does it work?

The next step in testing is connecting two Linux computers with i.Link cable: setting up firewire target on one, mounting it on the other. If this works, then the problem can probably be fixed on the OPL side.

1. The i.Link port and card reader from this chipset are functional on my laptop, so I ruled out broken port/chipset.

2. The image from fileio(target) was from a USB stick working with OPL, then dd as an image to be mounted. But I do not have a second PC with Firewire port to test if the target is working.

[tpimh]

I think I will get two cards with VT6315N to test a similar setup. The reason for this specific chip is that it's PCIe (not using PCIe to PCI converters) and would work on modern computers. Don't know when I will be able to test it, I am moving at the moment.

[lwx16917]

I think I will get two cards with VT6315N to test a similar setup. The reason for this specific chip is that it's PCIe (not using PCIe to PCI converters) and would work on modern computers. Don't know when I will be able to test it, I am moving at the moment.

Feel free to ask any questions, I'm very interested in using Firewire/i.Link for OPL.