Once the premium option for data transfers and remote control for high-end audiovisual and other devices, FireWire (IEEE 1394) has been dying a slow death ever since Apple and Sony switched over to USB. Recently Apple correspondingly dropped support for it in MacOS 26, and Linux will follow in 2029. The bright side of this when you’re someone like [Jeff Geerling] is that this means three more years of Linux support for one’s FireWire gear, including on the Raspberry Pi with prosumer gear from 1999.
If you’re not concerned about running the latest and greatest – and supported – software, then using an old or modern Mac or PC is of course an option, but with Linux support still available [Jeff] really wanted to get it working on Linux. Particularly on a Raspberry Pi in order to stay on brand.
Adding a FireWire port to a Raspberry Pi SBC is easy enough with an RPi 5 board as you can put a Mini PCIe HAT on it into which you slot a mini PCIe to Firewire adapter. At this point lspci shows the new device, but to use it you need to recompile the Linux kernel with Firewire support. On the Raspberry Pi you then also need to enable it in the device tree overlay, as shown in the article.
With this you now have FireWire 400 support right off the bat, but to use the FireWire 800 port you need to also connect external power to the adapter, which [Jeff]’s Canon GL1 video camera with its FW400 port does not require, so he didn’t bother with that.
Capturing the video from the GL1 via FW400 was done using the DVgrab utility, with a subsequent capture attempt successful. This means that at least until 2029 [Jeff] will be happily using his GL1 camera this way.
Meanwhile over on the Dark Side, you can still happily install FireWire drivers made for older Windows versions on Windows 10 and 11, which is great news for e.g. people who have expensive DAW gear kicking around. Perhaps the demise of FireWire is still a long while off as long as you’re not too picky about the OS you’re running.
I’m curious about the urgency for dropping support all together. I had a misinformed impression that Linux had really long horizons for hardware support. Like, doesn’t it still compile for the original 60mhz 32 bit Pentium from 1993? Surely FireWire products, which include some very high end video hardware from 20 years later, are more likely to see use today?
I suppose it’s a question of ancestry. Much of the Pentium code is probably still applicable to current cpus, while FireWire code is an evolutionary dead end.
32-bit support isn’t all that common anymore among distros. I have an old EeePC, that’s 32-bit with very little ram (512mb). I’ve had a hard time finding something that would fit. Gentoo was one solution, but the compile times were awful. 32-bit distros are generally being dropped, and even then if you find one, you’ll be severely limited with packages, which will be few and outdated (on the point of repos, I think gentoo has an advantage because it will always compile the source for your architecture). It’s a bit sad because appart from that, you can still do a lot with two cores and 512mb of ram. And I really liked the size/design of that laptop, it was very handy.
Try https://antixlinux.com/
Works great with 256mb of ram (with gui) and can even install and run on just 64mb of ram. Plus you get access to all the Debian packages and more.
I would say it’s mostly because no-one is interested enough to maintain it.
The current maintainer has decided to do it only until 2029, but it seems they wouldn’t oppose someone else continuing the work https://www.phoronix.com/news/Linux-Firewire-New-Maintainer
As for “keep it until it breaks”.. I think Linux is probably far too important to include completely unmaintained code anymore. At that point you might just as well run an old kernel to have the Firewire support.
Also, nothing is legally stopping anyone from nicking the relevant firewire kernel bits and turning it into a DKMS module or similar (apart from code licensing if you happen to dislike the GPL).
Which would be the ideal fate anyway, since it’d still be accessible to those who need it, but is at the same time distanced from official kernel development.
Linux is dropping a lot of stuff recently, what’s going on?
What happens to the concept that Linux is great for old hardware?
Is planned obsolence the new paradigm in Linux land? What about sustainability?
Dropping Firewire support is as radical as dropping SCSI or IDE support, isn’t it?
Firewire aka i.Link aka IEEE 1394 is an industry standard, just like RS-232.
Also, how about networking? On Windows XP, at very least, it was possible to connect two PCs over Firewire connection.
In the days of 100 Mbit ethernet NICs, Firewire 400 and Firewire 800 were quite a speed upgrade.
Dropping Firewire because of “old hardware” looks like a lame excuse, thus.
The current Firewire hardware still works fine, after all.
Likely will do so in the next 25 years (especially pro equipment, which might be the majority), unless Linux will force the retirement.
I mean, even macOS users are unhappy about the decision to drop it in macOS 26.
While new consumer devices aren’t made anymore, perhaps, it’s perfectly easy to use Firewire on modern Macs via Thunderbolt to Firewire dongles.
A lot of professional audio interfaces (external soundcards) do still use Firewire in favor of USB.
Because it’s simply better in terms of latency, for example.
Up until USB 3.0, USB was an interface for cheap, timing uncritical consumer devices like keyboards and mice.
Firewire and USB had two different use cases up until that point.
Firewire and USB did compare like SCSI and IDE/ATAPI did.
Anyway, it’s simply depressing how much Linux world copies from Win/Mac world.
Back in the 90s, KDE and Gnome always imitated the newest Windows/Mac GUI instead of having the guts to develop something unique.
And now Linux drops hardware support just like the big players?
What’s next? Will Linux drop support for old PCs just like Windows 11 does?
dont forget, this is foss, so the maintainers are getting older also. getting a younger developer interested in That Old Stuff ™ is difficult.
There is a ton of high end pro audio stuff that will be finally obsolete as well, not to mention Film and photo scanners. mist of the time people use age correct computers for them because that is the only setup that works.
What’s the big deal, maybe you want to step in to maintian the driver? Or create a DKMS module out of it?
Both can be true at the same time, it does still support older stuff far better than anything else, but you can’t expect folks to keep putting in the work to support the old stuff forever, especially the unpaid maintainers…
And you can if you really want to still tweak (if needed) and compile the old unmaintained code for anything you like if you really want to, and often it will still just work alongside the most bleeding edge kernel.
Or just do as the CNC machinists, lab equipment users etc are so likely to have done keep on running something obsolete (XP in many cases for years after support was dropped).
I am guessing that someone and that means you Joshua, did not maintain enought driver sourcecode in the kernel. .-)
Olaf
Hm. Counter question – how comes Linux supports so many irrelevant niche architectures all the time,
but same time has no concerns about dropping stuff in a blink of an eye that’s actually useful or has an existing userbase? :)
And why can’t there be external modules anymore? What happened to modprobe?
If it’s still there, couldn’t Firewire be implemented as an external module somehow?
A big issue with Linux is of course that it’s a monolithic kernel with no fixed driver ABI, which is why you need to keep updating those kernel modules and a hybrid kernel like NT6 with fixed ABI can use the same kernel driver for a few decades.
Of course, getting Linus to admit that not having a fixed ABI for drivers was a mistake will happen right after the heat death of the Universe.
It would also mean that almost no new open source drivers would be created anymore. Vendors only do this, because they need to be compatible to the current Kernel,
It would also mean that you can compile that Realtek WNIC driver once and update the kernel without having to plug in the Ethernet to recompile said driver module once again.
Yes, I’m very salty about that.
Firewire is irrelevant and niche to me. What is irrelevant and niche to one person is critical to another. If they were to drop everything irrelevant and niche to focus on what you care about, there would be torches and pitchforks.
That is easy. Someone wrote a driver for a hardware he owns and like to use. For example many years ago I did this for a CD-rom. But a few years later you have a different hardware and not interested in the old one anymore.
Olaf
Hm. Great attitude. I hope Linux devs have no pets or elderly relatives to care for.. 🙄
Would you maintain a driver you wrote in your free time indefinitely? I wouldn’t, unless someone paid me and even then I would prioritize my current projects.
Linux dropping hardware is annoying.
386, 486, firewire…
Somebody is currently trying to recreate Firewire support for macOS26+: https://github.com/mrmidi/ASFireWire
It seems he has made already a lot of work, very impressive!
But he also says that you need to have a paying Apple Developper account ($99/y i think) in order to be able to load this new driver in the OS.
Genuine question: what do you have to “maintain” in the code for such an old technlology ? There’s no more evolution or standard revision, no new functionality to add. Since the existing code has been tried and used since a long time now, and is working well, what do you have to do to keep using it with new/future OS versions?
Changes in the kernel change the ways the drivers can talk to hadware/kernel/programs. Older functions are replaced, structures change names, etc.
Then if you want to mantain it, you need to adapt it to the newer code of the kernel.
Never pronounce the “p” in raspberry (wait for it)
https://m.youtube.com/watch?v=FtwWzhwQ2vs&pp=ygUpYm90cyBpbiB0aGUgaGFsbCBob3cgZG8geW91IGtpbGwgYSBnaG9zdD8%3D