How can i disable the debug console so that i can repurpose UART4.

[vbuon.1]

hi,

i would like to disable the uart debug console so that i can use uart4 for something else.

how do i disable the console?

thanks,

vince

[Bubbles]

Hi @vbuon.1​ ,

on what product?

BR,

J

[Olivier GALLIEN]

Hi @vbuon.1​ ,

From the tag and your post history I presume it's about STM32MP15 and OpenSTLinux Device Tree settings.

Look at the property stdout-path which link the console to an UART.

You can modify or remove it.

Similar question was treated here :

https://community.st.com/s/question/0D53W000019ePr2SAE/change-default-tfa-and-uboot-serial-linux-console

Hope it help,

Olivier

[vbuon.1]

hi,

thanks for the response.

this is for the mp1.

i commented out the property stdout-path in the device tree files for kernel, u-boot and t-fa. i also removed the lines for u-boot,dm-pre-reloc. the only change that stopped console messages from going to the console was renaming the alias for uart4. instead of using the alias serial0 i used serial4. this stopped messages from being logged to the console.

unfortunately, the cube programmer was only able to flash two of four boards. the two boards that failed the cube programmer printed the following error message:

RUNNING Program ... 
 PartID: :0x03 
 
Reconnecting the device ...
 
Error: 
Unable to reconnect the target device: time out expired
 
Error: Start operation failed at partition 0x03
Error: TSV flashing service failed

if i put the alias back to serial0 then the flashing works.

i have also tried to the following line in the kernel arguments list but it did not work:

console=ttynull

any other suggestions would be appreciated.

thanks,

vince

[Olivier GALLIEN]

@vbuon.1​ 

Will need more information to help.

First what is rational to repurpose UART4 which is the recommand one for Linux console ?

Do you plan to use console with another UART or no console at all ( which is a problem for debug) ?

Please confirm the 4 tested boards are identical custom board on your side ?

You are flashing through USB DFU ?

Could you please share complete log for a working flash operation and failed one ?

Joining working and not working Uboot DTS could also help.

u-boot,dm-pre-reloc is a property that has nothing to do with console management. I recommend to not touch it.

Olivier

[vbuon.1]

Hi,

the reason for disabling the debug console is to connect two of our devices to UART4. we enabled the ability to use ethernet over usb so that we can ssh into the mp1. this will give us the ability to monitor dmesg to check if there are errors or if we need to do other types of debugging.

currently our devices are connected to usart1. but, usart1 is not behaving like usart3 where we have another one of our devices connected. we have usart1 connected to the mdma like usart3 is connected to one of the other dmas. however, there are times when usart1 does not send us the data that is sent by one of the devices. when a subsequent request for data is sent to one of the devices we will get the data for the current request as well as the data for the previous request. it’s as if usart1 is holding back the data until it receives another byte of data.

all four of the custom boards are identical to each other. we are flashing using usb dfu mode. there is only one set of dts files that are used to remove the debug console.

as requested, i have attached the dts files that i use to disable the debug console as well as the log files for the successful flashing and the failed flashing of the custom boards.

thank you for your help,

vince

[vbuon.1]

hi,

we decided to switch to uart4 which is configured similarly to usart3. we configured the console to use usart7 (currently not being used on our custom board) instead of uart4. we rerouted the uart signals to our device to use uart4. we are now able to reliably communicate w/ our device. this seems to indicate that usart1 is an unreliable uart port. maybe you have some suggestions as to why usart1 is unreliable.

thanks,

vince

[Olivier GALLIEN]

Hi @vbuon.1​ ,

Thanks for feedback and share you have find a workaround.

I will escalate this issue internally for reproduction and analyze

Keep you posted

Olivier

[Kevin HUBER]

Hello @vbuon.1​ ,

For the moment, I don't understand the weird behavior that you encountered, but I'm trying to reproduce it on my stm32mp157f board.

The particularity of USART1 relative to the others USART is that it can be used for secure application.

This is visible in the RM0436 v6.0 at page 1118.

And in relation to that, I noticed that in your Linux DTS, that you were using the pins PZ6 and PZ7:

	usart1_pins_z_mx: usart1_mx-0 {
		pins1 {
			pinmux = <STM32_PINMUX('Z', 6, AF7)>; /* USART1_RX */
			bias-pull-up;
		};
		pins2 {
			pinmux = <STM32_PINMUX('Z', 7, AF7)>; /* USART1_TX */
			bias-pull-up;
			drive-push-pull;
			slew-rate = <2>;
		};
	};
 
	usart1_sleep_pins_z_mx: usart1_sleep_mx-0 {
		pins {
			pinmux = <STM32_PINMUX('Z', 6, ANALOG)>, /* USART1_RX */
					 <STM32_PINMUX('Z', 7, ANALOG)>; /* USART1_TX */
		};
	};

As you can see PZ6 and PZ7 are parts of pinctrl_z, which are the secure pins of the device.

And inside your TF-A DTS, you are using the USART1 in non secure mode:

DECPROT(STM32MP1_ETZPC_USART1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)

I didn't reproduce the problem yet, but maybe this misalignment creates a bad behavior.

If you are still working on that, please can you make a test with two other pins?

For instance, PA9 and PA10 (DS12505 v7.0 page 93) :

or another one that is not a PZ pin and that supports USART1 as Alternate Function.

Regards,

Kevin

[Kevin HUBER]

Hi @vbuon.1​ ,

And please is-it possible to have your DTS files when your setup works with uart4?

Regards,

Kevin

[vbuon.1]

hi kevin,

thank you for the response.

• based on an article we found we thought that we could remove gpio bank z from the trusted zone (make it non-secure) but it seems that st has removed the ability to do so (the id no longer exists in stm32-etzpc.h):

DECPROT(STM32MP1_ETZPC_USART1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)

• with regards to your suggestion to use non-z gpio pins, unfortunately it is not possible for us to do so on our custom board for usart1. what we can do is to use our stm eval board and configure it to use usart1 to talk to our devices. we have the ability to connect our devices using the eval board’s 40 pin expansion connector. i will update you when we have completed the experiment.
• with respect to reproducing the error, it took many tries (15 to 30) for the problem to appear after connecting the mdma to usart1. the problem most likely will not appear if you try it once or twice.
• I have uploaded our latest dts files.

cheers,

vince