J7200XSOMXEVM: J7200-EVM UART/LIN Multiplexer Configuration for GNSS Data

sarthak sharma

Part Number: J7200XSOMXEVM
Other Parts Discussed in Thread: DRA821, J721EXCPXEVM

Tool/software:

Hi Team,

Hardware Setup
- **Board**: J7200-EVM with DRA821 SoC
- **OS**: Yocto-built Linux image (Kernel 6.1.80-ti-g2e423244f8c0)
- **Target**: Configure UART0/UART1 for GNSS data reception
- **Multiplexer**: SN74CB3Q3257PWR (U41) controlling UART/LIN selection

Goal -
I need to configure the multiplexer to route signals to UART (instead of LIN) to receive GNSS data from one of the UART ports (UART0 or UART1).

Current Status - What I've Achieved

1. Identified the Multiplexer Control GPIOs
Using `gpioinfo`, we found the control lines:

gpiochip0 - 8 lines:
        line   4: "UART/LIN_MUX_SEL" unused input active-high
        line   6: "GPIO_LIN_EN" unused input active-high

2. Successfully Reading GPIO Status
bash
# Current configuration shows UART mode
root@j7200-evm:~# gpioget gpiochip0 4    # UART/LIN_MUX_SEL = 0 (UART mode)
0
root@j7200-evm:~# gpioget gpiochip0 6    # GPIO_LIN_EN = 0 (LIN disabled)
0

3. Confirmed libgpiod Tools Are Available
bash
root@j7200-evm:~# which gpioget gpioset gpioinfo
/usr/bin/gpioget
/usr/bin/gpioset
/usr/bin/gpioinfo

4. Current Multiplexer Status
The multiplexer appears to be configured for **UART mode**:
- `UART/LIN_MUX_SEL = 0` → Signals routed to UART
- `GPIO_LIN_EN = 0` → LIN transceiver disabled

Questions and Issues

1. GPIO Control Behavior
When using `gpioset gpiochip0 4=0 6=0`, the command executes without error, but `gpioinfo` still shows the lines as "unused input". Is this expected behavior, or should they show as "output [used]"?

2. UART Device Availability
With the multiplexer configured for UART mode, what should be the expected device paths for UART0 and UART1? Should they appear as `/dev/ttyS0` and `/dev/ttyS1`, or different device nodes?

3. Device Tree Configuration
Should I check or modify any device tree settings to ensure UART0 and UART1 are properly enabled? The current boot args show:

console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000

4. Persistent GPIO Configuration
Is there a recommended method to make the GPIO multiplexer configuration persistent across reboots? Should this be handled in the device tree, or through userspace scripts?

5. Hardware Validation
How can I verify that the multiplexer is actually switching the signals correctly? Are there any recommended testing procedures for the J7200-EVM UART/LIN functionality?

## Commands I've Used So Far

bash
# Check GPIO status
gpioinfo gpiochip0
gpioget gpiochip0 4 6

# Configure for UART mode
gpioset gpiochip0 4=0 6=0

# Configure for LIN mode (if needed)
gpioset gpiochip0 4=1 6=1

# Check available UART devices
ls -la /dev/ttyS*

Expected Next Steps
1. Confirm UART devices are available and accessible
2. Test UART communication with GNSS module
3. Validate signal routing through the multiplexer
4. Implement persistent configuration if needed

Request for Guidance
I would appreciate any insights on:
- Proper UART device configuration for J7200-EVM
- Best practices for multiplexer control on TI EVMs
- Device tree modifications (if any) required
- Testing procedures to validate UART/LIN switching

Hardware Details:
- SoC: DRA821 (J7200)
- Board: J7200-EVM
- Multiplexer: SN74CB3Q3257PWR (U41)
- I2C GPIO Expander: Address 0x21 on I2C bus 1

3 months ago

0 Gokul Praveen 3 months ago

TI__Genius 11390 points

Hi Sarthak,

Sorry for the delayed response.

sarthak sharma said:
With the multiplexer configured for UART mode, what should be the expected device paths for UART0 and UART1? Should they appear as `/dev/ttyS0` and `/dev/ttyS1`, or different device nodes?

Just to confirm, you are referring to MAIN UART 0 and MAIN UART 1,right?

Regards

Gokul

0 sarthak sharma 3 months ago in reply to Gokul Praveen

Prodigy 100 points

Yes, i'm referring to MAIN_UART0 AND MAIN_UART1.

Regards,

Sarthak

0 Gokul Praveen 3 months ago in reply to sarthak sharma

TI__Genius 11390 points

Hi Sarthak,

sarthak sharma said:
2. UART Device Availability
With the multiplexer configured for UART mode, what should be the expected device paths for UART0 and UART1? Should they appear as `/dev/ttyS0` and `/dev/ttyS1`, or different device nodes?

The expected device paths are:

MAIN_UART0:/dev/ttyS2

MAIN_UART1:/dev/ttyS3

sarthak sharma said:
3. Device Tree Configuration
Should I check or modify any device tree settings to ensure UART0 and UART1 are properly enabled? The current boot args show:

console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000

