I recently bought this device because it was the only small board with eMMC and onboard ethernet. Love the hardware, but the BSP support is horrible. They use an ancient U-Boot 2017.09 version, which doesn’t support extlinux. There are 8 (wtf?) different partitions created and their official Alpine image uses an immutable rootfs overlayed with a data partition, so you can’t even run docker on this thing The kernel is dumpeed onto the disk and doesn’t seem easily upgradable unless you overwrite it with dd
I saw DietPi is the only distro that supports this board. I just flashed the image and examined it. It uses the same weird 8 partitions. I saw that there are some u-boot-current and u-boot-edge packages, which (so I hope) are not this vendor crap.
Did you succeed in building an up-to-date U-Boot image that works with extlinux? I also tried upgrading the kernel and the DietPi wouldn’t boot anymore. What’s the right way of having something newer than the vendor 6.1 kernel?
It seems there’s still a FriendlyELEC image on the eMMC? That doesn’t make any sense, does it? Why not just flash a DietPi image onto the eMMC directly and boot from that? That way you save on the SD card. And if the Zero 2 absolutely has to boot from an SD card, I’d wipe the entire eMMC first and create just one partition.
Just got the NanoPi Zero2 (amazing hardware!) as well with eMMC and flashing DietPi to the eMMC is not straightforward. I’m trying the USB method, with driver. The FriendlyElec provided RKDevTool v3.30 does not accept DietPi_NanoPiZero2-ARMv8-Trixie.img (Loading firmware failed!), but reading this topic, it seems that it expects a specific partition layout.
What is the suggested way? I have a TF to eMMC adapter that I can try (but I need to disassemble the device, inckluding wifi antennae), but if the board expects a specific partition layout on eMMC, I shouldn’t even have to try.
Quite easy to get the NanoPi Zero 2 up from eMMC. Just boot of TF card and flash the image to eMMC using dd commend. Takes less than a couple of minutes.
Thank you for the reply. Do you speak from personal experience or is the dd method linked earlier possible more complicated than just the straightforward approach? The article and latest comment mention specific difficulties with NanoPi device and eMMC.
(I’ve already spent 3 hours on just getting DietPi to run from microSD, failed twice, now running a stock image on eMMC and I’m about to go mad, lol.)
Reading Moving a running DietPi system to a USB stick/disk or an onboard eMMC – DietPi Blog , it says that I need to set the file system to read only before copying the microSD card’s contents to eMMC. It also warns me that ‘If you set the file system to read only, an access via SSH is not possible after the reboot, i.e. in this case you need access to the local console (via keyboard and monitor).‘
After the dd copy, I need to shutdown the system and start it without the microSD and then ‘change the root filesystem back to read/write‘.
Wouldn’t that be impossible over SSH, since SSH access is not possible after the reboot? I don’t have UART access.
I decided to go ahead without the RO step. Everything worked fine!
root@DietPi:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 14.5G 0 disk
└─mmcblk0p1 179:1 0 14.4G 0 part /
mmcblk2 179:32 0 58.2G 0 disk
├─mmcblk2p1 179:33 0 4M 0 part
├─mmcblk2p2 179:34 0 4M 0 part
├─mmcblk2p3 179:35 0 4M 0 part
├─mmcblk2p4 179:36 0 16M 0 part
├─mmcblk2p5 179:37 0 40M 0 part
├─mmcblk2p6 179:38 0 32M 0 part
├─mmcblk2p7 179:39 0 32M 0 part
├─mmcblk2p8 179:40 0 1.7G 0 part
└─mmcblk2p9 179:41 0 56.4G 0 part
mmcblk2boot0 179:64 0 4M 1 disk
mmcblk2boot1 179:96 0 4M 1 disk
root@DietPi:~# dd if=/dev/mmcblk0 of=/dev/mmcblk2 bs=1M status=progress
15514730496 bytes (16 GB, 14 GiB) copied, 300 s, 51.7 MB/s
14804+0 records in
14804+0 records out
15523119104 bytes (16 GB, 14 GiB) copied, 302.183 s, 51.4 MB/s
root@DietPi:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 14.5G 0 disk
└─mmcblk0p1 179:1 0 14.4G 0 part /
mmcblk2 179:32 0 58.2G 0 disk
└─mmcblk2p1 179:33 0 14.4G 0 part
mmcblk2boot0 179:64 0 4M 1 disk
mmcblk2boot1 179:96 0 4M 1 disk
^ I had to expand the 14.4G mmcblk2p1 partition to fully use the 64G eMMC.
the ro is needed if you transfer a running system itself. It basically should ensure a consistent status. It is not needed if you flash an image directly from a running SD card.
Which image did you used to boot of your SD card? I can try to replicate your steps. The wifi module should not have an effect to the system, if you still try to use ethernet.
This is a reaction to my deleted post, I think. I thought DietPi wasn’t booting well, but my Unify clients list is just unreliably slow. I think it only lists DietPi after the initial setup fully finishes, even though the Zero2 had gotten an IP address for quite a while. So in the end, everything works as described. Thanks for your help!
Am I not doing exactly that with dd if=/dev/mmcblk0 of=/dev/mmcblk2 bs=1M status=progress from a running system that booted from SD? Afaik I’m not flasing an image, but copying the SD card to eMMC.
Asking this, because I’m setting up a second Zero2 and had an issue that could be related to consistency.
The kernel is dumpeed onto the disk and doesn’t seem easily upgradable unless you overwrite it with dd 