October 11Oct 11 Hi everyone, I'm looking for help troubleshooting a boot issue with my Orange Pi 5 Pro (RK3588S). The board previously booted successfully with multiple operating systems, including: Armbian Ubuntu by Joshua Riek Android 12 However, after leaving the board unused for several months, I tried using it again and found that it could no longer boot properly. Current symptoms I'm connecting to the board through its serial console at 1,500,000 baud using picocom. With Armbian Debian Trixie Minimal, using the current kernel (6.18.55), the boot process stops after: picocom v3.1 port is : /dev/ttyACM2 flowcontrol : none baudrate is : 1500000 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no hangup is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, logfile is : none initstring : none exit_after is : not set exit is : no Type [C-a] [C-h] to see available commands Terminal ready DDR b8ce94f14b cym 25/09/26-15:48.05,fwver: v1.20 ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 ch0 ttot7 LPDDR5, 2400MHz channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB ch1 ttot7 channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB ch2 ttot7 channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB ch3 ttot7 channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Manufacturer ID:0xff DQS rds:h2,l0 CH0 RX Vref:25.5%, TX Vref:20.0%,0.0% DQ rds:l1 h4 h1 l1 h2 h1 h1 l3, h7 h1 l2 h1 l0 l1 h1 h3 DQS rds:l0,l0 CH1 RX Vref:25.4%, TX Vref:22.0%,0.0% DQ rds:h3 h2 h1 h1 l0 l0 h1 h7, h1 l0 h1 h4 h3 h1 h1 l0 DQS rds:h1,l0 CH2 RX Vref:26.7%, TX Vref:21.0%,0.0% DQ rds:h1 l0 h2 h1 h1 h6 h4 h1, h1 h2 l0 h1 h1 l1 l0 h3 DQS rds:h1,h1 CH3 RX Vref:28.5%, TX Vref:20.0%,0.0% DQ rds:h3 l0 l0 h3 h6 h1 h4 h5, h1 h1 h5 l0 h3 h3 h5 h2 stride=0x2, ddr_config=0x2 hash ch_mask0-1 0x20 0x40, bank_mask0-3 0x0 0x2400 0x44800 0x89000, rank_mask0 0x0 change to F1: 534MHz ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 change to F2: 1320MHz ch0 ttot8 ch1 ttot8 ch2 ttot8 ch3 ttot8 change to F3: 1968MHz ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 change to F0: 2400MHz ch0 ttot7 ch1 ttot7 ch2 ttot7 ch3 ttot7 out U-Boot SPL 2025.10_armbian-2025.10-Se50b-Pc70f-Hbc88-Vf68a-B56a7-R448a (Oct 06 2026 - 02:25:05 +0000) The board does not appear to proceed beyond this point. When I use Armbian with the vendor kernel (6.1.172), the DDR initialization output is similar, but the boot process fails with a synchronous abort: picocom v3.1 port is : /dev/ttyACM2 flowcontrol : none baudrate is : 1500000 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no hangup is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, logfile is : none initstring : none exit_after is : not set exit is : no Type [C-a] [C-h] to see available commands Terminal ready DDR b8ce94f14b cym 25/09/26-15:48.05,fwver: v1.20 ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 ch0 ttot7 LPDDR5, 2400MHz channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB ch1 ttot7 channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB ch2 ttot7 channel[2] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB ch3 ttot7 channel[3] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=2048MB Manufacturer ID:0xff DQS rds:h2,l0 CH0 RX Vref:25.5%, TX Vref:21.0%,0.0% DQ rds:l1 h3 h1 l1 h2 h1 h1 l3, h7 h1 l2 h1 l0 l1 l0 h3 DQS rds:l0,l0 CH1 RX Vref:25.4%, TX Vref:22.0%,0.0% DQ rds:h3 h2 h1 h1 l0 l0 h1 h7, h1 l0 h1 h4 h3 h1 h1 l0 DQS rds:h1,l0 CH2 RX Vref:26.7%, TX Vref:20.0%,0.0% DQ rds:h1 l0 h2 h1 h1 h6 h4 h1, h1 h1 l0 h1 h1 l1 l0 h3 DQS rds:h1,h1 CH3 RX Vref:28.5%, TX Vref:21.0%,0.0% DQ rds:h3 l0 l0 h3 h6 h1 h4 h5, l0 h1 h4 l0 h3 h3 h4 h2 stride=0x2, ddr_config=0x2 hash ch_mask0-1 0x20 0x40, bank_mask0-3 0x0 0x2400 0x44800 0x89000, rank_mask0 0x0 change to F1: 534MHz ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 change to F2: 1320MHz ch0 ttot8 ch1 ttot8 ch2 ttot8 ch3 ttot8 change to F3: 1968MHz ch0 ttot6 ch1 ttot6 ch2 ttot6 ch3 ttot6 change to F0: 2400MHz ch0 ttot7 ch1 ttot7 ch2 ttot7 ch3 ttot7 out U-Boot SPL board init U-Boot SPL 2017.09 (Oct 06 2026 - 02:21:44) "Synchronous Abort" handler, esr 0x96000010 ELR: 9cf8 LR: 9df0 ESR: 96000010 (ec=37) x 0: 0000000000052280 x 1: 00000000fd7c0000 x 2: 0000000000000001 x 3: 00000000000283b8 x 4: 00000000fd7c0000 x 5: 0000000000000001 x 6: 0000000000000005 x 7: 00000000fd7c0000 x 8: 0000000003f5fa4c x 9: 000000000000000c x10: 0000000000034ef8 x11: 0000000000000003 x12: 00000000000003f0 x13: 0000000000000000 x14: 0000000000034ef8 x15: 0000000003f5fa8c x16: 000000000000a49c x17: 0000000000000084 x18: 0000000003f5fe20 x19: 00000000fd7c0000 x20: 00000000000283b8 x21: 0000000000000001 x22: 0000000030a32c00 x23: 000000000bebc200 x24: 0000000000028c00 x25: 0000000003f5fc80 x26: 0000000000000001 x27: 0000000000023d33 x28: 00000000ff000000 x29: 0000000003f5fb00 Call trace: PC: [< 00009cf8 >] LR: [< 00009df0 >] Stack: [< 00009cf8 >] Copy info from "Call trace..." to a file(eg. dump.txt), and run command in your U-Boot project: ./scripts/stacktrace.sh dump.txt spl Resetting CPU ... ### ERROR ### Please RESET the board ### # Reset the board to bootrom # The failure occurs before the Linux kernel starts. What I've observed The DDR initialization appears to complete, including memory frequency transitions up to 2400 MHz. The behavior differs depending on the Armbian image: Current kernel image: stops after the U-Boot SPL banner. Vendor kernel image: reaches U-Boot SPL board init and then triggers a synchronous abort. The board previously booted Armbian, Ubuntu, and Android 12 successfully, so this is not a case where I have never been able to boot the board. Questions Could this indicate a corrupted or incompatible bootloader in SPI flash? Is it possible that the SPI flash contents have become corrupted or that the board is booting from an unexpected storage device? Could this be related to a mismatch between the DDR initialization firmware, U-Boot SPL, and the board's firmware version? What is the safest way to diagnose or recover the SPI flash bootloader without risking further damage? Are there any recommended steps to determine whether this is a bootloader issue, a storage issue, or a hardware problem? I would appreciate any suggestions, diagnostic procedures, or recovery instructions. Thank you!
October 12Oct 12 There are clearly two uboot versions in the log, so one is pulled from something else than sdcard which is the problem. either those or the underlaying ddr blobs don't like each other causing problems. rockchip socs have a fixed boot order which always begins with spi. if a boot loader is found there it will be used. it may not be obvious to the user because it passes basically just on to the next one. However this often causes problems.
October 12Oct 12 8 hours ago, Muiz Firmansyah said: But i don't use spi nor emcc, I only use sdcard. does that matter? As a test for yourself, you can power-on the SBC with no SD-card inserted. Then look if something is in UART serial console log. Also, you mention 2 Linux OSses worked, in general, you should have a backup of those, so with either of those you can wipe SPI (and eMMC). If you don't have a backup, you will need maskROM mode, so you need another cable and reading how that works for the OPi5Pro. Nothing magic, just time-consuming and no fun, but others (and yourself) can't guess what is programmed in the bare board. And what PSU you use, if that is OK or not and what SD-card, if that is OK or not and maybe also the USB-SD-card writer might be an issue, we have seen that on this forum for example, I still remember as that very well.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.