The document discusses optimizing boot times for an embedded Linux application with QT by specializing Linux functionality. It describes analyzing boot processes to identify delays, removing unnecessary functionality, optimizing code, and reordering processes. These techniques were applied to a home automation case study, reducing boot time from 19.44 seconds to 0.77 seconds, a 96% decrease. Further optimization may be possible by better understanding QT delays and utilizing hardware acceleration.
Renesas DevCon 2010: Starting a QT Application with Minimal Boot
1. ID 720C: SH7724 starting a QT application with minimal boot Andrew Murray (amurray@mpcdata.com) Embedded Linux Consultant Engineer 13 October 2010 Version: 1.0
2. 2 Mr. Andrew Murray Embedded Linux Consultant Engineer, MPC Data Driver and kernel development Embedded applications development Windows driver development Education MEng in Software Engineering from University of Wales, Aberystwyth, UK Member of the IET working towards CEng professional accreditation Work Experience 4+ years of experience working with embedded Linux devices Taking a key role in developing the swiftBoot service for optimizing boot times in embedded devices 2
3. 3 Innovative devices often require complex functionality and minimal boot times - for minimum power consumption or maximum user experience 3 Innovation
4. 4 Innovative devices usually require Lots of complex functionality Minimal boot times Meeting the needs of innovative devices is a challenge Complex functionality is difficult without an operating system Minimal boot time is typically difficult with an operating system Where should you spend your time? Itâs my view that with the right approach complex functionality can be achieved with embedded Linux in minimal time Weâre going to examine how this is possible 4 Minimal Boot Times are Achievable with Linux!
5. 5 Who are MPC Data? Why does embedded Linux take so long to boot? Best approach to boot time reduction Case Study: MS7724 âEcovecâ Demonstration Conclusion and Q&A 5 Agenda
6. 6 MPC Data is a well established embedded systems integrator with a strong focus on platform development 55 strong team serving North America & Europe Experts in embedded development and optimization Contributors to the open source community Technical focus and track record backed-up by numerous successful products in a wide variety of markets Renesas Alliance Platinum Partner Provides the unique swiftBoot boot time reduction service Contact: business@mpc-data.comhttp://www.mpcdata.com/ 6 MPC Data
7. 7 Why so long anyway? Embedded Linux is: General purpose Likely to contain functionality your device doesnât require which will result in more initialisation and a larger image size Convenient and flexible Likely to probe and detect hardware which you know will always be there which will contribute to boot delays Boot speed isnât seen as the highest priority A lot of duplication between boot-loader and kernel There are many approaches to overcome large boot delays such as hibernation, stand-by and similar technologies, This presentation describes how boot times can be drastically reduced by specialising Linux to your deviceâs needs and product requirements 7
35. 14 Case Study Use the MS7724 âEcoVecâ as a case study for a home automation system Boot time functionality: Responsive QT user interface Additional functionality: Video capture/render (representing a security camera) Will describe tools and techniques along the way 14
38. 17 Case Study Use the MS7724 âEcoVecâ as a case study for a home automation system Boot time functionality: Responsive QT user interface Additional functionality: Video capture/render (representing a security camera) Will describe tools and techniques along the way 17
40. 19 Case Study Use the MS7724 âEcoVecâ as a case study for a home automation system Boot time functionality: Responsive QT user interface Additional functionality: Video capture/render (representing a security camera) Will describe tools and techniques along the way 19
41. 20 Case Study Typical Starting Point: BootLoader: UBoot (2009-01) OS: Linux (2.6.31-rc7) Filesystem: Buildroot (2010.05) Application: QT Embedded Opensource 4.6.2 20
42. 21 MS7724 Boot Process Boot process: UBoot loads compressed kernel into RAM, Kernel mounts root filesystem and starts init process, Init scripts start GUI application Component times measured using GPIO and a logic analyser, UBoot time measured time between reset and GPIO line being asserted Sources modified to toggle GPIO Time to required boot time functionality: > 19 seconds! 21
47. 26 Compressed Kernel Images The purpose of the boot loader is to jump to an uncompressed kernel image (usually in RAM) A number of factors should be considered If Flash throughput is greater than decompression throughput then an uncompressed image is quicker 26
51. 30 QT Reducing the boot time of the QT application was the biggest challenge and very time consuming Un-optimized QT application was large and took 7.4 seconds to reach itâs main function! Improvements reduce time to 0.3 seconds: Measurements show incremental effects against original binary (from left to right)
52. 31 Why does QT take so long to start? Only a portion of the QT application is required to display a UI to the user Event handling, additional forms, etc come later As Linux uses Demand Paging - when an executable is run only parts of the executable used are read from flash This reduces unnecessary flash accesses and decreases application start up time However the application is on a block filesystem so when an entire block is retrieved at a time⊠âŠThis results in unnecessary flash access time if the required executable code is spread over the entire image
53. 32 Function Reordering and Block Sizes Sections highlighted in red represent parts of executable required at start up Most of these parts could fit in a single file-system block I.e. we could optimise the application such that only 2 blocks of flash are accessed rather than 4 Thus the executable can be optimised by: Reducing block size Eliminating FS readahead Reordering executable
54. 33 Function Reordering GCC compiler features can be used to assist: --finstrument-functions --ffunction-sections Before the entry and after the exit of every function call â GCC will call two new functions when âfinstrument-functions is used: void __cyg_profile_func_enter (âŠ.) void __cyg_profile_func_exit (âŠ.) These calls can be implemented to find out which functions are called when This information can be used to generate a custom linker script â when âfunction-sections is used each function lives in its own section. This way we can ensure all the required sections for startup are contained contiguously in flash
56. 35 Essential tools Discrete events can be measured by toggling GPIO outputs and utilising a logic analyser, Kernel events can be measured with: Printk timings, Initcall_debug and bootchart scripts, Userspace events can be measured with ubootchart http://code.google.com/p/ubootchart/ http://www.bootchart.org/ These are just some of the many tools available
59. 38 Guiding Principles Observe and Record Measuring boot times is the only way to form a clear picture of what is contributing to boot time, Keep copious notes Tackle the biggest delays in the system first, Identify the largest delays and remove them to be most effective Be aware and try to understand varying boot times Remember the uncertainty principle Donât forget testing Remember â you can change any of the source code
60.
61. 40 Minimal Boot Times are Achievable with Linux! Complex functionality with short boot times (< 5 seconds) are certainly achievable with Embedded Linux (with the right approach), Boot time reductions can be achieved by specialising Linux (and friends) to your deviceâs boot time functionality needs: E.g. Removal of unnecessary functionality, optimisation and re-ordering, Other functionality can come later The internet covers many techniques for reducing boot speed but to make a big difference you need the right approach, Observe, record, remove, optimise and re-order Everything you require to make an improvement is freely availably online Requires time and in-depth knowledge of the kernel and software components...
62. 41 Other Solutions MPC Data offer fixed price packaged services from $8,000 Input: Your new or existing embedded Linux product, Process: Identification of required boot time functionality, Extensive and holistic investigation into boot delays of your product including all our areas of our expertise Output: swiftBoot report Approximately 20 pages, Documents boot process including narration on boot delays and mitigations, Enough information for your engineers to act on â though we can also help with implementation, Typically provide recommendations to reduce boot time in excess of > 50%! Visit http://www.swiftBoot.com/
67. 46 Initcall Debug Add the following to your kernel command line: initcall_debug(to add debug) loglevel=0 (to reduce the impact this has on boot time) Ensure the following are set in your kernel configuration: CONFIG_PRINTK_TIME (add timings to printks) CONFIG_KALLSYMS (ensure symbols are there) CONFIG_LOGBUF_SHIFT = 18 (ensure there is room in the log buffer) Copy the output of âdmesgâ Type âcat output | ./scripts/bootgraph.pl > graph.svgâ
