|
Fast booting techniques meet automotive infotainment/telematics activation needs
No single technique can possibly manage all of the booting and shutdown requirements of car infotainment systems. Nonetheless, several techniques have emerged that, together, address almost any fast-boot scenario.
|
|
By
Sheridan Ethier and Randy Martin, QNX Software Systems
|
Page 1 of 3
|
Automotive DesignLine
(11/17/2006 3:03 PM EST)
|
|
|
Every automotive embedded system must boot up and begin responding to external events within a very short and predictable timeframe. For example, a telematics control unit may have to respond to the CAN (controller area network) network within 50 milliseconds of power on. An infotainment system, meanwhile, may have to display a "splash" screen within one second of bootup to allow user interaction within two seconds of bootup.
Figure 1. Systems like this navigation unit must boot quickly and reliably, even after a power failure. Photo: SsangYong Motor Company.
To address such requirements, systems design engineers can employ several fast-booting techniques. These techniques fall into two categories:
Cold boot: The device boots from a state in which the processor and peripherals are completely powered off.
Warm boot: The device boots from a state in which the processor or peripherals still have power or some form of residual information.
Cold booting techniques
Cold booting is a multi-stage process for the CPU, the operating system (OS), and applications. Some of these stages occur in parallel and some cannot begin until other stages are complete. To cold boot, an embedded device may use one or all of the following techniques:
Support a multi-stage booting process for precise control of the boot flow
Respond to the environment quickly by enabling hardware interaction immediately after the boot process begins, in many cases before the OS initializes
Use a file system that can initialize and repair itself quickly after power failures and other unplanned shutdowns
Multi-stage booting
Multi-stage booting allows a telematics or infotainment system to meet device-activation times after a cold boot. It consists of dividing the software boot process into multiple device-activation stages so that the fastest path to each stage can be achieved.
To enable multi-stage booting, some operating systems, such as the QNX Neutrino RTOS, can launch multiple device drivers and protocol stacks in parallel; they can also provide boot synchronization mechanisms to manage dependencies during different phases of the boot process. For instance, an AC97-compliant audio chip may take hundreds of milliseconds to initialize. During this time, the audio driver can periodically poll the chip's status. Once the chip is ready, the audio stack becomes available to the rest of the system software. By employing this polling approach, the OS can start many other services at the same time, thereby ensuring that no CPU time is wasted during boot.
Mini-drivers enable hardware interaction
Automotive-grade CPUs are providing increasingly higher levels of hardware integration. For example, the main CPU can now directly control CAN, SAE J1850, and MOST interfaces.
While this approach reduces the need for extra chips and circuitry, it also raises concerns for the software developer. For instance, a telematics control unit has to receive CAN messages within 30 to 100 milliseconds from the time that it is powered on; it must then respond to those messages within 100 milliseconds of receiving them. Unfortunately, the complex software running on the main CPU can easily take hundreds of milliseconds, or longer, to boot up.
To address these timing requirements, designs have traditionally relied on an auxiliary communications processor or external power module—a relatively simple, but expensive, solution. Many newer designs have eliminated that hardware by using a software-based approach called mini-driver technology. This approach, introduced by QNX, consists of small, highly efficient device drivers that start executing before the OS kernel is initialized.
Mini-drivers are based on a simple concept: Make a peripheral device usable throughout the boot process. A mini-driver consists of two components:
Handler function: Performs read/write access to the peripheral hardware and implements any other logic related to the mini-driver, such as reading, buffering, and responding to messages
Message data storage: A block of memory that lets the handler function store any messages it receives. These messages can subsequently be retrieved by user applications or by a full-featured device driver.
Once a mini-driver launches, its handler function is constantly called during the boot process to ensure that messages aren't missed. The handler function can be triggered by the device's hardware interrupt or, if a polled approach is required, by a system timer.
Once the system has finished booting, a full-featured device driver can take control from the mini-driver, without incurring blackout times. The full driver simply attaches to the device interrupt, and the mini-driver exits gracefully.
The full driver can also access any messages the mini-driver has buffered in its data storage, ensuring a seamless transition. (If the system doesn't need a full driver, the mini-driver can simply continue to run.)
View a full-size image
|
|
|
|
CAREER CENTER
|
Ready to take that job and shove it?
|
|
SPONSOR
|
|
|
|
RECENT JOB POSTINGS
|
|
|
For more great jobs, career related news, features and services, please visit EETimes' Career Center. |
|
