Connecting display on BeagleBone AI-64 miniDP is not working

General Discussion
1

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.

2

I have not used the video on the ai-64. From your comment is it safe to assume your hardware is 100% functional when using the default factory image?

If that is the case you are in pretty good shape, someplace in BB space is a build script for building the images. I would look that over and look for patches. Also keep in mind you are using 6.8 kernel I would back peddle to the same kernel version that is used for the known working image. This might be your only sane solution unless you have MANY hours to burn trying to fix some of the issues.

This is all theoretical solutions, not first hand fact so keep that in mind.

3

Yes, with factory image the board boots and display turns on without any problems.

I have found the repository of the kernel used for the factory board, and we tried to copy graphics and bus driver configuration of that kernel to our buildroot kernel configuration but it didn’t work. I guess we might try to build and use that kernel, but we tried to stick to some build system such as buildroot/yocto for the sake of project (as it’s kinda easier to show the configuration and tools used when we get to the project presentation point). We will try this soon. Thank you for your answer, we are just looking for any ideas and solutions since we are running out of ours. :slight_smile:

4

Your best option is a yocto build if you need it customized.

Pretty sure if you back peddle to the same kernel version as the working image you will have good results. Kernel modules are compiled with the headers of kernel version used, so that takes you in direction of complete overhaul.

This stuff changes like the wind, so it is better sometimes to use the old and proven methods and focus on your task at hand. Get your project to the point of a functional prototype using the factory image.

At one time we had the AI-64 up and running using the weston compositor, pretty sure it was kirkstone. Went back a few months later and made another image and it would not boot using the fresh image, well ai64 has been on the shelf since. Way too much time burned up, not sure why Ti stuff is so difficult to work with. I also use competitive SoC and their BSP is set up much better.

If you try out yocto it would be best to use kirkstone, scarthgap is working for the BBB but that board is not nearly as complex as the AI-64. If you get stuck on yocto post what is wrong along with your layers, distro, machine, etc and enough that I can lite it up here. I will try to recreate what you are doing and my time limit will be 1 hour. I will give it that much time, if not able to get it running I will drop it.

If you decide on yocto do it exactly as the getting started docs on the yocto site recommend. That is the only correct method. It is important that it builds successfully the first time out the of the gate. Also, keep in mind you might have to go into u-boot and wipe out some of the boot loader mmc so it will force a total boot from SD card. This is due to u-boot args that are changing between versions.

5

Thank you very much for your time. My colleague will try to backpedal the kernel version in buildroot together with other settings and we will try with that. I’m also building the kernel that is supposed to be the factory one and we will try that one also. If nothing works I guess we will try to create our build system with yocto, but it may take more time since we are pretty inexperienced and it seems way more complex than buildroot (we had only one lab exercise with yocto in this course, more like introduction :slight_smile: ). The deadline for the project is also approaching (at least to get the grade), but even if we have to hand over the project unfinished we will ask our professor to keep the board and try it for ourselves, since we are really interested in the project. Thanks once again, I guess I will be back with progress information, if any :slight_smile:

6

Once you get it dialed in it is an extremely powerful tool. I struggle constantly with it, if I used it everyday it would be much different. If you can validate that the hardware will perform as needed for the application, at that point it might be better to hire someone to do the yocto. Once it is setup it is fairly easy to add and remove packages.

7

Hello…I do not search the kernel much these days but.

  1. I see what you are working towards with displays on Buildroot and/or Yocto. The example DTS in the link you provided seems reasonable for starting.

  2. You may have to review each, separate TDA4VM offset with corresponding address for your purpose.

  3. Also, I found a few links that may provide some background:

a. frame-buffer.rst « driver-api « Documentation - kernel/git/stable/linux.git - Linux kernel stable tree

b. And then whatever else it takes to make it work, e.g. if sound is needed and/or if there is a particular chipset on the TDA4VM suited just for booting into graphics and so on…

c. I am sure I am just reviewing or annoying you here. So, I am keeping it short.

Seth

P.S. Um, if this is a project or for income, I implore you to keep it up and report findings. You and your friends or coworkers are not the only viable resource and things get expensive (quickly). I am not even saying I can help. I just want to be left to wither while helping for now. So, all I can do is try.

Update

Also…I found that this whole idea around firmware is just that it can be self-produced for specific chips.

Now, do I know if the rproc subsystem is small enough to fit in the built-in, self-produced firmware that the TDA4VM is using to boot graphics? No. I cannot say that is a fact. How would I find out…? No clue.

But…if you can build a specific firmware for booting graphics like with some Linux Distro or Buildroot or whatever and find the cure, good on you. It seems to take more than just the regular TDA4VM system manuals for it. I mean, mix that in with POSIX systems and a few know everything.

Anyway, the reason for this update is to know of the display island to just handle Graphics. I know the VR Rogue is around too. I am not sure if you are wanting graphics or just a userspace use case where someone can type into a TDA4VM to handle their task or not.

So, in hindsight, as I am steadily learning what others like in time, I am also learning a bit. Annoying yes but very rich in data as I am seeing more and more. I am a 100% into learning while taking on tasks that I may never be able to handle by myself…

So, with a graphics driver (Rogue in this case), it may be years before it gets Open Sourced if it ever does get a GPL license. Of course, I do not know what, if any, Rogues you will be using. So, maybe there is a way to get to the fb and by way of less coprocessors. Oh and I did say links and not link.

Here: lp855x-driver.rst « backlight « driver-api « Documentation - kernel/git/stable/linux.git - Linux kernel stable tree is another driver type either for a small screen or large screen. There are the basics of what I could put together quickly. If that is garbage to you, say so and I will leave you in peace…

As I keep reading about my conversation to myself here, I have noticed that the mDP/DP license may be in fact an Open Source license of sorts. Hmm. I wonder…

I cannot contact them as I do not have any business with them. Hence, I may never know. Anyway, lengthy and boring here…up, up, and away.

8

Hello again everyone. Glad to say I am back with the solution :slight_smile:
In the end we tried many different solutions, built many different kernels (earlier versions) and many stuff everyone mentioned above but nothing gave results. Today we tried to check some more kernel logs with dmesg and luckily we found something that opened the path for our solution. We used dmesg | grep dp, and caught the following output of interest:

[    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.

After this we understood that our dp bridge driver was not working at all the entire time because of the missing firmware blob resulting in inability of the rest graphics drivers to detect and use our display connected to the miniDP. Then we proceeded to download the latest linux firmware (10.06.2024.) from which we copied mhdp8546.bin file located in cadence folder to /lib/firmware/cadence folder of our root filesystem on the board (of course making this as an overlay in buildroot is the right method which we did after we confirmed the solution). After rebooting the board, our display worked fine :smiley:

I would like to mention that besides this (if anyone stumbles on such a problem and looks for this solution) you most likely need to enable kernel configurations for DRM, TIDSS and CADENCE (CONFIG_DRM, CONFIG_DRM_TIDSS, CONFIG_DRM_CDNS_MHDP8546, CONFIG_DRM_CDNS_MHDP8546_J721E, CONFIG_DRM_DISPLAY_CONNECTOR, CONFIG_PHY_CADENCE_TORRENT and configs like these if I missed some). I think some of these are not enabled by default in buildroot generated linux so take care.

2 Likes