Hi Alex,
We tried it on another board, getting the same issue. For some more context, changed setenv settings to include console and ttyLP1. Verified on the host that the baud and other settings match up. Is there anything else that we may be missing on the apalis settings?
Thanks
Hi Alex,
Looking at similar threads, realized UART 1 and UART 2 are rs 232 and operate at different voltage levels, we were using usb to uart adapter which likely wouldn’t work. Could you please confirm the same?
Thanks
The Apalis module itself uses 3.3V I/O levels, including for UART signals. The Ixora carrier board features a MAX3243 RS-232 transceiver on UART1 and UART2, which converts these 3.3V UART signals to RS-232 voltage levels, available on the X21 and X22 connectors.
Please check Ixora carrier board datasheet and schematic for more details.
Please note that to connect an RS-232 cable to the Ixora board, you will need a 10-pin IDC to DB9 adapter. The adapter must follow the DTK or Intel standard, which is not compatible with most commonly available PC-style DB9 adapters, even though they may appear similar in form
Hi Alex,
We were able to get the boot logs, here they are:
U-Boot 2024.04-7.3.0+git.4db7ef83ebd6 (Jan 01 1970 - 00:00:00 +0000)
CPU: NXP i.MX8QM RevB A53 at 1200 MHz at 30C
DRAM: 8 GiB
Core: 203 devices, 24 uclasses, devicetree: separate
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Model: Toradex 0067 Apalis iMX8QM 8GB WB IT V1.1A
Serial#: 15610250
Boot: MMC0
Reset cause: POR
BuildInfo:
- SCFW 83624b99, SECO-FW c9de51c0, IMX-MKIMAGE 71b8c18a, ATF lf-6.6.
- U-Boot 2024.04-7.3.0+git.4db7ef83ebd6
flash target is MMC:0
Net: eth0: ethernet@5b040000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
MMC: no card present
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
969 bytes read in 1 ms (946.3 KiB/s)
## Executing script at 9d480000
7086 bytes read in 2 ms (3.4 MiB/s)
179208 bytes read in 6 ms (28.5 MiB/s)
38 bytes read in 2 ms (18.6 KiB/s)
Working FDT set to 9d400000
Applying Overlay: lpuart0-dma-overlay.dtbo
473 bytes read in 2 ms (230.5 KiB/s)
11497894 bytes read in 250 ms (43.9 MiB/s)
13143221 bytes read in 286 ms (43.8 MiB/s)
Uncompressing Kernel Image to 0
## Flattened Device Tree blob at 9d400000
Booting using the fdt blob at 0x9d400000
Working FDT set to 9d400000
Loading Device Tree to 00000000fd628000, end 00000000fd676fff ... OK
Working FDT set to fd628000
/bus@5a000000/dma-controller@5a1f0000, 58480
/bus@5a000000/dma-controller@5a9f0000, 59712
/bus@59000000/dma-controller@591f0000, 24036
/bus@59000000/dma-controller@591f0000, 24036
/bus@59000000/dma-controller@599f0000, 25388
Starting kernel ...
[ 1.120496] mu_a1: failed to power off resource 214 ret -22
Starting systemd-udevd version 255.21^
sysroot.readonly configuration value: 0 (fs writable: 1)
Using legacy ostree bind mount for /
[ 6.798400] nvmem imx-scu-ocotp0: cell mac raw len 6 unaligned to nvmem word size 4
[ 6.806261] nvmem imx-scu-ocotp0: cell mac raw len 6 unaligned to nvmem word size 4
[ 6.998543] imx-audmix imx-audmix.0: failed to find SAI platform device
[ 23.223376] Bluetooth: hci0: unexpected event for opcode 0x0000
Torizon OS 7.3.0+build.18 apalis-imx8-15610250 ttyLP1
This says that lpuart0-dma-overlay.dtbo is getting applied. I also confirmed that the overlay was applied successfully:
$ cat /proc/device-tree/chosen/overlays/lpuart0-dma-overlay.dtbo
0
When I check the registered interrupts, here’s what I see:
$ cat /proc/interrupts | grep edma
22: 0 0 0 0 0 0 GICv3 489 Level edma2-chan8-rx
23: 0 0 0 0 0 0 GICv3 491 Level edma2-chan9-tx
24: 0 0 0 0 0 0 GICv3 493 Level edma2-chan10-rx
25: 0 0 0 0 0 0 GICv3 495 Level edma2-chan11-tx
27: 0 0 0 0 0 0 GICv3 349 Level edma2-chan15-tx, edma2-chanx
31: 0 0 0 0 0 0 GICv3 360 Level edma2-chan19-tx
42: 0 0 0 0 0 0 GICv3 448 Level edma0-chan0-rx
43: 0 0 0 0 0 0 GICv3 449 Level edma0-chan1-tx
46: 0 0 0 0 0 0 GICv3 452 Level edma0-chan4-rx
47: 0 0 0 0 0 0 GICv3 453 Level edma0-chan5-tx
52: 0 0 0 0 0 0 GICv3 468 Level edma0-chan14-rx
53: 0 0 0 0 0 0 GICv3 469 Level edma0-chan15-tx
Channels 12 and 13 are still not in this list. Given that there’s confirmation that the device tree overlay got applied properly, can we assume DMA is enabled for those channels? Or is there something else we’re missing?
Could you please collect the full boot log from the debug UART and share it here as a plain text attachment?
This is all that’s being printed. After this point, UART prompts to log in and runs the shell.
What OS image you are using?
We’re using the same build as before, torizon OS 7.3.0+build.18
I should also correct a statement we made earlier in the thread:
according to the link you shared, 0 means the overlay was applied successfully, so that seems to work.
Yes, looks loke overlay was applied successfully. Now we need to figure out why it doesn’t work.
Could you please attach a dmesg output here?
dmesg.log (43.0 KB)
I attached the dmesg log.
Do you have files dmas and dma-names at /proc/device-tree/bus@5a000000/serial@5a060000/ when your dma overlay applied?
Hi Alex, yes we do see them
Hi Alex,
I believe we figured it out. The interrupts seem to be registered lazily, and earlier we were checking right after flashing the OS and adding the overlay, so there was no consumer actually using the UART TTY. We tested with a usecase where we start using the UART channel, and see that channel 12 and 13 appear in the registered interrupts list after that point.
Thanks for your help!