Hello,
I am working on the hardware implementation of a new LVDS display.
Using the available PCB design in Altium Designer, I noticed a parameter in the Layer Stack Manager. It concerns the internal dielectric layer between the internal copper layers. This parameter is the DK value, which refers to the dielectric constant of the insulator. In the design, its value is set to 0. Altium Designer detects this as an error because the value cannot be lower than 1. The DK parameter is related to the impedance matched for high-speed LVDS signals.
Was the DK value of 0 intentionally set in this design?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Sylwester,
Thank you for reaching out with your question. The DK (dielectric constant) value is indeed a crucial parameter in PCB design, particularly for high-speed signals like LVDS, as it plays a significant role in impedance matching. A DK value of 0 is not physically meaningful and is likely an error in the design setup. Typically, the DK value should be greater than 1, which reflects the properties of the dielectric material used between the copper layers.
In your Altium Designer project, the DK value set to 0 should be corrected to ensure proper impedance matching and signal integrity for your LVDS display. I recommend checking the design documentation or consulting with the original designer to determine the appropriate DK value for the dielectric material specified in your project.
I hope this helps you move forward with your design. If you have any more questions, feel free to ask.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Thank you for bringing this to our attention. I have contacted our Hardware team and they are looking into it. We are unsure of how this has occurred and the public packages will be fixed. In the meantime I would urge you to please use 4.2.
Dear Collin
Tank you for the answer, Have you contected with your engineer team ?
what do you mean by 4.2, is it the hardware version. The existing version of the adapter is 1.1
Best regards
Sylwester
I have indeed contacted our developer team, but they have not been able to alter the public package yet. With 4.2 we meant the value you should use as the DK parameter. This was told to me by our lead in R&D.
Hope this helped clear up the mystery around the 4.2 and apologies for the confusion.
I designed the PCB according to the available design data, regardless of the DK parameter value. I hope that some engineer did this consciously and successfully launched this adapter.
I finally got the LVDS display working but have a problem with capacitive touch panel my display is Powertip PH102600T013-ZFC04.
Driver IC’s for CTP is ST5021-G3-1, ST5651CB-G3-1 can toradex handle the drivers?
what you listed seems to be the DSI controller on the display instead of the touch controller. Looking at the datasheet, which can be found here, I believe the touch controller to be ICNT8952. A driver to that could not be found on our side. It originates from this manufacturer. Chiptone provides two drivers in the kernel. Them being:
drivers/input/touchscreen/chipone_icn8318.c
drivers/input/touchscreen/chipone_icn8505.c
Only the first one supports device tree though. You could see, if this driver might work for you with the device tree node looking something like this:
The documentation can be found under documentation/devicetree/bindings/input/touchscreen/chipone,icn8318.yaml inside the kernel. Should this not work for you I would suggest contacting the display manufacturer. From time to time, it happens that they can provide the necessary driver.
I have forwarded the matter to my colleague, Daniel.L, a software engineer. Below, I am attaching his question, as he wanted to join this thread but was blocked:
How can we enable this module on Torizon OS 7.1.0? I guess we need to compile the kernel modules from source files, although this solution unfortunately didn’t work for me.
Could you guide us through this process, or does your team have the capabilities to check it for us?
Thank you for making us aware of the previous message. If you use the driver as an external module you can use the Torizon Core Builder, for which instructions can be found at our developer page. This should then fetch the correct Kernel version.
Alternatively you could also build everything with Yocto, for which instructions can be found under this developer page. In this case you can make changes as a “regular” kernel patch.
We tried compiling the kernel/modules and then deploying the modules to the board according to the Build Linux Kernel from Source Code documentation on your site. Unfortunately, the deployed modules returned errors with either the vermagic version failure or with “chipone_icn8318: .gnu.linkonce.this_module section size must match the kernel’s built struct module size at run time” (I compiled the modules with the same kernel version as the torizon OS kernel). I understand that there is also the possibility of building an TorizonOS image with Yocto but that is something that we don’t really have the experience to deal with and what we wanted to avoid from the start. Is there any other way you can support us through this?
Best ragards
Sylwester
I am sorry to hear about the trouble you are facing. I think something might have been jumbled up during the inclusion of the module however. I presume that the following process might help to actually build it:
make mrproper
make <defconfig>
make Image.gz
make modules
MODULES_INSTALL_PATH=modules make modules_install
The reason behind the steps I mentioned above is that I believe that the modules might have been installed into an incorrect kernel version, which would explain the errors you mentioned.
“uname -r” on the target board gives “6.6.84-rt52-7.2.0-devel-gb3ce92963d04” (I use the monthly TorizonOS version 7.2.0 but the same happened to me on the 7.1.0 stable version)
This is what I do on my Ubuntu 22.04 Host Virtual Machine
I prepare the machine for Cross-Compilation 64 bit Arm (“Prepare the Host Machine for Cross-Compilation” in the docs)
I install the required tools and dependencies.
I pull the “linux-toradex” repo and switch to branch “toradex_ti-linux-6.6.y”
I copy the config.gz file from the target board to Ubuntu and rename it to .config in the linux-toradex dir (the kernel version in the Makefile is 6.6.84).
I do “make menuconfig” and enable the module for /input/touchscreen/chipone_icn8318
I do “make -j$(nproc) modules”
After that I do
$ mkdir modules
$ export INSTALL_MOD_PATH=modules
$ make modules_install
$ cd modules
$ tar -czf …/modules.tar.gz .
“scp …/modules.tar.gz torizon@:/home/torizon”
On the target board I do “sudo su” → “cd ~/” → “mv /home/torizon/modules.tar.gz ~/” → “tar -xzf modules.tar.gz -C /”
Now I have two versions in /lib/modules so I rename the new modules directory to match the “uname -r” and run “depmod”.
When I try to “sudo modprobe chipone_icn8318” I get the following
[ 193.379775] chipone_icn8318: disagrees about version of symbol module_layout
[ 3129.733518] chipone_icn8318: disagrees about version of symbol module_layout
There might be a few issues here. Looking at your previous message we believe that steps 1 - 3 are fine. From then on I think you should probably proceed as follows:
git checkout b3ce92963d04
Copy config.gz and unzip it: zcat config.gz > .config
Make sure that the directory in the modules directory is the same as what uname -r on the module gives. If it is different, make sure you checked out the correct version and that export LOCALVERSION=“…” used the correct string
fakeroot tar -czf …/modules.tar.gz
Untar the modules on the target
reboot
Please let me know how you fare with this process.
Best regards,
Collin
Your instructions did work as intended, we’ve managed to enable the chipone_icn8318 module on the system. We also added an entry to the device tree as you’ve suggested earlier with the i2c part looking like this
The dmesg returned a line
input: icn8318 as /devices/platform/bus@f0000/20010000.i2c/i2c-1/1-0048/input/input1
And when I used evtest on /dev/input/event1 it gave me details on the chipone driver
Input driver version is 1.0.1
Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "icn8318"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 330 (BTN_TOUCH)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Value 0
Min 0
Max 1023
Event code 1 (ABS_Y)
Value 0
Min 0
Max 599
Event code 47 (ABS_MT_SLOT)
Value 0
Min 0
Max 4
Event code 53 (ABS_MT_POSITION_X)
Value 0
Min 0
Max 1023
Event code 54 (ABS_MT_POSITION_Y)
Value 0
Min 0
Max 599
Event code 57 (ABS_MT_TRACKING_ID)
Value 0
Min 0
Max 65535
Properties:
Property type 1 (INPUT_PROP_DIRECT)
Testing ... (interrupt to exit)
The i2cdetect -y -r 1 register 48 changed to UU after applying the correct devicetree
Maybe there is something I’ve missed in the i2c section of the devicetree?
