Thank you for providing the logs. Based on your description of a sudden boot failure after sudo poweroff on a previously working system, combined with the fact that recovery mode works perfectly, this points to a specific boot configuration issue rather than hardware failure.
Analysis of Your Situation
The pattern you describe—working normally for three months, then sudden failure after a clean shutdown with no serial output whatsoever—suggests one of these scenarios:
- Boot partition corruption or misconfiguration during shutdown
- eMMC boot configuration register changed unexpectedly
- Bootloader binary corruption in the active boot partition
Since TEZI works perfectly, the SoM hardware, eMMC controller, and UART are all functional. The issue is isolated to the normal boot path.
Immediate Recovery Steps
Step 1: Verify and Restore Boot Configuration
From the TEZI shell, execute these commands to check and reset the boot configuration:
# Check current boot configuration
mmc extcsd read /dev/mmcblk2 | grep -E "PARTITION_CONFIG|BOOT_BUS"
# Reset boot configuration to known-good defaults
echo 0 > /sys/block/mmcblk2boot0/force_ro
echo 0 > /sys/block/mmcblk2boot1/force_ro
# Set boot partition 1 as active with acknowledgment
mmc bootpart enable 1 1 /dev/mmcblk2
# Configure boot bus width
mmc bootbus set single_backward x1 x8 /dev/mmcblk2
sync
Step 2: Verify Bootloader in Both Boot Partitions
Check if the bootloader exists in both boot partitions:
# Check boot partition 0
dd if=/dev/mmcblk2boot0 bs=512 count=1 | hexdump -C | head -n 5
# Check boot partition 1
dd if=/dev/mmcblk2boot1 bs=512 count=1 | hexdump -C | head -n 5
Both should show the IVT header d1 00 20 41 at the beginning. If one is missing or corrupted, that’s your problem.
Step 3: Manual Bootloader Restoration
If the bootloader is missing or corrupted in the active boot partition, you need to restore it. From TEZI shell:
# Mount the boot partition from the installed image
mkdir -p /mnt/boot
mount /dev/mmcblk2p1 /mnt/boot
# The bootloader should be in the boot directory
ls -la /mnt/boot/
# If imx-boot exists, flash it to both boot partitions
echo 0 > /sys/block/mmcblk2boot0/force_ro
echo 0 > /sys/block/mmcblk2boot1/force_ro
# Flash to boot partition 0 (offset 33KB as per i.MX8M Plus spec)
dd if=/mnt/boot/imx-boot of=/dev/mmcblk2boot0 bs=1k seek=33 conv=fsync
# Flash to boot partition 1
dd if=/mnt/boot/imx-boot of=/dev/mmcblk2boot1 bs=1k seek=33 conv=fsync
sync
Step 4: Complete Wipe and Reinstall
If the above steps don’t work, perform a complete wipe:
- In TEZI GUI, before installing, select the “Wipe” option
- This erases all eMMC partitions and boot configuration
- Then install Torizon OS 7.6.1+build.38 fresh
- This ensures all boot registers and partitions are initialized correctly
Potential Root Cause: eMMC Write Protection Issue
Given that this happened after a poweroff command, there’s a possibility (though rare) that the eMMC entered a write-protected state during shutdown. While your health indicators look good, it’s worth checking(1):
From TEZI shell:
# Check if eMMC is write-protected
mmc writeprotect user get /dev/mmcblk2
# Check boot partition write protection
cat /sys/block/mmcblk2boot0/force_ro
cat /sys/block/mmcblk2boot1/force_ro
If any write protection is enabled unexpectedly, this could prevent proper boot.
What Likely Happened
Based on your symptoms, the most probable scenario is:
- During the
poweroff sequence, something interrupted the eMMC boot configuration or corrupted the bootloader in the active boot partition
- The eMMC boot configuration register (
PARTITION_CONFIG) may have been modified, causing the ROM to attempt booting from an empty or corrupted partition
- Since recovery mode uses a different boot path (USB/UART download mode), it bypasses the eMMC boot configuration entirely, which is why it works
Next Steps
- Execute the boot configuration reset commands above
- Verify bootloader presence in both boot partitions
- If needed, manually restore the bootloader
- If all else fails, perform a complete wipe and reinstall
Please share the output of these commands:
mmc extcsd read /dev/mmcblk2 | grep -E "PARTITION_CONFIG|BOOT_BUS|BOOT_CONFIG_PROT"
dd if=/dev/mmcblk2boot0 bs=512 count=1 | hexdump -C | head -n 5
dd if=/dev/mmcblk2boot1 bs=512 count=1 | hexdump -C | head -n 5
This will help pinpoint exactly where the boot path is breaking.
Best regards,
Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
