AM6422: How to use main uart1 as R5 debug serial

xixiguohx

Intellectual 720 points

Part Number: AM6422

Tool/software:

Hi TI experts,

Below are my debug environment,

Hardware: customized board based on AM6422

Software: A53 runs rt linux based on SDK 09.02

R5 runs RTOS based on MCU SDK 09.02

When I used uboot2021 to bootup, I can get the R5 debug logs on MAIN UART1.

When I used uboot2023 to bootup, I can not get R5 debug logs on MAIN UART1. But I'm sure that R5 is running, because I can see the R5 debug logs under the /sys/kernel/debug/remoteproc/remoteproc0/trace0.

The both version of uboot all keeps below configures in dts,

/* main_uart1 is reserved for firmware usage */
&main_uart1 {
	status = "reserved";
};

Both version of uboot disabled the TISCI debug trace. In uboot2021, disabled the TISCI trace debug with not define ENABLE_TRACE in board-cfg.c. In uboot2023, disabled the TISCI trace in board-cfg.yaml with trace_dst_enables : 0x00 .

And the linux kernel dts,

&main_uart1 {
	status = "disabled";

	pinctrl-names = "default";
	pinctrl-0 = <&main_uart1_pins_default>;

	rs485-rts-active-low;
	rs485-rx-during-tx;
	rs485-rts-delay = <1 0>;
	linux,rs485-enabled-at-boot-time;
};

The R5 .syscfg about MAIN UART1 is like below，

I don't know why the uboot2021 works, but uboot2023 does not work. Please help to give some suggestions, thank you!

xixiguohx

4 months ago

0 Vaibhav Kumar 4 months ago

TI__Mastermind 45086 points

Hi,

If the question is more on why the UART1 logs do not come on the COM PORT Terminal then I would suggest you to look at the correct UART which you would use.

Please refer: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1276094/faq-sk-am62-purpose-of-different-uarts

If you are referring the correct COM PORT, then I would let another expert look into this and comment further. The MCU PLUS SDK side of things look okay to me.

Please allow the other expert some time to comment on this query.

Thanks for your patience.

Regards,

Vaibhav

0 xixiguohx 4 months ago in reply to Vaibhav Kumar

Intellectual 720 points

Hi Vaibhav,

Thank you!

Because I need to debug both on A53 and R5, so I keep UART0 for A53 debug and want to use UART1 for R5 debug. I think I used the correct UART, because these work with uboot2021, I don't know why it does not work on uboot2023.

Thanks for help asking other experts, looking forward for their reply.

xixiguo

0 Bin Liu 4 months ago in reply to xixiguohx

TI__Guru**** 168231 points

Hi Xixiguo,

What are the exact software difference in both of your use case with U-Boot 2021 and U-Boot 2023? only the 3 U-Boot binaries are different but the reset of software, such as Linux and RTOS binaries are all the same?

0 xixiguohx 4 months ago in reply to Bin Liu

Intellectual 720 points

Hi Bin,

Yes, only the 3 U-boot binaries are different. The Linux and RTOS binaries are all the same, and I used power down to restart the board.

xixiguo

0 Bin Liu 4 months ago in reply to xixiguohx

TI__Guru**** 168231 points

Hi xixiguo,

I cannot think of any reason which would cause the problem. Can you please check the padconfig registers of the UART1 TXD/RXD pins in both cases if they are still the same?

0 xixiguohx 4 months ago in reply to Bin Liu

Intellectual 720 points

Hi Bin,

In the kernel dts, we have disabled the pins mode configure, and disabled MAIN_UART1 like bellow,

    main_uart1_pins_default: main-uart1-pins-default {
		pinctrl-single,pins = <
			/* AM64X_IOPAD(0x024c, PIN_OUTPUT, 7) /* (E16) UART1_485_DIR GPIO1.59*/
            /* AM64X_IOPAD(0x0240, PIN_INPUT, 0)  /* (E15) UART1_RXD */
			/* AM64X_IOPAD(0x0244, PIN_OUTPUT, 0) /* (E14) UART1_TXD */
            /* AM64X_IOPAD(0x017c, PIN_INPUT, 7)  /* (T1) UART1_485_Error GPIO1.7*/
		>;
	};
	
