UART2 device reads 'random' data after porting from BSP 2.8 to BSP 5.5

We are using the Apalis iMX6 Quad 1GB on a custom carrier board.

I’ve been porting our firmware from BSP 2.8 to BSP 5.5 and ran into the following problem when testing our UART2 (/dev/ttymxc1) port. Writing to the port works without issue (verified with a logic analyzer), however, reading from the port gives wrong/random data. The response data that is sent from the remote device shows up properly on the logic analyzer though.

What is especially strange is when I cat from /dev/ttymxc1 I get the following output (I am expecting 6 bytes from the remote device):

cat /dev/ttymxc1 
@è!�b���������X!�b�����������	et�����������nding 6
nr_mlock 0
nr_page_table_pages 126
nr_kernel_stack 904
nr_bounce 0
nr_free_cma 48883
nr_inactive_anon 1173
nr_active_anon 2008
nr_inactive_file 10284
nr_active_file 5521
nr_unevictable 0
nr_slab_reclaimable 1762
nr_slab_unreclaimable 3023
nr_isolated_anon 0
nr_isolated_file 0
workingset_nodes 0
workingset_refault 0
workingset_activate 0
workingset_restore 0
workingset_nodereclaim 0
nr_anon_pages 1951
nr_mapped 3572
nr_file_pages 17045
nr_dirty 6
nr_writeback 0
nr_writeback_temp 0
nr_shmem 1242
nr_shmem_hugepages 0
nr_shmem_pmdmapped 0
nr_file_hugepages 0
nr_file_pmdmapped 0
nr_anon_transparent_hugepages 0
nr_unstable 0
nr_vmscan_write 0
nr_vmscan_immediate_reclaim 0
nr_dirtied 129
nr_written 121
nr_kernel_misc_reclaimable 0
nr_dirty_threshold 41883
nr_dirty_background_threshold 20916
pgpgin 68820
pgpgout 42840
pswpin 0
pswpout 0
pgalloc_normal 118433
pgalloc_high 0
pgalloc_movable 0
allocstall_normal 0
allocstall_high 0
allocstall_movable 0
pgskip_normal 0
pgskip_high 0
pgskip_movable 0
pgfree 363201
pgactivate 4510
pgdeactivate 0
pglazyfree 0
pgfault 133192
pgmajfault 537
pglazyfreed 0
pgrefill 0
pgsteal_kswapd 0
pgsteal_direct 0
pgscan_kswapd 0
pgscan_direct 0
pgscan_direct_throttle 0
pginodesteal 0
slabs_scanned 0
kswapd_inodesteal 0
kswapd_low_wmark_hit_quickly 0
kswapd_high_wmark_hit_quickly 0
pageoutrun 0
pgrotated 0
drop_pagecache 0
drop_slab 0
oom_kill 0
pgmigrate_success 0
pgmigrate_fail 0
compact_migrate_scanned 0
compact_free_scanned 0
compact_isolated 49171
compact_stall 0
compact_fail 0
compact_success 0
compact_daemon_wake 0
compact_daemon_migrate_scanned 0
compact_daemon_free_scanned 0
unevictable_pgs_culled 0
unevictable_pgs_scanned 0
unevictable_pgs_rescued 0
unevictable_pgs_mlocked 0
unevictable_pgs_munlocked 0
unevictable_pgs_cleared 0
unevictable_pgs_stranded 0
swap_ra 0
swap_ra_hit 0
0 0 0 0 0 16 0 0 0 0 0 22 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 20 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 35 0 0 0 0 0 0
IpExt: InNoRoutes InTruncatedPkts InMcastPkts OutMcastPkts InBcastPkts OutBcastPkts InOctets OutOctets InMcastOctets OutMcastOctets InBcastOctets OutBcastOctets InCsumErrors InNoECTPkts InECT1Pkts InECT0Pkts InCEPkts ReasmOverlaps
IpExt: 0 0 229 25 27 0 167686 19251 145389 3336 5164 0 0 418 0 0 0 0
         0          0          0          0       GPC 113 Level     mmdc_1
 75:          0          0          0          0       GPC 114 Level     mmdc_1
 76:          1          0          0          0       GPC   9 Level     galcore:0
 77:          1          0          0          0       GPC  10 Level     galcore:2d
 78:          1          0          0          0       GPC  11 Level     galcore:vg
 79:          0          0          0          0       GPC   8 Level     2800000.ipu
 80:          0          0          0          0       GPC   7 Level     2800000.ipu
 85:          0          0          0          0  gpio-mxc   4 Edge      Wake-Up
111:          1          0          0          0  gpio-mxc  30 Level     2188000.ethernet-1:07
209:          0          0          0          0  gpio-mxc   0 Edge      edt-ft5306
305:         22          0          0          0       GPC 105 Level     2101000.jr0
306:          0          0          0          0       GPC 106 Level     2102000.jr1
IPI0:          0          0          0          0  CPU wakeup interrupts
IPI1:        102        100        113         62  Timer broadcast interrupts
IPI2:       1280       3628       1138        970  Rescheduling interrupts
IPI3:        293        780        740        795  Function call interrupts
IPI4:          0          0          I5:       2237       1658        331        824  IRQ work interrupts
IPI6:          0          0          0          0  completion interrupts
Err:          0
etries:        4

Tick Device: mode:     1
Per CPU device: 3

Here are the relevant parts of our device tree

    pinctrl_custom_uart2: custom_uart2 {
        fsl,pins = <
        MX6QDL_PAD_SD4_DAT4__UART2_TX_DATA   0x1b0b1
        MX6QDL_PAD_SD4_DAT7__UART2_RX_DATA   0x1b0b1
        >;
    };
&uart2 {
	status = "okay";
	pinctrl-0 = <&pinctrl_custom_uart2>;
	/delete-property/uart-has-rtscts;
	/delete-property/fsl,uart-has-rtscts;
};
# dmesg | grep ttymxc1
[    1.318103] 21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 69, base_baud = 5000000) is a IMX
# fw_printenv | grep tty
console=ttymxc0

Any idea what I am missing here? Is this some kind of dma issue?

Hi @dieteric !

I would like to ask you some questions to better understand what is going on.

Just to clarify, the lines after your cat /dev/ttymxc1 are the output of the command?

Could you share the physical connection setup (photo/schematics/…) that you used on this test?

I suppose that you are porting your layers and recipes (Yocto) to the BSP 5.5, right? If you use the default reference image from BSP 5.5 (tdx-reference-minimal-image), do you get the same behavior?

Have you made any modifications related to the UART other than the device tree customizations that you shared? Maybe something on the drivers?

Also, really seems like something is sending data to your /dev/ttymxc1 other than the 6 bytes that you were expecting. Could you double-check it?

Best regards,

Hi @henrique.tx ! Thank you for your response.

I’ve managed to find the culprit. I went back to the default kernel defconfig and devicetree (which turned out to be working) and gradually applied the changes until it broke. It turned out to be this defconfig entry:

CONFIG_IMX_SDMA=y

I don’t know why this was changed from m to y in our old kernel but changing it back to its default m value fixes the issue.

Thank you for your help!

Hi @dieteric !

Great to know that you found the issue! And thanks for sharing.

Best regards,