Verdin IMX8MM boot performance

Hello,

I am creating an image based on the tdx-xwayland-rt distro and tdx-reference-minimal-image and trying to speed up the boot time of the Verdin IMX8M mini on Dahlia Carrierboard.

systems-analyze blame:

2.773s dev-mmcblk0p2.device
 686ms systemd-logind.service
 473ms systemd-udev-trigger.service
 371ms systemd-timesyncd.service
 242ms systemd-networkd.service
 242ms connman.service
 206ms systemd-modules-load.service
 203ms dev-hugepages.mount
 181ms systemd-fsck-root.service
 179ms systemd-journald.service
 179ms dev-mqueue.mount
 168ms sys-kernel-debug.mount
 146ms tmp.mount
 143ms iptables.service
 135ms kmod-static-nodes.service
 117ms dev-mmcblk0p1.device
  97ms systemd-random-seed.service
  90ms rpcbind.service
  83ms wpa_supplicant.service
  59ms avahi-daemon.service
  57ms systemd-remount-fs.service
  56ms sys-kernel-config.mount
  55ms systemd-sysctl.service
  54ms systemd-journal-flush.service
  53ms var-volatile.mount
  51ms systemd-update-utmp-runlevel.service
  49ms systemd-udevd.service
  48ms systemd-update-utmp.service
  43ms systemd-tmpfiles-setup.service
  38ms systemd-tmpfiles-setup-dev.service
  34ms systemd-user-sessions.service
  30ms alsa-restore.service

I am wondering why dev-mmcblk0p2.device is that ‘slow’.

`journalctl | grep mmcblk0*`:
 kernel: mmcblk0: mmc0:0001 Q2J54A 3.59 GiB
 kernel: mmcblk0boot0: mmc0:0001 Q2J54A partition 1 16.0 MiB
 kernel: mmcblk0boot1: mmc0:0001 Q2J54A partition 2 16.0 MiB
 kernel: mmcblk0rpmb: mmc0:0001 Q2J54A partition 3 512 KiB, chardev (237:0)
 kernel:  mmcblk0: p1 p2
 kernel: EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
 kernel: EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
 kernel[321]: [    0.876799] 000: mmcblk0: mmc0:0001 Q2J54A 3.59 GiB
 kernel[321]: [    0.876989] 000: mmcblk0boot0: mmc0:0001 Q2J54A partition 1 16.0 MiB
 kernel[321]: [    0.877177] 000: mmcblk0boot1: mmc0:0001 Q2J54A partition 2 16.0 MiB
 kernel[321]: [    0.877570] 000: mmcblk0rpmb: mmc0:0001 Q2J54A partition 3 512 KiB, chardev (237:0)
 kernel[321]: [    0.882862] 000:  mmcblk0: p1 p2
 kernel[321]: [    2.324309] 000: EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
 kernel[321]: [    3.782578] 000: EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)

Can someone explain to me what’s causing this, or give me an hint to speed it up?

Best Regards,
Markus

Hi @DrWenz !

Could you please share more information about your setup?

  • Which exact Verdin iMX8M Mini are you using (its “full name”)? Please share its version as well.
  • What is the version of Dahlia Carrier Board?
  • Which BSP version are you using for the tdx-reference-minimal-image?
  • Have you done any modification/customization on the image?
  • Could you please also try the tdx-xwayland (non-rt) as well? This way we can maybe see if the RT patches has some impact (wildly guessing here :slight_smile: )

Best regards,

Hello,

  • Which exact Verdin iMX8M Mini are you using (its “full name”)? Please share its version as well.
    → Verdin iMX8M Mini DualLite 1GB
  • What is the version of Dahlia Carrier Board?
    → Rev. 1.1
  • Which BSP version are you using for the tdx-reference-minimal-image?
    → 5.x.y
  • Have you done any modification/customization on the image?
    → added packages: nano, kmscube, libinput
  • Could you please also try the tdx-xwayland (non-rt) as well? This way we can maybe see if the RT patches has some impact (wildly guessing here :slight_smile: )
    → below systemd-analyze blame on complete fresh install with tdx-wayland and tdx-reference-minimal-image:
2.563s dev-mmcblk0p2.device
 910ms dropbearkey.service
 377ms systemd-udev-trigger.service
 373ms set-hostname.service
 360ms run-postinsts.service
 334ms systemd-modules-load.service
 321ms systemd-logind.service
 271ms ldconfig.service
 247ms dev-hugepages.mount
 231ms dev-mqueue.mount
 215ms sys-kernel-debug.mount
 209ms tmp.mount
 183ms kmod-static-nodes.service
 182ms systemd-timesyncd.service
 179ms ofono.service
 173ms systemd-fsck-root.service
 147ms systemd-sysusers.service
 136ms systemd-journal-catalog-update.service
 124ms systemd-udevd.service
 122ms connman.service
 115ms systemd-networkd.service
 113ms ip6tables.service
 107ms systemd-random-seed.service
 104ms systemd-update-utmp-runlevel.service
  96ms rpcbind.service
  95ms iptables.service
  85ms avahi-daemon.service
  84ms systemd-journald.service
  75ms systemd-machine-id-commit.service
  71ms systemd-remount-fs.service
  71ms systemd-tmpfiles-setup.service
  69ms sys-kernel-config.mount
  67ms systemd-sysctl.service
  61ms dev-mmcblk0p1.device
  58ms systemd-update-utmp.service
  41ms wpa_supplicant.service
  40ms systemd-journal-flush.service
  31ms systemd-user-sessions.service
  31ms var-volatile.mount
  23ms alsa-restore.service
  22ms systemd-tmpfiles-setup-dev.service
  18ms systemd-update-done.service

