1.
ID 720C: SH7724 starting a QT application with minimal boot<br />Andrew Murray (amurray@mpcdata.com)<br />Embedded Linux Consultant Engineer<br />13 October 2010<br />Version: 1.0<br />

2.
2<br />Mr. Andrew Murray<br />Embedded Linux Consultant Engineer, MPC Data<br />Driver and kernel development<br />Embedded applications development<br />Windows driver development<br />Education<br />MEng in Software Engineering from University of Wales, Aberystwyth, UK<br />Member of the IET working towards CEng professional accreditation<br />Work Experience<br />4+ years of experience working with embedded Linux devices<br />Taking a key role in developing the swiftBoot service for optimizing boot times in embedded devices<br />2<br />

3.
3<br />Innovative devices often require complex functionality and minimal boot times - for minimum power consumption or maximum user experience<br />3<br />Innovation<br />

4.
4<br />Innovative devices usually require<br />Lots of complex functionality<br />Minimal boot times<br />Meeting the needs of innovative devices is a challenge<br />Complex functionality is difficult without an operating system<br />Minimal boot time is typically difficult with an operating system<br />Where should you spend your time?<br />It’s my view that with the right approach complex functionality can be achieved with embedded Linux in minimal time<br />We’re going to examine how this is possible<br />4<br />Minimal Boot Times are Achievable with Linux!<br />

5.
5<br />Who are MPC Data?<br />Why does embedded Linux take so long to boot?<br />Best approach to boot time reduction<br />Case Study: MS7724 ‘Ecovec’<br />Demonstration<br />Conclusion and Q&A <br />5<br />Agenda<br />

6.
6<br />MPC Data is a well established embedded systems integrator with a strong focus on platform development<br />55 strong team serving North America & Europe<br />Experts in embedded development and optimization<br />Contributors to the open source community<br />Technical focus and track record backed-up by numerous successful products in a wide variety of markets<br />Renesas Alliance Platinum Partner<br />Provides the unique swiftBoot boot time reduction service<br />Contact: business@mpc-data.comhttp://www.mpcdata.com/<br />6<br />MPC Data<br />

7.
7<br />Why so long anyway?<br />Embedded Linux is:<br />General purpose<br />Likely to contain functionality your device doesn’t require which will result in more initialisation and a larger image size<br />Convenient and flexible<br />Likely to probe and detect hardware which you know will always be there which will contribute to boot delays<br />Boot speed isn’t seen as the highest priority<br />A lot of duplication between boot-loader and kernel<br />There are many approaches to overcome large boot delays such as hibernation, stand-by and similar technologies,<br />This presentation describes how boot times can be drastically reduced by specialising Linux to your device’s needs and product requirements<br />7<br />

8.
8<br />The Approach<br />8<br />

9.
9<br />The Approach<br /><ul><li>Understand what functionality is required:

10.
Immediately after boot

11.
Sometime after

12.
The better your understanding the more able you are to specialise Linux and thus improve boot time</li></ul>9<br />

13.
10<br />The Approach<br /><ul><li>It is important to visualise what contributes to boot time

14.
Measuring boot time across the entire software stack is essential

15.
Without tools, gauging small boot delays can be impossible

16.
Being able to accurately measure boot time across the board will allow you to measure the effect of any changes you make…

17.
…otherwise you’ll be lost in the dark</li></ul>10<br />

18.
11<br />The Approach<br /><ul><li>Unnecessary functionality will increase boot time due to

19.
Increased image size (flash transfer time)

20.
Time spent initialization during start up

21.
“But I might use this feature in the future, it’s nice to have” – Be strict!

22.
Don’t dive into the kernel’s KConfig system – consider your boot loader, application and libraries

23.
Some functionality may have little effect</li></ul>11<br />

24.
12<br />The Approach<br /><ul><li>Functionality you require can be optimised

25.
It may already be optimised in a later version of sources

26.
This may involve:

27.
Optimising flash timings

28.
Removing unnecessary probing

29.
Refactoring code

30.
Taking a new approach to problems</li></ul>12<br />

