Rock 5B+ Power Supply over DP Alt Type-C Port?

#1

For context, I’m hoping to make a custom laptop using Rock 5B+. I want to expose the side with most of the IO ports on the side of the laptop. However, the power connector is on that side, so I can’t route the battery power through that.

What options are there for powering the Rock 5B+? I’m aware that you can supply >5V (e.g. 12V) into the USB Type-C power connector, without any special USB PD hardware. I’m also aware that you can give it a 5V supply over the GPIO pins, but the board can draw a lot of current, making connector and wire resistances problematic, especially if I’m using an NVME SSD. Would I be able to power the board with a similar voltage through the other USB Type-C port, the one with DP alt mode? Or is the power port the only one that supports >5V?

I’m also aware that the board has PoE pins, but those aren’t well-documented. If I understand correctly, that only accepts 5V anyway, making it worse than the GPIO pins. Am I wrong? Can I supply a higher voltage using those pins? If so, how?

#2

According to the schematic, I’m only seeing TYPEC_VIN on the USB-C connector (4 pins), the FUSB302 chip and the DC-DC converter. So maybe if you’re lucky you’ll be able to access the VBUS{1…4} pins behind the USB-C connector and solder there, but that sounds tricky (and risky as you don’t necessarily want to fry any device connected there).

#3

@willy can you help me understand where this is on the schematic? I’m looking at this file: https://dl.radxa.com/rock5/5b+/docs/hw/radxa_rock5bp_v1.2_schematic.pdf

Page 3, “block diagram”, shows only one USB-C port with a DCDC 5V. It is labeled “TYPEC0 With DP”, which is the one on the rear. No mention of the power-only front USB-C. It also says LPDDR4 RAM instead of LPDDR5, so I guess this is a copy-paste error from the 5B’s schematic.

Page 28, “Type-C port”, has a 24+8 pin (32!) USB-C port (J11) that’s connected to VBUS_TYPEC0 and CC1/CC2.

Page 33, “Power Type-C in” shows the front USB-C port connected to TYPEC_POW1, which in turn is connected to a USB-PD negotiation chip (CH224D) and a power distribution chip (WS4684C) that turns it into TYPEC_VIN.

Page 32, “Power DC 5V”, shows two DC-DC convertors (MP8759), one accepting TYPEC_VIN to produce VCC5V0_SYS and another to step that down further to VCC4V0_SYS.

VBUS_TYPEC0 from the rear port isn’t handled by these DC-DC convertors. Instead, back on page 28 there are three consumers:

  1. FPF2595UCX chip connected to VBUS_TYPEC0 (VONT) and VCC5V0_SYS (VIN). “VONT” seems to be a typo for “VOUT”. One source describes this chip as “advanced load-management switch [that] targets applications requiring a highly integrated solution. It disconnects loads powered from the DC power rail.”
  2. FUSB302BMPX chip that’s also between VBUS_TYPEC0 and VCC5V0_SYS. This one appears to be a “programmable USB Type-C controller w/PD”.
  3. WS4684C chip that’s connected to all of TYPEC_VIN, VBUS_TYPEC0 and TYPEC_POW1 (why?). This one appears to be a power source switch.

Asking because I tried a USB-C PD input on the rear port and it negotiated 12V. The system voltages reported in /sys/devices/iio_sysfs_trigger/subsystem/devices/iio:device0/in_voltage?_raw also remain identical when powering from either front or rear, either 12V PD or 5V raw, except for number 6 (USB-C power, front) and 7 (USB-C DP, rear), which reflect the voltage source. Which means one of these three chips is somehow responsible for processing the 12V on the rear USB-C port.

  1. FPF2595UCX also has a signal pin named TYPEC5V_PWREN_H (judging from the >> marker). I think this means it will connect VBUS_TYPEC0 to VCC5V0_SYS if something elsewhere certifies it as safe voltage. TYPEC5V_PWREN_H is an output from RK3588_H VCCIO3 Domain. If so, it’s probably not the step-down regulator.

  2. FUSB302BMPX as per its datasheet has no voltage regulator. It needs regulated input instead (VCC5V0_SYS -> VCONN).

  3. Which leaves us with the WS4684C that’s connected to all three raw power sources. I guess this one is responsible for connecting VBUS_TYPEC0 (in) to TYPEC_VIN (out) if TYPEC_POW1 has no voltage (judging by the 100k resistor on TYPEC_POW1)?

