imx8mp DMA configure with UART and SPI

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

imx8mp DMA configure with UART and SPI

5,430 Views
AngelF
Contributor II

Hello,

We are working on a custom board based on iMX8MP chipset derivated from the evaluation board EVK-IMX8MP, and we got FW from NXP version 5.4.70_2.3.2.

We have problems when trying to configure UARTS and SPI with DMA. Looking at this post

https://community.nxp.com/t5/i-MX-Processors/custom-imx8-nano-imx8mn-uart4-tx-working-rx-failing/m-p...

we made interfaces work by disabling dma from uart3, uart4, ecspi1, ecspi2 and ecspi3. We removed "dmas" and "dma-names" features from these nodes at imx8mp.dtsi

Could you please help us to configure dma with these interfaces please?

This is what I get when starting the system:

root@arm:/home# dmesg | grep dma
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.134609] imx-sdma 30bd0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2
[ 0.134622] imx-sdma 30bd0000.dma-controller: Falling back to sysfs fallback for: imx/sdma/sdma-imx7d.bin
[ 0.136043] mxs-dma 33000000.dma-apbh: initialized
[ 1.244065] spi_imx 30820000.spi: dma setup error -19, use pio
[ 1.254431] spi_imx 30830000.spi: dma setup error -19, use pio
[ 1.264717] spi_imx 30840000.spi: dma setup error -19, use pio
[ 6.446371] imx-sdma 30bd0000.dma-controller: loaded firmware 4.5
root@arm:~# ls -l /lib/firmware/imx/
total 20
drwxr-xr-x 2 root root 4096 May 31 08:56 easrc
drwxr-xr-x 2 root root 4096 May 31 08:56 sdma
drwxr-xr-x 2 root root 4096 May 31 08:56 sof
drwxr-xr-x 2 root root 4096 May 31 08:56 sof-tplg
drwxr-xr-x 2 root root 4096 May 31 08:56 xcvr
root@arm:~#
root@arm:~#
root@arm:~# ls -l /lib/firmware/imx/sdma/
total 8
-rw-r--r-- 1 root root 2746 May 31 08:56 sdma-imx6q.bin
-rw-r--r-- 1 root root 2862 May 31 08:56 sdma-imx7d.bin

Best regards and thank you
Angel

0 Kudos
17 Replies

5,397 Views
ceggers
Contributor V

Hi Angel,

[ 0.134609] imx-sdma 30bd0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2
[ 0.134622] imx-sdma 30bd0000.dma-controller: Falling back to sysfs fallback for: imx/sdma/sdma-imx7d.bin

I already saw these messages in another post I answered:

https://community.nxp.com/t5/i-MX-Processors/imx6-linux-imx-sdma-firmware-load-failed-error/m-p/1193...

Please let me know whether this helps.

regards,
Christian

5,386 Views
AngelF
Contributor II

Hi Christian,

Thanks for your answer.

Build the imx-sdma driver as a kernel module loads de FW and the error during start-up is removed.

I still have to remove dma configuration for ecspi1 and ecspi2 at imx8mp.dtsi, because mcp2518fd drivers do not work when dma is enabled.

Best regards and thank you

Angel

0 Kudos

5,379 Views
Yuri
NXP Employee
NXP Employee

@AngelF 
Hello,

  Looks like the DMA mode is hardcoded in the driver.

https://community.nxp.com/t5/i-MX-Processors/Hi-could-you-share-the-reference-implmentation-configur...

 In such case You need to modify the driver and rebuild it.

Regards,
Yuri.

0 Kudos

5,373 Views
AngelF
Contributor II

Hello Yuri,

As I understand this means that dma is used when available, and I think this is correct way to work.

If I set "static bool use_dma = false;" this means dma is no used anymore with spi ? or can we enable/disable for different spi interfaces ?

We have dma enabled in ecspi3 with ism330dlc drivers and it is working fine. We would like to be able also to enable dma with ecspi1 and ecspi2 and canfd drivers.

Best regards and thank you

Angel

0 Kudos

5,358 Views
ceggers1
Contributor IV

Hi Angel,

yes, the use_dma module parameter completely disables DMA for all ECSPI instances. In order to disable DMA for individual ECSPI masters, you have to remove the "dmas" and "dma-names" properties of the specific concrete instances in the board device tree.

According to the spi-imx.c driver, no DMA will be used for all SPI transfers shorter than 64 bytes (see spi_imx_can_dma()).

regards,
Christian

