Aquila AM69 and the DSI-to-HDMI adapter

Technical Support
, ,
21

Can you tell me what your base device tree is?

I’m using the exact same device tree you are. I only have the V1.0 module available to me anyways. So this is not a factor either.

I really don’t know what else could be the issue on your setup. I can guarantee the software is good and works, even had a colleague verify it as a sanity check on their setup.

If the software is not an issue then that really only leave the physical hardware setup as a potential difference. But It’s hard to say what exactly since I don’t have any issue on my setup to investigate. Meanwhile, nothing in your setup is jumping out as an obvious issue to me.

Best Regards,
Jeremias

22

We’ve done tons of testing. Lots of solutions (like adding an i2c mux to the dev board) look like they’re working, but nothing on the display.

I’m trying to rule out if our DSI-to-HDMI adapter itself could be not functioning (damaged, etc).

I’ve swapped it on to the verdin dev board, and it will not run weston on our known good working OS build that uses native HDMI (the native works, but not through the adapter).

I’ve verified it has the dsi adapter overlay enabled. I’ve also thown tezi 7.3.0 on there, and it will use the native hdmi, but nothing displays through the adapter.

Can you confirm for me if tezi will display through the adapter on the verdin dev board? If it should, then I think we’ve identified that maybe our adapter board is broken.

23

Can you confirm for me if tezi will display through the adapter on the verdin dev board? If it should, then I think we’ve identified that maybe our adapter board is broken.

I just checked and can confirm that when I have Toradex Easy Installer running on the Verdin i.MX8M Plus, I get video output from both the native HDMI, and DSI to HDMI interfaces by default. Therefore it does sound like there is something wrong with your adapter hardware.

Best Regards,
Jeremias

24

Awesome! Maybe this means I’m not crazy. 2 more incoming from mouser should be here tomorrow for subsequent testing (both with the i2c mux and the split bus workaround you have working).

25

At least that explains the discrepancy in our results. Hope you are able to get something going once the new hardware arrives.

Best Regards,
Jeremias

26

With one of the new boards, we can get it working on the verdin.

It looks like everything is good with that same board on the aquila dev board (using our i2c mux, and stock overlay that expects a mux there). The EDID probes perfectly. I2C detect seems to show what’s necessary as well.

Still no display. Many cables/monitors tried.

Then I started running debug ops through claude, who is now convinced that the issue is the cdns driver is loaded too late, and the fix is to just add that as built in on the kernel config options. I haven’t tried that yet.

We also saw no lanes registered, so we modified the stock overlay to put them in:

dsi0_out: endpoint {
    data-lanes = <1 2 3 4>;
    remote-endpoint = <&lt8912_1_in>;
};

But what was found basically boils down to no DSI to the lt8912 (dsi clock is zero). The bridge operations don’t register.

I have little faith in AI debugging this stuff, however. This could all be convincing nonsense. I’m a much higher level software guy, so I can’t personally tell. I’ll attach the report if you want to look.

cdns_debug_report.md (11.5 KB)

I may reconfigure next to do the split i2c bus that you said was working for you, and see if that’ll work for me.

27

So I just tried the test OS you sent me that was working for you (after removing the i2c mux and installing jumpers). Still the same:

**torizon@aquila-am69-12593476**:**\~**$ sudo cat /sys/kernel/debug/clk/clk_summary | grep -iE "dss|dsi|vp" clk:218:18                       0       0        0        600000000   0          0     50000      Y      4a00000.dss                     vp4clk:218:14                       1       1        0        148500000   0          0     50000      Y      4a00000.dss                     vp3clk:218:5                        0       0        0        600000000   0          0     50000      Y      4a00000.dss                     vp2clk:218:2                        0       0        0        594000000   0          0     50000      Y      4a00000.dss                     vp1clk:218:0                           1       1        0        600000000   0          0     50000      Y   4a00000.dss                     fckclk:215:5                           1       1        0        250000000   0          0     50000      Y   4800000.dsi                     dsi_sys_clkclk:215:2                           1       1        0        0           0          0     50000      Y   4800000.dsi                     dsi_p_clk

Seems no dsi clock, but i2c looks fine now:

torizon@aquila-am69-12593476:~$ i2cdetect -y -r 4
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         – – – – – – – –
10: – – – – – – – – – – – – – – – –
20: – – – – – – – – – – – – – – – –
30: – – – – – – – – – – – – – – – –
40: – – – – – – – – UU UU 4a 4b – – – –
50: 50 – – – – – – – – – – – – – – –
60: – – – – – – – – – – – – – – – –
70: – – – – – – – –
28