This bootargs show that MAIN_UART0 is used for printing console logs.Hence UART1 has to be used for receiving GNSS Data as MAIN_UART0 is used for console logs.

sarthak sharma said:
1. GPIO Control Behavior
When using `gpioset gpiochip0 4=0 6=0`, the command executes without error, but `gpioinfo` still shows the lines as "unused input". Is this expected behavior, or should they show as "output [used]"

sarthak sharma said:
4. Persistent GPIO Configuration
Is there a recommended method to make the GPIO multiplexer configuration persistent across reboots? Should this be handled in the device tree, or through userspace scripts?

It is not recommended to use gpioget and gpio set as it seems to have issues.We usually make changes in the device tree itself for gpio hogging.

sarthak sharma said:
- **Multiplexer**: SN74CB3Q3257PWR (U41) controlling UART/LIN selection

sarthak sharma said:
5. Hardware Validation
How can I verify that the multiplexer is actually switching the signals correctly? Are there any recommended testing procedures for the J7200-EVM UART/LIN functionality?

SInce you are using J7200 evm, by default , we do not have to make any changes to the MUX as it is by default configured for UART mode.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Just a couple of questions to ask, Sarthak.

Have you made any changes to enable MAIN_UART1.MAIN_UART0 is enabled by default in the device tree.
- If yes,Can you also provide the device tree changes made to enable MAIN_UART1 so that we can verify it.

Regards

Gokul

0 sarthak sharma 3 months ago in reply to Gokul Praveen

Prodigy 100 points

Hi Gokul,

Thank you getting back with a detailed reply.

As for your question - yes , I did made some changes to the device tree files.

1. k3-j7200-main.dtsi - I did the following changes

I changed the status from "disabled" to "okay" in both MAIN_UART0 and MAIN_UART1.

2. k3-j7200-common-proc-board-dts - I made the following changes.

I only added baud rate in &main_uart1 and added the following line current-speed = <115200>; because I was trying to work with that uart.

Regards,

Sarthak Sharma

0 Gokul Praveen 3 months ago in reply to sarthak sharma

TI__Genius 11390 points

Hi Sarthak,

These changes should be fine to get main uart0 and main uart 1 working.

Regards

Gokul

0 sarthak sharma 3 months ago in reply to Gokul Praveen

Prodigy 100 points

Hi Gokul,
While these might be fine but I'm not getting the output that should be expected - that is the data the data is not being forwarded from the receiver to either UART1 or UART0.

Is it possible to have a teams meeting so we can solve the issue faster or perhaps you'd like more information from me?

Regards,

Sarthak

0 Gokul Praveen 3 months ago in reply to sarthak sharma

TI__Genius 11390 points

Hi Sarthak,

MAIN_UART0 is configured for console prints by default.Hence, it is recommended to use UART1 port for sending the data.

Just a couple of questions to ask,sarthak:

Can you help us with the SDK version you are using?
Can you also help us with the detailed procedure you followed for testing?
Just to confirm, the only changes made to the linux kernel are the device tree changes you had mentioned earlier,right?

Regards

Gokul

0 sarthak sharma 3 months ago in reply to Gokul Praveen

Prodigy 100 points

Hi Gokul,

I'm using ti-processor-sdk-linux-j7200-evm-10_00_07_03
The only changes I made to the kernel were in the device tree.

The following is the procedure I followed -

So, the hardware team removed the U161 IC & we basically bypassed the IC and usb to uart converter to U94. Then we took the connection from U161 to pin no 4,5,6,7

Pin 4-5 - UART1

Pins 5-7 - UART2

Regards,

Sarthak Sharma

0 Gokul Praveen 3 months ago in reply to sarthak sharma

TI__Genius 11390 points

Hi Sarthak,

As I am not the right person to suggest if this hardware change is valid, I have requested the corresponding hardware expert to review this hardware change.

Thank you for your patience.

Regards

Gokul

0 sarthak sharma 3 months ago in reply to Gokul Praveen

Prodigy 100 points

Hi Gokul,

Thank you for your quick reply.
If you could speed up the process with the hardware expert if you be really appreciated.

Regards,
Sarthak Sharma

0 Gokul Praveen 3 months ago in reply to sarthak sharma

TI__Genius 11390 points

Hi Sarthak,

Sure.

Regards

Gokul

0 Robert Eschler 3 months ago in reply to Gokul Praveen

TI__Guru 52265 points

Yes - hardware changes should be fine for modifying the UART connections to connect with other peripherals. Ensure Processor TX is connected to peripheral RX (similar for Processor RX and peripheral TX). If peripheral is on another board - make sure to connect GND between boards (must have common GND).

0 sarthak sharma 3 months ago in reply to Robert Eschler

Prodigy 100 points

Hello Robert,

Thank you for getting back.

Just a couple of questions to ask:

1. Can you confirm if the UART1 and UART2 RX/TX lines on the J7200-EVM (after U161 is bypassed) are correctly routed to the DRA821 pins and FT4232, without any internal multiplexing conflicts or required pinmux settings?

2. Could any secure boot/ROM code restriction prevent early UART initialization or cause the UART data lines to be unresponsive post boot?