dmesg | grep -e mmc* -e sdhc*:

[    0.000000]   DMA32 zone: 4096 pages used for memmap
[    0.000000] Kernel command line: root=PARTUUID=651487e6-02 ro rootwait console=tty1 console=ttymxc0,115200 consoleblank=0 earlycon
[    0.008419] Console: colour dummy device 80x25
[    0.210782] imx8mm-pinctrl 30330000.pinctrl: initialized IMX pinctrl driver
[    0.266592] iommu: Default domain type: Translated
[    0.578073] Key type asymmetric registered
[    0.579339] Asymmetric key parser 'x509' registered
[    0.979774] sdhci: Secure Digital Host Controller Interface driver
[    0.985974] sdhci: Copyright(c) Pierre Ossman
[    0.997044] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.035740] mmc0: SDHCI controller on 30b40000.mmc [30b40000.mmc] using ADMA
[    1.146631] mmc0: new HS400 MMC card at address 0001
[    1.160755] mmcblk0: mmc0:0001 Q2J54A 3.59 GiB
[    1.177114] mmcblk0boot0: mmc0:0001 Q2J54A partition 1 16.0 MiB
[    1.186477] mmcblk0boot1: mmc0:0001 Q2J54A partition 2 16.0 MiB
[    1.196825] mmcblk0rpmb: mmc0:0001 Q2J54A partition 3 512 KiB, chardev (237:0)
[    1.209954]  mmcblk0: p1 p2
[    2.679958] sdhci-esdhc-imx 30b50000.mmc: Got CD GPIO
[    2.715687] mmc1: SDHCI controller on 30b50000.mmc [30b50000.mmc] using ADMA
[    2.950408] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    4.343318] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    5.432191] debugfs: Directory '30020000.sai' with parent 'imx8mm-nau8822' already present!

best regards,

Hi @DrWenz !

Thanks for the quick answer!

But we get some incomplete information.

Please add the module version

Please add the assembly variant (the subsequent letter e.g. V1.5F, V2.1B)

Does it mean that you are using the master branch? Could you please send the output of cat /etc/os-release?

Side comment here: grep uses Regular Expression syntax (I like to use this site to learn and test regular expressions: https://regex101.com). The * means 0 or more of the previous token. If I understood correctly, you do not want to filter the dmesg output like this. You can use dmesg | grep -e mmc -e sdhc instead.

Best regards,

Hello,

sorry bellow the full informations:

  • Verdin iMX8M Mini DualLite 1GB V1.1A
  • Dahlia V1.1B
  • Verdin DSI to HDMI Adapter V1.1A (don’t know if is necessary maybe)
cat /etc/os-release:
ID=tdx-xwayland
NAME="TDX Wayland with XWayland"
VERSION="5.7.0-devel-20220627150124+build.0 (dunfell)"
VERSION_ID=5.7.0-devel-20220627150124-build.0
PRETTY_NAME="TDX Wayland with XWayland 5.7.0-devel-20220627150124+build.0 (dunfell)"
DISTRO_CODENAME="dunfell"

Best regards,

Hi @DrWenz,

We tried to check it on our images and it seems that by default, a minimal image of the Verdin iMX8MMini 1GB takes a similar amount of time to turn everything on like yours even though it’s smaller than what you have:

2.067s dev-mmcblk0p2.device                
 410ms systemd-udev-trigger.service        
 274ms systemd-logind.service              
 256ms user@0.service                      
 182ms connman.service                     
 154ms systemd-hostnamed.service           
 149ms systemd-timesyncd.service           
 129ms systemd-fsck-root.service           
 128ms systemd-networkd.service            
 118ms sys-kernel-debug.mount              
 114ms dev-hugepages.mount                 
 112ms dev-mqueue.mount                    
 110ms tmp.mount                           
 103ms ofono.service                       
 102ms kmod-static-nodes.service           
  85ms systemd-udevd.service               
  77ms systemd-modules-load.service        
  72ms iptables.service                    
  72ms alsa-restore.service                
  69ms wpa_supplicant.service              
  64ms systemd-journald.service            
  61ms rpcbind.service                     
  60ms systemd-update-utmp-runlevel.service

On the 2GB module, the time to load the eMMC device was more than half a second smaller.

If you use systemd-analyze plot you could find a chart like this one:
systemd

It’s clear that this is the process that is taking longer to initialise and is the last one to do so but there may be some other initialising processes that depend on it to conclude or it depends on other stuff so that it could conclude itself.

However, if you see other points there, you can note that the kernel itself takes around 3s to boot. In order to improve performance, you could for instance eliminate drivers that are not needed.

Best regards,

Hi @DrWenz,

Do you have any news on this topic?

Best regards,

Hi @gclaudino.tx,

we are currently trying to make an optimized image.
I will come back to you when I have new results :slight_smile:

1 Like