New PowerBook project series posted, just in time for the tail end of MARCHintosh.
OMG, a "Blue1394" could be really useful for PPC era Macs. Linux looks like is has the support in the kernel to do it but the config interface isn't there.I haven't tested whether I can do FireWire networking with a Mac, or use the Pi as a Target Disk Mode disk or something like that—would be awesome to make a Pi a little FireWire swiss army knife for G3-G5 era PowerPC Macs (and even a few early Intel models...).
The FireWire mass storage device that the Mac in FireWire Target Disk Mode is pretending to be should have a LUN for each disk (block device) in the Mac (only the block devices that are usable by Open Firmware).A Mac in FireWire Target Disk Mode should look like a FireWire mass storage device to Linux?
sbp_target on Linux exists and seems to mostly work. I can share images from a fresh Debian Linux install (kernel 6.12) to a PowerBook G4 running 10.4.11 and even boot from them. Installing Tiger to a FW hard drive image fails most of the way through the installation, but it does successfully boot the installer over the same FW connection. One quirk I've noticed so far is that OpenFirmware seems to only probe LUN0, but MacOS sees them all so only 1 virtual drive will be bootable.OMG, a "Blue1394" could be really useful for PPC era Macs. Linux looks like is has the support in the kernel to do it but the config interface isn't there.
Time to dive into the PiSCSI rabbit hole....
So Linux already has a FireWire Target Disk Mode capability.sbp_target on Linux exists and seems to mostly work. I can share images from a fresh Debian Linux install (kernel 6.12) to a PowerBook G4 running 10.4.11 and even boot from them.
Open Firmware appears to have code to scan a range of LUNs, but for some reason the range is set to [0]. Maybe Apple had a good reason, like it wasn't fully implemented (LUN in a device path doesn't work?), or multiple LUNs might cause problems, such as duplicate entries, or maybe a LUN might be misinterpreted as a partition or id? Or maybe scanning LUNs takes too much time? I don't think the Open Firmware code leaves the LUN loop if a LUN doesn't exist.One quirk I've noticed so far is that OpenFirmware seems to only probe LUN0, but MacOS sees them all so only 1 virtual drive will be bootable.
4.9.6f0 (these numbers are in hex):
scsi-8 scsi-16 scsi-extended ide ata-4 sata fw usb
ilp-id-num 8 10 scsi-range-high - scsi-range-low + 1 2 1 1 1 1
ilp-id-off 0 0 scsi-range-low 0 -1 -1 -1 -1
ilp-lun-num 0 0 0 0 0 0 0 0
ilp-lun-off 0 0 0 0 0 0 0 0
ilp-part-num 21 21 21 21 21 21 21 21
ilp-part-off 1 1 1 1 1 1 1 1
ilp-businfo bi-t-scsi bi-t-scsi bi-t-scsi bi-t-ata bi-t-ata bi-t-sata bi-t-fw bi-t-usb
bi-s-narrow bi-s-wide bi-s-extended
-num is the count to probe-off is the starting numbersetenv aapl,debug-bps true)disk@0,1:3