5,382 Views
ceggers
Contributor V

Hi Angel,

I am not really sure whether SPI+SDMA works fully correct on my system...

For getting more information about your problem, I would have to debug your hardware setup.

What about the UARTs? Do they work with SDMA now?

regards,
Christian

0 Kudos

5,378 Views
AngelF
Contributor II

Hi Christian,

I am doing more tests, but uarts seem to work fine now.

Regarding the SPI, tell me what else I can send you for checking.

The error is ecspi1 and ecspi2 with CANFD drivers.

We also have ecspi3 with ism330dlc and this one works with dma enabled.

Best regards and thank you

Angel

 

0 Kudos

5,356 Views
ceggers1
Contributor IV

Hi Angel,

please send me the parts of your device tree for ecspi1 and ecspi2. Please look in your board's device tree and in the include files for your processor.

Are you able to compare SPI communication without DMA (working) and with DMA (not working)? Do you have access to a logic analyzer or a modern oscilloscope?

regards,
Christian

0 Kudos

5,296 Views
AngelF
Contributor II

Hi Christian,

I am sorry, but still uarts are not working fine with dma.

What I see in RX and TX lines is that data is corrupted, not expected values.

 I attach imx8mp.dtsi andimx8mp-pinfunc.h files (we get them from rel_imx_5.4.70_2.3.2) and custom.dts (our configuration for uarts and spi)

Best regards and thank you

Angel

5,284 Views
Yuri
NXP Employee
NXP Employee

@AngelF 
Hello,

   it is good idea to use hardware flow control (RTS, CTS) with DMA, when using UART.

Regards,
Yuri.

0 Kudos

5,268 Views
AngelF
Contributor II

Hello Yuri,

I agree, It is much better to use RTS/CTS when using uarts.

The problem is that we need all the uarts, and according to the pinmux requirements for our design, it is not possible to implement HW flow control in all the uarts.

Best regards and thank you

Angel

5,290 Views
ceggers1
Contributor IV

Hi Angel,

What I see in RX and TX lines is that data is corrupted, not expected values.

what does "data is corrupted" mean? Can you provide a picture from an oscilloscope or logic analyzer?

regards,
Christian

0 Kudos

5,267 Views
AngelF
Contributor II

Hello Christian,

I attach pictures of some data TX/RX.

tx_rx_ok.png shows a correct communication between the host and the salve.

When errors start to happen you see in tx_error.png "framing error" messages in some bytes. But slave still answers with the correct response (rx_error.png).

The problem is when trying to read from host, only 1 byte is available (most of the times same value 0xA1).

Up to now, the only way I found to make the system work fine is to remove "dmas" and "dma-names" features from imx8mp.dtsi file.

Best regards and thank you

Angel

0 Kudos

5,262 Views
ceggers
Contributor V

Hello Angel,

on tx_error.png, it looks like the UART sends 9 bits instead of 8. Depending on the content of the 9th bit, this is interpreted as a valid STOP bit or as a framing error.

Do you configure the UART for 9 bit frames? Is some kind of "RS-485 addressing mode" enabled?

regards,
Christian

0 Kudos

5,264 Views
AngelF
Contributor II

Hello Christian,

UART is configures with CS8 frame length. It is configured exactly the same way in both examples.

Anayway, now I disabled RS485 when configuring UART and repeated the test. It is still failing the same way.

Best regards

Angel

0 Kudos

5,227 Views
ceggers
Contributor V

Maybe the deviation of the UART's baud rate is too high. What type of clock supply do you use for i.MX chip? Can you please verify the UART baud rate with an oscilloscope? The logic analyzer may be to rough.

regards,
Christian

5,161 Views
AngelF
Contributor II

Hello Christian,

Sorry for the late answer, but we are busy trying to deliver first prototypes to customers.

I checked with the oscilloscope and baud rate is correct. Over this uart we have two different protocol implementatios with the same slave, and the framing error shown in pictures was probably an error in the parity setting of the logic analyzer.

Doing some more test I see that sometimes uart indicates a character is available for reading, and it is a 0x00. With the oscilloscope we see RX line is quiet, and Uart flush does not solve it.

What is rare for me is that this error never happens if dma is disable in uart configuration.

We made a workaround by ignoring this 0x00, as we know it is not possible to receive this character in that protocol.

Regarding the dma and SPI we need to do more test to provide more detailed information. By the moment we disabled dma for this interface.

Best regards
Angel

0 Kudos