JumboAg

I fried my original orangepi5 ages ago. Similar symptoms. If you try it with a PC using rkdevtool, does the PC even recognize it at all? Are you sure its USB0? What does dmesg (linux) or device manager (PC) show you when you plug it in?

Wiping the SPI allowed me to boot the Armbian SD card. Thank you. SPI-Flash updated to current armbian: U-Boot 2026.04_armbian-2026.04-S88dc-Pb430-H2ebc-V3dc7-B5da4-R448a (Jul 24 2026 - 14:21:45 +0000) Model: Xunlong Orange Pi 5 SoC: RK3588S

Welcome to minicom 2.10 OPTIONS: I18n Port /dev/ttyACM2, 18:53:53 [U] Press CTRL-A Z for help on special keys DDR 69ce204132 kwin.chen 26/08/03-14:25:25,fwver: v1.24 ch0 ttot10 ch1 ttot10 ch2 ttot10 ch3 ttot10 ch0 ttot16 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB ch1 ttot16 channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB ch2 ttot16 channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB ch3 ttot16 channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB Manufacturer ID:0x1 DQS rds:h1,h1 CH0 RX Vref:28.5%, TX Vref:21.8%,22.8% DQ rds:l0 l0 h1 l0 l1 h3 h3 h3, l0 l0 h1 h2 h2 l4 h5 h1, l0 h1 DQS rds:h3,l1 CH1 RX Vref:30.2%, TX Vref:22.8%,21.8% DQ rds:h2 l0 l0 h1 h1 h1 l0 h4, h3 h1 h5 h2 h5 l2 h1 h7, h1 l1 DQS rds:h1,h1 CH2 RX Vref:29.4%, TX Vref:22.8%,22.8% DQ rds:h5 h1 h2 h2 l0 h2 l0 h1, l0 h7 h3 l0 h3 h6 h2 h1, h1 l0 DQS rds:h1,l1 CH3 RX Vref:30.2%, TX Vref:22.8%,20.8% DQ rds:h1 h3 h1 l0 l0 h1 l0 l0, h1 h1 h1 h1 l0 h2 h5 h1, h1 l0 change to F1: 528MHz ch0 ttot10 ch1 ttot10 ch2 ttot10 ch3 ttot10 CH0 rx vref:28.5% CH1 rx vref:30.2% CH2 rx vref:29.4% CH3 rx vref:30.2% change to F2: 1068MHz ch0 ttot12 ch1 ttot12 ch2 ttot12 ch3 ttot12 CH0 rx vref:28.5% CH1 rx vref:30.2% CH2 rx vref:29.4% CH3 rx vref:30.2% change to F3: 1560MHz ch0 ttot14 ch1 ttot14 ch2 ttot14 ch3 ttot14 CH0 rx vref:28.5% CH1 rx vref:30.2% CH2 rx vref:29.4% CH3 rx vref:30.2% change to F0: 2112MHz ch0 ttot16 ch1 ttot16 ch2 ttot16 ch3 ttot16 stride=0x2, ddr_config=0x4 hash ch_mask0-1 0x20 0x40, bank_mask0-3 0xa00 0x1400 0x2800 0x0, rank_mask0 0x401000 out U-Boot SPL board init U-Boot SPL 2017.09-orangepi (Aug 20 2026 - 04:00:19) unknown raw ID 41 18 20 Trying to boot from MMC1 Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(7612223b82...) + OK ## Checking u-boot 0x00800000 ... sha256(8b0566a1dd...) + OK ## Checking fdt-1 0x008d5ae8 ... sha256(7b2c4c6dbe...) + OK ## Checking atf-2 0x000f0000 ... sha256(b2af21b504...) + OK ## Checking atf-3 0xff100000 ... sha256(70505bb764...) + OK Jumping to U-Boot(0x00800000) via ARM Trusted Firmware(0x00040000) Total: 470.441 ms Using the trixie current minimal image with the Armbian flasher, I definitely get more back than using balena etcher, but I still hang. This time I do at least get some feedback from uboot:

FWIW, I'm running into the exact same issue. Tried with both Trixie and ubuntu, as well as both vendor and community kernel levels. System isnt even recognizing the flashed SD card at all. If I try to boot off of it, I get nothing over the serial uart. I can flash the stock ancient image from orangepi themselves on the same SD, boots fine. Another item that may be of value: If I boot off the boards NVME drive and insert the SD card into the boards mmc reader, it isnt recognized at all. dmesg doesnt even indicate it tried to scan it. Total black hole. I CAN mount it if I put it in a USB sd reader though. I burned it with balena etcher. Wondering if there's a problem with current images in conjunction w/ Balena and they dont write correctly?