ROCK 5B Debug Party Invitation

Just for the record: @stuartiannaylor you personally contributed to this. Here in this ‘debug party’ by talking about your ‘90W PD’ not working. Also in some hidden communication channels others claimed the same.

Here where discussion should happen some participants of the ‘debug party’ (that is there to launch a product hopefully soon) discovered that there are problems with USB-C PD compliant chargers related to OS release. So if it’s about a ‘blocking issue’ that gets spread it would help if such claims can be verified.

Asides that your or mine opinions (I also prefer barrel plug with wide-range input instead of USB-C) really don’t matter much in the context of some ‘debug party’. While it’s great that Radxa gets so much free quality advise from you and e.g. from the Armbian guys where the TL;DR version is obviously ‘Radxa should neither use Rockchip reference designs nor Rockchip software!’ it certainly doesn’t help launching this product.

Thank you for clarification :slight_smile:

But it also highlights why this ‘debug party’ isn’t one. Since majority of relevant communication happens somewhere else so participants here just waste their time.

The next time Radxa starts something like this they really should try to learn from e.g. Hardkernel.

There is only you who has had the problem Radxa participate in all comms channels and they have the info they need.

I read about the updated DTB’s here and also the new revision and it has been said that Discord is merely for social chat, but there is only you that seems to have problems or believes a majority of communication happens elsewhere as it does not.

Section 6.3.13 in the PD spec (2.0 since we’re dealing with that class of hardware) claims a soft reset request can be used to recover the protocol layers without changing any negotiated voltages. Obviously none of these drivers are truly behaving this way. I believe this was the attempt made on the mainline driver for the ROC-PC. That can of course be revisited. It’s likely some supplies simply don’t honor that and go full reset anyway.

It could be better if we enable fusb302b in uboot, but maybe we still need more capacitors to make USB/pcie peripherals to keep power on during boot.

We are still troubleshooting this issue now, this need to dive deep into the PD protocol and state machine. To solve current issue, we will have to negotiate voltage in u-boot for sure, I can understand @Tonymac32 's pain but I think this is a whole eco-system issue. Someone should push this anyway. I think we are close to that.


No. The power loss is because of communication issue, so we should fix it. It seems we should set the i2c clock to fusb302 to 1Mhz to avoid the packet loss.


So the normal power mode switch speed is fast enough for not causing power loss during switching but PD hard reset still causes this?

My oldest 5V SBC power brick with A-to-C cable:

in0:           5.00 V  (min =  +5.00 V, max =  +5.00 V)
curr1:         0.00 A  (max =  +0.00 A)

in_voltage0_raw: 4081
in_voltage1_raw: 4093
in_voltage2_raw: 3275
in_voltage3_raw: 4
in_voltage4_raw: 4089
in_voltage5_raw: 3237
in_voltage6_raw: 888  -> 888 / 175 = 5.07
in_voltage7_raw: 1724

RPi USB-C power brick:

in0:           5.00 V  (min =  +5.00 V, max =  +5.00 V)
curr1:         3.00 A  (max =  +3.00 A)

in_voltage0_raw: 4082
in_voltage1_raw: 4092
in_voltage2_raw: 3042
in_voltage3_raw: 4
in_voltage4_raw: 4092
in_voltage5_raw: 2435
in_voltage6_raw: 927  -> 927 / 175 = 5.3
in_voltage7_raw: 1169

Apple 96W charger:

in0:           9.00 V  (min =  +9.00 V, max =  +9.00 V)
curr1:         3.00 A  (max =  +3.00 A)

in_voltage0_raw: 4080
in_voltage1_raw: 4093
in_voltage2_raw: 3282
in_voltage3_raw: 4
in_voltage4_raw: 4088
in_voltage5_raw: 3238
in_voltage6_raw: 1565 -> 1565 / 175 = 8.94
in_voltage7_raw: 1988

24W charger with default DT (maxing out at 12V):

in0:          12.00 V  (min = +12.00 V, max = +12.00 V)
curr1:         1.50 A  (max =  +1.50 A)

in_voltage0_raw: 4080
in_voltage1_raw: 4094
in_voltage2_raw: 3283
in_voltage3_raw: 3194
in_voltage4_raw: 4094
in_voltage5_raw: 3227
in_voltage6_raw: 2096 -> 2096 / 175 = 11.98
in_voltage7_raw: 2376

24W charger with adjusted sink-pdos DT entries:

in0:          15.00 V  (min = +15.00 V, max = +15.00 V)
curr1:         1.60 A  (max =  +1.60 A)

