My environment: Linux verdin-imx8mm-15034785 5.15.129-6.4.0-devel+git.21e464ea92b9 #1-TorizonCore SMP PREEMPT Tue Oct 10 13:30:12 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
We design our own carrier board and we need to use all 4 uarts (naming is Verdin Std Function):
UART1 for RS485
UART2 for RS485
UART3 for A53 debug
UART4 for RS485
So now I’m quite confused: in the Verdin iMX8MM Datasheet it is written:
UART_4 is in the “Reserved” class. This interface is
intended to be used for the real-time operating system (M4 core). The interface may be used as
But my understanding of different topics here is:
I can only use UART4 with the iMX8M mini Boards as general-purpose UART if I work with Yocto (see uart4-on-verdin. Not as we intend to work with Torizoncore.
So my question: can I use UART4 on iMX8M mini Verdin Board with torizoncore?
First of all, you are correct that the 4th UART is hard-coded for use by the M4 core. That said there is a way you might be able to work around this.
The spot where this UART is specified for use by the M4 is in the Arm-trusted-firmware. Specifically here: https://github.com/nxp-imx/imx-atf/blob/lf_v2.6/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c#L106
You can see via the system’s resource domain controller this UART gets assigned to the M4. This would need to be changed here. Specifically this line:
RDC_PDAPn(RDC_PDAP_UART4, D1R | D1W),
Would need to be changed to:
RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W),
This un-assigns the UART so it can be used by the normal A-cores.
Now once you do this change how can you deploy it on TorizonCore? You would need to build the arm-trusted-firmware into a new bootloader binary as documented here: Build U-Boot for NXP i.MX-based System on Modules | Toradex Developer Center
Then you can upload this customer bootloader for use in a Bootloader update to deploy to Torizon OS devices: Bootloader Updates in Torizon OS | Toradex Developer Center
All that said, as you can see it’s quite an involved process. Also you would need to maintain this custom bootloader going forward which is not ideal.
Now let me ask you something. As shown there is a path here to use the 4th UART on the Verdin i.MX8M Mini. But it’s not trivial work I would say. Have you and your team considered maybe adding additional UARTs via external hardware? That way you wouldn’t have to do all this and maintain the custom bootloader. Just suggesting a possibility.
Thanks a lot for the answer!
Yes, we considered to have an additional UART via HW (eg. SIC6IS7xx, for which you also provide the kernelmodul). The point is that this costs additional.
But of course you’re right, disable the UART4 for M4 debugging in the ATF is not trivial and I don’t like the idea of have a custom bootloader and maintain it. To have no maintanance for bootloader and kernel is one of the reasons that we choosed torizoncore.
Just a last question: do you know if you provide or could provide anothter SPI to UART Interface chip as module in the above mentioned Kernel? The SIC6IS7xx hasn’t 1.8V compatibility so we need another level shifter and power supply, what brings up even more costs.
do you know if you provide or could provide anothter SPI to UART Interface chip as module in the above mentioned Kernel? The SIC6IS7xx hasn’t 1.8V compatibility so we need another level shifter and power supply, what brings up even more costs.
You’re talking about software kernel modules correct? If that is the case then yes we can fairly easily add kernel modules to Torizon OS, assuming it’s readily available in the kernel version we use. You just need to let us know what kernel module specifically you’d like us to add.
I assume you’ll go and evaluate some UART options and get back to us once you’ve settled on something.