If I have understood this correctly, it’s safe to supply any acceptable voltage on either of the USB-C ports. The only difference is the front port is power-only with a hardware-controlled PD negotiator, while the rear port has software-controlled PD.

(There are also two GPIO named SARADC_VIN6_dcin and SARADC_VIN7_dcin connected to the front and rear ports that seem to be mislabeled as inputs instead of outputs. I guess these are the sources for the in_voltage[67]_raw values.)

#4

I’m now confused as well by seeing VCC5V0_SYS often very close to VBUS_TYPEC0, I don’t know if they are ever connected in reverse or if it’s only used to send 5V to USB-C. However you can see on page 32 that TYPEC_VIN enters the MP8759 DC-DC through a 5A fuse (FB60R_5A), so this one should be easy to locate to solder a thick wire and inject the power directly into it. Or maybe you could even remove the fuse and inject the power into the chip so as never to send TYPEC_VIN to the USB-C chip. This would be even cleaner! I think the board is designed under the assumption that the USB-C port is used for power and that there’s no issue with having it run at a high voltage since the only high voltage present on the board may come from this port by definition. But I personally wouldn’t like to have a USB-C female port exposing 12V by default!

#5

I ran a few more tests:

  1. Both USB-C ports negotiate PD 3.0 12V 3A (36W) with a USB-PD charger.
  2. The front port does not output power.
  3. The rear port offers PD 3.0 5V 3A (15W) to devices. It does not offer anything more. When the front port has 5V input (actual 5.3V from a dumb source), the measured output on the rear is a clean 5.0V. When the front is 12V via PD, the rear ticks up slightly to 5.17V.

These voltage readings are also available from /sys/devices. Here’s a little script and the output (using two raw-to-mV conversions):

for FILE in /sys/devices/iio_sysfs_trigger/subsystem/devices/iio\:device0/in_voltage?_raw; do
  VALUE=$(<"$FILE")
  printf "| %s | %s | %s | %1.f |\n"\
    "$(basename "$FILE")"\
    "$VALUE" "$(( $VALUE * 100000 / 17245 ))"\
    "$(( $VALUE * $(<$(dirname "$FILE")/in_voltage_scale) ))"
done

Powered from the rear with a raw 5V source (actual about 5.3V on a multimeter). The numbers in bold are the conversion formula that appears to be correct:

File Value mV val/172.45 mV val*in_voltage_scale
in_voltage0_raw 4074 23624 1790
in_voltage1_raw 4089 23711 1797
in_voltage2_raw 23 133 10
in_voltage3_raw 1 5 0
in_voltage4_raw 4088 23705 1796
in_voltage5_raw 4085 23688 1795
in_voltage6_raw 5 28 2
in_voltage7_raw 917 5317 403

Powered from the front with the same 5V source, with a USB PD probe (FNIRSI FNB58) on the rear:

File Value mV val/172.45 mV val*in_voltage_scale
in_voltage0_raw 4076 23635 1791
in_voltage1_raw 4090 23717 1797
in_voltage2_raw 23 133 10
in_voltage3_raw 3 17 1
in_voltage4_raw 4090 23717 1797
in_voltage5_raw 4084 23682 1795
in_voltage6_raw 914 5300 402
in_voltage7_raw 877 5085 385

12V USB PD 3.0 input on the front and a USB PD probe (FNIRSI FNB58) on the rear:

File Value mV val/172.45 mV val*in_voltage_scale
in_voltage0_raw 4076 23635 1791
in_voltage1_raw 4090 23717 1797
in_voltage2_raw 23 133 10
in_voltage3_raw 2 11 1
in_voltage4_raw 4088 23705 1796
in_voltage5_raw 4084 23682 1795
in_voltage6_raw 2083 12078 915
in_voltage7_raw 893 5178 392

I don’t understand the numbers for 0-5. They seem to reflect a 1.8V bus, but the schematic doesn’t indicate what they’re connected to. Input 0 is named “boot” and is shown connected to a “key” (page 12), which on the PCB is the recovery button. However, that button is actually input 1, which dropped from 1.8V to 0V when the recovery button was pressed. Maybe 0 is the boot button? I pressed it and it triggered a shutdown before I could get a voltage reading.

Input 4 is marked as connected to GPIO pin 22 (SARADC IN 4), but how does it have 1.8V if there’s nothing connected to that header? Schematic doesn’t show where it’s getting that voltage from. The other sources 2, 3 and 5 are also unknown.