3. Is there any clock or power domain required to be manually enabled for UART1/2 in the Linux device tree or kernel config?

Regards,
Sarthak Sharma

=========================================================================================================

Hi Team,

Greetings!

This is Umesh(Project Manager) , I am helping to manage this Project.

Thank you for your support which you are providing this is really helping us to moving forward, However we got stuck on this issue and trying to resolve.

Is it possible to have Team meeting so we can expedite the same that would help please confirm, basically this issue is in Critical mode now and Client is asking to resolve the same on priority .

Hope you understand .

Thanks,

Umesh Garg.

0 Gokul Praveen 3 months ago in reply to sarthak sharma

TI__Genius 11390 points

Hi Sarthak,

sarthak sharma said:
1. Can you confirm if the UART1 and UART2 RX/TX lines on the J7200-EVM (after U161 is bypassed) are correctly routed to the DRA821 pins and FT4232, without any internal multiplexing conflicts or required pinmux settings?

Have you made any other hardware changes. If yes, can you mention that as well,so that we can review it.

Also can you ensure these,as per Robert's suggestions.:

Processor TX is connected to peripheral RX (similar for Processor RX and peripheral TX).
If peripheral is on another board - make sure to connect GND between boards (must have common GND).

sarthak sharma said:
2. Could any secure boot/ROM code restriction prevent early UART initialization or cause the UART data lines to be unresponsive post boot?

No , main uart initialization / data lines willl not be affected by BOOT ROM.

sarthak sharma said:
3. Is there any clock or power domain required to be manually enabled for UART1/2 in the Linux device tree or kernel config?

UART1 clocks are already enabled in the device tree. Also you cannot use main uart 0 as it is configured for console prints and main uart2 as it is used by R5F firmware.

Gokul Praveen said:
Can you also help us with the detailed procedure you followed for testing?

Can you also help us with the testing mechanism followed.

Regards

Gokul

0 Robert Eschler 3 months ago in reply to sarthak sharma

TI__Guru 52265 points

I can confirm no issue with J7200 UARTs on EVM. Note the J7200 EVM is a two board solution - Processor Board + Base Board. On the Processor board - the UART connections with Base Board may be re-mapped. UART1 (on base) connects with UART1 on Processor, but UART2 (base) connects with UART3 on Processor.

0 sarthak sharma 3 months ago in reply to Robert Eschler

Prodigy 100 points

Hi Robert,

Thank you for your response.

Could you please clarify what you mean by "the UART connections may be re-mapped"? Specifically, how can I verify which UART instance on the processor board corresponds to each UART port on the base board?

Is there documentation or a schematic that outlines this mapping, or any recommended way to confirm it (e.g., from the device tree or board files)?

Thanks again for your help.

Regards,
Sarthak

0 Gokul Praveen 3 months ago in reply to sarthak sharma

TI__Genius 11390 points

Hi Sarthak,

sarthak sharma said:
Is there documentation or a schematic that outlines this mapping, or any recommended way to confirm it (e.g., from the device tree or board files)?

The remapping is present in the SOM schematics. I am attaching the reference for the same below :

Please refer to SOM to COMM PROC PRIMARY CONN #2 heading the below file:

SOM_SCH.pdf

I am also attaching the snapshots of the remapping below:

CP indicates the base board

Hence, UART 1 and UART3 can be used .

Regards

Gokul

0 Robert Eschler 3 months ago in reply to Gokul Praveen

TI__Guru 52265 points

The EVM user guide also includes several tables and diagrams that indicate which UARTs are supported: Link

0 sarthak sharma 3 months ago in reply to Robert Eschler

Prodigy 100 points

Hi Robert and Gokul,

I was having trouble with the muxing issue and therefore I thought of a workaround for this - can you please provide assistance in this matter and whether this approach will work.

My current setup has a working serial connection via J44, which I'm using for initial communication. However, I am planning to dedicate J44 to a GNSS module for receiving NMEA data. For general system debugging, I would ideally like to use J43.

My current issue: I am unable to get a reliable serial console connection via J43. When I connect a USB cable to J43, I see host, I'm not able to access the board.

My proposed approach:

Get J43 working reliably as the primary debug/console UART. This would provide a consistent interface for monitoring the boot process and interacting with the Linux prompt.
Dedicate J44 to the GNSS module. Once J43 is stable, I can then focus on configuring the specific DRA821 UART instance routed to J44 for communication with my GNSS sensor.

My questions to the team:

UART Mapping Confirmation: For the J721EXCPXEVM with the DRA821, could you please confirm which internal DRA821 UART instances are exposed via the FTDI bridges connected to J43 and J44 respectively? (Is J43 typically associated with main_uart0 or wkup_uart0, and J44 with another instance like main_uart1 or main_uart2?)
Troubleshooting J43: Based on my description, do you have any immediate suggestions for why I might not be getting console output on J43,? (I have already checked serial terminal settings (115200 8N1), tried different cables, and confirmed board power). Is there any specific I need to do for enabling console output on J43?
Best Practices for GNSS on J44: Assuming J43 works, what would be the recommended internal DRA821 UART instance to use for the GNSS module when connecting via J44? Are there any specific considerations for device tree configuration (e.g., pinmux settings, driver associations) for this specific UART to support a GNSS peripheral? Any existing examples or snippets for configuring a UART for a custom peripheral like GNSS would be highly appreciated.

