IMX7D UART does not work in DMA mode and lost data in non-DMA mode

[alexjun]

Hi,

I am enabling an uart device that is attached to UART6 on Linux 5.4.70. But long packet(250 bytes) cannot be received completely sometimes, the serdev receiver callback found it is called when there are 1 bytes ready, tens of bytes ready, more than 100 bytes ready. Sometimes I can see serdev receiver callback is called for a complete packet ready, not for most of times.

So I am trying to enable SDMA to have a check. But I see 1024 bytes are received for 4 times in very short time as below, while UART is in 9600 rate. I see similiar issue in below link [a] and new sdma firmware is suggested. I have tried 2 version firmware from branch master and nxp_mc in link [b], but there is no difference for this issue.

DTS file for machine is in bottom.

Question 1: Any suggestion for data missing bug non-DMA mode?

Question 2: What firmware shall I use?

[a] https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1040968/wl1837mod-bl...

[b] https://github.com/NXP/linux-firmware/tree/master/imx/sdma

[ 300.163808] imx_uart_startup:  (port)->cons->index 0 (port)->line 5
[ 300.163861] imx-sdma 30bd0000.sdma: Allocing channel..
[ 300.163873] imx-sdma 30bd0000.sdma: Allocing channel with pri 3, ret 0
[ 300.163898] imx-sdma 30bd0000.sdma: Allocing channel..
[ 300.163908] imx-sdma 30bd0000.sdma: Allocing channel with pri 3, ret 0
[ 300.163969] imx-uart 30a80000.serial: RX: prepare for the DMA.
[ 300.164017] imx-uart 30a80000.serial: We get 1024 bytes.
[ 300.164037] imx-uart 30a80000.serial: We get 1024 bytes.
[ 300.164054] imx-uart 30a80000.serial: We get 1024 bytes.
[ 300.164072] imx-uart 30a80000.serial: We get 1024 bytes.

DTS:

 &uart6 {
    assigned-clocks = <&clks IMX7D_UART6_ROOT_SRC>;
    assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
    status = "okay";

    client {

        /* compatible and pinctrl */

    };

};

[Yuri]

@alexjun 
Hello,

  it may be recommended to use CTS/RTS hardware flow control for DMA mode.

Regards,
Yuri.

[ceggers]

it may be recommended to use CTS/RTS hardware flow control for DMA mode.

@Yuri:
For me (and probably others), the main reason for using (S)DMA is not requiring hardware flow control. DMA usually offers much shorter latencies than interrupts (serviced by the CPU, probably running a non-realtime OS).

[alexjun]

Hi @Yuri

It is not reasonable to receive so much data in less than 1ms, even without hardware flow control. Is this a known bug to introduce this issue? Because the log in the link of previous post shows the identical issue. Where can I find latest firmware? 

[ceggers]

Please post the full uart6 section(s) of your device tree (and of the .dtsi files you have included). I would like to check whether you SDMA channels and events are assigned correctly.

regards,
Christian

[Yuri]

@alexjun 
Hello,

   perhaps the problem concerns the fact, that SDMA provides bursts for data
transfer. If data buffer length is not multiple of burst length some data will
wait the next burst. 

Regards,
Yuri.

[alexjun]

Hi @Yuri 

It is 4 * 1024 bytes received in less than 100us with 9600 baudrate and DMA is just enabled. Even the burst size is 1024, it takes 2.56 seconds to receive 3*1024 bytes. So the only conclusion is that SDMA is not working as expected.

The WiFi bug in below link also show the identical issue, which is resolved with new UART SDMA firmware. So please help point out where is the latest SDMA firmware. Thanks!

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1040968/wl1837mod-bl...

[ceggers]

Hi,

the SDMA firmware under

https://github.com/NXP/linux-firmware/tree/master/imx/sdma

is version 3.3. In the linux-firmware repository, you can find version 3.5:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma

regards,
Christian

[alexjun · Accepted solution]

Hi Christian,

The firmware in the link does not help on this bug. But I found below the firmware  in below package works. Thanks anyway!

https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.13.bin

[ceggers]

Hi alexjun,

although your problems seems to be solved, I made some investigations on this because ...

• I also have (sometimes) the situation that may UART receives buggy data
• I plan eventually moving from i.MX6 to i.MX7

I compared different version of the i.MX7 SDMA firmware and probably found out the reason for your problem:

• https://github.com/NXP/linux-firmware/tree/master/imx/sdma
  The sdma-imx7d.bin there is really old (version 4.2, the oldest I have ever seen). This firmware doesn't replace the existing SDMA ROM routines for the UART, so your application may work correctly with this file.
• sdma-imx7d.bin, version 4.4 (you didn't mention this)
  The version seems to be buggy. I installs the mcu_2_zqspi routine in the jump table entry for uart_2_mcu. Using a wrong SDMA routine for a peripheral can eat children, so it would explain why you get garbage data very fast.
• https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma
  The sdma-imx7d.bin there is 4.5, here the uart_2_mcu routine is not replaced by the QSPI code. So it should work.

If my explanation doesn't fit, I've a second one:

The format of the SDMA firmware header has been changed in a incompatible way for several times (e.g. [1], [2], [3], ...). So it's likely that you installed a combination of SDMA firmware and Linux kernel where the layout of struct sdma_script_start_addrs does not match.

The UART SDMA routines itself never changed between the different versions of the SDMA firmware.

Have a nice weekend
Christian

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/include/linux/platform_data/...

[2] https://git.phytec.de/linux-imx/commit/include/linux/platform_data/dma-imx-sdma.h?h=v5.10.72_2.2.0-p...

[3] https://git.phytec.de/linux-imx/commit/include/linux/platform_data/dma-imx-sdma.h?h=v5.10.72_2.2.0-p...