I am using a Verdin IMX95 with the IVY Plus carrier board. I need to use 3.3v UART for communication with a sensor. Unfortunately the only 3.3v UART port is used for the debug/console. The other two UART ports have RS232 or RS485 transceivers connected to them so I can’t use those. My plan is to switch the debug/console port to the UART connected to the RS232. What is the process to make this port change? Thank you
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
To help you properly configure the console UART port for your Verdin iMX95 with Ivy Plus carrier board setup, I need to clarify which OS and version you’re running on your device.
Could you please specify:
- Which OS are you using (e.g., Torizon OS, Yocto BSP)?
- What version are you running?
You can get this information by running the tdx-info command on your device. For more details about this command, see: Getting Device Information with Tdx-Info | Toradex Developer Center
UART Configuration Overview
Based on the Verdin iMX95 datasheet, the module provides multiple UART interfaces (1):
- UART_1: X1 pins 129, 131, 133, 135 (GPIO-based, 3.3V)
- UART_2: X1 pins 137, 139, 141, 143 (GPIO-based, 3.3V)
- UART_3: X1 pins 147, 149 (Primary console/debug port)
- UART_4: X1 pins 151, 153 (Secondary console/debug port)
The process for changing the console port will depend on your specific OS configuration, which is why I need to know your platform details first.
Common platforms to consider:
- Hardware: Verdin iMX95, Ivy Plus Carrier Board
- OS: Torizon OS 7.2.0, Yocto 7.2.0, BSP 7
- Implementation: Device tree overlay, U-Boot configuration
Once you provide the OS and version information, I can give you specific instructions for reconfiguring the console UART port.
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
I’m using a Yocto image for my board.
To help guide you through changing the console UART port on your Verdin iMX95 with Yocto, I need to know the specific version you’re running.
Could you please specify which version of Yocto BSP you’re using? You can get this information by running the tdx-info command on your device. For more details about this command, see: Getting Device Information with Tdx-Info.
Important Note About UART Port Changes
The documentation indicates that changing the debug UART from the default port is not recommended and may not be feasible on certain SoMs (1). Specifically, for i.MX 8 family SoMs (which includes your iMX95), it may be “nearly or even impossible to change the default UART” due to the System Controller Unit/System Controller Firmware (SCU/SCFW) or BootROM requirements (1).
Alternative Approach
Instead of changing the console port, consider these alternatives:
- Use a different UART for your sensor communication: The Verdin iMX95 provides multiple UART interfaces that you could potentially configure for 3.3V operation
- Level shifting solution: Use a level shifter to convert between the RS232 levels and 3.3V for your sensor
- Disable console output: You could disable the debug console entirely if you don’t need it for debugging (1)
Once you provide your specific Yocto BSP version, I can give you more detailed guidance on the available options for your setup.
Common Yocto versions to mention:
- BSP 7.x.y (Scarthgap)
- BSP 6.x.y (Kirkstone)
- Earlier versions
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
I’m building my own Yocto image on Scarthgap branch.
You can easily change the default Linux console to another UART using the U-Boot environment variable console.
Set it to ttymxc0 to use the RS-232 interface (UART1) on the Ivy board.
Unfortunately, changing the bootloader debug console is not as straightforward. Therefore, if it is acceptable for your sensor to receive some text over UART during the bootloader phase, this approach should work.
If that is not acceptable, you can use the UART1 3.3 V interface instead by soldering wires to the RA2 resistor array.
Thanks for your help.
Do you think these changes to UBoot is enough to switch the port completely?
imx95-console-port-change.patch (1.5 KB)
I am not sure whether these changes are sufficient, but the best way to verify this is to apply the diff, rebuild U-Boot, and test the console behavior on the target hardware.
Please also make sure that the selected UART is enabled and properly pinmuxed in the U-Boot device tree. In addition, the stdout-path, U-Boot console environment variable, UART clock initialization, and the actual UART instance you want to use should all point to the same UART.
Please note that we do not provide support for modifying the default U-Boot debug console.
You may try applying the changes and rebuilding U-Boot, but this would be considered a custom modification and would need to be validated on your side. We can only provide general guidance and cannot guarantee that such changes will work or be supported across BSP updates.
Got it. I haven’t received the imx95 yet but I’ll test it and report back. Hopefully it would help others down the road.
We recommend keeping the default debug UART dedicated to PC communication when designing a custom carrier board. Alternatively, please check the availability of other serial ports when selecting one of our existing carrier boards.
Based on your UART requirements, the Yavia or Mallow carrier board appears to be a better fit than the Ivy carrier board.
Unfortunately those alternate boards have other limitations mainly related to CAN port count or no transceiver. If my patch above works I consider an elegant solution. Thanks
I wish you good luck with this approach. However, based on our experience with similar attempts to change the default U-Boot console on other modules, such as Colibri iMX6, the success rate has been very low.
As an alternative, you may consider changing only the Linux console and keeping the default U-Boot debug console unchanged. If the issue is that the connected device must not receive any data during the bootloader stage, you could route the UART TX/ signal through a GPIO-controlled gate or buffer that is enabled only after Linux starts.
This approach prevents the external device from receiving bootloader console traffic.
Changing only the linux console maybe a viable solution. Do you know how to disable UBoot interruption? That might be my only concern - my UART device might send a signal during bootup that would cause UBoot to interrupt and not boot linux. Thanks
You can set bootdelay to 0. This makes U-Boot boot immediately without waiting for keyboard input. However there may still be a very small window where input could be processed.
A stronger option is:
setenv bootdelay -2
Disabling autoboot interruption also makes recovery and debugging through the U-Boot console more difficult. Please make sure this change is really necessary before applying it.
1 Like
Hi @dtran11 ,
All set with this?
Should we proceed and close this ticket or do you have further questions on this topic?
Best,
I’m good with this issue. Thanks for the support.