My goal is to establish a clear and stable setup for both debugging and peripheral integration.

Regards,
SArthak

0 sarthak sharma 3 months ago in reply to sarthak sharma

Prodigy 100 points

Also - a follow up question for this workaround:

When I connect a micro-USB-to-UART cable to J44, I see 4 COM ports on my PC (COM5–8), and COM5 provides access to the Linux console over serial.
However, when I connect to J43, I only see COM17 and COM18, and neither provides any serial output.

Questions:

Is J43 fully supported for UART serial communication?
Are any mux/GPIO/device tree changes needed to enable it?

Regards,

Sarthak Sharma

0 Gokul Praveen 3 months ago in reply to sarthak sharma

TI__Genius 11390 points

Hi Sarthak,

The below FAQ routes the debug logs to J43 port MCU UART(ie:COM18). Can you try following these steps.

e2e.ti.com/.../faq-tda4vm-j721e-j7200-how-to-switch-console-to-a-different-uart-instance

Regards

Gokul

0 Robert Eschler 3 months ago in reply to Gokul Praveen

TI__Guru 52265 points

J43 connects to FT2232HL device - which only supports two (2) COM ports. J44 connects to FT4232HL - which supports four (4) COM ports. This is documented in the EVM user guide - as previously reference. Below are the processor UARTs available on those interfaces:

0 sarthak sharma 3 months ago in reply to Robert Eschler

Prodigy 100 points

Hi Gokul,

Could you please clarify the following:

How are the UART signals routed to J43 and J44? Specifically, what determines which UART instances (e.g., WKUP_UART0, MCU_UART0, etc.) are assigned to these connectors?
Are J43 and J44 multiplexed in hardware? For example, do they use a multiplexer to switch between different UART signals, or are the UART assignments fixed?
If multiplexing is involved, is it configured via pinmux settings in the device tree (e.g., k3-j7200-common-proc-board.dts) or controlled by hardware settings?
In the J7200 EVM documentation, J44 is indicated to support four UARTs, while J43 supports two UARTs. Could you clarify how the UART signals are assigned to these connectors? Specifically, are J43 and J44 multiplexed in hardware to switch between different UART instances (e.g., WKUP_UART0, MCU_UART0), or are their UART assignments fixed?

Regards,
Sarthak

0 Gokul Praveen 3 months ago in reply to sarthak sharma

TI__Genius 11390 points

HI Sarthak,

The UART assignments are fixed.

Regards

Gokul

0 sarthak sharma 3 months ago in reply to Gokul Praveen

Prodigy 100 points

Hi Gokul,

Could you please tell me - if my workaround to get the data from gps antenna which is connected to the skytraq evb and the evb is connected to the one of the uart on the board via rx and tx.

I’m working on a setup where a SkyTraq EVB (with a GPS antenna) is connected to a TI board via UART (RX/TX). My goal is to configure the board such that I can use the J43 port for debugging and serial access, while using the J44 port (whose UART is already functional) to connect to the GNSS receiver via RX/TX.

My proposed workaround is as follows:

Enable the J43 port on the TI board for debugging and serial console access.
Use the J44 port’s UART to interface with the SkyTraq EVB for GNSS data communication.

I’d like to confirm if this is a feasible approach. Specifically:

Are there any potential conflicts or limitations when enabling J43 for debugging while using J44 for GNSS communication?
Are there specific configurations (e.g., pin muxing, UART settings) I should consider to ensure proper operation?
Is there a recommended setup for routing GNSS data from the SkyTraq EVB through J44’s UART?

I just wanted to clarify - what exactly I am trying to do here because in my previous tries I tried to connect the the board to UART1 or UART3 but I wasn't able to receive the data.

Regards,

Sarthak

0 Gokul Praveen 3 months ago in reply to sarthak sharma

TI__Genius 11390 points

HI Sarthak,

sarthak sharma said:
Are there any potential conflicts or limitations when enabling J43 for debugging while using J44 for GNSS communication?

Both are mutually exclusive of each other and hence one should not affect the other.

sarthak sharma said:
Are there specific configurations (e.g., pin muxing, UART settings) I should consider to ensure proper operation?

The below FAQ routes the debug logs to J43 port MCU UART. Can you try following these steps.

e2e.ti.com/.../faq-tda4vm-j721e-j7200-how-to-switch-console-to-a-different-uart-instance

sarthak sharma said:
Is there a recommended setup for routing GNSS data from the SkyTraq EVB through J44’s UART?

As this a custom architecture , it would be hard to comment on that .

Regards

Gokul

0 sarthak sharma 3 months ago in reply to Gokul Praveen

Prodigy 100 points

Hi Gokul,

The following in the what I get when I run the command - dmesg | grep tty

