![]() ![]() benchmark compressed versus non-compressed Kernel, on our board the decompression went faster than loading an uncompressed image.turn off console output by setting quiet option to command line or disabling completely printk, which also significantly reduces the kernel size.avoid calibration of loop delay by presetting the value to kernel command line lpj=1990656.remove from device tree redundant devices or set their status to disabled.reduce Kernel configuration to strict minimum drivers and features that the application need, this implies a lot of trial and error.build everything that is not needed at boot time as a kernel module.Here are few steps we performed to speed-up kernel loading and execution: This is an important part of the optimization since a big part of our boot process was spent at this stage. The kernel cmdline need to include: rootfstype=squashfs Or if using wic kickstart : part / -source rootfs -ondisk mmcblk -fstype=squashfs -label root -size 150M In Yocto this could be easily generated by selecting: IMAGE_FSTYPE += "squashfs" In case of eMMC/MMC, EXT3 or EXT4 are widely used but they have an overhead in compared to other Filesystems such as SquashFS (Read-only): finally use a lightweight C-library such as musl instead of default glibc: TCLIBC=musl MACHINE=my-machine bitbake my-imageĭepending on the storage type an appropriate Filesystem can be used:.remove unnecessary packages and dependencies from image recipes.remove DISTRO features that are not used in nf: DISTRO_FEATURES_remove = "bluetooth".Here are some tweaks to reduce the footprint of a Yocto based Root Filesystem : Size matters but in this case a smaller footprint will have less mount time. in case of a Qt QML based application, using QtQuickCompiler allows to compile QML source code into a binary that runs fasterīefore running the init process, the Kernel needs first to mount the root Filesystem, therefore size and choice of the Filesystem have impact on startup time.use prelink which reduce the time needed by dynamic linker to perform relocations.This will remove the overhead of using shared libraries choosing toolchains and compiler flags wisely, a new gcc build a faster code, compiler flags set with optimization flags: for example -O2 instead of -Os.In our example, Qt application alone took almost 0,7s to run! If there are many interdependent processes in play, systemd-analyze can be used to inspect those dependencies and reorder their priorities. #Initialize your time-critical application here !Īnd instruct the kernel to use it instead of the default /sbin/init, by adding it to kernel command line: init=/sbin/preinitĪ drawback of this Setup is that your application loses some benefits of Systemd such as auto-restart after crash. ![]() In our case we use Systemd so we change the default target from multi-user to basic and remove dependencies to other services as follow: ĮxecStart=/usr/bin/ConnectedCarIVI -plugin TslibĪs Systemd has an overhead, specially if not running on a multi-core CPU, we can start our application before Systemd initialization by creating a wrapper to init: #!/bin/busybox sh One obvious optimization is to configure the Start of the critical application as soon as possible, of course after starting dependencies. ![]() We start then from the last stage of the boot process, by optimizing the user-space and application start-up, then reduce kernel boot-time. OptimizationsĪs a recommendation, do not optimize things that reduce the ability to make measurements and hinder implementing further optimizations. Such time to start an Infotainment system in the car are unacceptable for an impatient end user. Our application needed more than 12 seconds to start-up, from special markers present in the serial logs, we can deduce the time spent on each stage: Important to note that grabserial cannot measure from power-on but starts counting time-stamps upon getting the first character on serial console. In the measurement above we set the time base to SPL using -m option. To measure the time taken by the application to show its availability, we will use grabserial running on a Host (Ubuntu Linux) to measure time-stamps coming from the target on the serial console: $ grabserial -d "/dev/ttyUSB0" -e 30 -t -m "U-Boot SPL*" For our example on Beaglebone black the application is an In-vehicle infotainment (IVI) QT5 based connected application and the goal is to reduce the time from Power-On of the device (Cold-Boot) until the application shows up on the display and fully operable by a user. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |