custom imx8 nano (imx8mn) - uart4 tx working, rx failing

[kippowens]

Hi there,

I have a custom imx8m nano board and we're hoping to utilize UART4 to communicate with a peripheral.  I'm walking my way through board bring-up and have run into a bit of a weird issue.  The TX is working, but the RX is not (fwiw, the scope shows the signal getting sent TO the RX pin, I'm just not seeing any input from within Linux).

Here's what I've done...

I've configured UART4 in imx-atf to allocate UART4 to the A53s per suggestions from this forum - notably changing the domain permissions to:

RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W),

Within u-boot and Linux device trees, I've configured the pins for UART RX and TX and enabled UART4...

pinctrl_uart4: uart4grp {
	fsl,pins = <
		MX8MN_IOMUXC_UART4_RXD_UART4_DCE_RX			0x140
		MX8MN_IOMUXC_UART4_TXD_UART4_DCE_TX			0x140
	>;
};

...

&uart4 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_uart4>;
	assigned-clocks = <&clk IMX8MN_CLK_UART4>;
	assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_80M>;
	status = "okay";
};

I have started the clock within u-boot...

static iomux_v3_cfg_t const uart4_pads[] = {
	IMX8MN_PAD_UART4_RXD__UART4_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
	IMX8MN_PAD_UART4_TXD__UART4_DCE_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
};

...

imx_iomux_v3_setup_multiple_pads(uart4_pads, ARRAY_SIZE(uart4_pads));
init_uart_clk(3);

From the Linux side, I'm just doing a loopback on the UART4 line to see if I can echo back the data I'm sending...

Am I missing something obvious?  Is it possible the M7 is still assigned somehow or there's a conflict due to the M7 usually owning UART4?

Thanks in advance!!

[igorpadykov]

Hi Christopher

for RX path one can check daisy setting described in  sect.8.2.5.119 Pad Mux Register (IOMUXC_SW_MUX_CTL_PAD_UART4_RXD), sect.8.2.5.267 Select Input Register (IOMUXC_UART4_RX_SELECT_INPUT)    i.MX 8M Nano Applications Processor Reference Manual

For testing one can use unit test

https://source.codeaurora.org/external/imx/imx-test/tree/test/mxc_uart_test?h=lf-5.10.y_1.0.0

Best regards
igor

[kippowens]

Thank you, Igor, for the quick response.

I did a quick check of these registers and things look as I would expect:

3033024c: 0x00000000 (ALT0 — Select signal UART4_RX)
3033050c: 0x00000002 (UART4_RXD_ALT0 — Selecting ALT0 mode of pad UART4_RXD for UART4_RX)

I also ran a quick experiment and set these pins to software configurable GPIO.  I was able to ensure that electrically, they're connected correctly.

Is there a conflict with M7 still I might be missing?

[igorpadykov]

one can try to attach jtag debugger and check UARTx_URXD register (described in sect.

15.2.14.1 UART Receiver Register (UARTx_URXD) Reference Manual) for status bits

Best regards
igor

[kippowens · Accepted solution]

Thanks again, Igor, for the reply.

I've got things going now - I had left dma enabled in linux (but disabled in u-boot).  After disabling dma, things look to be working.

Apologies for taking your time, but appreciate the help!
Kipp

For anyone else looking at this and maybe seeing issues...  I disabled dma in both u-boot and linux DTS files as follows:

uart4: serial@30a60000 {
	compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
	reg = <0x30a60000 0x10000>;
	interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
	clocks = <&clk IMX8MN_CLK_UART4_ROOT>,
			<&clk IMX8MN_CLK_UART4_ROOT>;
	clock-names = "ipg", "per";
	/* disabling DMA...
	dmas = <&sdma1 28 4 0>, <&sdma1 29 4 0>;
	dma-names = "rx", "tx";
	*/
	status = "disabled";
};

[Charlie_Owz]

We also had the same trouble with iMX8M Plus, and after disabling DMA as you mentioned, all started to work fine.

Do you know if it is a configuration failure or if we are missing something else? 

Is always necessary to disable it? Did you find to solve it in another way?

Have you found any explanation for this or someone from NXP told you how to do it in another way?

Many thanks in advance!

[kippowens]

@Charlie_Owz - My apologies for the slow response.   I didn't see this until today.

We have not solved it another way and have continued with the workaround I used above.  I've not received any further information from NXP, but I think @ceggers reply and suggestion above makes sense and would be worth trying!  Thank you for that response, @ceggers!

Best of luck!
-Kipp

[ceggers]

You didn't supply a kernel log. Some people have trouble with SDMA firmware loading. Please look for:

[ 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

If you can see these messages, please try my solution here:

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

regards,
Christian