31.
13<br />The Approach<br /><ul><li>Further improvements can be gained by doing things at different times:

32.
Parallelisation

33.
Deferred loading of less important features

34.
Re-ordering</li></ul>13<br />

35.
14<br />Case Study<br />Use the MS7724 ‘EcoVec’ as a case study for a home automation system<br />Boot time functionality: <br />Responsive QT user interface<br />Additional functionality: <br />Video capture/render (representing a security camera)<br />Will describe tools and techniques along the way<br />14<br />

36.
15<br />MS7724<br />15<br />

37.
16<br />SH7724<br />16<br />

38.
17<br />Case Study<br />Use the MS7724 ‘EcoVec’ as a case study for a home automation system<br />Boot time functionality: <br />Responsive QT user interface<br />Additional functionality: <br />Video capture/render (representing a security camera)<br />Will describe tools and techniques along the way<br />17<br />

39.
18<br />Case Study<br />18<br />

40.
19<br />Case Study<br />Use the MS7724 ‘EcoVec’ as a case study for a home automation system<br />Boot time functionality: <br />Responsive QT user interface<br />Additional functionality: <br />Video capture/render (representing a security camera)<br />Will describe tools and techniques along the way<br />19<br />

41.
20<br />Case Study<br />Typical Starting Point:<br />BootLoader: UBoot (2009-01)<br />OS: Linux (2.6.31-rc7)<br />Filesystem: Buildroot (2010.05)<br />Application: QT Embedded Opensource 4.6.2<br />20<br />

42.
21<br />MS7724 Boot Process<br />Boot process:<br />UBoot loads compressed kernel into RAM,<br />Kernel mounts root filesystem and starts init process,<br />Init scripts start GUI application<br />Component times measured using GPIO and a logic analyser,<br />UBoot time measured time between reset and GPIO line being asserted<br />Sources modified to toggle GPIO<br />Time to required boot time functionality: > 19 seconds!<br />21<br />

43.
22<br />Before Optimization<br />Boot Time = 19.44 seconds<br />

44.
23<br />Demonstration: After Optimization<br />Boot Time = 0.77 seconds!<br />

45.
24<br />UBoot<br />

46.
25<br />UBoot (Before and After)<br />Before (136 kB)<br />After (94 kB)<br />

47.
26<br />Compressed Kernel Images<br />The purpose of the boot loader is to jump to an uncompressed kernel image (usually in RAM)<br />A number of factors should be considered<br />If Flash throughput is greater than decompression throughput then an uncompressed image is quicker<br />26<br />

48.
27<br />Linux Kernel<br />

49.
28<br />Linux Kernel (Before and After)<br />

50.
29<br />Userspace (Mount and Init scripts)<br />Example of a bootchart graphic<br />

51.
30<br />QT<br />Reducing the boot time of the QT application was the biggest challenge and very time consuming<br />Un-optimized QT application was large and took 7.4 seconds to reach it’s main function!<br />Improvements reduce time to 0.3 seconds:<br />Measurements show incremental effects against original binary (from left to right)<br />

52.
31<br />Why does QT take so long to start?<br />Only a portion of the QT application is required to display a UI to the user<br />Event handling, additional forms, etc come later<br />As Linux uses Demand Paging - when an executable is run only parts of the executable used are read from flash<br />This reduces unnecessary flash accesses and decreases application start up time<br />However the application is on a block filesystem so when an entire block is retrieved at a time…<br />…This results in unnecessary flash access time if the required executable code is spread over the entire image<br />

53.
32<br />Function Reordering and Block Sizes<br />Sections highlighted in red represent parts of executable required at start up<br />Most of these parts could fit in a single file-system block<br />I.e. we could optimise the application such that only 2 blocks of flash are accessed rather than 4<br />Thus the executable can be optimised by:<br />Reducing block size<br />Eliminating FS readahead<br />Reordering executable<br />