in_voltage0_raw: 4080
in_voltage1_raw: 4090
in_voltage2_raw: 3277
in_voltage3_raw: 6
in_voltage4_raw: 4088
in_voltage5_raw: 3234
in_voltage6_raw: 2625 -> 2625 / 175 = 15
in_voltage7_raw: 2418

The 175 divider I just pulled out of nowhere…

From the schematic. The other appear to be board rev/etc

The others are described on page 15 of the schematic.

Since not being an EE or having any clues of hardware… is the 175 divider ok or not?

saradc is 1.8v so 12 bit FFF (4095) I guess.

35e to decimal = 862 / 4095 * 1.8 = .378

The resistor network is just the ratio of the total so 8.2k1/ 108.2k1
According to that
888 = 5.150v
927 = 5.376
1565 = 9.07
2096 = 12.156
2625 = 15.225

172.5 is closer. As Stuart pointed out, it’s a voltage divider. An easy reference though is that 20V is advertised as D79 hex, 3449 decimal. 3449/20V = 172.45

SarADC are often not that accurate and the errors can be non linear where sometimes in code there is an error correction table but prob not required here as its just sensing the approx input voltage.
Anyone measured the USB 5v when feeding with the 5v power sources, as guess this is just for interest?

Not with anything I would consider calibrated. I did just pick up a benchtop supply, so if I can get the power to a type C I can do a sweep and see. I don’t think it’s critical either though.

It doesn’t really as the second buck drives the further power domains from the 5.14 or whatever output the 1st gives.
Think its just usb 5v and fan / gpio vcc that take from that line and after the buck with inefficiencies guessing it could drop below 5v and not sure at what point the input needs to be to keep in USB spec with load.

Thanks for the feedback, Jack. As long as it is being looked at seriously, I have no complaints. I think the I2C clock at 1 MHz may be a bit of a risk on it’s own, I believe this is the absolute maximum frequency of the fusb302. I assume then this is running a default 400 khz now? I assume you’ll be changing to a bit stronger pullup than the 10k?

1 Like

I hope very much that they change the pull-up resistors. 10k is usually fine for 100kHz but will not work at 1MHz. The input capacitance of the fusb302 is specified with 50pF. If we double this to 100pF to account for PCB capacitance and the output capacitance of the RK3588 we have a Tau of the signal of 1us. Usually the Tau should at least be 4 times smaller than the target frequency so instead of using 10k resistors <2.5k are required for 1MHz operation (they should just use 1k ones to be safe).
Even 400kHz is borderline with 10k pull ups…

Regarding the measured VIN6 voltage, you should be able to calculate it by multiplying the raw LSB value with 0.0058V/LSB --> (1.8V/4095)*((100k+8.2k)/8.2k)
Fyi, 1/0.0058 = 172.41


I received the board this afternoon. I am running Ubuntu 20.04.4 LTS here (CLI).
I tried to encode and decode some files but failed. did anyone get this working?

Failed with:

[  999.117152] rk_vcodec: mpp_collect_msgs:1476: session 0 process cmd 100 ret -22
[  999.117198] rk_vcodec: mpp_dev_ioctl:1587: collect msgs failed -22
[ 1033.754919] rk_vcodec: mpp_collect_msgs:1476: session 0 process cmd 100 ret -22
[ 1033.754948] rk_vcodec: mpp_dev_ioctl:1587: collect msgs failed -22

SDL2 didn’t work properly either, but opengles is working perfectly with gbm.
Version: 2.23.1

Update: There is a fix for this error that i missed, but still not working.

SDL version 2.0.20 works with minor help:

DEBUG: /dev/dri/card0 connector, encoder and CRTC counts are: 2 3 4
DEBUG: /dev/dri/card0 connector, encoder and CRTC counts are: 2 3 4
DEBUG: Opening device /dev/dri/card0
DEBUG: Opened DRM FD (5)
DEBUG: Failed loading udev_device_get_action: /usr/local/lib/ undefined symbol: _udev_device_get_action
DEBUG: Failed loading eglGetPlatformDisplayEXT: /usr/lib/aarch64-linux-gnu/mali/ undefined symbol: _eglGetPlatformDispl
DEBUG: Failed loading _eglGetPlatformDisplayEXT: /usr/lib/aarch64-linux-gnu/mali/ undefined symbol: __eglGetPlatformDis
arm_release_ver of this libmali is 'g6p0-01eac0', rk_so_ver is '5'.
DEBUG: Could not hide current cursor with drmModeSetCursor().
DEBUG: Failed to set DRM cursor.
DEBUG: That operation is not supported
INFO: Screen bpp: 32
INFO: Vendor     : ARM
INFO: Renderer   : Mali-LODX
INFO: Version    : OpenGL ES 3.2 v1.g6p0-01eac0.3b670429c215b5ca848ad5d6b11ce5bc
INFO: Extensions : GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth24 GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_EXT_read_format_bgra GL_OES_compressed_paletted_texture GL_OES_compressed_ETC1_RGB8_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_EGL_sync GL_OES_texture_npot GL_OES_vertex_half_float GL_OES_required_internalformat GL_OES_vertex_array_object GL_OES_mapbuffer GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_type_2_10_10_10_REV GL_OES_fbo_render_mipmap GL_OES_element_index_uint GL_EXT_shadow_samplers GL_OES_texture_compression_astc GL_KHR_texture_compression_astc_ldr GL_KHR_texture_compression_astc_hdr GL_KHR_texture_compression_astc_sliced_3d GL_EXT_texture_compression_astc_decode_mode GL_EXT_texture_compression_astc_decode_mode_rgb9e5 GL_KHR_debug GL_EXT_occlusion_query_boolean GL_EXT_disjoint_timer_query GL_EXT_blend_minmax GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_OES_texture_3D GL_EXT_texture_storage GL_EXT_multisampled_render_to_texture GL_EXT_multisampled_render_to_texture2 GL_OES_surfaceless_context GL_OES_texture_stencil8 GL_EXT_shader_pixel_local_storage GL_ARM_shader_framebuffer_fetch GL_ARM_shader_framebuffer_fetch_depth_stencil GL_ARM_mali_program_binary GL_EXT_sRGB GL_EXT_sRGB_write_control GL_EXT_texture_sRGB_decode GL_EXT_texture_sRGB_R8 GL_EXT_texture_sRGB_RG8 GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_OES_texture_storage_multisample_2d_array GL_OES_shader_image_atomic GL_EXT_robustness GL_EXT_draw_buffers_indexed GL_OES_draw_buffers_indexed GL_EXT_texture_border_clamp GL_OES_texture_border_clamp GL_EXT_texture_cube_map_array GL_OES_texture_cube_map_array GL_OES_sample_variables GL_OES_sample_shading GL_OES_shader_multisample_interpolation GL_EXT_shader_io_blocks GL_OES_shader_io_blocks GL_EXT_tessellation_shader GL_OES_tessellation_shader GL_EXT_primitive_bounding_box GL_OES_primitive_bounding_box GL_EXT_geometry_shader GL_OES_geometry_shader GL_ANDROID_extension_pack_es31a GL_EXT_gpu_shader5 GL_OES_gpu_shader5 GL_EXT_texture_buffer GL_OES_texture_buffer GL_EXT_copy_image GL_OES_copy_image GL_EXT_shader_non_constant_global_initializers GL_EXT_color_buffer_half_float GL_EXT_unpack_subimage GL_EXT_color_buffer_float GL_EXT_float_blend GL_EXT_YUV_target GL_OVR_multiview GL_OVR_multiview2 GL_OVR_multiview_multisampled_render_to_texture GL_KHR_robustness GL_KHR_robust_buffer_access_behavior GL_EXT_draw_elements_base_vertex GL_OES_draw_elements_base_vertex GL_EXT_buffer_storage GL_EXT_texture_filter_anisotropic GL_OES_texture_float_linear GL_ARM_texture_unnormalized_coordinates GL_EXT_shader_framebuffer_fetch 
INFO: SDL_GL_RED_SIZE: requested 5, got 8
INFO: SDL_GL_GREEN_SIZE: requested 5, got 8
INFO: SDL_GL_BLUE_SIZE: requested 5, got 8
INFO: SDL_GL_DEPTH_SIZE: requested 16, got 24
DEBUG: New DRM FB (208): 1920x1080, stride 7680 from BO 0x558d5eb180
DEBUG: New DRM FB (252): 1920x1080, stride 7680 from BO 0x558d648240
DEBUG: New DRM FB (253): 1920x1080, stride 7680 from BO 0x558d566840
DEBUG: drmModeMoveCursor() failed.
INFO: 60.00 frames per second
DEBUG: Could not hide current cursor with drmModeSetCursor().
DEBUG: Delete DRM FB 253
DEBUG: Delete DRM FB 208
DEBUG: Delete DRM FB 252

Hi. Can somebody check if there is any working Vulkan driver on rock 5b on Debian or Android 12 at least?