Distributions

Building a Tizen IVI test experience

In November of 2013, I decided to undertake a garage-hacking project and build an in-vehicle infotainment (IVI) Linux box for my own car. Motivated hobbyists have done such things for years, of course. But, after having followed the development of various automotive Linux projects (such as GENIVI and Tizen IVI), I wanted to put them to the test, rather than simply stuff a Raspberry Pi into the glove compartment and run Rhythmbox on a tiny screen on the dashboard. Interesting developments were happening at automakers and software vendors, and they were worth exploring. It turned out to be a rather large project, so to cover it fully will take more than one installment. The first major milestone involves understanding the unique hardware, power, and boot requirements of an IVI unit (as well as finding a distribution that fits the bill).

It seemed clear fairly early on in the planning stage that Tizen IVI was the only real choice for the distribution. The situation has changed a bit since then, but at that time, GENIVI was not releasing installable OS images at all (although they did maintain some Yocto meta layers), and the Automotive Grade Linux (AGL) project had not been announced.

The central idea of this project was to build an IVI system using as close to "standard" hardware as possible and to avoid any overly deep hacking—so as to provide a relatively neutral assessment of Tizen IVI's usability. Certainly the phrase "overly deep" is vague enough to allow for a lot of wiggle room, but I roughly defined it as having to write non-trivial code from scratch.

Power

When I started work in earnest, Tizen IVI releases were made for two target devices: a difficult-to-acquire industrial IVI box and the Intel NUC. Since the NUC is a fairly standard Atom-based system on the inside, I decided to use a similar-generation mini-ITX Atom motherboard as the backbone for my build. It gave me more flexibility in the choice of components, provided more USB ports, and (unlike the NUC) can be fan-cooled if necessary. On the other hand, this choice put IVI power issues front and center.

Powering a fickle device like a PC from your car has two key angles. First, car batteries provide a nominal 12V DC, although the actual voltage varies a lot based on age, weather, and draw from the rest of the car electrical system. So an IVI system must have some device to regulate the battery output and provide "clean" 12V DC power, regardless of the conditions at any given moment. On the plus side, car batteries do provide a lot of amps, so there is little need to worry about current draw.

The contents of a modern motherboard need DC power, but almost all motherboards are built to get that power from an external, AC-to-DC power supply. Most mini-ITX boards provide ATX power connectors. Luckily, the few vendors that make aftermarket car-computer hardware make ATX-style DC power supplies that you can hook up to the battery for input and will provide an ATX connection (supplying well-regulated power) for output. That is what I went with in the end; an M4 PSU from Mini-Box that provides a 24-pin ATX connector.

Ironically, though, most mini-ITX cases expect external, laptop-style power supplies with a single cord. As far as I could tell, no vendors make an automotive DC-to-DC power supply designed for that usage. Hooking up a standard external AC power supply would then need a separate DC-to-AC inverter to run from the car battery, which is both inefficient and convoluted. Consequently, using the Mini-Box ATX PSU meant I had to cut a hole in the side of the case large enough to allow the ATX wire bundle through.

Just as cleaning the power to the motherboard is important, so is providing clean power to any peripherals. I tackled this by making my own 5V and 12V power cables that I hooked up to unfilled Molex connectors from the ATX PSU.

With power quality taken care of, there is the second IVI power issue: startup/shutdown handling. The historical thinking is that the PSU should wait a few seconds after the ignition circuit is turned off before it disconnects, to let the OS perform a clean shutdown. However, the historical thinking also says that PSU should wait a few seconds after ignition to power on the motherboard, to avoid trouble when the driver puts the key in then remembers something and takes the key back out, cutting the power while the system is mid-boot.