&main_uart1 {
	status = "disabled";

	pinctrl-names = "default";
	pinctrl-0 = <&main_uart1_pins_default>;

	rs485-rts-active-low;
	rs485-rx-during-tx;
	rs485-rts-delay = <1 0>;
	linux,rs485-enabled-at-boot-time;
};

So I think the R5 firmware take care of the MAIN UART1 pins configure in example.syscfg like bellow,

And I think it's correct, because uboot2021 works with these configures.

I'm really confused too. And I checked after the system started, the 0xF4240 and 0xF4244 values are,

root:~# devmem2 0xF4240
/dev/mem opened.
Memory mapped at address 0xffff8dc98000.
Read at address  0x000F4240 (0xffff8dc98240): 0x00050000
root:~# devmem2 0xF4244
/dev/mem opened.
Memory mapped at address 0xffff7f7a2000.
Read at address  0x000F4244 (0xffff7f7a2244): 0x00010000

Using uboot2021 or uboot2023 to bootup, the registers values are the same as above.

Is there any difference in uboot2021 and uboot2023 about the status = "reserved"?

xixiguo

0 Bin Liu 4 months ago in reply to xixiguohx

TI__Guru**** 168231 points

The devicetree handling for status property has always been the same.

0 xixiguohx 4 months ago in reply to Bin Liu

Intellectual 720 points

Hi Bin,

I'm sorry for the late reply due to the May Day holiday. I'm pretty sure that's because of the u-boot, but don't know the exactly where caused this.

xixiguo

0 Bin Liu 4 months ago in reply to xixiguohx

TI__Guru**** 168231 points

Hi Xixiguo,

No worries. Hope you had a great holiday break.

In theory, as long as the UART is initialized and the pin padconfig are programmed properly (which your devmem2 output should they are on your board), any program from any core could transmit characters to the UART port. I cannot think go any reason why different U-Boot would affect the MCU R5 program.

I am looping in our IPC expert for any input.

0 Nick Saulnier 4 months ago in reply to Bin Liu

TI__Guru** 101010 points

Hello Xixiguo,

How are the R5F cores being initialized? With Linux remoteproc driver during kernel boot? With u-boot rproc driver? during SBL boot, if you're using that instead of SPL boot?

Could I get you to post the trace logs you see for the core in working and non-working usecases? If this is a resource conflict where Linux or uboot is grabbing ownership of the UART1 before the R5F can request ownership, I usually see the R5F code get stuck during driver initialization in the main.c file. So it is pretty easy to drop a bunch of print statements in the R5F firmware and see how far the R5F code gets.

Regards,

Nick

0 xixiguohx 4 months ago in reply to Nick Saulnier

Intellectual 720 points

Hi Nick,

The R5F core is initialized with Linux remoteproc driver during kernel boot.

Of course, I have sent you the logs by private messages, thank you!

xixiguo

0 Nick Saulnier 4 months ago in reply to xixiguohx

TI__Guru** 101010 points

Hello Xixiguo,

Ok, so based on your logs it seems like the R5F RTOS drivers are getting loaded without any resource conflicts showing up. So it tentatively seems like no resource conflicts. I assume that on your UART terminal you see the same output as the Linux trace log. That also shows us that the R5F cores are actually loaded and running, and not just stalled out somewhere.

Bin already validated that the pinmuxing looks fine.

Those are the immediately obvious things I would want to check...

The next thing that would occur to me would be to verify the devicetree file settings that are actually getting applied on the board. I know that MCU+ R5F will complain if Linux has already grabbed ownership of a peripheral, but I am not sure what Linux would do if a Linux driver tried to grab a peripheral that was already owned by an MCU+ core. Let us know if you need guidance on how to check that.

