Embedded systems are fast becoming part of day to day life for comfort, convenience, entertainment, wellness and security. Be it phones, automobiles, home appliances and medical devices, everything is getting “smart” and connected. Increasing use of smart phones, decreasing hardware cost, ease of use and availability of free and open source OS-es like Linux and its variants have acted as a catalyst in the adoption of embedded systems in our day to day life.
With a large number of distributions available, Linux is gaining momentum as a leading platform for embedded designs. Boot time is one of the most important requirements for embedded systems and this is one of the drawbacks of Linux.
In this paper, we provide a brief introduction to Automotive Rear View Camera Systems (RVCS), the need for faster boot times, the challenges involved and how those can be addressed.
What is an Automotive Rear View Camera?
Upon engaging the reverse gear in a car, truck or other class of heavy automobile, an important information that the driver needs is the knowledge of activity and structures around the rear part of the automobile.
Advanced Driver Assistance Systems (ADAS) equip drivers with Rear View Camera Systems (RVCS) to address this. These could be simple RVCS which just project the rear field of view onto a display positioned near the driver or intelligent ones that run Object Detection (OD) algorithms on the captured video and generates warnings to the driver.
Automotive RVCS is a Real Time Embedded System which primarily consists of a Camera Sensor and associated processing units along with display and alarm units. The Camera Sensor [typically with a built-in Image Signal Processor (ISP)] will feed input to the processor unit and an LCD Display will display the preview or the processed video as output.
Figure 1. shows a typical block diagram of a RVCS. A camera sensor is connected to a System-On-Chip (SoC). The SoC boots its OS / image from Flash Memory, uses an external DDR memory for storing temporary image data and interfaces to a LCD panel. In addition, it could also connect to other components of the automobile using vehicular networks like CAN.
Figure 1: RVCS High-level Block Diagram
Linux boot sequence
Typically, a Linux device boots in three phases. At power on, a basic hardware specific code loads from ROM, executes a few instructions and initializes those peripherals (like UART, Flash and DDR) needed to run the boot-loader.
Then, the boot-loader will do a basic initialization of peripherals required to load the kernel into the memory. The kernel takes control once it gets loaded to RAM from secondary memory storage.
After the kernel load, device drivers for all available peripherals are loaded. The kernel then mounts and initializes the File System (FS), loads the “init” process which runs the initialisation scripts and finally starts the user interactive layer.
Need for faster boot-up time for RVCS
At power-on, it typically takes several seconds for a Linux system to load the application. Heavy initializations of subsystems like network add further delay to the boot time. If the application to be launched is a Rear View Camera, the driver has to wait for several tens of seconds before he can see the rear field of view of his vehicle.
Many European countries and Automotive Compliance frameworks (eg. GENIVI Alliance) have specified the standards for booting up automotive infotainment systems which include RVCS as an integral part.
Boot time optimization
Profiling the boot-up process is the first step in optimization. In the absence of built-in profilers for boot-loaders under Linux, enabling time stamp options in the boot-loader and kernel is an effective way of profiling. Instrumentation of boot-up will also be required. These measurement techniques provide near accurate results.
There are several ways we can solve the challenge of delayed boot up for RVCS.
- Using dedicated MCUs within the SoC for rear view camera sensors. This will bypass loading Linux and its other components and waiting for the complete boot process before we see the captured camera image. This is possible only in high end systems which have dedicated embedded controllers for vision systems.
- Keep the typical Linux boot as is but heavily optimize the boot sequence, components involved in booting like boot-loader, kernel, file systems and applications.
In this paper, we will focus on Approach 2).
Boot time optimization techniques
The techniques involve removing, postponing, parallelizing, reordering and optimizing functionality as required.
For optimizing boot time, we will focus on the following:
- Init RAM disk
- Stage 1 boot-loader
- Stage 2 boot-loader(like u-boot)
- Linux kernel
- File system (FS), services and applications
- Secondary Storage driver (MMC/NAND) optimization
- Init Ram disk :
The initial RAM disk (initrd) is an initial root file system that is mounted prior to when the real root file system is available. The initrd is bound to the kernel and loaded as part of the kernel boot procedure. The kernel then mounts this initrd as part of the two-stage boot process to load the modules to make the real file systems available and get to the real root file system.
The initrd contains a minimal set of directories and executables to achieve this, such as the insmod tool to install kernel modules into the kernel.
To get faster boot time for RVCS, we use initrd to tie the kernel and a minimal root FS which includes camera driver module, display driver module and camera application.
With this, we will initialize the boot-loader and kernel + rootfs (initrd), which will start streaming the camera capture. The remaining components of the file system services, applications and part of loadable kernel subsystems and modules will be loaded at a later time with the real root file system.
- Stage 1 Boot- loader :
This component initializes clocks, DDR, secondary storage for loading the Second stage boot-loader and other components.
In this stage, we choose the optimized CPU frequency and DDR clock settings for best performance of the system. We also reorder initialization of some of the components that are either not required or can be moved to the Second stage boot-loader.
3. Stage 2 Boot-loader :
a) We remove unnecessary functionality. Usually, boot-loaders include many features needed only for development and debugging (like network boot etc). Compile your boot-loader with fewer features.
b) Optimize required functionality. Tune boot-loader for faster performance, switch to another faster boot-loader (if available) or skip the Second stage boot-loader and load the kernel right away.
c) Disable the drivers like uSD card (if booting from on-board eMMC/NAND), Ethernet, USB, command line options, parser options and many other commands which are not required for the intended use case.
d) Optimize boot scripts and memmove, CRC checking, boot delay, use falcon uboot mode.
4. Linux Kernel :
a) Optimize kernel image and its code size(compression techniques, LZO and gzip etc ). Unless executing-in-place (XIP), the executable images have to be loaded into the memory from the storage media e.g. while booting from MMC/SD. Bigger means longer time to load the image, which impacts the boot time. While using compression techniques the size will be reduced however the loading can be slower. Various compression techniques can be used to optimize this.
b) Remove unnecessary functionality
c) Postpone/reorder other functionalities, driver modules except those required for RVCS.
d) Reduce the kernel image size by disabling kernel debug options, tracers and load symbols for device drivers.
e) Use deferred init calls.
f) Use fastmap method if booting from UBIFS, turn off the console option, use “quiet” mode.
g) Preset loops per jiffy
h) By using above methods and initrd, we will launch the RVCS within 2.5 seconds after power-on, on a dual-core SoC running at 1GHz. In the background, we will mount and load the real file system with all other components and services.
5. File system and its components :
With initrd, we have achieved our requirement of launching the RVCS in the least amount of time.
There are multiple optimization techniques in rootfs like choosing an optimum one (UBIFS vs JFFS vs ext series). Also, we can heavily optimize the scripts, launch applications, use systemd instead of sysVinit etc to attain further performance in the system.
6. Optimising MMC/NAND driver :
Timing analysis for read/write, burst mode read, using assembly instructions for read; enable multiple buffers in storage device for handling data.
This paper has demonstrated that with judicious selection of a combination of measures, it is possible to implement a RVCS system which can meet real-time requirements and standards compliance.
It is noted that on an ARM Cortex-A8 dual core based system running at 1GHz, the time taken for booting is reduced from around 18 seconds to around 2.5 seconds.
++ Prabhuraj T.