Orange Pi Zero Plus2 H5: Install to eMMC bricked device

[rmoriz]

Hi,

 

after successfully booting the "Armbian_5.69_Orangepizeroplus2-h5_Ubuntu_bionic_next_4.19.13.img" image from a SD-card I decided to use "armbian-config" to copy/install Armbian to the onboard eMMC. The operation finished without an error but the devices now hangs/loops on boot. I've a TTL UART so here is the output:

 

U-Boot SPL 2018.05-armbian (Jan 09 2019 - 22:59:13 +0100)
DRAM: 512 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.0(debug):a9f803b
NOTICE:  BL31: Built : 20:16:26, Jan  7 2019
NOTICE:  BL31: Detected Allwinner H5 SoC (1718)
NOTICE:  BL31: Found U-Boot DTB at 0x407ecc8, model: OrangePi Zero Plus2
INFO:    ARM GICv2 driver initialized
INFO:    Configuring SPC Controller
NOTICE:  BL31: PMIC: Defaulting to PortL GPIO according to H5 reference design.
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9


U-Boot 2018.05-armbian (Jan 09 2019 - 22:59:13 +0100) Allwinner Technology

CPU:   Allwinner H5 (SUN50I)
Model: OrangePi Zero Plus2
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from EXT4... ** File not found /boot/boot.env **

