Hello Toradex team,
I hope you are all doing great and you had a good time at Embedded World !
Hardware:
tdx-info:
Software summary
------------------------------------------------------------
Bootloader: U-Boot
Kernel version: 5.15.129-6.5.0+git.6f8fd49366db #1-TorizonCore SMP PREEMPT Fri Dec 22 11:15:52 UTC 2023
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/d9775fd5577822ec4e9d6473745ca17c46edd81fc5d56864931253b6cc6414eb/0
Distro name: NAME="TorizonCore"
Distro version: VERSION_ID=6.5.0-build.8
Distro variant: VARIANT="Docker"
Hostname: verdin-imx8mp-14777575
------------------------------------------------------------
Hardware info
------------------------------------------------------------
HW model: iMX8M Plus on *** Board
Toradex version: 0058 V1.1A
Serial number: 14777XXX
Processor arch: aarch64
------------------------------------------------------------
Images tested:
- torizon-core-docker-verdin-imx8mp-Tezi_6.5.0+build.8.tar (STABLE Release)
Guest OS:
- macOS (M1 Pro ARM64)
- Linux ubuntu (VM x86_64)
Issue:
We are trying to pass the EMI test and it seems that our LVDS display is the one blocking us to pass the test. The CLK is to fast and we want to tweak it by changing the MEDIA BLK_CTRL.
Based on the i.MX 8M Plus Applications Processor Reference Manual that I downloaded on NXP, those values can be modified but I don’t understand how those can be achieve in my dts.
I have found the definition of media_blk_ctrl in the imx8mp.dtsi and this is used as clock by lcdif2 used by LVDS display. So far so good. But the clock seems off in the register used:
...
clocks = <&media_blk_ctrl IMX8MP_CLK_MEDIA_BLK_CTRL_LCDIF2_PIXEL>,
<&media_blk_ctrl IMX8MP_CLK_MEDIA_BLK_CTRL_LCDIF2_AXI>,
<&media_blk_ctrl IMX8MP_CLK_MEDIA_BLK_CTRL_LCDIF2_APB>;
...
So my question is, do you have an idea how I can change the value of those clocks to reduce the spike in the signal ? This is beyond my small expertise in device-tree, so if you can guide me a bit that would be very nice !
Thank you in advance.
Best regards,
M
Hello @unablesalt,
The best would be to send us the schematic first and set up a design review call.
We offer the free how-to-design a carrier board call, and we usually check issues like that upfront.
We also offer design reviews. very often the emission has to do with GND and shielding problems.
Best Regards,
Matthias Gohlke
Hello @matthias.tx,
We already did a design review together.
It seems that the shielding is not enough, that’s why we want to try updating the CLK settings.
Best,
M
Hello Again,
So we would like to change the value for the register: LVDS_CTRL, that can be found in the section: 13.2.3.1.41 LVDS Control Register, from MEDIA BLK_CTRL.
I checked online and it seems that other people complains about the way that NXP design it and make it hard to change the value of the CLK. So did any of you had to update this value and/or experience working with the MEDIA BLK_CTRL ?
Thanks in advance!
Best regards,
M
ok, I check internally how to set up the LVDS Spread spectrum clock. That should help.
Best Regards,
Matthias Gohlke
1 Like
Hi @unablesalt !
Just to be sure: are you using native LVDS interface from Verdin iMX8MP or LVDS from DSI interface (therefore using DSI-LVDS adapter as well)?
Anyway, we do not have a ready-to-use approach for Spread Spectrum for neither of the interfaces and we will try to check with NXP if they can help us with it. Enabling it might involve changes on ATF and U-Boot.
In the past we managed to get a set of patch to enable Spread Spectrum on DRAM clock for Verdin iMX8M Mini for a customer that needed it and it became an article in Toradex Developer: Enable Spread Spectrum Clocking on the DDR Interface | Toradex Developer Center. As you can see, it is needed to use Yocto to build the image (in your case, Torizon OS) to enable this feature.
It is important to notice: enabling Spread Spectrum is not something that will impact only the interface that you need, but it will be performed on a PLL that also serves as root/parent clock for other interfaces/devices. Therefore, when you apply such patch, you will need to perform tests on your system to be sure that it is behaving accordingly.
Best regards,
1 Like
Hello @henrique.tx,
I realize that I missed your message, sorry!
For the first point, we are using native LVDS interface directly from the SOMM, nothing in between.
As for the LVDS_CTRL, we just want to be able to change the value for SLEW_ADJ not the spectrum. (See 13.2.3.1.41 LVDS Control Register (LVDS_CTRL).
It might be a bit easier to do ? Or is it related to the u-boot too ?
We can resume the situation as follow: Everything should be made as simple as possible, but not simpler 
Thanks in advance for your help 
Best Regards,
M
Hi @unablesalt !
Sorry for the delay.
Usually, changing a specific register is not straight forward due to the interactions between U-Boot, Linux, ATF, etc…
But I would like to ask some more broad questions, if that is ok.
Could you please share a bit more on how it was found out that LVDS is indeed the culprit?
In the mean time, I am checking internally if we have anything related to LVDS customization.
Best regards,
Hello @henrique.tx,
Thank you for taking the time to help us!
So we went to the lab to take the EMC test and we realize that the data related to the LVDS are the guilty one as you can see in the image bellow:
At first we thought it was the cable, but it’s completely shield and connected to the ground so we don’t think that the cable is responsible.
We are still looking for alternatives, but it we really want to be able to change this value to test it.
Keep me updated on the response you will receive internally.
Best regards,
M
