Optimized boot sequence

Hello I have watched a video that is on toradex’s channel https://youtu.be/TTcP3xeLrEY?si=DSlYZ4anFMJrxL91

and also I want to compile and deploy this image to my development board. Is there any guidenence about it, I want to use the same project that is on video. If it is possible is there any yocto layer for it?

Hello @erdemkahraman ,
Maybe it’s batter that you contact the author of the original post here:
Fast-Booting Qt Devices, Part 4: Hardware Matters

Best regards,

Hi @josep.tx
I’ve contacted with Risto but he did not answered me.

I am using Colibri iMX6DL and booting with emmc

root@colibri-imx6:~# cat /etc/os-release 
PRETTY_NAME="The Ångström Distribution v2017.12"

root@colibri-imx6:~# uname -r

BSP: 2.8b4

And my systemd-analyze blame output is

root@colibri-imx6:~# systemd-analyze blame
          8.637s dev-mmcblk0p2.device
          1.965s systemd-hwdb-update.service
          1.497s systemd-udev-trigger.service
          1.162s usbg.service
           961ms systemd-resolved.service
           899ms rc-local.service
           639ms rpcbind.service
           599ms systemd-logind.service
           527ms systemd-networkd.service
           460ms tmp.mount
           457ms systemd-remount-fs.service
           448ms systemd-journal-flush.service
           405ms systemd-fsck-root.service
           338ms sys-kernel-debug.mount
           332ms systemd-journald.service
           307ms systemd-udevd.service
           284ms sshd.socket
           242ms systemd-sysctl.service
           225ms alsa-restore.service
           194ms systemd-timesyncd.service
           177ms user@0.service
           137ms systemd-random-seed.service
           127ms systemd-journal-catalog-update.service
           127ms ldconfig.service
           115ms systemd-sysusers.service
           102ms systemd-modules-load.service
            95ms sys-fs-fuse-connections.mount
            95ms gpio-export.service
            92ms systemd-user-sessions.service
            80ms systemd-update-utmp.service
            73ms dev-mmcblk0p1.device
            69ms kmod-static-nodes.service
            60ms systemd-update-utmp-runlevel.service
            58ms var-volatile.mount
            45ms systemd-tmpfiles-setup.service
            40ms systemd-tmpfiles-setup-dev.service
            40ms systemd-update-done.service
            32ms sys-kernel-config.mount

My question is why this dev-mmcblk0p2.device cost to me 8 seconds? For example on my ubuntu laptop even if it is using ssd but the dev-sdb3.device is costing only 2 seconds. As far as I know emmc is faster than ssd, but on my image it is too slow. What may be the problem.

Hi @erdemkahraman!

Using an up-to-date version of our BSP, the same behavior is not observed:

root@colibri-imx6-10672468:~# tdx-info

Software summary
Bootloader:               U-Boot
Kernel version:           6.1.71-6.5.0+git.38fb82ecd144 #1 SMP Fri Jan  5 14:18:41 UTC 2024
Kernel command line:      enable_wait_mode=off galcore.contiguousSize=50331648 root=PARTUUID=a0f512ac-02 ro rootwait fec_mac=00:14:2d:a2:d9:54 consoleblank=0 no_console_suM
Distro name:              NAME="TDX Wayland with XWayland Upstream"
Distro version:           VERSION_ID=6.5.0-build.9
Distro variant:           -
Hostname:                 colibri-imx6-10672468

Hardware info
HW model:                 Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3
Toradex version:          0017 V1.1A
Serial number:            10672468
Processor arch:           armv7l
root@colibri-imx6-10672468:~# systemd-analyze blame
5.970s dev-mmcblk2p2.device
5.952s systemd-udev-settle.service
2.556s weston.service
2.248s ldconfig.service
1.695s systemd-timesyncd.service
1.288s set-hostname.service
1.057s systemd-udev-trigger.service
 944ms user@0.service
 666ms ofono.service
 637ms sys-kernel-debug.mount
 619ms tmp.mount
 599ms modprobe@configfs.service
 593ms kmod-static-nodes.service
 553ms modprobe@fuse.service
 546ms alsa-restore.service
 545ms systemd-logind.service
 545ms media-BOOT\x2dmmcblk2p1.mount
 545ms systemd-networkd.service
 535ms usbg.service
 519ms modprobe@drm.service
 509ms systemd-sysctl.service
 483ms systemd-fsck-root.service
 456ms ip6tables.service
 453ms systemd-network-generator.service
 446ms iptables.service
 442ms systemd-hostnamed.service
 425ms systemd-journal-catalog-update.service
 385ms systemd-machine-id-commit.service
 361ms systemd-journald.service
 339ms dbus.service
 318ms systemd-update-done.service
 296ms systemd-fsck@dev-mmcblk2p1.service
 280ms systemd-update-utmp.service
 246ms systemd-udevd.service
 243ms rpcbind.service
 241ms systemd-tmpfiles-setup.service
 235ms systemd-userdbd.service
 234ms systemd-backlight@backlight:backlight.service
 202ms connman.service
 138ms systemd-random-seed.service
 121ms systemd-tmpfiles-setup-dev.service
 119ms sys-kernel-config.mount
 118ms wpa_supplicant.service
 116ms sys-fs-fuse-connections.mount
 114ms systemd-update-utmp-runlevel.service
 111ms systemd-remount-fs.service
  85ms systemd-sysusers.service
  85ms user-runtime-dir@0.service
  84ms systemd-journal-flush.service
  81ms avahi-daemon.service
  74ms var-volatile.mount
  66ms weston.socket
  40ms boot.mount
  33ms systemd-user-sessions.service

Also, BSP 2 is End-Of-Life (EOL) since a while, so the recommendation is to use the newer BSP.

Please refer to the following articles to know more about Toradex’s support strategy for Linux and the current state of our BSPs:

Best regards,

Hi @henrique.tx
Got it, your offer is moving to the new BSP for example 6.x etc.
But still there is still something are not fitting to my mind. Why dev-mmcblk2p2.device is taking 5.970s.
What are the dependencies about the dev-mmcblk2p2.device. RAM? eMMC?
Because as far as I know eMMC is almost the fastest storage device.
For example If I have 2 gig ram on the device, Will it be faster?

Hi @erdemkahraman!

To answer this question, you would need to invest some time investigating why this is happening in your case. Using the critical-chain of Systemd helps to analyze the longest chain that causes the biggest impact in your boot time.


It is possible that what you are witnessing is not necessarily related to the devices’s performance for read and write operations, but to how it is being recognized by the OS.

With more RAM, the device can withstand more data at the same time, which would make it perform better, but if your use case is not reaching the the maximum amount of RAM available, it isn’t an issue.

Best regards,