Wikipedia defines Vital Product Data as
“…a collection of configuration and informational data associated with a particular set of hardware or software. Vital product data (VPD) stores information such as part numbers, serial numbers, and engineering change levels”
When hardware manufacturers design a product they often add a small data storage device to the design.
This storage device (an EEPROM) contains important information specific to each individual product. EEPROMS are inexpensive and have minimal capacity. They typically store 256 or 4096 bytes, not megabytes. A few bytes of storage is enough to make any device unique, to have its own ‘personality’, to differentiate one device from another.
Having each customer product be unique is highly desirable, often mandatory for use. Its often a govermenment or legal requirement, depending on the type of product.
During manufacturing, shortly after the product has been assembled, the Contract Manufacturer (CM) is usually required to run a custom software application inorder to check each device is functioning properly. The application looks for defects, runs unusual tests and may caliberate certain device functions (touch screens). When electronic behaviour varies between devices then they may require caliberation. The results of this process are permanently stored in the device. When a consumer uses the device, the caliberation information can be used by the device itself to ensure proper functionality.
The application is generally referred to as Production Test. Its written by the manufacturer of the device… Such as Apple, Samsung or Microsoft. The application is given to the CM for use in their Production Test facilities.
One Production Test is complete, final stages often include allocating a unique serial number for the device, ‘burning’ this information into the onboard device storage. This is usually done using hidden electrical interfaces or obscured factory programming interfaces.
A great example of this unique serial number is the IMEI in your cell phone.
Sidenote: Rarely do CM’s leak the Production Test software to the public although occasionally it does happen. It’s a good day when this happens.
Every car has a unique identifier, partly for legal reasons, partly for maintenance reasons.
Every PC has an internal serial number and unique network address. Partly for maintenance reasons and partly so that your PC can co-exist on a network with other PCs without confusing the network.
Unique identifiers are as useful as they are important. We need them.
Interestingly, as technology advances and manufacturers have attempted to limit the behaviour of their devices, depending on the contents of the VPD, thousands of commercial companies and home enthusiasts have been attracted to hardware hacking, altering or ‘upgrading’ their VPD to unlock new and unusual behaviours.
Sidenote: I once heard a story in the early 90’s related to IBM. In the 70’s, it was common practise to ship mainframes to customers with various internal performance limiters. A $2m mainframe was exactly the same hardware as the less expensive $1m mainframe, but the $2m model has a feature resister ‘cut’ by the IBM engineers to improve the speed. As a 20 year old this shocked me greatly. Today, I completely understand this behaviour and business practise. IBM didn’t design a cheap and expensive model, they designed the expensive model and made it available to more customers less-expensively with lessor features. At the time, I did wonder innocently whether anyone thought to hack this.
The same high value / low value price differentiation happens today in the automobile industry. Consumers can purchase cars with features that are ‘software unlocked’ by the dealer.
Some people object to this, much like my earlier objections to IBM, although most people are unaware or have no opinion.
Enthusiasts have a long history of modifying their products to adjust behaviour.
Basic examples of this include chipping / tuning your car, upgrading your digital camera to improve performance or unlock hidden features, Cloning mobile phones and pagers (back in the day), jailbreaking your cell phone in order to remove carrier locking restrictions. Adjusting the power of your wifi router higher than local laws allow. The list goes on.
Its dangerous and probably illegal in some countries to modify electronics, clone devices or adjust vehicle performance. People do so at their own risk.
In the world of Audio/Video capture cards, companies such as Hauppauge Computer Works store multiple data types in their VPD records. As a Linux developer, attempting to create Open Source drivers for their products, its helpful to understand these VPD records in order to build better device drivers.
… and yet we rarely do.
drivers/media/video/tveeprom.c contains a function:
void tveeprom_hauppauge_analog(…, struct tveeprom *tvee, unsigned char *eeprom_data);
It takes a array of bytes and attempts to decode Hauppauge’s production programming information (VPD). The results are stored in the tvee struct and can be passed around inside the driver to influence behaviour.
The data is not considered secret and if you compare the data taken from one device to another, generally the only difference you’ll notice is in the serial number field.
When it comes to a/v capture devices and VPD, I consider Hauppauge the ‘Gold Standard’. Their VPD is easy to access and Hauppauge Engineering have never refused a question from an enthusiast on its format, they’re helpful. That being said, you get little or no benefit from modifying Hauppauges VPD.
AVerMedia, and other companies rarely use VPD in their PCIe devices so they’re slightly more difficult to integrate into multi-capture commercial workflows. I’d prefer at a minimum they allocated a VPD serial number.
As you can see by looking at tveeprom.c above, Hauppauge go to great lengths to store the type information for important PCB sub-components, including Tuner and Demodulator type codes. In theory, any Windows or Linux device driver, rather than assuming product XYZ has a Philips Tuner and a LG Demodulator, can look at the manufacturing data to understand and support their sub-components.
This allows Hauppauge to keep product XYZ selling in retail, without changing its name, but slowly improve the design over time by changing Tuners, Demodulator and other components.
Its a good example of a data driven design.
The VPD indicates which components are installed on the PCB, the device driver attaches the appropriate software to its running model to differentiate product XYZ rev1 from rev2. Therefore, one device driver supports multiple revisions of a product.
Linux device drivers DO NOT do this. Instead they rely on the differences in their PCIe sub-vendor and sub-device fields to make runtime decisions about which subcomponents are installed. This isn’t a terrible approach, especially when a Linux driver supports Hauppauge and other vendor boards… But its a pity that the VPD for Hauppauge boards isn’t relied upon a little more, especially for exposing serial numbers to user space applications.
Commercial Needs - Multi-channel Capture
VPD serial numbers are useful for commercial customers using Linux drivers. They often deploy multiple capture products in a single server and need a reliable way to associated a V4L2 (analogTV) or DVB (digitalTV) device node with a physical RF TV feed.
At Kernel Labs we write and license Linux device drivers for many products.
One good example is the Hauppauge Colossus HD Capture card. Its a Component and HDMI card that is used by multiple commercial customers for 7x24 capture, recording and media monitoring.
For this driver, and for many other drivers we’ve written, we specifically parse the hardware VPD and expose the hardware serial number to user applications through sysfs. The benefit here is that its trivial for user applications to query sysfs to find a specific capture card by serial number and use this to also locate its Video4Linux2 device nodes.
In summary, a well written application, instead of asking the user to supply a DVB adapterNr on startup asks for the device serial number. Customers don’t care about adapter numbers, they care about RF input signals, and those are attached to capture cards with unique serial numbers that are easy to locate in any server, under any circumstances, with any mix of capture cards.
Consider the case where users are capturing from two devices simultaneously. Due to system failure, software updates or device enumeration changes, the DVB adapter numbers change beyond the customers expectation, they switch around. What was once on adapter #2 now appears on adapter #1, and vice versa. That’s bad for commercial customers who need 100% predictability with signal acquisition.
Assume you have 8 capture cards in a server, which command line syntax do you prefer?
- ./data-recorder-app -a AdapterNr
- ./data-recorder-app -c Serial#
The difference is subtle, until adapternr 0 breaks and has to be removed, then every other adapter can (although not always) shuffle. At this point the commercial customer usually calls and isn’t too thrilled.
Forward planning during driver development and proper VPD handling avoids issues like this.
Certain kinds of devices hold much more than serial numbers and vehicle horse power limitors. These typically have very large storage devices and hold megabytes of data, including firmware.
Tivo CableTV set-top-box devices store secure Cable TV network certificates. Some of these are public and can be downloaded directly from CableLabs, others are considered highly secret and should not be easy to extract using ‘typical debugging equipment’.
Examples of these are the device specific DTCP/IP or CableCard paring certificates.
Assuming you knew how to extract these certificates, you could feed those certificates into an open source implementation of a DTCP/IP stack and obtain highly valuable TV signals without DRM from some typical US CableTV devices.
TV enthusiasts like to prod and probe their Tivo boxes, all sorts of interesting details can be found on their internal hard drives.
Scratching an Itch
I recently visited the UK. I noticed that my rental car automatically retracted the side mirrors when the engine was stopped, bringing the mirrors close to the body of the vehicle. A neat feature.
My US vehicle has a similar feature but its completely manual, I have to elect to fold the mirrors in, flipping a button, or use the remote to trigger it.
Wouldn’t it be interesting if I could attached to the On Board Diagnostics vehicle interface, send a basic message to the car to (presumably) enable this feature by default? I think so.
Or, use an iBeacon proximity sensor, my iPhone and a blue-tooth OBDII interface to send some custom commands to the vehicle as my phone left or entered the proximity of the vehicle? Oh, that’s getting interesting, I might look into this.
Enthusiasts are already adjusting their vehicle behaviour, its nothing new.
To VPD or not VPD, that is the question.
Copyright © 2015 Steven Toth