root@j7200-evm:~# dmesg | grep tty
[ 0.000000] Kernel command line: console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 root=PARTUUID=164f123c-02 rw rootfstype=ext4 rootwait
[ 1.082111] 40a00000.serial: ttyS1 at MMIO 0x40a00000 (irq = 251, base_baud = 6000000) is a 8250
[ 1.091594] 2800000.serial: ttyS2 at MMIO 0x2800000 (irq = 252, base_baud = 3000000) is a 8250
[ 1.100445] printk: console [ttyS2] enabled
[ 1.119307] 2810000.serial: ttyS3 at MMIO 0x2810000 (irq = 253, base_baud = 3000000) is a 8250
[ 2.964567] systemd[1]: Created slice Slice /system/getty.
[ 3.010059] systemd[1]: Created slice Slice /system/serial-getty.
[ 7.810566] audit: type=1006 audit(1750395121.519:8): pid=558 uid=0 old-auid=4294967295 auid=1000 tty=(none) old-ses=4294967295 ses=1 res=1
[ 7.834429] audit: type=1300 audit(1750395121.519:8): arch=c00000b7 syscall=64 success=yes exit=4 a0=8 a1=ffffcf965fe8 a2=4 a3=ffff9196f020 items=0 ppid=1 pid=558 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="(systemd)" exe="/lib/systemd/systemd" key=(null)
[ 8.303481] audit: type=1006 audit(1750395122.011:9): pid=526 uid=0 old-auid=4294967295 auid=1000 tty=tty7 old-ses=4294967295 ses=2 res=1
[ 8.318571] audit: type=1300 audit(1750395122.011:9): arch=c00000b7 syscall=64 success=yes exit=4 a0=8 a1=ffffcf965fe8 a2=4 a3=ffff9196f020 items=0 ppid=1 pid=526 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty7 ses=2 comm="(weston)" exe="/lib/systemd/systemd" key=(null)
[ 31.856549] audit: type=1006 audit(1750395145.563:10): pid=1317 uid=0 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=3 res=1
[ 31.869545] audit: type=1300 audit(1750395145.563:10): arch=c00000b7 syscall=64 success=yes exit=1 a0=8 a1=ffffcf965fe8 a2=1 a3=ffff9196f020 items=0 ppid=1 pid=1317 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="(systemd)" exe="/lib/systemd/systemd" key=(null)
[ 31.911261] audit: type=1300 audit(1750395145.579:11): arch=c00000b7 syscall=280 success=yes exit=8 a0=5 a1=ffffde3669a0 a2=78 a3=0 items=0 ppid=1 pid=1317 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="systemd" exe="/lib/systemd/systemd" key=(null)
[ 31.958729] audit: type=1300 audit(1750395145.603:13): arch=c00000b7 syscall=280 success=yes exit=8 a0=5 a1=ffffde366a40 a2=78 a3=0 items=0 ppid=1 pid=1317 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3 comm="systemd" exe="/lib/systemd/systemd" key=(null)

I have connected my gnss board to s1, s2 and s3 but still I'm not able to receive any data from. Different architecture or not - I should be able to receive some data if I connect to one of the uarts?

Regards,
Sarthak

0 sarthak sharma 3 months ago in reply to sarthak sharma

Prodigy 100 points

Hi Gokul,

This issue has been persisting for quite some time now, and I cannot stress enough how important it is for us to get it resolved promptly. The back-and-forth through chat has become quite time-consuming and inefficient.

I believe having a Teams meeting would be immensely helpful. It would allow me to walk you through the exact issues I'm encountering in real time, which would significantly speed up the troubleshooting process.

Given the urgency of this matter, I kindly request we schedule a Teams meeting at the earliest possible convenience to get this resolved.

Looking forward to your response.

Regards,
Sarthak

0 Gokul Praveen 2 months ago in reply to sarthak sharma

TI__Genius 11390 points

HI Sarthak,

Before scheduling the team meeting, I would like to ask some things:

sarthak sharma said:
[ 0.000000] Kernel command line: console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02800000 root=PARTUUID=164f123c-02 rw rootfstype=ext4 rootwait

Have you applied the patch that I had given which routes the debug logs to J43 port MCU UART,because as per the logs you have given,you have not applied it.

Hence, I would first highly recommend and appreciate applying this patch and sharing the results before scheduling a meeting.

Regards

Gokul

0 sarthak sharma 2 months ago in reply to sarthak sharma

Prodigy 100 points

Hi Gokul,

I'm replying here since I was unable to respond to your last message directly.

I’ve applied the patch from the following post as suggested:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/988278/faq-tda4vm-j721e-j7200-how-to-switch-console-to-a-different-uart-instance

After updating the k3-j7200-common-proc-board.dts, recompiling the DTB, and copying it to the boot directory on the SD card, I used the following commands in U-Boot:

load mmc 1:1 ${loadaddr} Image
load mmc 1:1 ${fdt_addr} k3-j7200-common-proc-board.dtb
setenv bootargs console=ttyS5,115200n8 earlycon=ns16550a,mmio32,0x02820000 root=/dev/mmcblk1p2 rw rootwait
booti ${loadaddr} - ${fdt_addr}

While the board boots successfully, I'm still unable to access UART3. Despite the changes, the console output continues to show ttyS2, 115200n8 instead of the expected ttyS5.

