i.MX Processors Knowledge Base

Discussions

Question: How to enable touch functions on LVDS1/SabreAI base board? what should be soldered in order to connect the signals to i2c what to add in the Linux kernel (board-mx6q_sabreauto.c) BTW.: Why did we leave these disconnected? Is there any conflict on i2c? Answer: You can mount R305 and R306 to support touch on LVDS1, no code modification was needed. The only limitation is that the two LVDS's touch can't be connected to same I2C port, because they are using the same I2C address. Question: How is this working because the touch interrupt signal from LVDS1 called LCD1_TOUCH_INT_B is connected to pin21 on J44 on base board which is left floating (TP1) on CPU card P1A connector? Are both LVDS needed to work in the same time. Answer: That's the problem, the LVDS1 touch interrupt pin hasn't been connected to IMX6 CPU. Maybe you can use the SabreSD board, the two touch are ready on that board.

Question: Clarify if the delay units, mentioned in i.MX6 RM in two places are the same : 1. There are delay units for data strobes, that are considered in calibration procedures. 2. There are delay units for clocks SDCLK, mentioned in section 44.12.54 “MMDC PHY CK Control Register (MMDCx_MPSDCTRL)” of the RM. General delay units description states : “ The delay issued by the delay-line (according to the configured value) is absolute and takes into account the operating and temperature conditions. The delay-line has a resolution that may vary from device to device; an increment of 1 delay unit may vary between 20 pSec to 50 pSec.” It may be guessed that the same relates to SDCLK delays, but preliminary i.MX6 specs mention that bit fields SDCLKx_DEL (x=0,1) control SDCLK delay, that can be up to 1 cycle. This means SDCLKx_DEL step is 1/4 of the SDCLK. Please clarify SDCLK delays (SDCLKx_DEL) in more details. Answer: "The delay elements in the SDCLK path are similar to those in the data strobes but they are not exactly the same. The delay is on the order of picoseconds, though, not a full SDCLK cycle as might have been interpreted from the older document."

