AM5718: SPL/uBoot console to UART6

Hi Fredrik,

By default am5718-idk does not wire out the UART6. Have you done board modifications for that or you use
a custom board with UART6 brought out?

Best Regards,
Keerthy

Hi,

It is a custom board, yes. If uboot runs on uart3 and linux on uart6 it works fine. So the hardware works fine.

Best regards,

Fredrik

Hi Fredrik,

If you are getting traces on Linux from UART6 then i believe you have already programmed the pinmux for UART6.
Have you changed the pinmux for am5718 in u-boot folder in board/ti/am57xx/mux_data.h?

In u-boot: arch/arm/dts/am57xx-idk-common.dtsi

chosen {
stdout-path = &uart3;
};

Should be changed to:

chosen {
stdout-path = &uart6;
};

This might need more steps but can you try the above?

Also share changes you made to enable console via uart6 in kernel?

- Keerthy

Hi,

Yes, I have tried that. The UART6 clock is not started, when I check the registers. I think that's the problem.

I'll post some diffs here for you:

diff --git a/arch/arm/dts/omap5-u-boot.dtsi b/arch/arm/dts/omap5-u-boot.dtsi
index 5a1c7bc9fe..3f7cff13e3 100644
--- a/arch/arm/dts/omap5-u-boot.dtsi
+++ b/arch/arm/dts/omap5-u-boot.dtsi
@@ -46,6 +46,20 @@
 	reg-shift = <2>;
 };
 
+&uart6 {
+	u-boot,dm-spl;
+	reg-shift = <2>;
+};
+
+&ipu1 {
+        status = "okay";
+        u-boot,dm-spl;
+};
+
+&ipu1_rst {
+        u-boot,dm-spl;
+};
+
 &mmc1 {
 	u-boot,dm-spl;
 };

diff --git a/arch/arm/mach-omap2/clocks-common.c b/arch/arm/mach-omap2/clocks-common.c
index 9ae93cf439..7855d51db6 100644
--- a/arch/arm/mach-omap2/clocks-common.c
+++ b/arch/arm/mach-omap2/clocks-common.c
@@ -793,6 +793,10 @@ static void setup_clocks_for_console(void)
 			CD_CLKCTRL_CLKTRCTRL_SW_WKUP <<
 			CD_CLKCTRL_CLKTRCTRL_SHIFT);
 
+	clrsetbits_le32((*prcm)->cm_ipu_clkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
+			CD_CLKCTRL_CLKTRCTRL_SW_WKUP <<
+			CD_CLKCTRL_CLKTRCTRL_SHIFT);
+
 	/* Enable all UARTs - console will be on one of them */
 	clrsetbits_le32((*prcm)->cm_l4per_uart1_clkctrl,
 			MODULE_CLKCTRL_MODULEMODE_MASK,
@@ -809,6 +813,11 @@ static void setup_clocks_for_console(void)
 			MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN <<
 			MODULE_CLKCTRL_MODULEMODE_SHIFT);
 