Given the time we've spent trying to resolve this, would it be possible to schedule a Teams meeting to troubleshoot this more effectively? I’m available today at 2:00 PM or 3:00 PM IST, and would appreciate the opportunity to discuss this with your team directly.

Looking forward to your confirmation.

Best regards,
Sarthak

0 Gokul Praveen 2 months ago

TI__Genius 11390 points

Hi Sarthak,

I am still suspecting that your patch is not applied properly.

Can you ensure you have done the below steps as mentioned in the FAQ:

Making the u-boot changes described in the FAQ.
Making the ATF/OPTEE changes described in the FAQ.
Copying the compiled ATF/OPTEE to the prebuilt-images.
Recompiling u-boot using make u-boot command.
Recompiling tiboot3.bin,tispl.bin and u-boot.img from the build directory of uboot to the boot directory of sd card.
Make linux kernel dts changes, recompile it and copying it to the <sd card rootfs dir>/boot/dtb/ti directory

Also, can you provide the commands you entered step by step so that we can confirm that you are applying the patch correctly.

Once all these is done, please provide the output of 'printenv' command in u-boot so that we can confirm that the patches has been applied properly.

There is no point having a meeting if the patch is not applied properly.

Regards

Gokul

0 Gokul Praveen 2 months ago

TI__Genius 11390 points

Also first lets work on this which changes the console logs to MCU UART. Once this works fine , we will move to Enabling MAIN_UART3.

Regards

Gokul

0 sarthak sharma 2 months ago in reply to sarthak sharma

Prodigy 100 points

Hi Gokul -

These are the steps we followed to apply the patch -

1. go to main directory in SDK and make changes in atf and ti-u-boot directory -

/home/ik/ti-processor-sdk-linux-j7200-evm-10_00_07_03/board-support/trusted-firmware-a-2.10+git/plat/ti/k3/include/platform_def.h
2. Update Platform Configuration

Within `platform_def.h`, make the following modifications to update the UART base and clock speed:

#Original:

#define K3_USART_BASE 0x02800000
#define K3_USART_CLK_SPEED 48000000
```

Modified:
#define K3_USART_BASE 0x40a00000
#define K3_USART_CLK_SPEED 96000000
These changes point the firmware to the correct UART controller address and configure it for a faster baud rate.

3. Build Trusted Firmware-A (TF-A)

Use the following `make` command from the TF-A directory to build `bl31.bin`:

make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=generic SPD=opteed

4. Build U-Boot

After running make u-boot we get the following two files -

- `u-boot.img`
- `tispl.bin`

These files are then copied in the boot partition of the sd card.

The following image is the output from the console as you asked -

===================================

Hi Team,
This is Umesh and helping to manage projects.(Mahinda Defence)
Wanted to bring in to your attention we are working one of our Project which is related to Government Project.

Due to this issue we are totally stuck and not able to move further and it is totally Blocker for us, and on daily basis Government is asking for solution.

So requesting you if we can arrange TEAM Meet to discuss on the same that can help us, As we have already applied the "Patch" suggested by TI team.

Hope you understand the situation and we can do meeting tomorrow morning or afternoon as you previously suggested.

0 Gokul Praveen 2 months ago

TI__Genius 11390 points

HI Sarthak,

Can you mention the u-boot changes you have made just to confirm that they are matching with that in the FAQ.
Also you will have to make changes in the linux kernel as well as told in the FAQ.
Please provide the output of 'printenv' command in u-boot command line(not kernel command line) after halting in uboot so that we can confirm that the patches has been applied properly.

Regards

Gokul

0 sarthak sharma 2 months ago in reply to sarthak sharma

Prodigy 100 points

Hi Gokul,

PFA the printenv output file .

addr_fit=0x90000000
arch=arm
args_all=setenv optargs earlycon=ns16550a,mmio32,0x02800000 ${mtdparts}
args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
args_ufs=setenv devtype scsi;setenv bootpart 1:1; run ufs_finduuid; setenv bootargs console = ${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${scsirootfstype}; setenv devtype scsi; setenv bootpart 1:1
baudrate=115200
board=j721e
board_name=j7200
board_rev=E8
board_serial=0209
board_software_revision=01
boot=mmc
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr -q ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_efi_bootmgr=if fdt addr -q ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_fdt=try
boot_fit=0
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_rprocs=if test ${dorprocboot} -eq 1 && test ${boot} = mmc; then rproc init; run boot_rprocs_mmc; fi;
boot_rprocs_mmc=env set rproc_id; env set rproc_fw; env set secure_suffix; if test ${secure_rprocs} -eq 1; then env set secure_suffix -sec; fi; for i in ${rproc_fw_binaries} ; do if test -z "${rproc_id}" ; then env set rproc_id $i; else env set rproc_fw $i${secure_suffix}; run rproc_load_and_boot_one; env set rproc_id; env set rproc_fw; fi; done
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
boot_targets=ti_mmc mmc0 mmc1 usb0 pxe dhcp
bootargs=console=ttyS2,115200 root=/dev/mmcblk1p2 rw rootwait rootfstype=ext4
bootcmd=load mmc 1:1 ${kernel_addr_r} Image; load mmc 1:1 ${fdt_addr_r} ${fdtfile}; booti ${kernel_addr_r} - ${fdt_addr_r}
bootcmd_dhcp=devtype=dhcp; run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr -q ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_mmc1=devnum=1; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_ti_mmc=run findfdt; run init_${boot}; if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1; then run main_cpsw0_qsgmii_phyinit; fi; run boot_rprocs; if test ${boot_fit} -eq 1; then run get_fit_${boot}; run get_fit_overlaystring; run run_fit; else; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi;
bootcmd_usb0=devnum=0; run usb_boot
bootdelay=0
bootdir=/boot
bootenvfile=uEnv.txt
bootm_size=0x10000000
bootpart=1:2
bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr}
console=ttyS2,115200n8
cpu=armv8
default_device_tree=ti/k3-j721e-common-proc-board.dtb
dfu_alt_info_emmc=rawemmc raw 0 0x800000 mmcpart 1; rootfs part 0 1; tiboot3.bin.raw raw 0x0 0x800 mmcpart 1; tispl.bin.raw raw 0x800 0x1000 mmcpart 1; u-boot.img.raw raw 0x1800 0x2000 mmcpart 1; u-env.raw raw 0x3800 0x100 mmcpart 1
dfu_alt_info_mmc=boot part 1 1; rootfs part 1 2; tiboot3.bin fat 1 1; tispl.bin fat 1 1; u-boot.img fat 1 1; uEnv.txt fat 1 1; sysfw.itb fat 1 1
dfu_alt_info_nand=NAND.tiboot3 part 0 1; NAND.tispl part 0 2; NAND.tiboot3.backup part 0 3; NAND.u-boot part 0 4; NAND.u-boot-env part 0 5; NAND.u-boot-env.backup part 0 6; NAND.file-system part 0 7
dfu_alt_info_ospi=tiboot3.bin raw 0x0 0x100000; tispl.bin raw 0x100000 0x200000; u-boot.img raw 0x300000 0x400000; u-boot-env raw 0x700000 0x020000; rootfs raw 0x800000 0x3800000
dfu_alt_info_ospi_nand=ospi_nand.tiboot3 part 1; ospi_nand.tispl part 2; ospi_nand.u-boot part 3; ospi_nand.env part 4; ospi_nand.env.backup part 5; ospi_nand.rootfs part 6; ospi_nand.phypattern part 7
dfu_alt_info_ram=tispl.bin ram 0x80080000 0x200000; u-boot.img ram 0x81000000 0x400000
distro_bootcmd=scsi_need_init=; for target in ${boot_targets}; do run bootcmd_${target}; done
do_main_cpsw0_qsgmii_phyinit=1
dorprocboot=1
dtboaddr=0x89000000
efi_dtb_prefixes=/ /dtb/ /dtb/current/
envboot=echo Skipping envboot
eth1addr=70:ff:76:1f:09:c0
eth2addr=70:ff:76:1f:09:c1
eth3addr=70:ff:76:1f:09:c2
eth4addr=70:ff:76:1f:09:c3
ethaddr=dc:f3:1c:7d:7a:83
fdt_addr_r=0x88000000
fdtaddr=0x88000000
fdtcontroladdr=fdeb78b0
fdtfile=k3-j7200-common-proc-board.dtb
fdtoverlay_addr_r=0x89000000
fileaddr=82000000
filesize=127aa00
findfdt=echo Skipping findfdt
finduuid=part uuid ${boot} ${bootpart} uuid
get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/dtb/${name_fdt}
get_fdt_ufs=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
get_fit_config=setexpr name_fit_config gsub / _ conf-${fdtfile}
get_fit_mmc=load mmc ${bootpart} ${addr_fit} ${bootdir}/${name_fit}
get_fit_overlaystring=for overlay in $name_overlays; do; setexpr name_fit_overlay gsub / _ conf-${overlay}; setenv overlaystring ${overlaystring}'#'${name_fit_overlay}; done;
get_kern_mmc=load mmc ${bootpart} ${loadaddr} ${bootdir}/${name_kern}
get_kern_ufs=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${name_kern}
get_overlay_mmc=fdt address ${fdtaddr}; fdt resize 0x100000; for overlay in $name_overlays; do; load mmc ${bootpart} ${dtboaddr} ${bootdir}/dtb/ti/${overlay} && fdt apply ${dtboaddr}; done;
get_overlay_ufs=fdt address ${fdtaddr}; fdt resize 0x100000; for overlay in $name_overlays; do; load scsi ${bootpart} ${dtboaddr} ${bootdir}/${overlay} && fdt apply ${dtboaddr}; done;
importbootenv=echo Importing environment from mmc${mmcdev} ...; env import -t ${loadaddr} ${filesize}
init_main_cpsw0_qsgmii_phy=gpio set gpio@22_17; gpio clear gpio@22_16
init_mmc=run args_all args_mmc
init_ufs=ufs init; scsi scan; run args_ufs
kernel_addr_r=0x82000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadaddr=0x82000000
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr
loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/dtb/${fdtfile}
loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
main_cpsw0_qsgmii_phyinit=if test ${do_main_cpsw0_qsgmii_phyinit} -eq 1 && test ${dorprocboot} -eq 1 && test ${boot} = mmc; then run init_main_cpsw0_qsgmii_phy; fi;
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
mmcboot=mmc dev ${mmcdev}; devnum=${mmcdev}; devtype=mmc; if mmc rescan; then echo SD/MMC found on device ${mmcdev}; if run loadimage; then run args_mmc; if test ${boot_fit} -eq 1; then run run_fit; else run mmcloados; fi; fi; fi;
mmcdev=1
mmcloados=if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run get_fdt_mmc; then bootz ${loadaddr} - ${fdtaddr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;
mmcrootfstype=ext4 rootwait
name=hello
name_fit=fitImage
name_kern=Image
partitions=name=rootfs,start=0,size=-,uuid=${uuid_gpt_rootfs}
pxefile_addr_r=0x80100000
ramdisk_addr_r=0x88080000
rd_spec=-
rdaddr=0x88080000
rproc_fw_binaries= 1 /lib/firmware/j7200-mcu-r5f0_1-fw 2 /lib/firmware/j7200-main-r5f0_0-fw 3 /lib/firmware/j7200-main-r5f0_1-fw
rproc_load_and_boot_one=if load mmc ${bootpart} $loadaddr ${rproc_fw}; then if rproc load ${rproc_id} ${loadaddr} ${filesize}; then rproc start ${rproc_id}; fi; fi
run_fit=run get_fit_config; bootm ${addr_fit}#${name_fit_config}${overlaystring}
run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then part uuid ${devtype} ${devnum}:${distro_bootpart} distro_bootpart_uuid ; run scan_dev_for_boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;run boot_efi_bootmgr;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo EXTLINUX FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x80000000
scsi_boot=run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
scsirootfstype=ext4 rootwait
secure_rprocs=0
serial#=0000000000000209
soc=k3
stderr=serial@2800000
stdin=serial@2800000
stdout=serial@2800000
ubifs_boot=if ubi part ${bootubipart} ${bootubioff} && ubifsmount ubi0:${bootubivol}; then devtype=ubi; devnum=ubi0; bootfstype=ubifs; distro_bootpart=${bootubivol}; run scan_dev_for_boot; ubifsumount; fi
ufs_finduuid=part uuid scsi ${bootpart} uuid
update_to_fit=setenv loadaddr ${addr_fit}; setenv bootfile ${name_fit}
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi
vendor=ti

Environment size: 10170/32763 bytes
=>

Regards,

Sarthak

0 Gokul Praveen 2 months ago

TI__Genius 11390 points

Hi Sarthak,

From the output you have shared , the patch which I prvovided for enabling MCU uart for serial console logs has not been applied properly.

-------------------------------------------------------------------------------------

Your output : args_all=setenv optargs earlycon=ns16550a,mmio32,0x02800000 ${mtdparts}

Expected output : args_all=setenv optargs earlycon=ns16550a,mmio32,0x40a00000

-------------------------------------------------------------------------------

Your output : "console=ttyS2,115200n8"

Expected output : "console=ttyS1,115200n8"

-------------------------------------------------------------------------------

Please ensure that the patches provided in the FAQ[e2e.ti.com/.../faq-tda4vm-j721e-j7200-how-to-switch-console-to-a-different-uart-instance] are applied properly.

Regards

Gokul

0 Gokul Praveen 16 days ago

TI__Genius 11390 points

Just updating the conversation in the other E2E here:

FAQ: TDA4VM / J721E / J7200 - How to switch console to a different UART instance

However, that post is a bit dated, and I'm using the following SDK version:

PROCESSOR-SDK-LINUX-J7200 — 10.00.07.03

It looks like some of the files mentioned in the original instructions have been moved or restructured in this SDK release. Could you please provide updated guidance or suggestions on how to apply the patch and switch the UART console with this newer SDK?

Regards

Gokul

0 Gokul Praveen 16 days ago

TI__Genius 11390 points

Hi Sarthak,

I will look into the changes and get back to you .

Regards

Gokul

0 Gokul Praveen 11 days ago

TI__Genius 11390 points

Hi Sarthak,

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/uboot_5F00_mcuuartenbl.patch

Making the u-boot changes as mentioned in the patch above.
Making the ATF/OPTEE changes described in the FAQ.
Copying the compiled ATF/OPTEE to the prebuilt-images.
Recompiling u-boot using make u-boot command.
Recompiling tiboot3.bin,tispl.bin and u-boot.img from the build directory of uboot to the boot directory of sd card.
Make linux kernel dts changes, recompile it and copying it to the <sd card rootfs dir>/boot/dtb/ti directory

Once all these has been done , connect to mcu uart(the 2nd instance out of the 2 instance showing up when connecting to the J43 port and check if the logs are coming up.

Also please share the detailed steps you have followed so that I can cross verify that the patches have been applied properly.

Regards

Gokul

Processors

Processors forum

J7200XSOMXEVM: J7200-EVM UART/LIN Multiplexer Configuration for GNSS Data