Dietpi on Odroid XU4 won't boot from eMMC card

Troubleshooting
1

Raspi 4 are really rare currently so I remembered that I own an Odroid XU4. Unfortunately DietPi does not boot from eMMC card. Booting from µSD works but is much slower.

Required Information

  • DietPi version | 8.12.1
  • Distro version | bullseye
  • SBC model | Odroid XU4

Steps to reproduce

  1. Copy over the img to emmc card and try to boot
  2. dd if=DietPi_OdroidXU4-ARMv7-Bullseye.img of=/dev/sdX bs=1M

Expected behaviour

DietPi should boot

Actual behaviour

Device does not boot. I attached the UART
U-Boot 2018.01-2 (Feb 15 2018 - 02:09:52 +0000) Arch Linux ARM

CPU: Exynos5422 @ 800 MHz
Model: Odroid XU3 based on EXYNOS5422
Board: Odroid XU3 based on EXYNOS5422
Type: xu4
DRAM: 2 GiB
MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
starting USB...
USB0:   USB EHCI 1.00
USB1:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB2:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 2 USB Device(s) found
scanning bus 2 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
       scanning usb for ethernet devices... 1 Ethernet Device(s) found
Waiting for Ethernet connection... unable to connect.
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
2

I found a similiar issue here.

This warning is displayed when you try to access an uninitialized on-disk u-boot environment.
If you have serial access you may just interrupt the boot process by typing CR and then:

saveenv
reset

saveenv stores the current u-boot working environment on disk. During startup u-boot initializes the working environment with the environment stored on disk, if this fails u-boot falls back to the built-in environment. IMHO the HK images are shipped with an uninitialized (or empty) u-boot environment.

3

Unfortunately this does not help. But I think it is a hint for the right direction.
Recently I ran Arch Linux on that device and it seems that I forgot to copy that line bnut U-BOOT tells
U-Boot 2018.01-2 (Feb 15 2018 - 02:09:52 +0000) Arch Linux ARM

So I think it’s not DietPi fault but a misconfig of U-Boot.
Anyway I’m already planned to use a 2 partition installation using ext4 or fat for the kernel and f2fs for the system.

4

I have a bunch of Odroid XU4 devices running dietpi, all booting from the eMMC just fine.
@jnko is it possible that your XU4 has lost the hidden eMMC boot partition at some point ?

Perhaps try the recovery procedure before flashing the Odroid image, it’s what always do.
Recovery procedure.

5

That’s exactly what I did. As mentioned above I have had installed Arch Linux previously and the U-Boot loader on Arch is different from the HK one. That was the problem. After using the recovery method DietPi booted fine.

Thanks