Autodetection of hardware was a major part of making computers more usable for the average user. The Amiga had AutoConfig on its Zorro bus, Microsoft developed Plug And Play, and Apple used NuBus, developed by MIT. It’s something we’ve come to take for granted in the modern age, but it doesn’t always work correctly. [Evan] ran into just this problem with a video capture card that wouldn’t autodetect properly under Linux.
The video capture card consisted of four PCI capture cards with four inputs each, wired through a PCI to PCI-E bus chip for a total of sixteen inputs. Finding the cause of the problem wasn’t too difficult – the driver was detecting the card as a different model with eight inputs, instead of the sixteen inputs actually present on the card. The driver detects the device plugged in by a unique identifier reported by the card. The code on the card was identical to the code for a different model of card with different hardware, causing the issue.
As a quick test, [Evan] tried fudging the driver selection, forcing the use of a driver for a sixteen-input model. This was successful – all sixteen inputs could now be used. But it wasn’t a portable solution, and [Evan] would have to remember this hack every time the card needed to be reinstalled or moved to a different computer.
Looking further at the hardware, [Evan] discovered the card had four 24c02 EEPROM chips on board – one for each PCI card on board. Dumping the contents, they recognised the unique identifier the driver was using to determine the card’s model. It was then a simple job to change this value to one that corresponded with a sixteen-input card to enable functional autodetection by burning a new value to the EEPROM. [Evan] then published the findings to the LinuxTVWiki page.
It’s a tidy hack, and one that’s very forward looking – in ten years, if this card finds itself in the junk bin of another, they’ll have far less problems getting it up and running. Knowing about the ins and outs of autodetection will prove useful in your hacking career. In USB it’s done with PIDs & VIDs and there’s some controversy about how those are dished out.
It’s interesting that the author talks about “portability” here.
The hack, as presented, isn’t very portable in the sense that it’s the only card that has this firmware update. Anyone else out in the wild with this exact same card is going to run into this problem again. So unless they’re aware of this article _and_ they have the ability to update the firmware, they’re just going to fiddle with the drivers or just deal with the 8 inputs or worse, say “fuck Linux”.
I feel the correct solution is to have the driver author modify the drivers, either by auto-recognition or implement an option to choose (or rather force) a different driver.
This situation isn’t unusual. I’ve had success having drivers corrected and/or updated after presenting the author with detailed documentation and, in some cases, presenting the code that could simply be folded in. Of course, some authors are assholes and absolutely refuse to make changes or apply patches, but that’s true of every project. I admit that I was that asshole on occasion.
My point is, it’s not impossible or is it always ideal to change the driver, but it guarantees the largest net can be caught.
Right. I’ve looked at driver source code for a couple of soundcards. It’s not unusual for the Linux driver author to have to stuff in “quirks” – hacky attempts to autodetect or work around buggy hardware.
The best solution would be for the driver to do something like try to access port 9… if that fails, it’s probably the 8-port version : ) Or just default to showing all 16 ports in all cases, but the user will never see any actual inputs beyond port 8.
Oh, Quirks…. I have a laptop that reads the battery’s current and capacity. Found it cheap to use for calibrating cell replacements in my multimedia laptop.
However there is a HPET timer bug (the core-local one) where it cannot be software reset without an external IRQ, i.e. moving a mouse, typing or when the WiFi is left on.
Have to use nolapic_timer boot option or the sound just repeats a half second loop after about 5mins estimate.
Oh, and on the subject of EEPROMs: A bad power supply can reduce the data retention lifetime significantly (Bit fading effect) and can cause the EEPROM to not read at the lower/unstable voltage sooner.
To naysayers: It does happen, it is not (usually) the EEPROMs’ fault, but the environment (electronic/electrical, temperature, moisture, etc)
Also a case of skills on-hand. Everyone in the room that night *knew* how to use the TL866 to edit the chip’s contents, and knew it could be done in ten minutes. I have no idea what it would take to commit code changes in such a way that they wouldn’t simply be clobbered by a new version of the capture software.
Surely that’s easier for someone with the requisite skills, but that wasn’t us! And the goal wasn’t to learn how to be linux driver developers, the goal was to capture some camera feeds and make it so we wouldn’t have to poke at it later.
changing a byte in an eeprom is #NotAHack
Nah, using the bt878 is the hack… I have never seen one work out of the box without fighting it, let alone out of a junk box.
yeah most diont even have an eprom just a pad where one should go:)
the thing about these cards is: if you solder one on, with the memory location like I had it, it’ll probably detect just fine. The amount of tweaking and enabling of things someone with basic knowledge of electronics hardware can do is phenomenal. Using this method you can add hardware to a card you have, then it’s very easy to convince the driver (every time you plug in your custom hardware) that you have the new functionality and it all works fine.
Texas Instruments used Device Service Routines in the 99-4 and 99-4/A. Put the device drivers on the peripheral cards as direct extensions to the operating system. Never ever a need to go hunting for a driver and impossible to lose them.
As cheap as flash memory is these days, PCI and PCIe cards and USB devices could all come with drivers onboard for installing onto Win, Mac and Linux.
https://www.amazon.com/Brother-PC-Connectable-Label-Cutter-PT-2430PC/dp/B001IKKIVW
We had one of these in college, worked great, had the software on it in a usb mass storage device. I can say that we never tried it outside of windows, but it always worked. Everything should do this.
The technique used to produce the high-res scans of the card was the subject of a previous post:
http://hackaday.com/2015/09/09/smart-phone-camera-turns-laser-cutter-into-hi-res-scanner/