54.
33<br />Function Reordering<br />GCC compiler features can be used to assist:<br />--finstrument-functions <br />--ffunction-sections<br />Before the entry and after the exit of every function call – GCC will call two new functions when –finstrument-functions is used:<br />void __cyg_profile_func_enter (….)<br />void __cyg_profile_func_exit (….)<br />These calls can be implemented to find out which functions are called when<br />This information can be used to generate a custom linker script – when –function-sections is used each function lives in its own section.<br />This way we can ensure all the required sections for startup are contained contiguously in flash<br />

55.
34<br />Function Reordering and Block Sizes<br />Before:<br />After:<br />

56.
35<br />Essential tools<br />Discrete events can be measured by toggling GPIO outputs and utilising a logic analyser,<br />Kernel events can be measured with:<br />Printk timings,<br />Initcall_debug and bootchart scripts,<br />Userspace events can be measured with ubootchart<br />http://code.google.com/p/ubootchart/<br />http://www.bootchart.org/<br />These are just some of the many tools available<br />

57.
36<br />Case Study: Before and After<br />A reduction of 96%!<br />

58.
37<br />Demonstration: After Optimization<br />Boot Time = 0.77 seconds!<br />

59.
38<br />Guiding Principles<br />Observe and Record<br />Measuring boot times is the only way to form a clear picture of what is contributing to boot time,<br />Keep copious notes<br />Tackle the biggest delays in the system first,<br />Identify the largest delays and remove them to be most effective<br />Be aware and try to understand varying boot times<br />Remember the uncertainty principle<br />Don’t forget testing<br />Remember – you can change any of the source code<br />

60.
39<br />39<br />Question<br /> Question 1: Could you have further reduced the boot time on the EcoVec?<br /> Answer 1: Absolutely<br />However it’s a case of diminishing returns<br />With more time – areas of Improvement:<br />Further understand where boot delays arise in QT<br />Further reduce time taken by UBoot <br /><ul><li>Consider looking at ROMImage</li></ul>Utilize hardware acceleration, e.g. JPU<br />User land XIP<br />Frozen processes<br />…<br />

61.
40<br />Minimal Boot Times are Achievable with Linux!<br />Complex functionality with short boot times (< 5 seconds) are certainly achievable with Embedded Linux (with the right approach),<br />Boot time reductions can be achieved by specialising Linux (and friends) to your device’s boot time functionality needs:<br />E.g. Removal of unnecessary functionality, optimisation and re-ordering,<br />Other functionality can come later<br />The internet covers many techniques for reducing boot speed but to make a big difference you need the right approach,<br />Observe, record, remove, optimise and re-order<br />Everything you require to make an improvement is freely availably online<br />Requires time and in-depth knowledge of the kernel and software components...<br />

62.
41<br />Other Solutions<br />MPC Data offer fixed price packaged services from $8,000<br />Input: Your new or existing embedded Linux product,<br />Process: <br />Identification of required boot time functionality,<br />Extensive and holistic investigation into boot delays of your product including all our areas of our expertise<br />Output: swiftBoot report<br />Approximately 20 pages,<br />Documents boot process including narration on boot delays and mitigations,<br />Enough information for your engineers to act on – though we can also help with implementation,<br />Typically provide recommendations to reduce boot time in excess of > 50%!<br />Visit http://www.swiftBoot.com/<br />

63.
42<br />or contact amurray@mpcdata.com<br />42<br />Questions?<br />

64.
43<br />43<br />Feedback Form<br />Please fill out the feedback form!<br />If you do not have one, please raise your hand<br />

65.
44<br />44<br />Thank You!<br />

66.
45<br />45<br />Appendix<br />

67.
46<br />Initcall Debug<br />Add the following to your kernel command line:<br />initcall_debug(to add debug)<br />loglevel=0 (to reduce the impact this has on boot time)<br />Ensure the following are set in your kernel configuration:<br />CONFIG_PRINTK_TIME (add timings to printks)<br />CONFIG_KALLSYMS (ensure symbols are there)<br />CONFIG_LOGBUF_SHIFT = 18 (ensure there is room in the log buffer)<br />Copy the output of ‘dmesg’<br />Type ‘cat output | ./scripts/bootgraph.pl > graph.svg’<br />

68.
47<br />Gains<br />