Nanopi Neo Air not booting from eMMC

[devAtronia]

Hi,

On a project we are using Nanopi Neo Air boards with an Allwinner h3 processor and a 8GB eMMC flashed with an Armbian OS.
Recently we have been getting increasing reports of the boards being stuck on boot, and found out we have two scenarios:
1. The board gets stuck on boot on message 'Starting Kernel ...' From logs available on COM port we are able to see where boot process stops.

Although this behavior is highly undesirable, since the eMMC is visible in device tree when booting from an SD-Card, it can be recovered by running command

Code: Select all

fsck /dev/mmcblk2p1

In order to reproduce this behavior we have set up a continuous power cycle test where, booting from eMMC:

• Device is powered on
• After 70 seconds (enough time for the system to boot), power supply is interrupted
• Device remains powered off for 10 seconds

This would account for around 1000 power cycles per day and we were able to get the device bricked in the range of 68 to 5500 power cycles.

We then repeated the test but by booting from an SD-Card and were not able to reproduce the issue, having reached power cycle counts of 34381.

Are there any known issues with the eMMC that could potentially justify this behavior, or is someone able to provide some guidance on what we could do/check to try to prevent this from happening (or making the eMMC more resilient to power cycles)?

2. The board gets stuck on boot, nothing is displayed in COM port and eMMC is no longer listed in device tree when booting from SD-Card.

While troubleshooting this issue we took two approaches: if either the eMMC got faulty (HW issue) or its metadata "just" critically corrupted.

For checking eMMC metadata we tried the following:

• Reflash the eMMC using eFlasher (used h3-eflasher-multiple-os-20250402-30g.img.gz)
  
  

  Code: Select all

  root@NanoPi-NEO-Air:~# eflasher -g
  Using config file:  "/mnt/sdcard/eflasher.conf"
  -------------------------------------------------------
  open file error:  "/sys/class/block/mmcblk1/device/name"
  No eMMC Flash detected, , ,
  
  ---
  
  root@NanoPi-NEO-Air:~# eflasher --low-format -i /mnt/sdcard/debian-jessie-kernel3.4
  Using config file:  "/tmp/eflasher.conf"
  -------------------------------------------------------
  open file error:  "/sys/class/block/mmcblk1/device/name"
  No eMMC Flash detected, , ,

  
  
  
• Reflash the eMMC using Armbian 'nand-sata-install'. Only SD-Card was listed.

For checking HW issues we have:

• Created custom user overlays to make the eMMC slower (25MHz and 12.5MHz with 1bit bus)
  
  

  Code: Select all

  e.g.
  
  ## CREATE OVERLAY
  
  sudo mkdir -p /boot/overlay-user
  sudo nano /boot/overlay-user/sun8i-h3-slow-emmc-1bit.dts
  
  - - -
  
  /dts-v1/;
  /plugin/;
  / {
    compatible = "allwinner,sun8i-h3";
    fragment@0 {
      target-path = "/soc/mmc@1c11000";  // adjust if your path differs
      __overlay__ {
        status = "okay";
        bus-width = <1>;
        max-frequency = <12500000>;      // 12.5 MHz
        /delete-property/ mmc-ddr-1_8v;
        /delete-property/ mmc-hs200-1_8v;
        /delete-property/ mmc-hs400-1_8v;
        /delete-property/ mmc-hs;
        /delete-property/ cap-mmc-highspeed;
      };
    };
  };
  
  - - -
  
  ## COMPILE
  
  cd /boot/overlay-user
  sudo dtc -@ -I dts -O dtb -o sun8i-h3-slow-emmc-1bit.dtbo sun8i-h3-slow-emmc-1bit.dts
  
  
  ## ENABLE OVERALY IN `/boot/armbianEnv.txt`
  
  sudo sed -i '/^user_overlays=/d' /boot/armbianEnv.txt
  echo 'user_overlays=sun8i-h3-slow-emmc-1bit' | sudo tee -a /boot/armbianEnv.txt
  
  ## REBOOT

  
  
• Powered the board with a diffent 5V power source and cable
  
• Tried to re-init eMMC
  
  

  Code: Select all

  # FROIM userspace
  
  ls /sys/bus/platform/drivers/sunxi-mmc/
  
  lrwxrwxrwx   1 root root    0 Aug 22 14:40 1c0f000.mmc -> ../../../../devices/platform/soc/1c0f000.mmc
  lrwxrwxrwx   1 root root    0 Aug 22 14:40 1c10000.mmc -> ../../../../devices/platform/soc/1c10000.mmc
  lrwxrwxrwx   1 root root    0 Aug 22 14:40 1c11000.mmc -> ../../../../devices/platform/soc/1c11000.mmc
  
  # toggle host driver (assuming path 1c11000.mmc)
  
  echo 1c11000.mmc | sudo tee /sys/bus/platform/drivers/sunxi-mmc/unbind
  sleep 1
  echo 1c11000.mmc | sudo tee /sys/bus/platform/drivers/sunxi-mmc/bind
  echo 1 | sudo tee /sys/class/mmc_host/mmc2/rescan
  
  ---
  
  # From U-boot
  
  Autoboot in 1 seconds, press <Space> to stop
  
  Listed available devices:
  
  =>  mmc list
  mmc@1c0f000: 0 (SD)
  mmc@1c10000: 2
  mmc@1c11000: 1
  Tried to collect status data from eMMC.
  
  => mmc dev 2
  Card did not respond to voltage select! : -110
  
  =>  mmc dev 1
  Card did not respond to voltage select! : -110
  
  => mmc rescan
  
  => mmc info
  Device: mmc@1c0f000    <-- SD Card
  Manufacturer ID: 3
  OEM: 5344
  Name: SL16G
  Bus Speed: 50000000
  Mode: SD High Speed (50MHz)
  Rd Block Len: 512
  SD version 3.0
  High Capacity: Yes
  Capacity: 14.8 GiB
  Bus Width: 4-bit
  Erase Group Size: 512 Bytes
  

But still we were not able to get the eMMC listed in the device tree.
On boot, we always see the following messages:

Code: Select all

mmc2: Card stuck being busy! __mmc_poll_for_busy
mmc2: Failed to initialize a non-removable card

For now everything points to HW failure, but we do not know what caused it. Moreover, the only thing that we believe may remain to be tested is whether the MMC is being powered.

Is someone able to provide us with guidance on how we could test this, or is there something we can do/check to have a better understanding on why the eMMC got faulty?

Thanks in advance

[alicesphere]

From your test results, scenario #1 really looks like classic filesystem corruption from hard power loss. eMMC is generally more sensitive to sudden power removal than SD cards, especially if write cache is enabled. If you’re cycling power that aggressively (1000/day), you’re basically stress-testing the FTL constantly. We reduced similar issues by:popular games

Making rootfs mostly read-only

Moving logs to tmpfs

Lowering ext4 commit interval

Avoiding background writes as much as possible

Scenario #2 feels more like actual eMMC degradation. The -110 voltage select error + “Card stuck being busy” is something I’ve only seen when the eMMC was either dying or not getting stable VCC/VCCQ during init. If you can, I’d definitely scope the power rails during boot — even small dips can cause weird behavior.

Out of curiosity, are these boards using the stock FriendlyElec eMMC or a third-party module? If it’s consumer-grade eMMC, the failure rate under that power-cycle pattern isn’t too surprising.