Rock 5B Boot Loop

I’m currently experiencing a boot loop on the Rock 5B board. I’ve tried several USB power sources with no luck. I’m presuming that’s the problem. If so, I was wondering if it were possible to supply this board with power directly, not needing the USB C? I’m aware this would be at my own risk, but are there pads or pins that could be used to supply power? Otherwise, what specific rating am I looking for when finding an adequate USB C power source?

Just a side note, I was able to run the Rock 5B board for almost a week before this issue happened. It’s not clear to me why the board will no longer boot.

If I’m not mistaken - and I believe this is also how PoE hats do it - you can provide 5V directly to pins 2 and 4 on the GPIO header.

I bought the PSU on allnetchina and experienced system crashes, reboots, so on.
Once I understood the problem I bought a new higher class power supply, I opted for Ugreen 65W, perfect, no problem.

Applying 5V directly to headers does not work. Just in case anyone is wondering, it draws approximately 0.5A when applied, but still doesn’t boot.

I purchased the Ugreen 65W and tried that, no luck, still boot loops.

Either my board is bricked or I’m doing something wrong. I’ve done the following:

  1. Download and extract the Debian image (
  2. Load it onto my microSD card using balenaEtcher (verified)
  3. Install the microSD card.
  4. Apply power via the USB C port using the UGREEN 65W power source (
  5. I see the blue light go on. Shortly after I see the green light flash for maybe a second, then back to blue light.

What is going on?? How do I fix this?

Blue light is blinking when my board runs Debian or Ubuntu etc. I’m using it on sd card. So blue light means your linux is running, just try to reach over ssh if it answers to your ssh request then your problem might be hdmi cable or resolution.

Nothing over SSH, no device found on my router. It’s very clearly boot looping. I can watch my bench supply go through the exact same current profile over and over.

Is it possible the EEPROM somehow got corrupted? Is there a way to flash the EEPROM via a serial cable or something?

Read here Install the image to SPI Nor Flash

My suggestion is Pi Imager works better than Balena.
Also… get Samsung 45W Charger… so far no issues at all.

Well, I feel like I made some progress. I was able to hook up a serial to USB cable to the UART pins and boot ( Here’s what I saw:

DDR Version V1.08 20220617
LPDDR4X, 2112MHz
channel[0] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
channel[1] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
channel[2] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
channel[3] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
Manufacturer ID:0x6
CH0 RX Vref:27.7%, TX Vref:23.8%,23.8%
CH1 RX Vref:28.7%, TX Vref:23.8%,23.8%
CH2 RX Vref:29.7%, TX Vref:24.8%,24.8%
CH3 RX Vref:27.7%, TX Vref:23.8%,23.8%
change to F1: 528MHz
change to F2: 1068MHz
change to F3: 1560MHz
change to F0: 2112MHz
INFO:    Preloader serial: 2
NOTICE:  BL31: v2.3():v2.3-405-gb52c2eadd:derrick.huang
NOTICE:  BL31: Built : 11:23:47, Aug 15 2022
INFO:    spec: 0x1
INFO:    ext 32k is not valid
INFO:    GICv3 without legacy support detected.
INFO:    ARM GICv3 driver initialized in EL3
INFO:    system boots from cpu-hwid-0
INFO:    idle_st=0x21fdf, pd_st=0x11fff9, repair_st=0xfff70001
INFO:    dfs DDR fsp_params[0].freq_mhz= 2112MHz
INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
INFO:    dfs DDR fsp_params[3].freq_mhz= 1560MHz
INFO:    BL31: Initialising Exception Handling Framework
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9

Not sure what to make of this. I think this is the debian image (latest).

I also left the UART hooked up while trying to boot into maskrom mode, though I have no idea if there should be any output, nor whether the baud would be right (likely not 1.5Mb) but either way, I saw no output there.

I’m seeing the same here with the official Debian images…

@plasmaphase @kusma

  1. try using Armbian
  2. try a different SD card
  3. try various resetting methods, e.g: turn off and on using the button or by pulling the power adapter from the socket and plugging it again, etc.

Mmm… let me tell you my experiences.
I have no boot problems with official Ubuntu image, also with dedicated PD (a ugreen one 65W) and also with my laptop powered usb-c port, all well done.
I have boot problems with last Armbian image with both methods.
Something like a software problem? So strange…

Armbian: same problem
Different SD card: same problem
Various reset methods: same problem
Official Ubuntu image (assuming “official” means “the one from”): same problem

I was kind of expecting there to be some u-boot/firmware update I could try, as this device is straight out of the box as of yesterday… but I can’t really find anything.

Do you got the thunderbolt type c cable?
Also try do the spi flash to clear any boot issues.

Hello everyone,
I am having the same issue as @kusma and have tried different SD cards, the latest Radxa Ubuntu, Debian and Android images. Unfortunately my Rock 5B board is also stuck in a boot loop. Here is what I see with the status LEDs for the Debian image:

  1. supply power via USB-C (85W supply)
  2. green LED turns on for 2s
  3. blue LED turns on for 8s
  4. blue LEDs flashes once and turns off (green stays on)
  5. green LED turns off after 0.5s of blue flashing.
  6. repeat at step 2.

Any ideas what could be causing these issues and how to solve them?

Do the SPI flashing make sure your type c cables are 4k capable (thunderbolt).
If still happens then I suggest you the Samsung 45W which is the one that works for me or a more armbian stable image.