Yeah that debug analysis looks to be nonsense in my opinion. First of all we do load the cdns_dsi driver early in the initramfs:

[    4.087615] Kernel module loaded from ramdisk: i2c_mux_pca954x - result: 0
[    4.091177] Kernel module loaded from ramdisk: pwm_tiehrpwm - result: 0
[    4.095923] Kernel module loaded from ramdisk: tidss - result: 0
[    4.109904] Kernel module loaded from ramdisk: display_connector - result: 0
[    4.112744] Kernel module loaded from ramdisk: tc358768 - result: 0
[    4.115422] Kernel module loaded from ramdisk: ti_sn65dsi83 - result: 0
[    4.118626] Kernel module loaded from ramdisk: lontium_lt8912b - result: 0
[    4.121641] Kernel module loaded from ramdisk: sii902x - result: 0
[    4.124903] Kernel module loaded from ramdisk: cdns_dphy - result: 0
[    4.128837] Kernel module loaded from ramdisk: cdns_dsi - result: 0
[    4.141643] Kernel module loaded from ramdisk: cdns_mhdp8546 - result: 0

I even see an early splash screen in my setup on DSI to HDMI. Which would not be possible if the cdns_dsi driver wasn’t initialized early. Also if this point was even remotely true, then I would be affected as well, not just you.

On the point about the clocks. My clocks look exactly the same:

torizon@aquila-am69-12593482:~$ sudo cat /sys/kernel/debug/clk/clk_summary | grep -iE "dss|dsi|vp"
    clk:218:18                       0       0        0        600000000   0          0     50000      Y      4a00000.dss                     vp4
    clk:218:14                       1       1        0        148500000   0          0     50000      Y      4a00000.dss                     vp3
    clk:218:5                        0       0        0        600000000   0          0     50000      Y      4a00000.dss                     vp2
    clk:218:2                        0       0        0        594000000   0          0     50000      Y      4a00000.dss                     vp1
 clk:218:0                           1       1        0        600000000   0          0     50000      Y   4a00000.dss                     fck
 clk:215:5                           1       1        0        250000000   0          0     50000      Y   4800000.dsi                     dsi_sys_clk
 clk:215:2                           1       1        0        0           0          0     50000      Y   4800000.dsi                     dsi_p_clk

So this is not an indication on whether things are working properly or not.

It really just looks like something is wrong or broken in your Aquila setup. From the Linux perspective it seems everything is detected and working as it should. There’s no indication something is even wrong from the software side of things, based on the information you’ve given.

But, that makes it very difficult for me to say or even hypothesize what could be the issue on your setup.

Best Regards,
Jeremias

29

I swapped in another SOM, and now the i2c bus split version is working fine. Crazy that that was it after all of this mess.

I’ll test the i2c mux workaround next and make sure it’s still working like that, as I would prefer to mod our own board with that method (since it matches the stock overlays and I won’t have to mess with it anymore).

30

I swapped in another SOM, and now the i2c bus split version is working fine. Crazy that that was it after all of this mess.

Interesting so the specific SOM was problematic then? Maybe it got damaged somehow and that was affecting the solution?

Best Regards,
Jeremias

31

No idea. It hasn’t been mishandled or anything. That one has just lived on the dev board. I have another out on our board that I did most of the development on, which has been swapped between boards a hundred times. I’ll know later if that one still works in this respect (need to put the mux on our board first).

If you guys are really interested I could ship it back and maybe you could swap it for one that works?

BTW, I did test with the i2x mux on the dev board. That works as well, now, and is how we’ll mod our boards moving forward.

32

If you guys are really interested I could ship it back and maybe you could swap it for one that works?

I don’t think that’s necessary at this time. If it’s just the one module then we can just chalk it up to a strange coincidence.

In any case, it sounds like you’re progressing now which is good. Are there any other questions or issues regarding this topic, or are you all good to go now?

Best Regards,
Jeremias

33

Hi @TxSpace,

If you guys are really interested I could ship it back and maybe you could swap it for one that works?

We discussed this a bit more internally. If you can spare returning the module to us via standard RMA, then our team would be interested in analyzing it for possible issues. That said, we won’t be able to provide a replacement till around January. So please only return this module if you can actually spare having one less module for a while.

If you do RMA, then just follow our standard instructions here: Return Material Authorization (RMA)

Best Regards,
Jeremias

34

Thanks. RMA submitted.

35

Thank you for that.

Come January let us know if you need a replacement module for development.

Best Regards,
Jeremias