Regards,

Nick

0 xixiguohx 4 months ago in reply to Nick Saulnier

Intellectual 720 points

Hi Nick,

Yes, please help to give the guidance to check if a Linux driver tried to grab a peripheral that was already owned by an MCU+ core.

Below is the tty info on my board,

class="ui-code" data-mode="text">root@xxx:~# dmesg | grep -i uart root 0 Dec 10 21:54 console -> ../../devices/virtual/tty/console root 0 Dec 10 21:55 ptmx -> ../../devices/virtual/tty/ptmx root 0 Dec 10 21:55 ptyp0 -> ../../devices/virtual/tty/ptyp0 root 0 Dec 10 21:55 ptyp1 -> ../../devices/virtual/tty/ptyp1 root 0 Dec 10 21:55 ptyp2 -> ../../devices/virtual/tty/ptyp2 root 0 Dec 10 21:55 ptyp3 -> ../../devices/virtual/tty/ptyp3 root 0 Dec 10 21:55 ptyp4 -> ../../devices/virtual/tty/ptyp4 root 0 Dec 10 21:55 ptyp5 -> ../../devices/virtual/tty/ptyp5 root 0 Dec 10 21:55 ptyp6 -> ../../devices/virtual/tty/ptyp6 root 0 Dec 10 21:55 ptyp7 -> ../../devices/virtual/tty/ptyp7 root 0 Dec 10 21:55 ptyp8 -> ../../devices/virtual/tty/ptyp8 root 0 Dec 10 21:55 ptyp9 -> ../../devices/virtual/tty/ptyp9 root 0 Dec 10 21:55 ptypa -> ../../devices/virtual/tty/ptypa root 0 Dec 10 21:55 ptypb -> ../../devices/virtual/tty/ptypb root 0 Dec 10 21:55 ptypc -> ../../devices/virtual/tty/ptypc root 0 Dec 10 21:55 ptypd -> ../../devices/virtual/tty/ptypd root 0 Dec 10 21:55 ptype -> ../../devices/virtual/tty/ptype root 0 Dec 10 21:55 ptypf -> ../../devices/virtual/tty/ptypf root 0 Dec 10 21:55 tty -> ../../devices/virtual/tty/tty root 0 Dec 10 21:55 tty0 -> ../../devices/virtual/tty/tty0 root 0 Dec 10 21:55 tty1 -> ../../devices/virtual/tty/tty1 root 0 Dec 10 21:55 tty10 -> ../../devices/virtual/tty/tty10 root 0 Dec 10 21:55 tty11 -> ../../devices/virtual/tty/tty11 root 0 Dec 10 21:55 tty12 -> ../../devices/virtual/tty/tty12 root 0 Dec 10 21:55 tty13 -> ../../devices/virtual/tty/tty13 root 0 Dec 10 21:55 tty14 -> ../../devices/virtual/tty/tty14 root 0 Dec 10 21:55 tty15 -> ../../devices/virtual/tty/tty15 root 0 Dec 10 21:55 tty16 -> ../../devices/virtual/tty/tty16 root 0 Dec 10 21:55 tty17 -> ../../devices/virtual/tty/tty17 root 0 Dec 10 21:55 tty18 -> ../../devices/virtual/tty/tty18 root 0 Dec 10 21:55 tty19 -> ../../devices/virtual/tty/tty19 root 0 Dec 10 21:55 tty2 -> ../../devices/virtual/tty/tty2 root 0 Dec 10 21:55 tty20 -> ../../devices/virtual/tty/tty20 root 0 Dec 10 21:55 tty21 -> ../../devices/virtual/tty/tty21 root 0 Dec 10 21:55 tty22 -> ../../devices/virtual/tty/tty22 root 0 Dec 10 21:55 tty23 -> ../../devices/virtual/tty/tty23 root 0 Dec 10 21:55 tty24 -> ../../devices/virtual/tty/tty24 root 0 Dec 10 21:55 tty25 -> ../../devices/virtual/tty/tty25 root 0 Dec 10 21:55 tty26 -> ../../devices/virtual/tty/tty26 root 0 Dec 10 21:55 tty27 -> ../../devices/virtual/tty/tty27 root 0 Dec 10 21:55 tty28 -> ../../devices/virtual/tty/tty28 root 0 Dec 10 21:55 tty29 -> ../../devices/virtual/tty/tty29 root 0 Dec 10 21:55 tty3 -> ../../devices/virtual/tty/tty3 root 0 Dec 10 21:55 tty30 -> ../../devices/virtual/tty/tty30 root 0 Dec 10 21:55 tty31 -> ../../devices/virtual/tty/tty31 root 0 Dec 10 21:55 tty32 -> ../../devices/virtual/tty/tty32 root 0 Dec 10 21:55 tty33 -> ../../devices/virtual/tty/tty33 root 0 Dec 10 21:55 tty34 -> ../../devices/virtual/tty/tty34 root 0 Dec 10 21:55 tty35 -> ../../devices/virtual/tty/tty35 root 0 Dec 10 21:55 tty36 -> ../../devices/virtual/tty/tty36 root 0 Dec 10 21:55 tty37 -> ../../devices/virtual/tty/tty37 root 0 Dec 10 21:55 tty38 -> ../../devices/virtual/tty/tty38 root 0 Dec 10 21:55 tty39 -> ../../devices/virtual/tty/tty39 root 0 Dec 10 21:55 tty4 -> ../../devices/virtual/tty/tty4 root 0 Dec 10 21:55 tty40 -> ../../devices/virtual/tty/tty40 root 0 Dec 10 21:55 tty41 -> ../../devices/virtual/tty/tty41 root 0 Dec 10 21:55 tty42 -> ../../devices/virtual/tty/tty42 root 0 Dec 10 21:55 tty43 -> ../../devices/virtual/tty/tty43 root 0 Dec 10 21:55 tty44 -> ../../devices/virtual/tty/tty44 root 0 Dec 10 21:55 tty45 -> ../../devices/virtual/tty/tty45 root 0 Dec 10 21:55 tty46 -> ../../devices/virtual/tty/tty46 root 0 Dec 10 21:55 tty47 -> ../../devices/virtual/tty/tty47 root 0 Dec 10 21:55 tty48 -> ../../devices/virtual/tty/tty48 root 0 Dec 10 21:55 tty49 -> ../../devices/virtual/tty/tty49 root 0 Dec 10 21:55 tty5 -> ../../devices/virtual/tty/tty5 root 0 Dec 10 21:55 tty50 -> ../../devices/virtual/tty/tty50 root 0 Dec 10 21:55 tty51 -> ../../devices/virtual/tty/tty51 root 0 Dec 10 21:55 tty52 -> ../../devices/virtual/tty/tty52 root 0 Dec 10 21:55 tty53 -> ../../devices/virtual/tty/tty53 root 0 Dec 10 21:55 tty54 -> ../../devices/virtual/tty/tty54 root 0 Dec 10 21:55 tty55 -> ../../devices/virtual/tty/tty55 root 0 Dec 10 21:55 tty56 -> ../../devices/virtual/tty/tty56 root 0 Dec 10 21:55 tty57 -> ../../devices/virtual/tty/tty57 root 0 Dec 10 21:55 tty58 -> ../../devices/virtual/tty/tty58 root 0 Dec 10 21:55 tty59 -> ../../devices/virtual/tty/tty59 root 0 Dec 10 21:55 tty6 -> ../../devices/virtual/tty/tty6 root 0 Dec 10 21:55 tty60 -> ../../devices/virtual/tty/tty60 root 0 Dec 10 21:55 tty61 -> ../../devices/virtual/tty/tty61 root 0 Dec 10 21:55 tty62 -> ../../devices/virtual/tty/tty62 root 0 Dec 10 21:55 tty63 -> ../../devices/virtual/tty/tty63 root 0 Dec 10 21:55 tty7 -> ../../devices/virtual/tty/tty7 root 0 Dec 10 21:55 tty8 -> ../../devices/virtual/tty/tty8 root 0 Dec 10 21:55 tty9 -> ../../devices/virtual/tty/tty9 root 0 Dec 10 21:55 ttyS0 -> ../../devices/platform/bus@f4000/2820000.serial/tty/ttyS0 root 0 Dec 10 21:55 ttyS1 -> ../../devices/platform/serial8250/tty/ttyS1 root 0 Dec 10 21:55 ttyS2 -> ../../devices/platform/bus@f4000/2800000.serial/tty/ttyS2 root 0 Dec 10 21:55 ttyS3 -> ../../devices/platform/serial8250/tty/ttyS3 root 0 Dec 10 21:55 ttyp0 -> ../../devices/virtual/tty/ttyp0 root 0 Dec 10 21:55 ttyp1 -> ../../devices/virtual/tty/ttyp1 root 0 Dec 10 21:55 ttyp2 -> ../../devices/virtual/tty/ttyp2 root 0 Dec 10 21:55 ttyp3 -> ../../devices/virtual/tty/ttyp3 root 0 Dec 10 21:55 ttyp4 -> ../../devices/virtual/tty/ttyp4 root 0 Dec 10 21:55 ttyp5 -> ../../devices/virtual/tty/ttyp5 root 0 Dec 10 21:55 ttyp6 -> ../../devices/virtual/tty/ttyp6 root 0 Dec 10 21:55 ttyp7 -> ../../devices/virtual/tty/ttyp7 root 0 Dec 10 21:55 ttyp8 -> ../../devices/virtual/tty/ttyp8 root 0 Dec 10 21:55 ttyp9 -> ../../devices/virtual/tty/ttyp9 root 0 Dec 10 21:55 ttypa -> ../../devices/virtual/tty/ttypa root 0 Dec 10 21:55 ttypb -> ../../devices/virtual/tty/ttypb root 0 Dec 10 21:55 ttypc -> ../../devices/virtual/tty/ttypc root 0 Dec 10 21:55 ttypd -> ../../devices/virtual/tty/ttypd root 0 Dec 10 21:55 ttype -> ../../devices/virtual/tty/ttype root 0 Dec 10 21:55 ttypf -> ../../devices/virtual/tty/ttypf re/devicetree/base/bus@f4000/serial@2810000# cat status

xixiguo

0 Bin Liu 4 months ago in reply to xixiguohx

TI__Guru**** 168231 points

Hi Xixiguo,

I don't expect Linux would be a problem, since you said the only software change is the u-boot binaries. But anyway, please attach the full Linux boot log with uboot2023.

0 xixiguohx 4 months ago in reply to Bin Liu

Intellectual 720 points

Hi Bin,

I have sent the logs to you by private message, thank you!

xixiguo

0 Bin Liu 4 months ago in reply to xixiguohx

TI__Guru**** 168231 points

Hi Xixiguo,

Thanks for providing the logs. I didn't see anything obviously wrong which could lead to this main uart1 problem, but the log shows you use U-Boot 2023.10, which is not a supported version by Processor SDK. Can you please use U-Boot 2023.04 which is provided in SDK9.02 to see if the problem still happens?

0 xixiguohx 4 months ago in reply to Bin Liu

Intellectual 720 points

Hi Bin,

I will try it, but it will take sometime to do the transplant based on our board. Later when I finish it, I will let you know here, thank you!

xixiguo

Processors

Processors forum

AM6422: How to use main uart1 as R5 debug serial