+	clrsetbits_le32((*prcm)->cm_l4per_uart6_clkctrl,
+			MODULE_CLKCTRL_MODULEMODE_MASK,
+			MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN <<
+			MODULE_CLKCTRL_MODULEMODE_SHIFT);
+
 	clrsetbits_le32((*prcm)->cm_l4per_uart4_clkctrl,
 			MODULE_CLKCTRL_MODULEMODE_MASK,
 			MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN <<
@@ -817,6 +826,10 @@ static void setup_clocks_for_console(void)
 	clrsetbits_le32((*prcm)->cm_l4per_clkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
 			CD_CLKCTRL_CLKTRCTRL_HW_AUTO <<
 			CD_CLKCTRL_CLKTRCTRL_SHIFT);
+
+	clrsetbits_le32((*prcm)->cm_ipu_clkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
+			CD_CLKCTRL_CLKTRCTRL_HW_AUTO <<
+			CD_CLKCTRL_CLKTRCTRL_SHIFT);
 }
 
 void do_enable_clocks(u32 const *clk_domains,

diff --git a/arch/arm/mach-omap2/omap5/hw_data.c b/arch/arm/mach-omap2/omap5/hw_data.c
index 5683d7e76b..c8a7e62b7b 100644
--- a/arch/arm/mach-omap2/omap5/hw_data.c
+++ b/arch/arm/mach-omap2/omap5/hw_data.c
@@ -493,6 +493,7 @@ void enable_basic_clocks(void)
 		(*prcm)->cm_wkup_wdtimer2_clkctrl,
 		(*prcm)->cm_l4per_uart1_clkctrl,
 		(*prcm)->cm_l4per_uart3_clkctrl,
+		(*prcm)->cm_l4per_uart6_clkctrl,
 		(*prcm)->cm_l4per_i2c1_clkctrl,
 #ifdef CONFIG_DRIVER_TI_CPSW
 		(*prcm)->cm_gmac_gmac_clkctrl,

diff --git a/arch/arm/mach-omap2/omap5/prcm-regs.c b/arch/arm/mach-omap2/omap5/prcm-regs.c
index 164b747cea..54921b75f4 100644
--- a/arch/arm/mach-omap2/omap5/prcm-regs.c
+++ b/arch/arm/mach-omap2/omap5/prcm-regs.c
@@ -972,6 +972,7 @@ struct prcm_regs const dra7xx_prcm = {
 	.cm_l4per_uart3_clkctrl			= 0x4a009850,
 	.cm_l4per_uart4_clkctrl			= 0x4a009858,
 	.cm_l4per_uart5_clkctrl			= 0x4a009870,
+	.cm_l4per_uart6_clkctrl			= 0x4a005580,
 	.cm_l4sec_clkstctrl			= 0x4a009880,
 	.cm_l4sec_staticdep			= 0x4a009884,
 	.cm_l4sec_dynamicdep			= 0x4a009888,

In my defconfig I added (not that I think it matters):
CONFIG_SPECIFY_CONSOLE_INDEX=y
CONFIG_CONS_INDEX=6

in am57xx-idk-commot.dtsi:

    chosen {
        stdout-path = &uart6;
    };

&uart6 {
    status = "okay";
};

I'd say that I've followed all the steps needed for running UART1, 2, 3, 4, 5, 7, 8, 9 as console. UART6 and 10 are special though.

Best regards,

Fredrik

Hi Fredrik,

How about the pin muxing changes? Can you please make sure the uart6_rxd and uart6_txd lines are
muxed fine?

- Keerthy

diff --git a/meta-gradientech/recipes-bsp/u-boot/files/git/board/ti/am5718_gt/mux_data.h b/meta-gradientech/recipes-bsp/u-boot/files/git/board/ti/am5718_gt/mux_data.h
index c0e50b0..46415e1 100644
--- a/meta-gradientech/recipes-bsp/u-boot/files/git/board/ti/am5718_gt/mux_data.h
+++ b/meta-gradientech/recipes-bsp/u-boot/files/git/board/ti/am5718_gt/mux_data.h
@@ -1491,8 +1491,14 @@ const struct pad_conf_entry core_padconf_array_essential_am5718_gt[] = {
 };
 
 const struct pad_conf_entry early_padconf[] = {
-       {UART2_CTSN, (M2 | PIN_INPUT_SLEW)},    /* uart2_ctsn.uart3_rxd */
-       {UART2_RTSN, (M1 | PIN_INPUT_SLEW)},    /* uart2_rtsn.uart3_txd */
+       {UART2_CTSN, (M2 | PIN_INPUT_SLEW)},    /* uart2_ctsn.uart3_rxd */
+       {UART2_RTSN, (M1 | PIN_INPUT_SLEW)},    /* uart2_rtsn.uart3_txd */
+
+       {MCASP1_AXR0, (M3 | PIN_INPUT | SLEWCONTROL)},  /* mcasp1_axr0.uart6_rxd */
+        {MCASP1_AXR1, (M3 | PIN_OUTPUT | SLEWCONTROL)}, /* mcasp1_axr1.uart6_txd */
+        {MCASP1_AXR2, (M3 | PIN_INPUT)},        /* mcasp1_axr2.uart6_ctsn */
+        {MCASP1_AXR3, (M3 | PIN_OUTPUT)},       /* mcasp1_axr3.uart6_rtsn */
+
        {I2C1_SDA, (PIN_INPUT_PULLUP | M0)},    /* I2C1_SDA */
        {I2C1_SCL, (PIN_INPUT_PULLUP | M0)},    /* I2C1_SCL */
 

From our mux data. They are muxed in the regular struct as well. And it works from Linux, without any pinmuxing in the dts to my knowledge. Adding it to early_padconf had no impact, and removing uart3 from early_padconf didn't stop uart3 from working.

Best regards,

Fredrik

Hi Fredrik,

https://e2e.ti.com/support/processors/f/791/p/738108/2726354?cm_session=6c143d9a-ff95-4978-8824-9e795bb41c62&cm_type=link&cm_link=f5318652-e8e3-4c57-91f0-11de16c09fb4&utm_campaign=6c143d9a-ff95-4978-8824-9e795bb41c62&utm_medium=email&utm_source=contactmonkey&utm_content=sales%201%3a1&utm_term=RE%3a+Help+Booting+up+TI+Sitara+AM5728#2726354

That patch covers pretty much what is needed. Could you verify?

Here is the original reference: https://e2e.ti.com/support/processors/f/791/p/875382/3269856#3269856

Best Regards,
Keerthy

Hi,

This is one of the patches that I've tried applying to UART6 with no luck.

As I've stated many times now, UART6 is different that the rest.

I don't think we are making any progress here, could you try to involve some expert?

Best regards,

Fredrik

Hi again,

Any news here?

Have a nice weekend!

Hi Fredrik,

I am checking internally on this. I will get back to you as soon as I have some updates.

Best Regards,
Keerthy

Hi Fredrik,

Apologies. I have not got inputs from our internal team. I am checking on them.
I will post as soon as i get feedback from them. In the meantime if you happen to
try out on your own please do not let me know.

Best Regards,
Keerthy

Hi Fredrik,

IPU is typically turned on and firmware is loaded at SPL level in SDK 6.03 & it should be out of reset. Have you already tried with 6.03 SDK?
Also what is the use case that needs UART6 only and not other UARTs? Is it more of experimenting & trying to get UART6 working or you
have a real use case that needs UART6 specifically?

- Keerthy

We will try an alternative approach: use UART5 for uboot/linux and UART6 for IPU1 terminal.

They are on same FTDI circuit, so it doesn't matter that much. Hopefully UART6 works better from IPU1.

Hi Fredrik,

Thanks. I will wait for your results.

- Keerthy