Radxa 5C Boot Issue

I just bought a Radxa ROCK 5C SBC, flashed “Debian 12 KDE b1” OS from the Radxa 5C docs to a few microSD cards. But, when I connect it to a monitor via HDMI there’s no display, I don’t think the OS is booting on the 5C either (I only see the green light and no blue light). How can I get it to work??

(Tried at least 10 different HDMI cables, monitors & microSD cards - nothing works)

That is almost 10 too much. Instead you and others would benefit from a USB serial console/debug adapter cable that can observe the boot process. You can post the output text here on the forum.

See:

I have the same problem. Could you tell me if you have found a solution and what methods are available?

@Varun_Kuntoor @Daniel_Wu

@radrocks is right that a serial console is the next step. Before you get there, though, your LEDs have already told you something useful, and there are two things worth knowing when you wire that adapter up.

What “green on, blue off” means

From the ROCK 5C V2.10 schematic (sheet 20), the two LEDs are wired completely differently:

  • Green (LED1): VCC_3V3_S3 -> R257 4.7k -> LED1 -> GND. It lights as soon as the PMIC brings up the 3.3 V S3 rail. No software is involved. The SoC GPIO POWER_LED joins the same node through R258 2.2k, and its job is to pull the node down and turn the LED off.
  • Blue (LED2): IO_LED -> R259 200R -> LED2 -> GND, where IO_LED is an RK3588S GPIO (sheet 11). It only lights once software drives that pin.

So green on, blue off means your board is powered, the PMIC started correctly, and the failure is somewhere later in the boot. That also means swapping HDMI cables, monitors and microSD cards cannot narrow it down any further, which matches your experience of ten of each changing nothing.

(Reference designators differ between board revisions, so use the schematic that matches your board: Resource Download | Radxa Docs)

Wiring the console: the signal names are from the board’s point of view

This trips up almost everyone, so to be explicit: a UART is always crossed. One side’s TX goes to the other side’s RX. The names on the pinout are what the board does, not what you plug in.

wire board side adapter side what it is for
1 pin 8, UART2_TX_M0 (board transmits) adapter RX reading the boot log
2 pin 6, GND adapter GND always needed, never crossed
3 pin 10, UART2_RX_M0 (board receives) adapter TX typing into U-Boot only

So pin 8 does not go to your adapter’s TX, even though both are labelled TX. If you see nothing at all in your terminal, TX-to-TX is the first thing to check.

Settings are 1500000 8N1. Also make sure your adapter is set to 3.3 V logic, not 5 V. The 40-pin header is 3.3 V. Adapters with a voltage jumper are easy to leave in the wrong position.

Start with two wires, not three

Connect only wire 1 and wire 2 above, and leave wire 3 (adapter TX to pin 10) off. You still get the complete boot log, because the log travels board → PC over wire 1. The only thing you lose is the ability to type into U-Boot, which you do not need for a first look.

The reason I suggest this: on my ROCK 5C, if the adapter’s TX is connected to pin 10 when I apply power, the board does not start at all and the green LED does not even light. Remove that one wire and it boots every time, reproducibly.

A plausible explanation from the schematic: pins 8 and 10 are in the PMUIO domain (sheet 5, VCC_3V3_PMU), not in the general VCCIO domains like most header pins, and the only thing between the header pin and the SoC is R168, a 100 ohm series resistor. The ESD parts there (D27/D28, BTR04G02) are bidirectional TVS to GND, so they do not clamp to the rail. Driving 3.3 V into pin 10 while the board is unpowered therefore pushes roughly (3.3 - 0.7) / 100 = 26 mA into VCC_3V3_PMU through the SoC’s internal ESD clamp, pre-biasing an always-on PMU rail before the PMIC sequences. I have not confirmed that with a current measurement yet, so treat the mechanism as a hypothesis. The observation itself is solid and repeatable.

Either way, starting with two wires costs nothing and rules it out.

Once you have a boot log, post it here. Where it stops will say a lot more than any LED can.