Muiz Firmansyah

But i don't use spi nor emcc, I only use sdcard. does that matter?

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!