devAtronia

It seems that eMMC has built-in boot partitions. eMMC devices are not just "raw storage" (like SD-Cards) they have special reserved hardware partitions defined by the JEDEC eMMC standard. These include: boot0 – a small partition (usually a few MB) reserved for bootloader code. boot1 – a second small boot partition, often used as a backup. RPMB (Replay Protected Memory Block) – a secure partition for keys and counters. The SoC’s boot ROM (first-stage loader) can be configured to read directly from boot0 or boot1 when powering on. Also, these partitions are read-only to decrease the risk of having corrupted boot code. Beware that they’re not used by the Linux filesystem unless explicitly written to (usually via dd when flashing U-Boot).

@eselarm Thanks for the reply. We are using U-Boot: 2024.01-armbian-2024.01-S866c-P00ff-Ha5c2-V4cad-Bb703-R448a (Jan 21 2025 - 02:21:57 +0000) Allwinner Technology U-Boot 2024.01-armbian-2024.01-S866c-P00ff-Ha5c2-V4cad-Bb703-R448a (Jan 21 2025 - 02:21:57 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO Air DRAM: 512 MiB Core: 64 devices, 16 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial,usbkbd Out: serial Err: serial Net: No ethernet found. starting USB... No working controllers found Autoboot in 1 seconds, press <Space> to stop

@laibsch Thanks for the reply. Yes. The filesystem is formatted as ext4. # df -h Filesystem Size Used Avail Use% Mounted on udev 186M 0 186M 0% /dev tmpfs 49M 5.7M 43M 12% /run /dev/mmcblk2p1 7.0G 5.2G 1.5G 79% / tmpfs 244M 0 244M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 244M 8.0K 244M 1% /tmp /dev/zram1 49M 5.5M 40M 13% /var/log tmpfs 49M 0 49M 0% /run/user/0 tmpfs 49M 0 49M 0% /run/user/1000 # file -sL /dev/mmcblk2p1 /dev/mmcblk2p1: Linux rev 1.0 ext4 filesystem data, UUID=d3fe76cc-f19f-40a6-b8db-44a87f92714f (needs journal recovery) (extents) (64bit) (large files) (huge files) By bricked, I mean exactly that. Device boot is interrupted on the "Loading kernel" message. In these cases, the device can be recovered by booting from an SD Card and running fsck

@IBV Thanks! I will look into that info and check if we can do this conversion is runtime, and if so, how it can be automated.

Hi, First of all, thank You for your work. On a project we are using Nanopi Neo Air boards with an Allwinner h3 processor and a 8GB eMMC flashed with an Armbian OS: $ uname -a Linux <DEVICE_HOSTNAME> 6.6.75-legacy-sunxi #1 SMP Sat Feb 1 17:37:57 UTC 2025 armv7l GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye Recently we have been getting increasing reports of the boards being stuck on boot, on message 'Starting Kernel ...' (checked from logs available on COM port). 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 $ 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. Does anyone have a clue on why the eMMC displays 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)?