Systemd Boot Optimization: Why dev-mmcblk0p2.device Takes 4.5 Seconds on an Embedded eMMC System?

Systemd Boot Optimization: Why dev-mmcblk0p2.device Takes 4.5 Seconds on an Embedded eMMC System?

In systemd-analyze blame output, dev-mmcblk0p2.device indicates the time systemd waited for the block device /dev/mmcblk0p2 to become available. On embedded systems using eMMC, a long wait often stems from the eMMC initialization sequence and how systemd interacts with the kernel's device probing. Below, we address common causes and solutions grounded in eMMC protocol details. This answer directly addresses the engineer's question about reducing boot time after stripping non-essentials.

Q1: What exactly does dev-mmcblk0p2.device represent?

A: This is a systemd device unit that waits for the specified partition (p2) of the eMMC device (mmcblk0) to be fully probed and ready. The delay includes the time for the kernel to detect the eMMC, complete the initialization sequence, register the block device, and for udev to process rules. The 4.457 seconds indicates that the eMMC initialization or device detection consumed that time before the partition became usable.

Q2: Why is the eMMC initialization so slow?

A: The eMMC initialization sequence requires several steps: power-up, clock provision, sending CMD0 (GOIDLESTATE), CMD1 (SENDOPCOND) to negotiate voltage, CMD2 (ALLSENDCID) to get the card ID, CMD3 (SETRELATIVEADDR), and reading CSD/EXTCSD registers to identify capabilities. By default, the kernel uses a low clock frequency (400 kHz) during identification, which adds latency. Per the Loongtion eMMC datasheet, the power-on sequence has tPRUH and tPRUL delays (5 µs to 35 ms) that must be respected, and the boot operation mode (mandatory or alternate) may also add time. Additionally, the EXTCSD register read (CMD8) and configuration steps (CMD6 for bus width and timing) require multiple command-response cycles.

Q3: Can I reduce the dev-mmcblk0p2.device wait time?

Yes. Here are actionable improvements:

• Increase kernel initial speed: Some kernel versions allow the MMC subsystem to skip slow identification steps if the device supports high-speed modes. Check <code class="bg-gray-100 px-2 py-1 rounded text-sm">CONFIGMMCDEBUG</code> and <code class="bg-gray-100 px-2 py-1 rounded text-sm">.config</code> options.
• Use a custom initramfs: Include the eMMC driver and run systemd after the device is available, reducing redundant waits.
• Adjust systemd device timeout: Add <code class="bg-gray-100 px-2 py-1 rounded text-sm">rootdelay=</code> kernel parameter to reduce the maximum wait time, but be careful not to cut it too short.
• Enable early device probing: Pass <code class="bg-gray-100 px-2 py-1 rounded text-sm">mmcblock.perdevminors=4</code> or similar kernel parameters to speed up partition detection.
• Reduce udev rule complexity: Use <code class="bg-gray-100 px-2 py-1 rounded text-sm">rd.systemd.unit=emergency.target</code> to test if udev processing is the bottleneck.

Q4: Does the eMMC power-on sequence affect boot time significantly?

A: Yes. According to the Loongtion eMMC datasheet, the power-on timing includes tPRUH (VCC ramp-up) and tPRUL (VCCQ ramp-up). The specified min/max values are 5 µs to 35 ms for VCC and 5 µs to 25 ms for VCCQ. The typical values are at the low end, but the system must wait for the maximum worst-case. If your power supply ramp-up is slow, it can add tens of milliseconds. Additionally, the eMMC controller must complete its internal initialization before responding to commands. Using a proper power sequence and ensuring stable voltages can minimize this portion.

Optimization Strategies for Reducing dev-mmcblk0p2.device Wait Time

The following strategies focus on kernel parameters, eMMC configuration, and systemd tuning to bring the 4.5s wait down.

Q5: Could the boot partition or partition configuration cause delays?

