Eddie

There are updated images v24.5.2, which should work OOB.

Hello,
I found the solution (for me) about this issue. I hope it will resolve in armbian community too:
Remove data on SPI flash chip sudo su - devicesize=$(blockdev --getsz /dev/mtdblock0) dd if=/dev/zero of=/dev/mtdblock0 bs=1M count=$devicesize status=progress && sync Download working uboot image wget https://github.com/si0ls/u-boot-orangepi5/releases/download/v1.0/u-boot-v2024.04-orangepi5-plus-spi.bin Write the u-boot file to SPI flash dd if=u-boot-v2024.04-orangepi5-plus-spi.bin of=/dev/mtdblock0 bs=1M status=progress && sync Reboot the system reboot Enjoy!  
Some tests (still in progress!):
root@orangepi5-plus-nvme:~# memtester 30G 1 memtester version 4.6.0 (64-bit) Copyright (C) 2001-2020 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffffffffffff000 want 30720MB (32212254720 bytes) got 30720MB (32212254720 bytes), trying mlock ...locked. Loop 1/1: Stuck Address : ok Random Value : \  
 
What I use:
Orange PI 5 Plus 32GB RAM version Original raspberry pi 4 power supply (USB-C 4A) NVME 128GB M.2 2230 And I tested couple of Armbian images (just execute memtester 30G 1 and wait ~2 minutes for crash ...  and when nothing happend then change nvme with another system):  # md5sum Armbian_24.* e5d74477e3f976ece5f85e8261491b43 Armbian_24.5.1_Orangepi5-plus_bookworm_vendor_6.1.43_minimal.img ec5c88f73a50ae583c6b07684b28a394 Armbian_24.8.0-trunk.123_Orangepi5-plus_bookworm_edge_6.8.12_minimal.img e29bc71aa4e1d9d4af358faf7ebe81b6 Armbian_24.8.0-trunk.123_Orangepi5-plus_bookworm_vendor_6.1.43_minimal.img  
Source link : https://github.com/si0ls/u-boot-orangepi5

@usual user@Efe Çetin
it seem to work with
 
i burned an sd card with the new compiled Armbian-unofficial_24.8.0-trunk_Orangepi5-plus_bookworm_legacy.5.10.160 image .
I boot from the sdcard
It seems to work as i have no crash copying a 250GB file between a usb ssd and the mvne.
 
I'm trying now memtester 31G. ...
  ... trying mlock ...Killed
BUT not crash
 
trying memtester 30G is working ...
... and it does not crash.
 
@Efe Çetin Is it possible to make the official release working for the 32Gb version ?

rk3588: experimental UEFI edk2 support
core extensions: fix: don't redefine extension_function_info when recursing otherwise when there's a chain of enable_extension() we lose the original info extensions: grub-with-dtb: add UMS menu entry to GRUB if initramfs ums hook is detected this allows user to enter UMS mode from GRUB for usage with the initramfs-usb-gadget-ums extension has no effect unless initramfs-usb-gadget-ums extension is enabled together with grub-with-dtb extensions: initramfs-usb-gadget-ums: kernel cmdline enables initramfs UMS of all block devices this optional extension adds an initramfs script that: enumerates and filters all block devices exposes each device as an UMS (USB Mass Storage) in an USB Gadget loops forever with info (board never boots) the idea here is to compensate for UEFI's lack of "ums" or "rockusb" mode that's present in u-boot it also allows to expose USB/NVMe devices that might or not be detected by bootloader, if the kernel works extensions: uefi-edk2-rk3588: deploy edk2 (not u-boot) for rk3588 boards this extension is 100% optional and shouldn't adversely affect any builds if not enabled requires UEFI_EDK2_BOARD_ID to be set in board file, so we know which UEFI/edk2 build to use it finds the latest edk2 version from GitHub automatically (currently v0.9.1) it downloads (and caches) the correct edk2 build image automatically if forces certain aspects of the image: must use GPT partitioning must NOT use a separate /boot partition it disables the building and deploying of u-boot completely (thus blobs etc are from edk2) it creates a GPT "uboot" partition pointing to edk2's FIT, required by SPL this extension: automatically enables 'grub-with-dtb' automatically enable 'initramfs-usb-gadget-ums', to compensate for lack of ums/rockusb since we dont have u-boot anymore rk3588: configure UEFI_EDK2_BOARD_ID for all UEFI-supported boards From https://github.com/edk2-porting/edk2-rk3588/releases/tag/v0.9.1 For example, for rock-5b_UEFI_Release_v0.9.1.img UEFI_EDK2_BOARD_ID is rock-5b Important: this has no effect unless optional extension is enabled to test this out: make sure to read carefully the instructions at https://github.com/edk2-porting/edk2-rk3588/blob/master/README.md suppose you previously built the regular u-boot version with: ./compile.sh BOARD=rock-5b BRANCH=legacy RELEASE=jammy now you can build the UEFI version with: ./compile.sh BOARD=rock-5b BRANCH=legacy RELEASE=jammy EXT=uefi-edk2-rk3588 write the produced image to SD or eMMC and boot it use normally, or enter "UMS" mode by selecting that option in the grub menu You can write image to eMMC, boot it, enter UMS, write it again to NVMe, reboot, press in UEFI and boot from NVMe Also works if .img is written to eg USB stick, and UEFI edk2 is separately deployed to SPI flash Important: make absolutely sure you are able to force Maskrom mode (by shorting pins, pressing buttons, etc) before writing an UEFI image to eMMC; UEFI has no RockUSB ("Loader mode" support) at all. The new "initramfs-usb-gadget-ums" extension hopes to address this, but it is not guaranteed to work. View the full article

Hi all,
Just want to share this issue i came across from my recently purchased OPI5+ 32GB version.
I noticed it freezes when transferring .img from micro SD card to eMMC or NVMe drives via the command line.
 
Now the img file are armbian OS and no its not the img file issue.

 
at times I can get it to around 70seconds and it will freeze. hard reboot is required, unable to complete the transfer.
 
I have also tried to reduce the bs=10 speed but still the same.
 
 
Now i have also got the 16GB version and this works fine with no issues...
 
Good chance there is something wrong with this latest hardware..  ? ?