Hi @rania !
This is due to how you are designing your system. It is related to how you implemented Plymouth and also to the services you are using.
From you shared here and in all the other threads, doesn’t seem like you are incurring in an error.
About the initial blank screen before your splash screen
From what I saw you implemented Plymouth without initramfs. Therefore it will start latter than it would with initramfs. To get instantaneous splash screen, you would even need to modify your bootloader, which I am not sure it is supported by NXP on i.MX8QM.
About the blank screen after your splash screen
This is mos probably Weston starting right after plymouth-quit.service
because of wayland-app-launch.service
, which is expected. This time between Weston starting and your application starting is something that you could overcome by optimizing your application/GUI framework to start using the screen as quickly as possible. You could also customize weston.ini
to show something that makes sense for your device, so you don’t have a blank screen.
About the splash screen quitting too quickly
I guess this is because weston.service
/wayland-app-launch.service
is starting, therefore they are using the display, so the splash screen ends abruptly. If you don’t want it, you need to check how the services are configured, so Weston takes a bit longer to start and you have more splash screen time. For example: have you tried to add plymouth-quit.service
to weston.service
’s After=
property and add the the sleep 5
to plymouth-quit.service
? Be sure to watch out for cyclic dependencies on Systemd: they show up on your boot logs (and dmesg). Example:
...
[ SKIP ] Ordering cycle found, skipping Start a wayland application
...
Some tips to check what is going on on Systemd
Please be aware that some of them are meant to run on your module an some are meant to run on your computer (which will SSH into the module)
Get the complete boot chart of your system:
You need to execute it from your computer. The computer must be able to SSH into the module.
ssh root@192.168.11.1 "systemd-analyze plot" | tee boot.svg && inkscape boot.svg &
Here I am using Inkscape because I like it and I can search for service names. You can use any image viewer that is SVG-capable. This is an example of what you get (here I zoomed into the botom part of the graph):
Get the dependencies of services
This command you need to run on the module.
root@verdin-imx8mp-15247228:~# systemctl list-dependencies plymouth-quit.service
plymouth-quit.service
● ├─system.slice
● └─sysinit.target
● ├─dev-hugepages.mount
● ├─dev-mqueue.mount
● ├─kmod-static-nodes.service
○ ├─ldconfig.service
● ├─plymouth-read-write.service
● ├─plymouth-start.service
● ├─rngd.service
○ ├─run-postinsts.service
● ├─sys-fs-fuse-connections.mount
● ├─sys-kernel-config.mount
● ├─sys-kernel-debug.mount
○ ├─sys-kernel-tracing.mount
○ ├─systemd-ask-password-console.path
○ ├─systemd-hwdb-update.service
○ ├─systemd-journal-catalog-update.service
● ├─systemd-journal-flush.service
● ├─systemd-journald.service
○ ├─systemd-machine-id-commit.service
● ├─systemd-modules-load.service
● ├─systemd-network-generator.service
○ ├─systemd-pstore.service
● ├─systemd-random-seed.service
● ├─systemd-sysctl.service
○ ├─systemd-sysusers.service
● ├─systemd-timesyncd.service
● ├─systemd-tmpfiles-setup-dev.service
● ├─systemd-tmpfiles-setup.service
● ├─systemd-udev-trigger.service
● ├─systemd-udevd.service
○ ├─systemd-update-done.service
● ├─systemd-update-utmp.service
● ├─local-fs.target
● │ ├─-.mount
● │ ├─systemd-fsck-root.service
● │ ├─systemd-remount-fs.service
● │ ├─tmp.mount
○ │ ├─var-volatile-cache.service
○ │ ├─var-volatile-lib.service
○ │ ├─var-volatile-spool.service
○ │ ├─var-volatile-srv.service
● │ └─var-volatile.mount
● └─swap.target
With this, you can check which dependencies the service has.
You can also get the services that depend on a given service:
root@verdin-imx8mp-15247228:~# systemctl list-dependencies --reverse plymouth-quit.service
plymouth-quit.service
● └─multi-user.target
● └─graphical.target
Please be sure to use the tools available in Systemd to check what is going on with the services you are using. Checking Systemd’s documentation you can also find more [sub]commands and arguments that can help you to debug the what is happening.
Best regards,