A: Yes. The eMMC supports boot partitions (Boot Area) and user data areas. If the boot partition is enabled or if the partition configuration requires extra time, systemd may wait longer. Use mmc extcsd read /dev/mmcblk0 to check Boot Partition Enable and Partition Config fields. If not needed, disable boot partitions via echo 0 > /sys/block/mmcblk0/device/bootconfig (or through the driver). The Loongtion datasheet shows that partition management is handled in EXTCSD registers (e.g., BOOTPARTITIONENABLE at byte 192). Incorrect settings may cause the kernel to take extra probing steps.

Q6: How can I use eMMC sleep mode to improve boot time?

A: The eMMC sleep mode (CMD5) minimizes power consumption, but it is not directly beneficial for boot time. However, if your system performs a warm reboot, ensuring the eMMC is in sleep state before reset may reduce re-initialization time. During a cold boot, the eMMC always starts from pre-idle state, so sleep mode does not apply. The Loongtion datasheet specifies that in sleep state, only reset and wake commands are accepted. Using proper reset (hardware or software) is faster than a full power cycle.

Q7: What kernel parameters can I tweak for faster eMMC detection?

A: Consider these kernel boot parameters:

• <code class="bg-gray-100 px-2 py-1 rounded text-sm">mmcblock.perdevminors=4</code> — reduces the number of minors per device, speeding up partition scanning.
• <code class="bg-gray-100 px-2 py-1 rounded text-sm">rootwait</code> — enables kernel to wait for root device to appear; avoid using <code class="bg-gray-100 px-2 py-1 rounded text-sm">rootwait=0</code> as it is invalid.
• <code class="bg-gray-100 px-2 py-1 rounded text-sm">quiet loglevel=0</code> — suppresses kernel messages, but does not affect timing.
• <code class="bg-gray-100 px-2 py-1 rounded text-sm">initcallblacklist=mmcinit</code> — not recommended, but can debug.
• Use <code class="bg-gray-100 px-2 py-1 rounded text-sm">init=/bin/sh</code> to test boot without systemd to compare device availability time.

Q8: Is the delay caused by udev or systemd itself?

A: Possibly. After the kernel registers the block device, systemd-udevd triggers rules which may call blkid, fsck, or other tools that access the eMMC. If the eMMC is slow to respond (e.g., due to read disturbance or BKOPS), those commands add time. Check systemd-analyze blame for systemd-udevd.service and systemd-journald.service — in your output they sum to about 1.59s (1.303s + 0.287s). Optimize udev rules by moving non-essential rules to later stages or using udevadm settle --timeout=1. The Loongtion eMMC supports Background Operations (BKOPS) and High-Priority Interrupt (HPI) which can reduce latency during reads – ensure your driver enables these features.

Summary of Practical Steps:

1. Use a minimal kernel config with <code class="bg-gray-100 px-2 py-1 rounded text-sm">CONFIGMMCBLOCK</code> and <code class="bg-gray-100 px-2 py-1 rounded text-sm">CONFIGMMCDEBUG=n</code>.
2. Set <code class="bg-gray-100 px-2 py-1 rounded text-sm">CONFIGMMCHS200SUPPORT</code> and <code class="bg-gray-100 px-2 py-1 rounded text-sm">CONFIGMMCHS400SUPPORT</code> if your SoC supports them.
3. Add these kernel parameters: <code class="bg-gray-100 px-2 py-1 rounded text-sm">root=/dev/mmcblk0p2 rootwait rootfstype=ext4 ro</code> (adjust accordingly).
4. Disable unnecessary udev rules for the eMMC partitions.
5. If using initramfs, build a minimal image that does not include unnecessary tools.
6. Monitor <code class="bg-gray-100 px-2 py-1 rounded text-sm">dmesg</code> to see the exact time spent in <code class="bg-gray-100 px-2 py-1 rounded text-sm">mmcinit</code> and <code class="bg-gray-100 px-2 py-1 rounded text-sm">mmcadd_card</code>.

By systematically addressing each stage, you can often reduce the 4.5s wait to under 2s. For further assistance, consult your SoC vendor's board support package and the Loongtion eMMC datasheet for optimized power and initialization settings.

For related products and specifications, see the product line.