Change U-Boot UART for the verdin

Technical Support
, , , ,
1

Hi,

I am trying to change the debug UART the verdin board. I have managed to change the output of the kernel and spawn a console after the device has started. However I am not trying to change the uboot output to the same port, but with no success. I am trying to redirect the output to the port that is defined as /dev/ttymxc2 in userspace, which should be defined as UART_2 by the toradex documentation.

I am building u-boot and the and container according to this page. I have verified that the build is correct and works on my verdin.

As an example I have used the patches mentioned in this topic. This means that I have made the following changes:

In this file I changed line 142:

- #define CONFIG_MXC_UART_BASE		UART1_BASE_ADDR
+ #define CONFIG_MXC_UART_BASE		UART3_BASE_ADDR

and in In this file I changed line 46-50:

  -  /* Verdin UART_3, Console/Debug UART */
  -  static iomux_v3_cfg_t const uart_pads[] = {
  -  	IMX8MM_PAD_SAI2_RXFS_UART1_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
  -  	IMX8MM_PAD_SAI2_RXC_UART1_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
  -  };

  +  /* Verdin UART_2, Console/Debug UART */
  +  static iomux_v3_cfg_t const uart_pads[] = {
  +  	IMX8MM_PAD_SAI3_TXFS_UART2_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
  +  	IMX8MM_PAD_SAI3_TXC_UART2_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
  +  };

The definitions of the pin numbers have been retrieved from this pin definition file. But this does not seem to work. And this brings me to the following questions that are aimed to get the output to the correct UART port:

  1. Are this all the steps needed to redirect the UART output or is there some other place I have to update a defintion?
  2. In the pin definition file there are multiple UART3_RX/TX entries, how come there are multiple definitions and how do I know which one is the correct one?
2

You also need to make a changes to the U_Boot Device Tree. Modify stdout-path and replace each uart1 by uart3 here.

3

Ok, so as you commented, in this file I have updated:

chosen {
-		bootargs = "console=ttymxc0,115200 earlycon=ec_imx6q,0x30860000,115200";
-		stdout-path = &uart1;

+		bootargs = "console=ttymxc2,115200 earlycon=ec_imx6q,0x30880000,115200";
+		stdout-path = &uart3;
	};

And replaced uart1 with uart3 on line numbers 97 and 122 in this file. But the serial is not moved to the intended UART. In fact, u-boot is not starting at all, which suggests I something is not right. To verify that these changes caused the issue (and not some other file that is part of the boot container), I have reverted the changes made explained in this topic, and everything works (but the wrong UART). So what I still wrong here?

4

A update from my side:
Looking at the verdin datasheet (page 45), I am not convinced that in this file (line 46) the correct definition for UART that is mapped to /dev/ttymxc2 should be:

static iomux_v3_cfg_t const uart_pads[] = {
        IMX8MM_PAD_ECSPI1_MOSI_UART3_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
        IMX8MM_PAD_ECSPI1_SCLK_UART3_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
};

But this did not solve the problem. U-Boot still does not start.

5

Hi @StevenMedusa

Which Carrier board are you using?
Could you provide the version of the Bsp?

Thanks and best regards,
Jaski

6

Hi Jaski,

Thank your for your response. We are using a the Verdin Development board V1.0B (eventually we will move to our custom carrier board). Using BSP version 5.0.0 / 5.1.0 (according to this page). Not really sure if we use the 5.0.0 or 5.1.0

7

Don’t forget to adjust TF-A as well.

http://git.toradex.com/cgit/imx-atf.git/commit/?h=toradex_imx_5.4.70_2.3.0&id=f24b57e7728c3b4b4b21bcb510f4e26b86c011ba

8

Ah yes, I did not do this.
I have changed this address to 0x30880000 and did the building of the ATF with the command make PLAT=imx8mm IMX_BOOT_UART_BASE=0x30880000 bl31

But unfortunately the verdin still doesn’t start. Is there some way I can check if this is due to the ATF or due to an uboot configuration error?

9

Hi @StevenMedusa

It is not possible to check what is really the issue. We had to do lot of effort to make the console work on UART1. Is there any strong reason, why you want to change the console port?

Best regards,
Jaski

10

Hmm, that makes it a very difficult issue to debug. In our hardware design we have reservered thus UART as the debug UART and the current UART as a functional UART. This is because we were under the assumption that this would be configurable and therefore the choice of UARTs didn’t really matter. Since this is all software my current understanding is that cannot make it work (yet), because I do not fully understand how to configure UART port.

Based on your answer I get the idea that you suggest that we should change the hardware design so that it is not necessary to change the UART. And this is because you also don’t fully understand how to configure this port and need to put effort in to get this understanding. Is this correct?

11

Yes, we were in the same situation. I am not sure if this is possible at all. I found this thread on NXP forum:

https://community.nxp.com/t5/i-MX-Processors/i-MX8MQ-serial-debug-console-port-change/m-p/1023774

I wrote internally also to the Hardware Team, so they can check and change the hardware design guide. I am sorry for the inconvenience.

Maybe you can check this with NXP too.

12

Ah, that topic indeed suggests that it is not possible. Still it would be nice to learn why this is the case. I do not understand why the kernel can redirect it’s output, but the bootloader cannot.

13

Actually this NXP post is about iMX8MQ and you are using iMX8MM. What I wanted to point out, that it should be possible to change, since we did the same on our carrier board.

NXP is using uart2 and we switched to uart1. So maybe you can also check the U-Boot from NXP what is different there.

Best regards,
Jaski