My colleague and I are working on an university project that requires us to create a Linux based build system for BeagleBone AI-64 board. The created build system should be able to detect cameras connected to CSI/USB ports and displays connected to miniDP port. To confirm functionality we have to build a streaming application that collects video signal from camera and streams it directly to the display (with some effects, for example edge detection) using Video4Linux (V4L) and GStreamer.
To create the build system we used Buildroot, version 2024.05 with beagleboneai64_defconfig as our starting point for configuration. Then, we picked the latest kernel version (in this case it was Linux 6.8.12) with default defconfig and in-tree device tree source (dts) (k3-j721e-beagleboneai64.dts) for our kernel. Chosen bootloader is U-Boot, for init system we used systemd and lastly the toolchain we used is the one Buildroot creates. Then we proceeded to choose the packages and libraries for our application. We enabled GStreamer and some of it's plugins that were necessary for our application, V4L driver and some of it's tools (like v4l2grab) and dropbear for ssh connection.
So far we have tested our build system and it boots without problems on the board. We also tested our USB Camera which works fine with V4L, and we tested some GStreamer pipelines that we are going to use for our application. We confirmed these functionalities by saving the images/videos from camera to the file (filesink) and then copying it over to the host machine, and also by network connection with board and host using the udpsink to stream camera data to host display via UDP.
The problem began after we tried to connect the display to the board via miniDP. We used desktop monitor with miniDP to DP cable to establish the connection, but the connection failed. Display doesn't receive any signal from the board and it just goes to standby mode after few tries. We tried basically everything we could find on the internet. On the board we ran some test tools and commands like kmsprint, modetest and checked kernel logs with dmesg (I will display the results). We tried to check display status in /sys/class/card0-DP-1 and it was disconnected and disabled. Also we couldn't retrieve edid from that directory. From our research we definitely understood that DRM and tidss driver are responsible for connecting with the display, but we couldn't find any solution or something that we are missing. Since we are stuck with this for quite some time now, we hope that someone has an idea on how to fix this problem.
Here are some logs we got from the following commands. We looked at the kernel logs with dmesg and used grep dss to get information or drm and tidss driver. This was the output:
>> dmesg | grep dss
[ 0.040778] platform a000000.dp-bridge: Fixed dependency cycle(s) with /bus@100000/dss@4a00000
[ 0.041302] platform a000000.dp-bridge: Fixed dependency cycle(s) with /bus@100000/dss@4a00000
[ 0.041335] platform 4a00000.dss: Fixed dependency cycle(s) with /bus@100000/dp-bridge@a000000
[ 6.732895] [drm] Initialized tidss 1.0.0 20180215 for 4a00000.dss on minor 0
[ 6.740127] tidss 4a00000.dss: [drm] Cannot find any crtc or sizes
[ 6.746863] tidss 4a00000.dss: [drm] Cannot find any crtc or sizes
Obviously the last 2 lines are worrying, but we couldn't find anything useful online, or we didn't really understand what we were looking at. Then we tried to use libdrm tool modetest but everything failed:
>> modetest
trying to open device 'i915'...failed
trying to open device 'amdgpu'...failed
trying to open device 'radeon'...failed
trying to open device 'nouveau'...failed
trying to open device 'vmwgfx'...failed
trying to open device 'omapdrm'...failed
trying to open device 'exynos'...failed
trying to open device 'tilcdc'...failed
trying to open device 'msm'...failed
trying to open device 'sti'...failed
trying to open device 'tegra'...failed
trying to open device 'imx-drm'...failed
trying to open device 'rockchip'...failed
trying to open device 'atmel-hlcdc'...failed
trying to open device 'fsl-dcu-drm'...failed
trying to open device 'vc4'...failed
trying to open device 'virtio_gpu'...failed
trying to open device 'mediatek'...failed
trying to open device 'meson'...failed
trying to open device 'pl111'...failed
trying to open device 'stm'...failed
trying to open device 'sun4i-drm'...failed
trying to open device 'armada-drm'...failed
trying to open device 'komeda'...failed
trying to open device 'imx-dcss'...failed
trying to open device 'mxsfb-drm'...failed
trying to open device 'simpledrm'...failed
trying to open device 'imx-lcdif'...failed
trying to open device 'vkms'...failed
no device found
and also modetest -M tidss:
Encoders:
id crtc type possible crtcs possible clones
39 0 none 0x00000001 0x00000001
Connectors:
id encoder status name size (mm) modes encoders
40 0 disconnected DP-1 0x0 0 39
props:
1 EDID:
flags: immutable blob
blobs:
value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
5 link-status:
flags: enum
enums: Good=0 Bad=1
value: 0
6 non-desktop:
flags: immutable range
values: 0 1
value: 0
4 TILE:
flags: immutable blob
blobs:
value:
CRTCs:
id fb pos size
38 0 (0,0) (0x0)
#0 nan 0 0 0 0 0 0 0 0 0 flags: ; type:
props:
24 VRR_ENABLED:
flags: range
values: 0 1
value: 0
27 CTM:
flags: blob
blobs:
value:
28 GAMMA_LUT:
flags: blob
blobs:
value:
29 GAMMA_LUT_SIZE:
flags: immutable range
values: 0 4294967295
value: 256
Planes:
...
Also we tried to play something on with GStreamer pipeline hoping it will "awake" the display but it failed:
>> gst-launch-1.0 v4l2src ! jpegdec ! kmssink driver-name=tidss
Setting pipeline to PAUSED ...
ERROR: from element /GstPipeline:pipeline0/GstKMSSink:kmssink0: Could not get allowed GstCaps of device
Additional debug info:
../sys/kms/gstkmssink.c(1217): gst_kms_sink_start (): /GstPipeline:pipeline0/GstKMSSink:kmssink0:
driver does not provide mode settings configuration
ERROR: pipeline doesn't want to preroll.
ERROR: from element /GstPipeline:pipeline0/GstKMSSink:kmssink0: GStreamer error: state change failed and some element failed to post a proper error message with the reason for the failure.
Additional debug info:
../libs/gst/base/gstbasesink.c(5881): gst_base_sink_change_state (): /GstPipeline:pipeline0/GstKMSSink:kmssink0:
Failed to start
ERROR: pipeline doesn't want to preroll.
Failed to set pipeline to PAUSED.
Setting pipeline to NULL ...
Freeing pipeline ...
>> gst-launch-1.0 v4l2src ! jpegdec ! autovideosink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
WARNING: from element /GstPipeline:pipeline0/GstAutoVideoSink:autovideosink0: Could not initialise Xv output
Additional debug info:
../sys/xvimage/xvimagesink.c(1944): gst_xv_image_sink_open (): /GstXvImageSink:autovideosink0-actual-sink-xvimage:
Could not open display (null)
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:10.655685875
Setting pipeline to NULL ...
Freeing pipeline ...
Note: We confirmed that the display and the cable are working fine and can connect to the board when we boot the board with the system that comes on the eMMC card, so we discarded these as a potential problem.
We basically tried everything we could find on the internet. We tried to include many many graphics drivers and libraries from both buildroot config and kernel config but nothing changed. We suspected that device tree might be a problem (since our knowledge on writing and understanding device tree is pretty low) but we paid a lot of attention to this and the recommended dt-bindings. We really couldn't see what is missing in our device tree source to make the display work, and we even tried to replace our dtb with the dtb that is used on the system on eMMC card (which is working with the display) but still nothing happend. We checked in kernel configuration that DRM and tidss drivers are enabled, and as I said we tried to enable many different drivers and libraries for graphics but nothing worked so far.
Update: Unfortunately we haven't been able to solve the issue, but we "grepped" some new information that might be helpful (dmesg | grep dp)
[ 6.579043] cdns-mhdp8546 a000000.dp-bridge: invalid resource (null)
[ 6.586830] cdns-mhdp8546 a000000.dp-bridge: Failed to get SAPB memory resource, HDCP not supported
[ 6.597952] cdns-mhdp8546 a000000.dp-bridge: Direct firmware load for cadence/mhdp8546.bin failed with error -2
[ 6.609014] cdns-mhdp8546 a000000.dp-bridge: cdns_mhdp_fw_cb: No firmware.
So basically, the last update log I posted was the solution. We downloaded latest linux firmware (10.06.2024.) and copied mhdp8546.bin file from cadence folder to /lib/firmware/cadence folder in board root filesystem. After rebooting the display connected successfully. Also I'm pretty sure some configuration from kernel config such as ones droptop mentioned above have to be enabled (check for DRM, TIDSS and CADENCE_TORRENT configs).