Port.C of boot serial console is IO inverted on CoreMP135.

[nnn112358]

The boot serial console can be accessed from Grove Port.C on the CoreMP135, via USB serial. U-Boot logs are output from Port.C pin 1 (non TX-RX swap signal), while the Linux console is output from Port.C pin 2 (with TX-RX swap signal).

Uart6 in linux-dts,opte-dts,tfa-dts,uboot-dts has "rx-tx-swap" set. Afer commit ( https://github.com/m5stack/CoreMP135_buildroot-external-st/commit/d01345a18a2f54aaca111e8eda60b4616c869545 ).

In uboot-dts uart6 has rx-tx-swap disabled. rx-tx-swap or no rx-tx-swap, IO is not switched. Otherwise, for example, uart6 on linux-dts has rx-tx-swap enabled, and IO can be switched with or without rx-tx-swap.

By @ciniml, the datasheet says that the IO of UART6 is the Boot UART when BOOT.

Isn't UART6 in uboot-dts fixed with HW? If so, I would like uart6 in linux-dts, opte-dts, tfa-dts, uboot-dts to be aligned without "rx-tx-swap". I would like to see the U-Boot logs and Linux console(linux, opte, tfa) aligned on the same IO.

U-Boot logs

from Port.C non TX-RX swap signal
NOTICE:  CPU: STM32MP135D Rev.Y
NOTICE:  Model: STMicroelectronics STM32MP135F-DK Discovery Board
NOTICE:  BL2: v2.6-stm32mp1-r1.0(release):2021.05-10169-gb885d5525a
NOTICE:  BL2: Built : 15:39:25, May 15 2024
NOTICE:  BL2: Booting BL32
optee optee: OP-TEE: revision 3.16 (b885d552)

U-Boot 2021.10-stm32mp-r1 (May 15 2024 - 15:39:22 +0800)

CPU: STM32MP135D Rev.?
Model: STMicroelectronics STM32MP135F-DK Discovery Board
Board: stm32mp1 in trusted mode (st,stm32mp135f-dk)
DRAM:  512 MiB
optee optee: OP-TEE: revision 3.16 (b885d552)
Clocks:
- MPU : 650 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
WDT:   Started with servicing (32s timeout)
NAND:  0 MiB
MMC:   STM32 SD/MMC: 0
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
invalid MAC address 0 in OTP 00:00:00:00:00:00
Net:   No ethernet found.
Hit any key to stop autoboot:  0
Boot over mmc0!
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:5...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
160 bytes read in 20 ms (7.8 KiB/s)
1:      stm32mp135f-coremp135-buildroot
Retrieving file: /boot/zImage
7923832 bytes read in 579 ms (13.1 MiB/s)
append: root=/dev/mmcblk0p5 rw panic=5 quiet rootwait
Retrieving file: /boot/stm32mp135f-coremp135.dtb
68116 bytes read in 24 ms (2.7 MiB/s)
Kernel image @ 0xc2000000 [ 0x000000 - 0x78e878 ]
## Flattened Device Tree blob at c4000000
   Booting using the fdt blob at 0xc4000000
   Loading Device Tree to cffec000, end cffffa13 ... OK
gc2145@3c node not found - DT update aborted
FDT: cryp@54002000 node disabled for STM32MP135D Rev.?

Starting kernel ...

Linux logs from Port.C with TX-RX swap signal

[    0.004005] /cpus/cpu@0 missing clock-frequency property
[    0.435138] stm32-cpufreq stm32-cpufreq: OPP-v2 not supported
Starting syslogd: OK
Starting klogd: OK
Starting modules: soundcore success, snd success, snd_timer success, snd_pcm success, snd_pcm_dmaengine success, snd_soc_core success, snd_soc_simple_card_utils success, snd_soc_audio_graph_card success, snd-soc-simple-card success, snd_soc_stm32_sai success, snd_soc_stm32_sai_sub success, cdc-acm success, libcomposite success, g_serial success, OK
Running sysctl: OK
Starting mdev... OK
Seeding 256 bits and crediting
Saving 256 bits of creditable seed for next boot
Starting tee-supplicant: Using device /dev/teepriv0.
OK
Starting network: OK
Starting dhcpcd...
dhcpcd-9.4.1 starting
DUID 00:01:00:01:2d:f9:ec:09:2a:88:82:9b:b0:f0
forked to background, child pid 177
[    5.966541] m_can_platform 4400e000.can can0: bit-timing not yet defined
[    5.974064] m_can_platform 4400e000.can can0: failed to open can device
[    5.988759] m_can_platform 4400f000.can can1: bit-timing not yet defined
[    5.994164] m_can_platform 4400f000.can can1: failed to open can device
Starting dropbear sshd: OK
Stopping /etc/rc.localOK

#     #  #######   #####   #######     #      #####   #    #
##   ##  #        #     #     #       # #    #     #  #   #
# # # #  #        #           #      #   #   #        #  #
#  #  #  ######    #####      #     #     #  #        ###
#     #        #        #     #     #######  #        #  #
#     #  #     #  #     #     #     #     #  #     #  #   #
#     #   #####    #####      #     #     #   #####   #    #
Welcome to CoreMP135, Powered by M5Stack.
CoreMP135 login:

Reference:

https://community.m5stack.com/topic/6563/port-c-of-boot-serial-console-is-io-inverted-on-coremp135 https://www.st.com/ja/microcontrollers-microprocessors/stm32mp135d.html

[dianjixz]

Regarding the issue of rx-tx-swap not taking effect in TFA, OP-TEE, and U-Boot, this is a known problem and is currently considered a bug. There are two points to note about this bug: First, the order of txrx in Port.C port has been changing, which is why you see the appearance of rx-tx-swap. Second, the decision made by the boss is to use Port.C solely as a serial port without outputting log information. Therefore, I have made settings to disable log output and modify the txrx order. When adjusting the txrx order, I discovered this bug. After considering a few points, I have decided not to address this bug. First, the CoreMP135 requires a boot log output, especially when users need to adjust the U-Boot startup, which is crucial. It is very cumbersome to enable log output through other methods. Second, with a different pin order, the log output will not affect external devices connected to Port.C, thus minimizing errors. In conclusion, simply swapping the two wires will allow you to see the log output during the startup phase. I believe this is a rather ideal solution that meets the boss's requirements and fulfills the function of controlling U-Boot through log viewing. If you wish to use Port.C as the system's login port, please provide feedback to the boss at M5Stack, and I will implement this modification.

[nnn112358]

Thank you for your response.

I understood that without "rx-tx-swap" is incorrect because PortC needs to make a connection with an external device.I think you are right about the default. Since the CoreMP135 kernel is open source in this repository, I use Port.C, modified as needed in my CoreMP135.

In the future, anyone with the same question will be convinced by this issue.