quickboot on i.mx6

Quickboot on i.MX6FTF2014

04/10/2014

Gary Bisson

Embedded Software Engineer

SESSION OVERVIEW

1. Introduction

2. Boot Process

3. Optimizations

4. Solutions

5. Demonstrations

6. Conclusion

ABOUT THE PRESENTER

• Embedded Software Engineer at Adeneo Embedded

(Bellevue, WA)

I Linux / Android

♦ BSP Adaptation

♦ Driver Development

♦ System Integration

I Partners with Freescale

Introduction

Quickboot on i.MX6 Introduction

ARE WE TALKING ABOUT FASTBOOT?

This presentation is about quick boot

• Fastboot is the protocol used by Android to communicate

with the bootloader in order to reflash a system on the

device

• Type fastboot into google: 90% hits within first 10 pages

are about android

Warning

Fastboot is not the subject here!

5


SPEED DOES MATTER

• Critical systems

I Automotive: need to handle CAN message within a

specific time frame after boot (typically x100ms)

I Monitoring: need to reboot ASAP in case of failure

6


SPEED DOES MATTER

Consumer are used to previous generation of non-smart

devices that starts immediately

• Consumer products

I TV: turn on quickly whenever pressing on the power

button

I Phones: deep sleep mode allowing to have a

aggressive power management policy while keeping

responsiveness

7


SPEED DOES MATTER

It is still possible to cheat

• Display splash screen early in the bootloader (x100ms)

• Animate the splash screen while booting

Those tricks give the end user the illusion of a quick boot, but

this could not apply to critical systems.

8


SET YOUR GOALS

• Need to have clear goals:

I Prioritize features

I Set constraints

• Boot-Time optimization = trade-offs

9


GOAL OF THE PRESENTATION

This presentation aims at:

• Showing different existing technics to optimize boot time

• Explaining how to integrate those technics

• Showing real customer solutions

10

Boot Process

Quickboot on i.MX6 Boot Process

BOOT PROCESS

12


BOOT PROCESS

Typical i.MX6 boot process:

• Boot ROM

• U-Boot

• Linux Kernel

• Rootfs:

I Linux

I Android

13


BOOT ROM

• Boot devices:

I NOR Flash

I NAND Flash

I OneNAND Flash

I SD/MMC

I SATA HDD (only i.MX 6Dual/6Quad)

I Serial (I2C/SPI) NOR Flash and EEPROM

14


BOOT ROM

• IVT Header

I Entry point (fixed offset)

I Points to DCD table

• DCD Table

I List of init commands

• Boot data

I A table indicating the program image offset and size

15


MEASUREMENT TOOLS

• Grabserial

I Serial output time-stamps

• Bootgraph

I Kernel driver graph

• Bootchart

I Init scripts graph

16

Optimizations

Quickboot on i.MX6 Optimizations

METHODOLOGY

18


INTUITION

The first things that comes in mind are usually:

• Smaller size

I Loads faster (bandwidth of the storage mdevice)

I Loads from faster storage (NOR, MMC class 10)

• Remove uneeded features

I Smaller system (see above)

I Not wasting time

19


GENERIC OPTIMIZATIONS

• lpj

I If your products are similar, you can set lpj

I Gain about 250 ms by skipping the calibration loop

• Stripping init

I Start your critical application as soon as possible: rcS

or inittab

I An idea may be to try to use your critical application as

init

20


GENERIC OPTIMIZATIONS

• flash storage:

I NAND, NOR, SD

I We usually get really good performance booting from

SD cards, class 4 or class 6, but you will still have to

benchmark

• toolchains

I Not all toolchains are created equal. Changing

toolchains, will usually make you gain the last hundred

of ms

21


BOOTLOADER

• U-Boot is slow? Get rid of it!

• arm-kernel-shim solutions

• Freescale platforms: configure just a few register then

passing atags

I Thanks to BootROM / DCD table

22


BOOTLOADER

• Kernel may not initialize every device

