Re Enabling /dev/ttymxc1 on Colibri iMX7

Technical Support
, , ,
1

Hello

For an already launched product we are using our version of boot2qt 5.15 image with kernel revision 5.4.193 (downstream)

During development process we have been using Cortex M4 console output for debugging and at some point we somehow have disabled “/dev/ttymxc1” (UART_B) access from the Kernel. Now we need to use this UART port for a different peripheral on A7 side but we couldn’t re-enable it.

I confirmed that both on Toradex Colibri iMX7 BSP5 Reference Minimal Image and Boot2qt 5.15 Colibri iMX7 that this peripheral is enabled and listed under /dev/ttymxc*

What I tried so far:

On u-boot I set “m4boot=;” to avoid loading the firmware (this stopped the console output)

I used “imx7d-colibri-emmc-eval-v3.dtb” file from the tdx reference image on our device (no overlays) incase it was a devicetree issue (which I already confirmed that nothing is disabling uart2)

I used “zImage” from tdx reference image on our device (incase it was a defconfig issue)

Non of these helped to get the “/dev/ttymxc1” to appear on kernel

Then I tried in reverse, our zImage and dtb files on a target with “tdx-reference-minimal image” and I still get “/dev/ttymxc1”

I am suspecting that it might be either a u-boot configuration which we did not rebuild or modify other than the environmental variables or a command that we are missing during the boot.

Are there any commands in run time or enviromental variables of u-boot that would disable this port?

Thanks in advance,
Fahri

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello Fahri,

Thank you for your detailed explanation.

Based on your testing, since your kernel and device tree function correctly on the Toradex reference image but not on your boot2qt system, this strongly suggests a runtime or U-Boot configuration difference rather than a device tree or kernel issue.

U-Boot Environment Variables Affecting UART Availability

There are several U-Boot environment variables to check, as they may affect the availability or usage of UART ports:

  1. console – Defines the debug console port. For the Colibri iMX7, it’s usually ttymxc0. If set incorrectly, it could interfere with other UARTs.
  2. tdxargs – Adds kernel parameters. Parameters here could enable/disable serial ports, or set them to alternate functions.
  3. fdtfile – Should match your board, but you’ve already tested the reference .dtb.

To check the current values of these variables in U-Boot, enter the following at the U-Boot prompt:

printenv
printenv console
printenv tdxargs

Compare the output with one from a working reference minimal image. Pay special attention if the kernel command line contains options like console=ttymxc1 (which can tie the port to the kernel console), or anything related to serial/UART disabling.

Next Steps/Suggestions:

  • Compare U-Boot Variables: Compare all U-Boot environment variables between your boot2qt and the reference image (guide).
  • Check kernel boot arguments: Sometimes, extra arguments can disable certain UARTs or set pinmuxing incorrectly. Review the full bootargs line passed to the kernel.
  • Check pinmuxing: If early in boot (e.g., in SPL or U-Boot) pins are set to a different function, it could prevent the kernel driver from claiming the peripheral—but since the device tree is the same and works on another rootfs, this is unlikely.
  • Overlay/Init Scripts: Ensure that on your boot2qt rootfs, no init scripts or Qt services (systemd, custom scripts, etc.) are manipulating udev rules or permissions for ttymxc1.
  • Restore U-Boot defaults: If you suspect corrupted or unintended settings:
    env default -a
saveenv
    (Note: This retrieves factory defaults for all U-Boot variables, use with caution.)

Documentation for reference:

Would you like guidance on how to compare the variables or interpret the bootargs line?

Best regards, Toradex AI Assistant.

3

Thank you @ToradexAI for the answer

As usual %95 of the time I found the problem 2 minutes after posting this which also the @ToradexAI suggests.

Comparing the uEnv.txt file from b2qt reference image to ours I might have found the dirtiest way to modify dtb file.

fdt_fixup=fdt addr ${fdt_addr_r} && fdt rm /soc/aips-bus@30800000/spba-bus@30800000/serial@30890000

This line from environmental variables of u-boot was removing the serial port node at every boot of our system.

Now all good! Thanks again

Fahri

4

Thanks for your response.

Please remember to tick the “Solution” checkbox below if my response solves your question. If you have follow-up questions, just continue to tag me using @ToradexAI in your new posts.

Did you like my answer? :+1: :-1:

Hello Fahri,

That’s great news, and thank you for sharing your findings! Indeed, the variable is a runtime device tree modification command in U-Boot, and as you noticed, it was removing the (UART_B/ttymxc1) node before booting the kernel. This is a powerful—but, as you noted, sometimes dangerous—mechanism in U-Boot for adjusting hardware configuration at boot time. It’s easy to overlook if you’re focusing on device tree or kernel differences alone.

For future reference, to check or manage U-Boot environment variables in Linux, you can use , or use in the U-Boot shell. Documentation for these features can be found here:

Congratulations on resolving the issue and thank you once again for closing the loop!

Best regards, Toradex AI Assistant.