Odroid N2+ - won't boot eMMC, but will SPI/petiteboot, then eMMC

Troubleshooting
1

Required Information

cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=14
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
G_LIVE_PATCH_STATUS[0]=‘not applicable’
G_LIVE_PATCH_STATUS[1]=‘applied’
G_LIVE_PATCH_STATUS[2]=‘applied’

  • Distro version | bullseye
  • Kernel version | 6.1.11-meson64
  • SBC model | Odroid N2 (aarch64)
  • Power supply used | 12V/4A POE adapter
  • SD card used | oDroid 16G MMC

Steps to reproduce

  • Clean install of latest DietPI (8.14.1) from : https://dietpi.com/downloads/images/DietPi_OdroidN2-ARMv8-Bullseye.7z

  • write directly to eMMC card, either while installed in N2, or via adapter.

  • will not boot in “MMC” mode. Other distros (ubuntu/etc) will.

  • will boot in SPI mode when petiteboot is started first, then boots from first found disk

Expected behaviour

Should be bootable in eMMC mode

2

If you have backup image before it will still boot from MMC just restore to eMMC then update , but fresh install new dietpi image not working , I don’t know why i already tried 2 type of eMMC but install other os like android Ubuntu without problem .

Forget about the eMMC unless you need dualboot because you can now use SPI directly boot from external ssd .

3

same issue I’m seeing.

  • dietpi will not boot from eMMC without SPI, all others will
1 Like
4

ping @MichaIng maybe he could assist

5

Interesting, in my case it is the other way round: It boots fine from eMMC with “MMC” mode, but fails to do so via petitboot :smile:.

The newer U-Boot build we use does already fix a set of cases where eMMC boot failed (@greentea1 and others) before (in “MMC” mode, when petitboot was not supported at all). There was a single case where it fails to boot from SD card, while the previous U-Boot build did, and now another single case with eMMC. Looks like the U-Boot build which reliably boots on Odroid N2(+) from any SD card and eMMC still needs to be found. At least in your case it works via SPI.

Maybe we should do own U-Boot builds to throw a third candidate into the game :smile:.

6

@d.lasher There has been a patch added to Armbian’s U-Boot sources which seem to be related to your eMMC boot issue: odroidn2: u-boot: fix eMMC stability · armbian/build@5c15e3f · GitHub

Would you mind to test this:

wget 'https://dietpi.com/downloads/binaries/testing/linux-u-boot-odroidn2-current.deb'
dpkg -i linux-u-boot-odroidn2-current.deb
source /usr/lib/u-boot/platform_install.sh
# Unmute output/errors
eval "$(declare -f write_uboot_platform | sed -e 's| > /dev/null 2>&1||g' -e 's|status=none|status=progress|g')"
write_uboot_platform "$DIR" "$(lsblk -npo PKNAME "$G_ROOTFS_DEV")"

But if it fails, you would need to flash the other U-Boot binary from another Linux system, to make it boot again :wink:.