I relies on the bootloader

• Should we migrate everything to the kernel?

23


GENERIC SOLUTIONS

U-Boot Secondary Program Loader (SPL)

• Small binary that fits in SRAM and loads the main U-Boot

into RAM

• Within U-Boot source tree, sharing same code base

• Two scenarios:

I Fast path: SPL loads and then starts Linux kernel

I Development or maintenance mode: SPL loads

U-Boot

24


KERNEL OPTIMIZATIONS

• Remove as many features as possible

I The smaller, the faster to copy from storage to RAM

I Less features means less initializations

• Not always what you want

I What about a full-featured kernel?

• Easy optimizations:

I printk and DEBUGFS

I try CONFIG_CC_OPTIMIZE_FOR_SIZE=y

I SLOB memory allocator

I KALLSYMS

25



• Stripping a lot of features from is not always possible

• Use modules!

I Load them when your critical application is ready

I Not always possible to compile as module (example:

networking)

• Kernel compression

I None

I Gzip

I LZO

26



Use of deferred_initcalls

• Kernel stills grows

• Need to patch kernel

I see http://elinux.org/Deferred_Initcall

• Need to modify drivers

I deferred_module_init

• Will execute some init only when asked for (user-space)

I cat /proc/deferred_initcalls

27

http://elinux.org/Deferred_Initcall


SMP

• SMP is quite slow to initialize

• UP systems may be faster to boot

• Hotplug the other cores afterwards

I /sys/devices/system/cpu/cpuX/online

28


ROOTFS

• Multiple challenges when building your rootfs

I May not be able to optimize the customer’s application

I Even worse, you may not have the sources (blobs)

I Sometimes not possible to reduce the size of your

rootfs

29


ROOTFS

• Use an initramfs, but use it right!

• For critical tasks only

• Use of uClibc reduces the size

• Use of mklibs to further strip the libs

• Then switch_root or pivot_root to the final rootfs

30

Solutions

Quickboot on i.MX6 Solutions

SOLUTIONS

• Boot from SDcard

• Custom bootloader

• Stripped down kernel

• Start a custom init:

I launches critical application (CAN daemon)

I calls deferred_initcalls

I switch_root to the final rootfs and exec the final init

32


SOLUTIONS

• Boot from SDcard

• Custom bootloader

• Stripped down kernel

• Start a custom init that launches the OpenGL application

• Rootfs has been stripped using mklibs

• Final image (bootloader + kernel + rootfs): 5.2MB

I 3MB for HW blobs libraries

I No compression

33


RESULTS

• CAN messages ready for transfer in about 360ms

• OpenGL application is started in 720ms from power on

590ms from reset

34


NEXT STEPS

• Use of DMA to load the image

• Parallel inits

• Provide a more generic solution

35

Demonstrations

Quickboot on i.MX6 Demonstrations

HARDWARE SELECTION

• i.MX6Q Sabre Smart Device

• Kernel 3.0.35 release v4.1.0

• 10" LVDS display

37

Quickboot on i.MX6 Demonstrations

SOURCE CODE

• Code for the custom bootloader:

https://github.com/alexandrebelloni/whoosh

• Code for U-Boot SPL: coming soon...

• Main inspiration was http://www.elinux.org/Boot_Time but it

needs some updates

38

https://github.com/alexandrebelloni/whoosh

http://www.elinux.org/Boot_Time

Conclusion

Quickboot on i.MX6 Conclusion

CONCLUSION

• No one-size-fits-all solution

• Highly depends on constraints

• Generic solution progress

40


QUESTIONS?

41


REFERENCES

• elinux.org: http://www.elinux.org/

• Free Electrons' training: http://www.free-electrons.com/

42

http://www.elinux.org/

http://www.free-electrons.com/

quickboot on i.mx6

Engineering

boot time

boot process3

quick boot fastboot

aspecific time frame

faster storage

critical systemsi automotive

display splash screen

storage mdevicei loads