linux-kernel - imx6sx uart failing loopback tests with sdma firmware (ROM works)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <6d8280df85c6e5b2ddba635780cd2912d9c5d425.camel@nxp.com>
Date:   Mon, 26 Nov 2018 11:53:18 +0000
From:   Leonard Crestez <leonard.crestez@....com>
To:     "l.stach@...gutronix.de" <l.stach@...gutronix.de>,
        "u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
        Andy Duan <fugang.duan@....com>
CC:     "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        Robin Gong <yibin.gong@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: imx6sx uart failing loopback tests with sdma firmware (ROM works)

Hello,

On a build farm at NXP we found that linux-next now fails on simple
loopback tests on imx6sx-sdb (but not other SOCs AFAICT). I tracked
this down to commit 30fdd51be161
("ARM: imx_v6_v7_defconfig: add CONFIG_FW_LOADER_USER_HELPER")

All that does is enable loading SDMA firmware from rootfs, in theory
this config was always supported so it would not be a new bug.

This doesn't happen with the NXP vendor tree but there is quite a large
delta in uart dma code. In particular upstream dropped IDDMAEN claiming
that this works with both ROM and FW scripts, see commit 905c0decad28
("serial: imx: don't use idle condition detect for DMA transfers")

This doesn't seem to work on 6sx though and I don't know why :(

The issue can be worked-around by forcing RX script from ROM:

diff --git drivers/dma/imx-sdma.c drivers/dma/imx-sdma.c
@@ -894,9 +894,11 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
                break;
        case IMX_DMATYPE_UART:
-               per_2_emi = sdma->script_addrs->uart_2_mcu_addr;
+               //per_2_emi = sdma->script_addrs->uart_2_mcu_addr;
+               per_2_emi = 817;
                emi_2_per = sdma->script_addrs->mcu_2_app_addr;
                break;
        case IMX_DMATYPE_UART_SP:

The above doesn't look like a good fix. I tried to revert 905c0decad28
and resolve conflicts and that also seems to work, pushed here:
https://github.com/cdleonard/linux/commit/0a1757f467e6dc96037ec2e3ea7c88c5a4eb2ceb

You can find test code here (not very interesting):
https://source.codeaurora.org/external/imx/imx-test/tree/test/mxc_uart_test/mxc_uart_test.c?h=imx_4.14.62_1.0.0_beta

Any idea on how to fix this?

--
Regards,
Leonard