** Unable to read "/boot/boot.env" from mmc0:1 **
Failed (-5)
In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
230454 bytes read in 35 ms (6.3 MiB/s)
starting USB...
No controllers found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3042 bytes read in 39 ms (76.2 KiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
143 bytes read in 31 ms (3.9 KiB/s)
28541 bytes read in 84 ms (331.1 KiB/s)
504 bytes read in 104 ms (3.9 KiB/s)
Applying kernel provided DT overlay sun50i-h5-usbhost2.dtbo
504 bytes read in 105 ms (3.9 KiB/s)
Applying kernel provided DT overlay sun50i-h5-usbhost3.dtbo
4155 bytes read in 81 ms (49.8 KiB/s)
Applying kernel provided DT fixup script (sun50i-h5-fixup.scr)
## Executing script at 44000000
8781919 bytes read in 480 ms (17.4 MiB/s)
14243848 bytes read in 744 ms (18.3 MiB/s)
## Loading init Ramdisk from Legacy Image at 4fe00000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    8781855 Bytes = 8.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 4979f000, end 49fff01f ... OK
   reserving fdt memory region: addr=4fa00000 size=6d000
   Loading Device Tree to 000000004972f000, end 000000004979efff ... OK

Starting kernel ...

[   44.234023] reboot: Restarting system

 

As you can see this takes ~44 seconds and then loops. I've also re-written the image to the SD-Card but this didn't change anything.

 

When booting the device without an SD-Card, the following is looping rapidly without an interruption:

Resetting CPU ...

resetting ...
"Synchronous Abort" handler, esr 0x5e000000
elr: 0000000000011ce4 lr : 000000004fdfa850
x 0: 0000000084000009 x 1: 000000004fdfa870
x 2: 0000000000016894 x 3: 000000004fdfa890
x 4: 0000000000013f20 x 5: 000000004fdfaa90
x 6: 00000000ffffffc8 x 7: 000000000000000a
x 8: 0000000000000044 x 9: 000103d600000000
x10: 9419820400000000 x11: 000000000000000c
x12: 4008173a0007fffe x13: 02052020a1fe8800
x14: 0c440182d8408000 x15: 00020100c4640000
x16: 100420254a2c0844 x17: 0c03fc400001a946
x18: 000000004fdffe80 x19: 000000004fdfaab0
x20: 00000000ffffffc8 x21: 000000004fdfeb70
x22: 000000000001717b x23: 000000000001717b
x24: 000000004fdfeb30 x25: 000000004fdfec70
x26: 000000004fdfeb31 x27: 0000000000000030
x28: 5e0f02892c9e0465 x29: 000000004fdfa830

 

With pressing space I can prevent autoboot and I'm getting the U-Boot shell. Sadly I have no idea what to do. Is there an easy way to revert to SD-Card booting at least?

 

Thanks!

 

Roland

[sfx2000]

12 minutes ago, rmoriz said:

With pressing space I can prevent autoboot and I'm getting the U-Boot shell.

 

Should be able to stop uBoot from autobooting...

 

The problem you have is with AllWinnner, uBoot goes off the edge of the world, otherwise the H5 should go into FEL mode

 

@Igor - uBoot has failsafe mode, but many of the tools aren't available right now with Armbian

[Igor]

7 hours ago, rmoriz said:

When booting the device without an SD-Card, the following is looping rapidly without an interruption:

Can't reproduce this problem on my board. Not with a clean image, not with updated. http://ix.io/1zbp

 

Must be some hw defect or incompatibility.

 

7 hours ago, sfx2000 said:

uBoot has failsafe mode

how-to?

 

... or insufficient powering. As usual.

[rmoriz]

When I attach a display via HDMI and provide the sd card, Armbian boots successfully and stays up for at least 5 minutes. So maybe my 3.3V TTL-UART-USB or not having an HDMI output is part of the problem?

 

The logs seem to  "miss" the part between "Starting the Kernel" and "[ 44.234023] reboot: Restarting system" which does not make sense.

If the kernel cmdline does not configure serial output, then why the "Restarting system" appears?

 

Anyway, when a HDMI display is connected, I can see the full boot process which looks flawless. (when I start without an SD card, the HDMI screen stays dark)

 

Power supply: Yes, I know. The board is designed to be powered by micro USB which I do using a power supply that worked successfully with RP3B and RP0W before (yes, doesn't mean anything), even under heavy load (compiling kernel modules).

I've also attached a reasonable accurate power meter and the consumption is only around 1.3-2W and the power adapter is rated for at least 1A (5W). I'll try it with "a better" one this weekend and keep you informed.

 

 

[rmoriz]

Ah, just to record another oddity regarding wifi:

 

iw scan failed to detect my 2.4 GHz WiFi running using channel 13 however it listed networks of the shops 30m away (line of sight) ruling out defect antenna or broken driver. 

Regular domain was correctly set to my location (DE)  (manually with `iw` and by setting in  /etc/default/crda). Maybe I missed something? (Using channel 13 is prohibted in the US afaik)

 

I changed the channel on my AP to 10 and the device connected without further issues. (this was before I decided to install everything to eMMC.)

 

[Igor]

I did try all possible combinations. It doesn't break down. If anything matters it's a voltage drop. Mine shows 4.90V at header while stressing the board.

 

3 minutes ago, rmoriz said:

iw scan failed to detect my 2.4 GHz WiFi running using channel 13 however it listed networks of the shops 30m away (line of sight) ruling out defect antenna or broken driver. 

Regular domain was correctly set to my location (DE)  (manually with `iw` and by setting in  /etc/default/crda). Maybe I missed something? (Using channel 13 is prohibted in the US afaik)

Upstream problem in any case. Perhaps related to this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892229#49

[martinayotte]

15 hours ago, rmoriz said:

As you can see this takes ~44 seconds and then loops.

To see more verbosity, edit /boot/armbianEnv.txt, make sure that "verbosity=7" and "console=serial" instead of "console=both".

This way, you will be able to see what is happening during this 44 seconds ...

[rmoriz]

current progress:

 

- System starts again from SD

- Used the same power supply but no UART-TTL connected (I guess this was the cause of the original case). 

- tried again to install the system to eMMC (armbian-config/nand-sata-install finishes successfully)

- after power cycle system still boots from SD (/dev/mmcblk0p1 instead of /dev/mmcblk2p1)

- eMMC /dev/mmcblk2 is mountable and looks good (contains the armbian system)

- System does not boot without SD-card

 

relevant package versions:

ii  linux-bionic-root-next-orangepizeroplus2-h5 5.69                              arm64        Armbian tweaks for bionic on orangepizeroplus2-h5 (next branch)
ii  linux-u-boot-orangepizeroplus2-h5-next      5.69                              arm64        Uboot loader 2018.05

 

=> apt-get dist-upgrade

ii  linux-bionic-root-next-orangepizeroplus2-h5 5.70                              arm64        Armbian tweaks for bionic on orangepizeroplus2-h5 (next branch)
ii  linux-u-boot-orangepizeroplus2-h5-next      5.70                              arm64        Uboot loader 2018.05

=> again nand-sata-install + reboot

=> still booting off SD (/dev/mmcblk0p1)

[martinayotte]

26 minutes ago, rmoriz said:

but no UART-TTL connected (I guess this was the cause of the original case).

I doubt !

26 minutes ago, rmoriz said:

System does not boot without SD-card

Sound strange !

If you re-run "nand-sata-install", does it provide the option "Install/Update the bootloader on SD/eMMC" ? If Yes, simply give it a try ...

Also check if the content of /boot of eMMC is almost identical to the /boot of SDCard ...

 

[rmoriz]

Update:

 

In /boot/armbianEnv.txt on the SD-Card the rootdev still pointed to the sd card root. I changed it to the UUID of the eMMC (used `blkid` get it)

 

After rebooting, root partition is now eMMC:

root@orangepizeroplus2:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            173M     0  173M   0% /dev
tmpfs            49M  2.3M   46M   5% /run
/dev/mmcblk2p1  7.1G 1015M  5.7G  15% /

 

However system does not boot without the SD-Card inserted, showing the "Resetting CPU ..." behaviour as mentioned in my opening post. Is that expected/by design? 

[martinayotte]

27 minutes ago, rmoriz said:

Is that expected/by design?

No ! something strange happened ...

But as I said earlier :

Quote

If you re-run "nand-sata-install", does it provide the option "Install/Update the bootloader on SD/eMMC" ? If Yes, simply give it a try ...

Also check if the content of /boot of eMMC is almost identical to the /boot of SDCard ...

Maybe "nand-sata-install" can fix that by re-install u-boot sectors on the eMMC.

[5kft]

@rmoriz, for the sake of completeness:  Did you previously run an earlier build of Armbian from the eMMC and was that okay?  If not, I'm wondering if you might have an issue with the eMMC hardware...?  You could try booting from SD, format the eMMC, mount it, then do a filesystem tests, perhaps?

 

FWIW, I been using the eMMC exclusively on my Plus2 H5s and have never seen anything like what you are experiencing (another reason to suspect a hardware issue with the eMMC)...  E.g.,

root@orangepizeroplus2:~# uptime
 23:18:11 up 11 days, 22:47,  1 user,  load average: 0.00, 0.00, 0.00
root@orangepizeroplus2:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            175M     0  175M   0% /dev
tmpfs            49M  5.3M   43M  11% /run
/dev/mmcblk2p2  7.2G  954M  6.0G  14% /
tmpfs           241M     0  241M   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           241M     0  241M   0% /sys/fs/cgroup
/dev/mmcblk2p1   58M   29M   26M  54% /media/mmcboot
/dev/zram5      234M  292K  217M   1% /tmp
/dev/zram0       49M  3.0M   42M   7% /var/log
tmpfs            49M     0   49M   0% /run/user/1000
root@orangepizeroplus2:~# cat /proc/version
Linux version 4.19.13-sunxi64 (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.70 SMP Sat Jan 12 17:41:57 CET 2019
root@orangepizeroplus2:~#

(I'm using btrfs as the main filesystem)

 

[rmoriz]

eMMC seems to be fine because i can mount and write to it.

# fdisk  -l /dev/mmcblk2
Disk /dev/mmcblk2: 7.3 GiB, 7818182656 bytes, 15269888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9050a3d5

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk2p1       8192 15117183 15108992  7.2G 83 Linux

# blkid
/dev/mmcblk0p1: UUID="962faea8-b247-4f0b-8614-9f3cbcd3593d" TYPE="ext4" PARTUUID="51af9c91-01"  # SD
/dev/mmcblk2p1: UUID="fdccd95d-8138-4dbd-a07f-28425d05aa1c" TYPE="ext4" PARTUUID="9050a3d5-01"  # eMMC
...
/dev/mmcblk0: PTUUID="51af9c91" PTTYPE="dos" # SD
/dev/mmcblk2: PTUUID="9050a3d5" PTTYPE="dos" # eMMC

# fsck.ext4 /dev/mmcblk2p1
e2fsck 1.44.1 (24-Mar-2018)
/dev/mmcblk2p1: clean, 35980/472352 files, 306094/1888624 blocks

# cat /proc/cmdline 
root=UUID=962faea8-b247-4f0b-8614-9f3cbcd3593d rootwait rootfstype=ext4 console=ttyS0,115200 console=tty1 panic=10 consoleblank=0 loglevel=1 ubootpart=51af9c91-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=memory swapaccount=1

# mkdir /tmp/emmc
# mount /dev/mmcblk2p1 /tmp/emmc
# diff -r /boot /tmp/emmc/boot
diff -r /boot/armbianEnv.txt /tmp/emmc/boot/armbianEnv.txt
5c5
< rootdev=UUID=962faea8-b247-4f0b-8614-9f3cbcd3593d
---
> rootdev=UUID=fdccd95d-8138-4dbd-a07f-28425d05aa1c
Binary files /boot/boot.scr and /tmp/emmc/boot/boot.scr differ
diff: /boot/dtb/dtb-4.19.13-sunxi64: Too many levels of symbolic links
diff: /tmp/emmc/boot/dtb/dtb-4.19.13-sunxi64: Too many levels of symbolic links
diff: /boot/dtb-4.19.13-sunxi64/dtb-4.19.13-sunxi64: Too many levels of symbolic links
diff: /tmp/emmc/boot/dtb-4.19.13-sunxi64/dtb-4.19.13-sunxi64: Too many levels of symbolic links

 

 

 

 

[Igor]

7 hours ago, rmoriz said:

# fsck.ext4 /dev/mmcblk2p1 e2fsck 1.44.1 (24-Mar-2018) /dev/mmcblk2p1: clean, 35980/472352 files, 306094/1888624 blocks

 

eMMC could also only be damaged outside Linux filesystem areas, where u-boot is written. I have seen this problem at one SD card. I could format it and write anything to it, but the bootloader. If this is the case, there is nothing you can do about ... except replacing eMMC chip. Which I doubt that it makes sense.

[rmoriz]

I couldn't sleep and tried another approach: I learned that OrangePI ships at least their (shady, outdated) Ubuntu 16.04 Image with an "install to eMMC" script. The image is called "ubuntu_server_zeroplus2_H5_V0_1.img" and available from http://www.orangepi.org/downloadresources/orangepizeroplus2H5/orangepizeroplus2H5_adce81482f863b39.html

 

I flashed it with Etcher but it didn't successfully boot, as it *requires* an already partitioned and formatted eMMC (I wiped it with dd prior that attempt) to successfully finish the boot process. 

 

So back to Armbian SD boot: fdisk the emmc, create 2 partitions, mkfs (first ext2 and second ext4 as required by the systemd unit of the shady 16.04 Image).

 

The OrangePI 16.04 image then booted successfully (from SD) and I was able to execute their "OrangePi_Settings" script (sudo OrangePi_Settings) and choose the Install to eMMC option. After the installation finished, I powered off the device, removed the SD card, and powered it up again: It booted successfully from eMMC.

 

Device names are different than with Armbian: mmcblk0=eMMC, mmcblk1=SD. (Kernel "3.10.65+"). 

 

Ubuntu 16.04.1 LTS Orangepi ttyS0
Orangepi login: root
Password: 
Last login: Thu Apr  6 12:02:12 UTC 2017 on ttyS0
Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 3.10.65+ aarch64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
  ___                             ____  _ 
 / _ \ _ __ __ _ _ __   __ _  ___|  _ \(_)
| | | | '__/ _` | '_ \ / _` |/ _ \ |_) | |
| |_| | | | (_| | | | | (_| |  __/  __/| |
 \___/|_|  \__,_|_| |_|\__, |\___|_|   |_|
                       |___/              

*****************************************************************
-e  When you first running OrangePi ZeroPlus2 
-e  Please use OrangePi Configure tools, such as: 
-e  sudo OrangePi_Settings 
******************************************************************
blkid                                              
/dev/mmcblk0: PTUUID="560b2c98" PTTYPE="dos"
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="EMMCBOOT" UUID="E713-9DD0" TYPE="vfat" PARTUUID="560b2c98-01"
/dev/mmcblk0p2: LABEL="emmclinux" UUID="cc931d85-f58d-460d-9126-b10502c48bf5" TYPE="ext4" PARTUUID="560b2c98-02"
/dev/mmcblk1: PTUUID="000ebed2" PTTYPE="dos"
/dev/mmcblk1p1: SEC_TYPE="msdos" LABEL="BOOT" UUID="16AC-FBA4" TYPE="vfat" PARTUUID="000ebed2-01"
/dev/mmcblk1p2: LABEL="rootfs" UUID="f254ba92-d0ab-42b1-90a2-3ced2cfdef8e" TYPE="ext4" PARTUUID="000ebed2-02"

 

And as you can see there is a vfat /boot partition. The contents are identical on SD and eMMC:

root@Orangepi:~# mount /dev/mmcblk0p1 /tmp/boot
root@Orangepi:~# diff -r /boot /tmp/boot
root@Orangepi:~# find /boot
/boot
/boot/orangepi
/boot/orangepi/uImage
/boot/orangepi/OrangePiH5orangepi.dtb
/boot/orangepi/OrangePiH5.dtb
/boot/initrd.img
/boot/uEnv.txt
/boot/backup
/boot/backup/orangepi
/boot/backup/orangepi/uImage
/boot/backup/orangepi/OrangePiH5orangepi.dtb
/boot/backup/orangepi/OrangePiH5.dtb
/boot/backup/uEnv.txt
/boot/backup/initrd.img

Is it intentional, that Armbian's `nand-sata-install` does not create such a VFAT partition?

 

 

(PS: I've extracted and uploaded OragenPI scripts and uboot binaries to https://github.com/rmoriz/orangepi_scripts )

Edited January 27, 2019 by rmoriz
typo

[martinayotte]

16 minutes ago, rmoriz said:

The image is called "ubuntu_server_zeroplus2_H5_V0_1.img"

This image is NOT from Armbian !!! So no support ...

[rmoriz]

6 minutes ago, martinayotte said:

This image is NOT from Armbian !!! So no support ...

There is no support needed for that image. I just wanted to provide insights.

[Igor]

4 hours ago, rmoriz said:

does not create such a VFAT partition?

There is no need to have VFAT, which is here with a purpose to "emulate" Raspberry Pi way which must have VFAT to be able to load firmware. But you can try one more thing: use EXT2 filesystem instead of EXT4 when transfering to eMMC.

[rmoriz]

ext2 does not work either. CPU reset loop.

 

I wish I would understand more details of the boot process i.e. how the SoC "knows" where U-boot is.

[guidol]

On 1/26/2019 at 11:11 AM, Igor said:

 

eMMC could also only be damaged outside Linux filesystem areas, where u-boot is written. I have seen this problem at one SD card. I could format it and write anything to it, but the bootloader. If this is the case, there is nothing you can do about ... except replacing eMMC chip. Which I doubt that it makes sense.

little "dumb" idea:

if the part outside the linuxfilesystem is damaged, the non-armbian-image will work because of the vfat partition which is "covering" the error.

years ago I had a old hdd which has bad sectors in the first 1GB.

after adding a 1GB partition ad the start of the hdd and using the rest as the second partition the os could be installed and used from the second partition.

Maybe @rmoriz could use the other partition style for armbian when tranfering armbian manually to emmc.

[rmoriz]

IMHO eMMC is fine. Here is an attempt to prove it:

 

# dump the entire eMMC to get its size:
$ dd if=/dev/mmcblk2 of=emmc
15269888+0 records in
15269888+0 records out
7818182656 bytes (7.8 GB, 7.3 GiB) copied, 537.777 s, 14.5 MB/s

# create a new file on the sd card with the exact size, filled with random data 
$ dd if=/dev/urandom of=emmc.new bs=7634944 count=1024
1024+0 records in
1024+0 records out
7818182656 bytes (7.8 GB, 7.3 GiB) copied, 513.515 s, 15.2 MB/s

# checksumming
$ sha512sum emmc.new
b94f6133d5843418a036ed0d405ae78a5058759265e677d3c6c1a60397a383bc4e39b08449b0dab0bf564a422599ecb1bd05150e70c5841cd6c309adfdabec3a  emmc.new

# writing the file to the eMMC
$ dd if=emmc.new of=/dev/mmcblk2 bs=7634944 count=1024
1024+0 records in
1024+0 records out
7818182656 bytes (7.8 GB, 7.3 GiB) copied, 327.95 s, 23.8 MB/s

# again dump the entire eMMC to sd:
$ dd if=/dev/mmcblk2 of=emmc.readback
15269888+0 records in
15269888+0 records out
7818182656 bytes (7.8 GB, 7.3 GiB) copied, 532.28 s, 14.7 MB/s

# verify
$ sha512sum  emmc.readback
b94f6133d5843418a036ed0d405ae78a5058759265e677d3c6c1a60397a383bc4e39b08449b0dab0bf564a422599ecb1bd05150e70c5841cd6c309adfdabec3a  emmc.readback

# both shasums are identical

 

[rmoriz]

Yesterday evening I also tried the oldest Armbian releasess I was able to find:

 

Armbian_5.59_Orangepizeroplus2-h5_Ubuntu_bionic_next_4.14.65.img

Armbian_5.69_Orangepizeroplus2-h5_Debian_stretch_next_4.19.13.img

 

nand-sata-install in that versions does not work either.

 

Has someone of you actually managed to get a full eMMC based installation working with nand-sata-install on the Orange Pi Zero Plus2 H5?

[guidol]

12 minutes ago, rmoriz said:

Has someone of you actually managed to get a full eMMC based installation working with nand-sata-install on the Orange Pi Zero Plus2 H5?

Yes - on my OPi Zero Plus2 H5 I installed  Armbian_5.72_Orangepizeroplus2-h5_Debian_stretch_dev_4.20.2.img 

- which I did compile with the armbian-build-system -

without problems to eMMC

 

Also my DEV-compile before was successfully installed to eMMC:
Armbian_5.67_Orangepizeroplus2-h5_Debian_stretch_dev_4.19.4.img

[rmoriz]

3 minutes ago, guidol said:

Yes - on my OPi Zero Plus2 H5 I installed  Armbian_5.72_Orangepizeroplus2-h5_Debian_stretch_dev_4.20.2.img 

- which I did compile with the armbian-build-system -

without problems to eMMC

 

Also my DEV-compile before was successfully installed to eMMC:
Armbian_5.67_Orangepizeroplus2-h5_Debian_stretch_dev_4.19.4.img

Could you share the images or provide me an URL to download? That would be great!

 

[martinayotte]

1 hour ago, rmoriz said:

Has someone of you actually managed to get a full eMMC based installation working with nand-sata-install on the Orange Pi Zero Plus2 H5?

It is and was always worked successfully on my side, and not only on my OPiZeroPlus2-H5, both on all my boards ...

[5kft]

1 hour ago, martinayotte said:

It is and was always worked successfully on my side, and not only on my OPiZeroPlus2-H5, both on all my boards ...

 

Likewise - I have always used the eMMC exclusively on all of my Orange Pi Zero Plus2 H5 boards (I have multiple) and have never seen anything like this...  (It's also always worked for my NEO Core 2 boards, NEO Plus 2 boards, etc.)

 

In order to try narrowing the problem down, perhaps try @guidol's suggestion above (https://forum.armbian.com/topic/9440-orange-pi-zero-plus2-h5-install-to-emmc-bricked-device/?tab=comments#comment-71034).  It could be that Armbian's partition layout is such that it exacerbates a H/W problem with your particular board?  E.g., it'd be interesting to see if you still have problems if you layout the image to start at 1GB rather than at zero.

[guidol]

3 hours ago, rmoriz said:

Could you share the images or provide me an URL to download? That would be great!

Sorry, I cant because of the flaky slow 0,7MBit Upload-Speed of my DSL.
A dowload URL isnt available, because the images are only created via the armbian-build-system.

 

But with Virtualbox you could easily create the armbian-build-system with VirtualBox and a minimal ubuntu-image:
https://docs.armbian.com/Developer-Guide_Build-Preparation/

[rmoriz]

4 minutes ago, 5kft said:

 

Likewise - I have always used the eMMC exclusively on all of my Orange Pi Zero Plus2 H5 boards (I have multiple) and have never seen anything like this...  (It's also always worked for my NEO Core 2 boards, NEO Plus 2 boards, etc.)

 

In order to try narrowing the problem down, perhaps try @guidol's suggestion above (https://forum.armbian.com/topic/9440-orange-pi-zero-plus2-h5-install-to-emmc-bricked-device/?tab=comments#comment-71034).  It could be that Armbian's partition layout is such that it exacerbates a H/W problem with your particular board?  E.g., it'd be interesting to see if you still have problems if you layout the image to start at 1GB rather than at zero.

 

I already did a full eMMC test 

 

[rmoriz]

5 minutes ago, guidol said:

Sorry, I cant because of the flaky slow 0,7MBit Upload-Speed of my DSL.
A dowload URL isnt available, because the images are only created via the armbian-build-system.

 

But with Virtualbox you could easily create the armbian-build-system with VirtualBox and a minimal ubuntu-image:
https://docs.armbian.com/Developer-Guide_Build-Preparation/

 

But this does not deliver an exact version build. I have many builds that don't work, another one will not help me. That's why I'm asking for exact versions.

[5kft]

8 minutes ago, rmoriz said:

I already did a full eMMC test 

 

 

Sure, but it is rather difficult to solve a problem if you don't try to debug it   Why not put a little more effort into this, it certainly is an interesting and strange problem...!