Reducing OS Boot Times for In-Car Computer Applications, Part II

In our last article, we discussed the motivation for wanting boot time reduction. As discussed, we are trying to create as "instantly on" an experience as we can for in-car computers. We're taking a holistic approach to the problem by looking at every place that the system delays during bootup and trying to list all our options for reducing the times in that area.

You may have noticed over the last several years that the delay has increased between when you start a car and when you hear the radio. When head units were simply analog FM and cassette adapters, music would start blaring out, at the current volume, the instant the car was started. These old stereo units had analog potentiometers for the volume control, analog tuners to get the FM signal and analog tapes that instantly started producing sound. Nowadays, a CD player/FM tuner is a mini-computer. The volume can be set to a non-blaring volume automatically between startups. The buttons and knobs now used rarely are potentiometers; they merely send plus/minus information to the tuner controls. To play a CD now requires spinning up the CD, and the firmware on these devices has to boot up, going through some sort of POST (power-on self-test). Sometimes the newest devices actually have to talk to the car's computer, adding additional delay.

There are other reasons for the increasing delay. When aftermarket amplifiers are installed in a car, you often have a staged system where the head unit turns on and sends 12 volts back to an amplifier, which then turns on, at which point you get sound. The amplifier has to charge up its capacitors and level out its power in order to produce high volume. Thus, you now have a cascading delay effect where the car turns on, then the head unit (radio) boots up, then it tells the amp to power on and then the amp boots up--thus, it takes several seconds before you hear anything. If the amp is wired to start up at the same time as the head unit, you may experience a loud pop as the amplifier pumps out transient voltages from the not-yet-powered head unit. They even sell devices that add several seconds of delay to a 12-volt line to solve these popping problems.

So while the BMW 7-series navigation unit is engineered to show a video splash within milliseconds, the norm for audio devices is to produce output after several seconds. Thus, it is reasonable to give this same leeway to an aftermarket in-car computer. However, fully booting an in-car PC can take almost a minute. The question is, how does one reduce that time?

Booting many homebrew in-car PCs can take, literally, a minute. A lot of the delay results from the operating system booting or waking up from hibernation, but it's worth looking at the entire sequence to establish a baseline for the hardware we're using. For the purposes of our analysis, booting up a computer in a car consists of the following steps:

Car power stabilization: The 13.8V power line, which dips down to as low as 6V or gets cut off during engine cranking, must stabilize over 12V. This takes fractions of a second but it does take time. (Cost: ~ tens of milliseconds)

Power supply/regulator stabilization: The circuitry that powers the engine, be it a 120V inverter or a DC-DC power supply, and the associated power regulation circuitry that delivers clean 12V/5V to the computer must stabilize. Inverters can take several seconds to deliver 120V, while DC-DC boards are pretty quick. (Cost: ~ hundreds of milliseconds to seconds)

Power sequencer hits ATX-on button: This step can add time. Many motherboards now have a wake on power loss feature (technically a wake after power loss) that makes them instantly start up when power becomes available. However, many power sequencer/shutdown controllers, which make sure computers turn on and off with the car, tend to add delays to start-up. They usually give the power supply 2-3 seconds to fully stabilize its voltage at 12V; if this doesn't occur, the motherboard can hang on boot. (Cost: up to 3 seconds)

POST: The power-on self-test is the first part of the bios code. This can be reduced greatly but not eliminated by disabling memory checks, startup flash screens, floppy seeks and the like. Without getting a custom BIOS, however, this still takes time. In practice, it can be reduced on some motherboards to less than a second. (Cost: ~ 1 second)

BIOS: These are the rest of the BIOS functions that occur after the possibly necessary self-test. They include a variety of auto-configuration of plug-and-play settings, auto-detection of hard drives, power management and the dreaded DMI pool message that lingers on the screen for many seconds. This is the bulk of the pre-OS boot time. (Cost: ~ 1-10 seconds)

Bootstrap: This doesn't take long at all, but this step can vary based on the boot device. Because it could be hard drive or Flash, at the minimum you have the access time and transfer speed of the device, so it can take several tens to hundreds of milliseconds. If this is a two-staged process, as can be the case with boot loaders (that redirect from the beginning of the disk to some offset on the disk, if I understand correctly) that can add a bit more time. Although the latency of the disk or solid-state memory can change this bootstrap timing, the more important impact of changing the disk is in the boot times discussed below. (Cost: ~hundreds of milliseconds for bootstrap; tens of seconds to minutes for actual OS load)

Run boot loader: This step of the process is the first time we get to run code we may have written. In the Linux case, this would be GRUB or LILO. (Cost: less than a second)

Operating System and Drivers: This step is the long (potentially upwards of a minute) leg of our journey to a user prompt. The baseline we used when benchmarking this particular step is the venerable DOS, which boots in about the same time as the Linux boot loader. The worst case would be a full install of some operating system, un-tuned, with tons of unnecessary drivers, which could take another minute to boot. (Cost: Un-optimized, over 60 seconds. Somewhat optimized, as low as 15 seconds. Goal, less than five seconds).

Show user prompt: The OS eventually must finish booting and show the prompt, whether that is a GUI screen, a text prompt or a voice prompt for audio commands. At this point the system must be fully functional and able to accept any commands.