Blog

  • Home
  • Blog
  • Optimizing boot time of Arm based embedded devices

Optimizing boot time of Arm based embedded devices

Category: Networking Author: Peter Zorovsky Posted: 04 Jan 2024 0 Comments

The ecosystem of Arm based devices grow rapidly in the last years. Many Arm devices run various Operating Systems (OS). These devices also adopted specialized boot loaders, so to benefit from their flexibility, when a OS needs to be loaded and run.

In order to keep the device price low, often the designers chose smaller flash memories, slower CPU cores (or lower clock frequency) and pose other restrictions as well. This is not always bad, because less components and slower CPUs often mean less consumed energy (which might be critical for the project).

In time critical applications there are requirements for the device boot time, which must be met.

Optimizing the device boot time involves various tasks, which concern each of the SW components involved.

These tasks might be:

1. Review the boot process and try to remove all unneeded operations.

2. Check boot loader(s) and avoid any blocking there. Usually this might be a task, if we use proprietary boot loaders. Most modern systems use open source and widely deployed third-party components, which are flexible, functionality rich and quite stable. One such boot loader is U-Boot. In case we use such third-party bootloader, then in most cases we need to verify the options, which are enabled and if needed to re-compile and re-install the boot loader. If we use more than one boot loader, which run subsequently, then we need also to check every boot loader in the chain.

3. Check boot sequence of the OS. Depending on the OS, which is used (some RTOS, Linux, other free and commercial OSs), we might need to review all the components, which are loaded (OS kernel modules, OS daemons, proprietary daemon software) and remove/exclude all unneeded modules. Changes in kernel modules of OS modules involves re-compilation of the kernel and/or OS fs, so these changes to take effect. Special care should be taken to ensure that no daemon, from those, which must be started is blocking the boot process. If needed, relevant changes in such daemons should be done. This might become huge task in some cases. For the moment, it is important just to mention this as possibility.

One practical example of common problem with embedded systems is how to minimize the boot image. The boot image can be the OS kernel itself plus the needed kernel device data. Minimizing the boot image allows us to write it in flash memory with restricted size (remember the cost cutting reason for such decision).

The easiest way to minimize the boot image is to compress it. There are many available data compressor algorithms. We will use in our example LZ4.

Compression of boot image is done during compilation time. The software project uses scripts to compile the kernel and other components. Once the scripts finish we can compress the newly created files with LZ4 compressor. This compressed image then can be written in the flash memory. During boot, the boot loader will read the flash, decompress the data and store it in the right memory locations. After that it can start the kernel and the booting of the OS in general.

It was very interesting that the time needed to decompress the boot image can be quite long, if using standard library, which is implemented in C. In order to improve the
performance of the decompressor we opted for implementation of the decompressor in Arm assembly language. Embedding assembler code in C project is not a problem, so the rest of the code stays as it is. In our example case, we managed to measure huge improvement in the LZ4 decompressing. Actually assembly decompressor was more than 5 times faster in decompressing the boot image.

It worth to mention that our LZ4 decompressor implementation in assembler language was less than 50 bytes. Compared to the implementation in C language, this is not huge reduction for the overall size of the boot loader, but still it is an improvement.

As a conclusion we can say that understanding well the boot process and being able to pinpoint and address the bottle neck can bring big improvement for the software overall in terms of speed and size.

Mina soft provides outsourcing services for OS and bootloader SW development and optimization.




leave a comment


blog categories

Send us a message

If you want to say something to us, feel free to do it


I agree with Privacy policy