The PSU I selected addresses this too, by including an ignition-sense input (which you tap into the car's existing ignition-sense wire) and a set of timers for startup and shutdown. Unfortunately, although it is theoretically possible to change the timer durations, the manufacturer only provides Windows software to do so. Luckily, an enterprising hacker has posted a simple program on GitHub that brings this functionality to Linux.

The final wrinkle is that these ignition-sense PSU delays interfere with the automotive industry's regulatory mandate to make an IVI system boot up in less than 3.5 seconds, so it can display live footage from the car's rear-view camera to the driver. GENIVI and Tizen IVI both spend a lot of effort ensuring that they meet this requirement.

Fortunately, the consumer market "solves" this dilemma, albeit inadvertently and with little flexibility. Aftermarket dash displays typically have multiple inputs (e.g., HDMI, S-Video, and composite RCA) and provide a hardware setting that switches to the RCA input whenever it has a signal present. Aftermarket rear-view cameras are almost all RCA and are activated by putting the car in reverse, so if you hook one of them up to a dash display, the display will switch over to camera input regardless of how long the PC software takes to boot.

Hardware

The power-cleaning and startup/shutdown concerns are important to building a running system, but one must also not ignore the physical build process, which is non-trivial in any car, and varies greatly from model to model. For instance, I mounted my computer case in the trunk, where it would be more easily accessible than it would be crammed under the dash. But Ford, in a fit of inconvenience, decided to place my car's battery under the front hood. And I had to mount the IVI display in the dash in order to see it.

Altogether, that meant several long cable runs are involved in getting power to where it needs to be. In fact, running cables is one of the most time-consuming parts of the entire process. While I would like to say that I made plans in advance and got all of the cable pulling done in one go, in reality it seems like there is always another need to pull the interior panels out of the car and grapple with another cable or length of protective "wire loom" (the split-sided plastic tubing used to wrap wires).

I/O peripherals are also tricky. Standard practice among hobbyists is to use 7-inch diagonal LCD touchscreens, because they fit neatly into the double-DIN sized stereo head unit bay. There is, however, no keyboard option that is free from complications. I first experimented with Bluetooth, but found that unusable during the boot process and at the BIOS screen (which are two of the main points one needs a keyboard). The next best thing is RF wireless, but it can be flaky in the RF-rich (and highly metallic) car environment. USB would be nice, except that you then have another cable to wrangle and must find somewhere to stow a USB keyboard. Audio also requires special hardware: a car amplifier (separately powered) and a sound card.

Looking back on the hardware-design process, trying to put the PC hardware in the trunk so it could be easily removed complicated matters greatly. I learned early on that "pulling the computer" was no simple task even from the trunk. The mounting board had to be unbolted, then a mass of cables disconnected: power, ground, ignition sense, HDMI and USB to the dashboard, antennas (GPS, WiFi, and Bluetooth), as well as power and ground to the audio amplifier and six sets of speaker cables.

I put in quick-disconnect terminals for all of the analog cabling, which helped, but it might have been far simpler to have purchased a second display and simply run the cable into the open trunk whenever I needed to work on the machine in the garage. But it is harder to say whether I would have been better served by building around a compact single-board computer (SBC). It would have been smaller and more portable, but the "PC-like" build was easier to debug and triage, and I never encountered any compatibility problems with software I had to compile.

My (somewhat limited) experience with SBCs like the BeagleBone Black suggests that SBC distributions and packages would require more work to drive the odd peripherals. I used a well-reviewed USB GPS, for example, while BeagleBone Black owners tend to gravitate toward GPS "capes." SBCs also tend to expect removable flash cards for storage, while I preferred to stick with an SSD. Non-ARM SBCs like the MinnowBoard improve on some of these issues, but not all. It is a trade-off. Your mileage, of course, might vary.

Installation concerns

Tizen IVI releases at that time were made as full-disk images—including a partition table, a pre-determined partitioning scheme, and the U-Boot bootloader—meant to be copied directly onto the boot media. Separate builds were provided for UEFI and traditional BIOS machines (using GPT and MBR partition tables, respectively), but there was no installer. This setup caused considerable headaches when none of the release images would boot on my hardware—regardless of how I configured UEFI or the BIOS boot settings, and regardless of what the various diagnostic tools told me about the images.

By sheer luck, I eventually tracked the problem down to a motherboard-specific bug in the BIOS, wherein it would misinterpret a UEFI partition table if there had previously been an MBR partition table on the same media (due to the different sizes of the two partition-table types). The fault for this bug clearly falls on the manufacturer, but it was quite hard to track down. As it turns out, fewer and fewer ATX-style motherboard buyers are running Linux at all—the market seems to be dominated by Windows PC gamers. A few years ago, this was not the case, but today it can be difficult to find anyone (even on the motherboard-maker's discussion forum) who is using Linux.

I initially got a weekly build of Tizen IVI 2.0 installed on the motherboard, but had less luck with subsequent updates. Around the time that the Tizen IVI 3.0 release came out in early 2015, I considered doing a full reinstall, but again found that the disk images would not boot on my hardware. By that time, however, I had a simple workaround in place. I had installed another Linux distribution on a separate partition (Ubuntu 14.04, in this case, but others would do), so I simply copied the contents of the Tizen boot media onto a new partition, changed the bootloader's root, initrd, and vmlinuz references to match the new, correct paths, and updated GRUB2 from the Ubuntu partition.

The main reason I had installed another distribution on the disk was to make use of some applications not built for Tizen; more will be said about that in a later installment. The fact that it side-stepped the temperamental-installer trouble was merely a bonus. My current recommendation for new IVI-system builders is to use three partitions: one for the IVI distribution, one for a "fallback" distribution, and one to store media files. Another side effect of the Tizen full-disk-image releases is that any data files (audio, maps, etc.) have to be stored in a separate partition to not get overwritten; it also helps that they will be accessible from any other distributions.

It is easy enough to configure GRUB2 (or whatever bootloader you choose from your fallback distribution of choice) to boot immediately into Tizen IVI, but I chose to configure GRUB with a two-second boot delay. That allows me to easily alternate between distributions at boot time, and in practice I am rarely in enough of a hurry that I need my IVI display up in less than two seconds.

The installation problem is a serious drawback to Tizen IVI. Whether the fault lies with U-Boot, a lack of diverse hardware testing, or elsewhere, users coming to the IVI-build process themselves may hit the wall quite early on and be discouraged. When the 3.0 releases were first announced, there was talk of the project adding an installer. As it turns out, though, all that was provided was a minimalist Tizen Core disk image that would attempt to fetch the full IVI package set once installed. It did nothing to make installation easier.

Kernel issues (or lack thereof)

Despite the trouble that Tizen IVI caused during installation, it deserves high marks for usability once it is installed on the system. For all intents and purposes, Tizen IVI is a standard desktop Linux distribution underneath. The kernel is modern and includes all of the modules required to get up and running on generic hardware. By comparison, an embedded device is likely to be tied to a specific kernel version, come with a limited set of device drivers, and require a board-support package with any number of out-of-tree patches.

To provide one anecdotal example of how easy it is to get Tizen IVI up and running, during my first install I somehow neglected to hook up a mouse, and when the GUI booted I needed some way to click on the "Terminal" application launcher. So I grabbed the nearest piece of free hardware, which was a pressure-sensitive Wacom graphics tablet. Tizen not only detected it as a pointing device when I plugged it in, but it loaded the wacom module (which is distinct from generic USB HID support). Pressure-sensitive tablet support is probably unnecessary in the car, but it is nice to have options.

More importantly, though, I was pleasantly surprised to find that Tizen supported my GPS device, touchscreen, and 3G USB modem without any additional work. The only hardware that required any special effort was the motherboard's combination WiFi/Bluetooth adapter, which unfortunately needs a proprietary firmware blob to run. That said, everything from wget to the normal GCC toolchain is available in Tizen, so I downloaded the vendor's kernel module, compiled it, and loaded the firmware blob without incident.

At this point, whenever the ignition key is turned, the PSU waits for five seconds, then the system boots up. All of the necessary hardware support is enabled, at least at the OS level. When the key is turned off, the process is reversed. In our next installment, we will take a look at configuring system services like the window manager and audio, as well as at connecting what is currently a generic Linux box to the car's diagnostic tools.

I realize that many of the power and hardware-design issues discussed so far may seem trivial from an OS perspective. But my experience with this project has taught me that none of these steps can be taken for granted. A car is, in many ways, a hostile and antagonistic environment for a computer: it includes flaky power, constant vibration, heat, corrosive liquids and gases, and in some places, actual flying rocks. Failing to take any of those challenges seriously can leave you with a broken system—regardless of how good the software might be.

Comments (7 posted)

Distribution quotes of the week

Comments (none posted)

OpenSUSE Leap 42.1 milestone 1 released

Comments (none posted)

Plasma Mobile launched

Comments (39 posted)

CentOS Continuous Release Repository updated with CentOS-6.7 RPMs

Full Story (comments: none)

Sparc removal

Full Story (comments: none)

Ubuntu 14.10 (Utopic Unicorn) End of Life

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 620 (July 27)
• 5 things in Fedora this week (July 24)
• Linux Mint Monthly News (July)
• Ubuntu Weekly Newsletter, Issue 426 (July 26)

Comments (none posted)