Question: LVDS in split mode (dual lvds) is used. In this configuration, only LVDS0_CLK is used. What is the suggestion for the LVDS1_CLK? The HW user guide says that if this is unused, then to leave it floating. Would we also suggest the same for this case or would termination be more appropriate? Or is there some possible way to gate this clock? (if so, it isn't obvious in the RM) Answer: According to the MX6 Developer's Guide, any unused LVDS pins should be left floating, so the LVDS1_CLK pair, in this case should be left floating. In order to minimize any potential EMC, the lands for those balls should not have any additional traces leading away. To add a bit more information, the customer ran some tests and found that the clock gate bits for the LVDS1 are essentially ignored in Dual mode. The only way to disable it is if they are both disabled which is not helpful in this case. It seems that the Dual mode setting overrides the CG.

In some applications, we need to shift frequencies to avoid interference from certain frequencies, such as shifting to avoid Wi-Fi interference. The document is a guide for shifting DDR3 frequency. The document uses the iMX8M Nano DDR3 as an example, but the process is the same for the iMX8M mini, iMX8M Plus, LPDDR4, etc. The main issue is resolving the DDR pll configuration. Before reading this article, we assume you are already familiar with using the DDR stress tool and DDR config rpa, or the DDR tool of the config tools. pll_to_table_entry_rates.py can help you to find the settings.

Question: The following contradicting information regarding the UART clock tree has been seen in the Rev. 1.0 version of the reference manual: Page 813: PLL3_PFD1 -> divide by 6 -> adjustable post divider -> UART Page 839: PLL3 -> divide by 6 -> UART In the old Rev D I found: Page 803: PLL3 -> divide by 6 ... and something about 80MHz The assumption is that correct path would be: PLL3 -> divide by 6 -> post divider -> UART. Answer: The designer said that UART _CLK_ROOT comes from PLL3 (not PLL3:PFD1) and is divided by 6 to produce 80 MHz. I'm waiting for him to confirm that the divider he mentions is CSCDR1[UART_CLK_PODF].

this poring is based on the imx415 driver, the capture format is based on raw10, the bsp version is 6.6.52, the patches are attached Disclaimer: − “Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.”

It is suggested to create a layer when creating or modifying any metadata file (recipe, configuration file or class). The main reason is simple: modularity. Follow these steps 1. To have access to Yocto scripts, setup the enviroment from the BASE folder fsl-community-bsp $ . setup-environment build 2. Move to the place you want to create your layer and choose a name (e.g. `fsl-custom`) sources $ yocto-layer create fsl-custom # Answer the questions. Make sure the priority is set correctly (higher numbers, # higher priorities). Set the priority equal to the lowest already present, except # when you have introduce a new recipe with the same name as other and want to shadow # the original one. 3. Add any metadata content. Suggestion: Version the layer with Git and upload your local git repo to a server 4. Edit and add the layer to the `build/conf/bblayers.conf` file 5. To verify that your layer is *seen* by BitBake, run the following command under the build folder build $ bitbake-layers show-layers This document was generated from the following discussion: i.MX Yocto Proyect: How can I create a new Layer?

As part of the patches attached with this blog, we will relay the pcie write transaction from Endpoint-A to Endpoint-B connected to iMX95FRDM PRO. Linux-imx used - lf-6.18.2-1.0.0 Attached are the following files:- imx95-19x19-frdm-pro-pcie0-ep-dtbs - EP A shall use the dtb built with this dtbs imx95-19x19-frdm-pro-pcie1-ep-dtbs - EP B shall use the dtb built with this dtbs rc_pcie_dma_relay.c - driver used on RC to relay pcie write from EP-A to EP-B conf_pcie0.sh - script to be executed on Endpoints A and B to configure the EPF driver //To build the dtb and relay kernel driver 1. git clone git clone https://github.com/nxp-imx/linux-imx.git git checkout origin/lf-6.18.y 2. Copy the dtbs to arch/arm64/boot/dts/freescale/ Copy rc_pcie_dma_relay.c to drivers/pci/ 3. Make the following changes as per this diff diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile index aa3cfdf1aafc..56e3db653208 100644 --- a/arch/arm64/boot/dts/freescale/Makefile +++ b/arch/arm64/boot/dts/freescale/Makefile @@@ -1205,6 +1205,16 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm-8mic-reve.dt dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro.dtb imx95-19x19-frdm-pro-aud-hat.dtb + +dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro-pcie0-ep.dtb +dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro-pcie1-ep.dtb + +imx95-19x19-frdm-pro-pcie0-ep-dtbs := imx95-19x19-frdm-pro.dtb \ + imx95-19x19-frdm-pro-pcie0-ep.dtbo + +imx95-19x19-frdm-pro-pcie1-ep-dtbs := imx95-19x19-frdm-pro.dtb \ + imx95-19x19-frdm-pro-pcie1-ep.dtbo + imx95-19x19-frdm-pro-os08a20-isp-dtbs := imx95-19x19-frdm-pro.dtb \ imx95-19x19-frdm-pro-os08a20.dtbo dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro-os08a20-isp.dtb 4. Add the following to drivers/pci/Makefile +obj-m += rc_pcie_dma_relay.o 5. Trigger the kernel build. You will obtain rc_pcie_dma_relay.ko, imx95-19x19-frdm-pro-pcie0-ep.dtb and imx95-19x19-frdm-pro-pcie1-ep.dtb. 6. We are only using pcie0 M.2 Key M slots of Endpoint A and Endpoint B so you only need to upload this dtb to both the endpoint boards - imx95-19x19-frdm-pro-pcie0-ep.dtb and boot linux with it after passing 'iommu.passthrough=1' at uboot mmcargs. This is to disable smmu for our tests. RC will boot with the default dtb - imx95-19x19-frdm-pro.dtb 7. Connect the Endpoint-A to RC's K1 via M.2 Key M to Key M cable. Similarly connect the other Endpoint-B to other RC's K2 M.2 slot via Key M to Key M cable. 8. Execute this script on both the endpoints - ./conf_pcie0.sh 9. Then reboot the RC iMX95 FRDM Pro and ensure that you see both the endpoints:- 0000:01:00.0 and 0001:01:00.0 are the enumerated endpoints. 10. Upload rc_pcie_dma_relay.ko to the RC board and insert it like this:- insmod rc_pcie_dma_relay.ko src_phys=0x910100000 dst_phys=0xa10100000 relay_len=0x100000 chunk_len=0x10000 you will observe similar logs on dmesg:- [ 4949.082087] rc_pcie_dma_relay: init src=0x910100000 dst=0xa10100000 len=1048576 chunk=65536 [ 4949.082150] rc_pcie_dma_relay src_before: [0]=0xdeadbeef [1]=0xdeadbeef [2]=0xdeadbeef [3]=0xdeadbeef [ 4949.082171] rc_pcie_dma_relay dst_before: [0]=0x00000000 [1]=0x00000000 [2]=0x00000000 [3]=0x00000000 [ 4949.125779] rc_pcie_dma_relay dst_zeroed: [0]=0x00000000 [1]=0x00000000 [2]=0x00000000 [3]=0x00000000 [ 4949.141380] rc_pcie_dma_relay src_after: [0]=0xdeadbeef [1]=0xdeadbeef [2]=0xdeadbeef [3]=0xdeadbeef [ 4949.141427] rc_pcie_dma_relay dst_after: [0]=0xdeadbeef [1]=0xdeadbeef [2]=0xdeadbeef [3]=0xdeadbeef [ 4954.272981] rc_pcie_dma_relay: verify OK for 1048576 bytes [ 4954.273000] rc_pcie_dma_relay: DMA relay verify PASSED 11. Finally, via devmem5 on RC, you can verify the data of EP-A transferred to EP-B ./devmem5 r 0xa10100000 w

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

uImage

Q&A: i.MX6 SabreAI LVDS1 touch

Q&A: Delay units in SDCLKx_DEL of MMDCx_MPSDCTRL register

SOM6361A_2.JPG

Q&A: LVDS1_CLK Termination

android platform key in iMX.6 sabre solution

Mouse pointer on Android R13.4.1 SabreSD

1280x720.mjpg test input for libvpuwrap 1.0.46 decoder test

Enabling Cortex-M7 Asymmetric Multiprocessing boot support for i.MX8MPEVK on Qemu

iMX8MN DDR3 Frequency Shifting

Integrity for rootfs

xaf

RT1050 Developer Resource

Q&A: Errors in the i.MX6 reference manual regarding the clock tree for the UART

IMX415 porting on imx8mp with ISI

wxWidgets on i.MX

Question, i.MX6Q SSI time slot

GSTREAMER LOG

i.MX Yocto Proyect: How can I create a new Layer?

Relaying PCIe data between two endpoints via RC on iMX95 FRDM PRO