OKMX8MP Linux System Boot Optimization Practice
Boot Time Consumption Analysis, System Tailoring, and GUI App Auto-Start Optimization
In embedded applications such as industrial control, HMI, and intelligent terminals, the duration from device power-on to the availability of the service interface directly affects user experience. Based on actual debugging records from the OKMX8MP platform running Linux 5.4.70, this article provides a phased analysis of the system boot time and outlines optimisation strategies covering log output, systemd services, the auto-start of GUI applications, and U-Boot. This article emphasises the "measure first, then identify, then trim" approach, to avoid blindly deleting services without first confirming their dependencies.
Data Caliber: Original debug records show the system takes >15s from power-on to GUI app auto-launch: ~3s to Logo display, ~5s to "Starting kernel" log, ~10s for full kernel boot, plus ~3s for app auto-start. The 2.860s figure here only counts systemd-analyze's Kernel+Userspace duration, not full power-on-to-usable-GUI boot time.
Problem Background and Boot Chain Breakdown
In production projects, customers reported their Linux system takes over 15s from power-on to GUI app auto-launch, resulting in excessive wait times. For display-enabled embedded terminals, end users care nothing about kernel boot completion, but only how soon they can view and operate the business interface after power-on. This requires optimization to cover the full end-to-end boot chain (rather than isolated stages) from Bootloader through to the final application.
Per original debug logs, the measured typical boot timestamps are:
Power-on to Logo display: ~3s
To "Starting kernel" prompt: ~5s
Full Linux kernel boot completion: ~10s
Extra time for GUI app auto-start: ~3s
Total boot time is the cumulative sum of all sequential stages. To simplify localization, the full boot flow is:
SoC Power-On ↓ U-Boot ↓ Linux Kernel ↓ RootFS / systemd ↓ GUI Runtime ↓ Business App
The core of boot optimization is not chasing a "one-size-fits-all magic parameter", but identifying non-essential tasks on the critical boot path, and validating each for potential disabling, deferral, or on-demand execution only.
Overall Troubleshooting Workflow
This optimization is carried out along four core directions:
U-Boot: Remove unnecessary initialisation and disable bootdelay;
Disable or reduce verbosity in U-Boot, the Linux kernel and the file system;
Analyse the time taken for systemd to start up, and disable unnecessary services in the filesystem;
Optimize driver compilation mode and GUI application launch strategy.
Optimization Principle: All boot optimization must follow the sequence: first measure, then judge, then modify. For any service marked for disabling, first verify its dependencies on network, graphics, audio, cellular communication or core business applications.
Optimization 1: Reduce Kernel and Filesystem Log Output
Linux Kernel Log Verbosity Reduction
During product development, serial logs are critical for troubleshooting boot anomalies and driver issues. But once system functions are fully stabilized, if mass-produced devices do not require full boot logs, you can appropriately lower the kernel loglevel to cut down console output overhead. The configuration in the original debug records is as follows:
forlinx=>setenv mmcargs setenv bootargs root=/dev/mmcblk2p2 rootwait rw loglevel=0 forlinx=>saveenv
Here loglevel=0 minimizes kernel log output. Whether this setting is suitable for end products needs to be evaluated against on-site maintenance methods and fault localization requirements.
Systemd Status and Service Log Output Reduction
The root filesystem boot phase also generates a large volume of service status outputs and logs. The original implementation adjusts this by editing /etc/systemd/system.conf:
/etc/systemd/system.conf LogLevel=error ShowStatus=no
LogLevel=error: Only retains logs at Error level;
ShowStatus=no: Suppresses systemd’s service startup status prints on the console.
Note: Log trimming is recommended only in the productization phase. Sufficient logs should be retained during R&D and issue reproduction phases, otherwise subsequent troubleshooting difficulty will increase significantly.
Optimization 2: Profile and Prune Filesystem Services
Boot Latency with Systemd-analyze Location
systemd comes with a built-in boot latency profiling tool. You can run systemd-analyze blame to view the startup time of each service and device unit sorted by time consumption. Partial results from the original test environment are as follows:
root@OK8MP:~# systemd-analyze blame 1.547s dev-mmcblk2p2.device 347ms systemd-udev-trigger.service 331ms [email protected] 240ms systemd-logind.service 124ms systemd-resolved.service 106ms systemd-timesyncd.service 103ms systemd-udevd.service 88ms console-kit-log-system-start.service 83ms systemd-journald.service 77ms systemd-networkd.service
The original record also includes services such as rc-local, rpcbind, iptables, lighttpd, syslogd, alsa-restore and avahi-daemon. Through this tool, you can quickly identify the time-consuming items, and then judge whether there is a cutting space according to the actual function of the product.
Non-essential Service Disabling
After confirming that the business operations did not rely on the relevant services, the original debugging log disabled some services and applied changes to the Weston service:
mv /lib/systemd/system/[email protected] /lib/systemd/system/[email protected]_bak systemctl disable matrix.service systemctl disable klogd.service systemctl disable syslogd.service systemctl disable avahi-daemon.service systemctl disable rpcbind.service systemctl disable ofono.service systemctl disable lighttpd.service
Notice: The above list is processing records from a specific test environment, and shall not be directly used as a universal pruning checklist for all projects. For example, whether services including lighttpd, avahi-daemon and ofono can be disabled depends on if the product requires Web, mDNS/ZeroConf, cellular communication and other corresponding functions.
A more reliable practice is to establish a "Mandatory Service Set" for the specific product. Different from desktop Linux which emphasizes full-feature coverage, embedded products are more suitable for retaining only truly required services on the critical boot path.
Optimization 3: GUI Application Launch Mode Adjustment
For embedded products equipped with displays, the completion of Linux boot does not equal the product being "available". If the business goal is to make the GUI application visible as soon as possible, the application launch link also needs separate analysis. The original scheme launches the application via the autorun.service of systemd.
[Unit] Description=autorun #After=basic.service X.service thermal-zone-init.service [Service] ExecStart=/etc/init.d/autorun.sh start #[Install] #WantedBy=multi-user.target
The original record of the corresponding start-up script is as follows:
#!/bin/sh source/etc/profile.d/qt5.sh sync /usr/bin/fltest_qt_4g exit0
Description: All scripts above are retained in accordance with the original debug records. Before official deployment, verification shall be conducted against the actual shell syntax, spaces and file paths, to avoid directly introducing format issues in the records into mass production scripts.
The core of application launch optimization lies in confirming which system capabilities the GUI application truly depends on. If the application does not rely on certain network services or background services, it is not necessary to wait for all systemd targets to be fully ready before starting. Whether the application can be launched in advance needs to be verified item by item according to the dependencies of display, input, file system, network and business logics.
Optimization 4: U-Boot Boot Phase Optimization
The Bootloader also occupies part of the device power-on boot time. In the original debug records, the U-Boot bootdelay is disabled first:
forlinx=>setenv bootdelay 0
For mass-produced products, if there is no requirement for interactive waiting to enter the U-Boot command line, disabling bootdelay can directly eliminate the fixed waiting time. In addition, the original troubleshooting ideas also include pruning unnecessary initializations in U-Boot. The specific prunable contents need further confirmation based on the board-level hardware configuration and the actual BSP implementation.
Optimization Results and Data Interpretation
After completing relevant optimizations, the systemd-analyze time command can be used to check the boot time of the Linux Kernel and the Userspace. The result in the original debug records is:
root@OK8MP:~# systemd-analyze time Startup finished in 1.791s (kernel) + 1.069s (userspace) = 2.860s graphical.target reached after 1.034s in userspace
This set of data indicates that in the test environment, the total boot time of Kernel + Userspace counted by systemd is approximately 2.860 seconds, among which graphical.target is reached about 1.034 seconds after the Userspace boot process starts.
Data interpretation: 2.860 seconds is not the total time of "complete machine from power-on to GUI application operable". Stages including Boot ROM execution, U-Boot running, Kernel loading, display initialization, and the GUI application’s own initialization may not be fully covered by this statistical result. Consequently, the product should ultimately focus on both internal Linux metrics and user experience metrics.
It is recommended to adopt two sets of boot metrics:
| Indicators: | Measurement Method | Main Purpose |
|---|---|---|
| Linux Internal Boot Metric | systemd-analyze / systemd-analyze blame | Analyze time consumption of Kernel, Userspace and services |
| User Experience Metric | Actual measurement of the process "Power-on → First interactive business interface" | Evaluate the final product experience |
Summary of Boot Optimization
This practice proves that the essence of Linux fast boot is to reduce unnecessary workload on the critical boot path. The optimization can be carried out in the following sequence:
Clarify the user experience goal: Define the specific state that marks "boot completion" after power-on;
Split boot phases: Distinguish four core phases: U-Boot, Kernel, Userspace and applications;
Locate with data: Identify time-consuming items via tools such as systemd-analyze;
Confirm dependency relationships: Verify whether services, drivers or initialization processes are business-mandatory;
Prune and verify item by item: Re-test functions and boot time after each modification;
Reserve maintenance capabilities: Strike a balance between boot speed, log output and diagnosability.
Thefull optimization logic can be summarized as the following workflow:
Power-on ↓ U-Boot: Reduce fixed waiting time and unnecessary initialization processes ↓ Kernel: Cut down non-essential logs and extra initialization operations ↓ systemd: Reserve only services truly required for application operation ↓ GUI: Shorten the dependency chain to launch business applications as early as possible
Precautions and Application Boundaries
The commands and time-consuming data in this article are derived from the specific debugging environment of OKMX8MP + Linux 5.4.70, and do not represent the fixed results of other BSPs, storage media, peripheral combinations or applications.
Before disabling logs and services, you need to confirm the requirements for mass production maintenance, remote diagnosis and fault recurrence.
The statistical results of systemd-analyze cannot directly replace the full-machine power-on time test.
Any service pruning must be followed by functional regression tests, especially for services related to network, audio, display, cellular communication and application dependencies.
Further pruning of U-Boot, driver compilation modes and hardware initialization requires analysis combined with specific BSP source code and board-level configurations.
Conclusion
Linux boot optimization is not a simple matter of deleting a few services, nor is it t a single impressive time figure. A more effective approach is to focus on the actual usage scenarios of the product, conduct layer-by-layer analysis from the Bootloader, Kernel, RootFS, systemd to the GUI application, and continuously shorten the critical business path.
For "power-on and use" devices such as industrial HMIs, smart terminals and instruments, it is recommended to take the boot time as one of the key indicators in the productization phase. On the premise of ensuring functionality, stability and maintainability, the overall boot experience of the device can be further improved through system pruning, log strategy adjustment, service optimization and application boot link design.
Document Statement
This article is sorted out based on the actual debugging records of OKMX8MP Linux 5.4.70. The specific commands, service pruning scope and boot effect will vary with different BSP versions, hardware configurations, file systems and application dependencies. Please verify against the actual project before implementation.
