FS 8ULP OSM-SF – Clarification on UART port to core mapping (A35 / M33)

Ajith Ali · Jul 23rd 2026

Hi F&S Support Team,

We are designing a carrier for the FS 8ULP OSM-SF (HW Rev 1.10) and need clarification on UART assignment to the Cortex-A35 (APD) and Cortex-M33 (RTD) cores.

From Hardware Documentation 2.2.3 UART (Table 6):

Module UART	Pads	Datasheet comment
UART_CON	PTE6 / PTE7	Cortex-A35 debug (APD)
UART_C	PTB2 / PTB3	Cortex-M33 debug (RTD)
UART_A	PTE8–PTE11	(no core stated)
UART_B	PTA2/3/16/17	(no core stated)
UART_D	PTA10 / PTA11	(no core stated)

Please confirm: Which core owns / is intended to use UART_A, UART_B, and UART_D (A35, M33, or via software assignment)?

Thanks,

Ajith

fs-support_KM · Jul 27th 2026

Hello

the assignment is as followed:

Module UART	Pads	Datasheet comment
UART_CON	PTE6 / PTE7	Cortex-A35 debug (APD)
UART_C	PTB2 / PTB3	Cortex-M33 debug (RTD)
UART_A	PTE8–PTE11	Cortex-A35
UART_B	PTA2/3/16/17	Cortex-M33
UART_D	PTA10 / PTA11	Cortex-M33

In general the assignment is like this:

PTA, PTB, PTC - Cortex-M33

PTD, PTE, PTF - Cortex-A35

Your F&S Support Team

Ajith Ali · Jul 31st 2026

Hi,

What about lpuart4 and lpuart7?

Is it possible to use these uart in fs-osm-sf-mx8ulp.dtsi? Whether hardware connection for lpuart4 and lpuart7 is provided in FS 8ULP SF?

Thanks,

Ajith

fs-support_CS · Aug 4th 2026

Hi Ajith Ali ,

do you need Ethernet or RGB display?

you can use LPUART4 via PTE16/17/18/19 (Ethernet)
Or LPUART7 via PTF4/5/6/7 or PTF20/21/22/23 (RGB display)

you will need to declare the UART-Interfaces with proper pinctrl in dts.
Like here:
https://github.com/FSEmbedded/…mx8ulp.dtsi#L381C1-L387C3

You will also need the alias definition for lpuart4 or lpuart7, like here:
https://github.com/FSEmbedded/…-mx8ulp.dtsi#L62C2-L62C25

Ajith Ali · Aug 6th 2026

Hi,

We are trying to use lpuart6, lpuart4, lpuart7 as uart ports from A35 core as a uart interface not as Ethernet or RGB Display.

Also, according arch/arm64/boot/dts/F+S/fs-osm-sf-mx8ulp.dtsi, lpuart6 is configured but it pinouts are not working as expected.

Whether in OSM carrier card these pinouts are given as uart or not?

pinctrl_lpuart6: lpuart6grp {

fsl,pins = <

MX8ULP_PAD_PTE8__LPUART6_CTS_B 0x3

MX8ULP_PAD_PTE9__LPUART6_RTS_B 0x3

MX8ULP_PAD_PTE10__LPUART6_TX 0x3

MX8ULP_PAD_PTE11__LPUART6_RX 0x3

>;

};

The device ttyLP1 is getting enumerated but it cant be used for uart communication. So please confirm lpuart6 pinouts are given in carrier board.

Thanks,

Ajith

fs-support_CS · Aug 7th 2026

Hi Ajith Ali ,

On our Starterkit OSM8ULP with ADP-OSM-BB2 PTE8/9/10/11/ where used for Ethernet and is connected to a phy on ADP-OSMBB2.
The signals are not accessable.

If you design a own carrier board, and if you do not need Ethernet for your application, then you can get LPUART6 from those signals.

Bharath · Aug 7th 2026

Hi F&S Team,

We are using the FS 8ULP OSM-SF (HW Rev. 1.10) on the starter kit (ADP-OSM-BB + PicoCoreBBDSI).

In Linux, we currently see:

/dev/ttyLP0 → OSM UART_CON (working on baseboard J8)
/dev/ttyLP1 → OSM UART_A (DTS: lpuart6)

According to the OSM hardware documentation, UART_A is available on lands B13 (TX) and A14 (RX).

From the ADP-OSM-BB documentation, our understanding is:

PicoCore UART_A (J8) is mapped from OSM UART_CON (D22/D23), not from OSM UART_A.
OSM UART_A (B13/A14) does not appear to be routed to J8, J9, or J10 on the PicoCoreBBDSI.

Could you please clarify the following?

Is OSM UART_A (/dev/ttyLP1) routed to any connector on the starter kit?
Can you confirm whether J3B is only a schematic symbol representing the OSM land interface and not a physical connector on the board?
OSM UART_A (B13/A14) → Linux ttyLP1 Which connector/pins on the ADP and PicoCoreBBDSI is it routed to, if any? Or is it not routed at all?

We need clarification on how the OSM UART signals are routed through the adapter board to the PicoCoreBBDSI baseboard so that we can complete the device tree configuration correctly.

Attachments

ADP schematic: J1 (for reference image osm-j1 connector) showing UART_A/B/C/D signal names.
ADP schematic: SERIAL / level shifter showing OSM lands (e.g., D13, D22, B13, etc.).

Note: On the SERIAL schematic page, the J3B block appears to be a schematic symbol representing the OSM land interface only. We do not see a physical J3B connector on the board.

Thanks

fs-support_CS · Aug 10th 2026

Hi @Bharath,

OSM_UART_A is not routed to any connector on the SKIT.

J3B represents the Contact-Grid of the OSM.

Only OSM_UART_CON, OSM_UART_B and OSM_UART_C is available.

Ajith Ali · Aug 13th 2026

Hi Team,

We need some clarification regarding OSM_UART_B, which is routed to the Cortex-M33.

By default, this OSM_UART_B is not enabled in the DTS files, so we have enabled it as shown below:

osm_eth_a: &fec {};

osm_uart_con: &lpuart5 {}; /* A35 console ttyLP0 */

osm_uart_a: &lpuart6 {}; /* Hardware Pin mapping is not there */

osm_uart_b: &tty2_rpchip {};

osm_uart_c: &tty1_rpchip {}; //debug

osm_uart_d: &tty0_rpchip {}; //transfer

osm_i2c_int: &lpi2c4 {};

/delete-node/ aliases;

aliases {

ethernet0 = &osm_eth_a;

serial0 = &osm_uart_con;

serial1 = &osm_uart_a;

serial2 = &osm_uart_c;

serial3 = &osm_uart_d;

serial4 = &osm_uart_b;

&osm_uart_con {

status = "okay";

};

&osm_uart_a {

status = "okay";

};

&osm_uart_b {

status = "okay";

};

&osm_uart_c {

status = "okay";

};

&osm_uart_d {

status = "okay";

};

Our expectation is that OSM_UART_B should get enumerated as /dev/ttyRPMSG4, but we do not see this device node being created.

Could you please confirm whether OSM_UART_B is configured and supported on the FS-OSMULP EVK carrier card?

Additionally, we are trying to communicate from the A35 to the M33 using /dev/ttyRPMSG3 with the following command:

echo "hello" > /dev/ttyRPMSG3

However, we are not able to observe the communication on the M33 side.

Could you please clarify whether /dev/ttyRPMSG3 is routed to any other OSM_UART connector on the FS-OSMULP carrier card, or if there is any other routing/configuration required to enable communication between the A35 and M33?

For more information, we have verified the communication between A35 and M33 using /dev/ttyRPMSG2 and the communication is successful using same echo write method.

Any details regarding the UART mapping, RPMSG device enumeration, and routing between these interfaces would be greatly appreciated.

Thanks,

Ajith

fs-support_CS · Aug 14th 2026

Quote from Ajith Ali

Hi F&S Support Team,

We are designing a carrier for the FS 8ULP OSM-SF (HW Rev 1.10) and need clarification on UART assignment to the Cortex-A35 (APD) and Cortex-M33 (RTD) cores.
From Hardware Documentation 2.2.3 UART (Table 6):

Module UART

Pads

Datasheet comment

UART_CON

PTE6 / PTE7

Cortex-A35 debug (APD)

UART_C

PTB2 / PTB3

Cortex-M33 debug (RTD)

UART_A

PTE8–PTE11

(no core stated)

UART_B

PTA2/3/16/17

(no core stated)

UART_D

PTA10 / PTA11

(no core stated)

Please confirm: Which core owns / is intended to use UART_A, UART_B, and UART_D (A35, M33, or via software assignment)?

Thanks,
Ajith

Display More

I just noticed that, although UART_C is marked as DBG in the hardware documentation, UART_B is used as DBG in the realtimed firmware.

This means that in Linux, only UART_C and UART_D from RTD can be accessed.

If you also want to use UART_B in Linux, you’ll need to disable DBG in the Cortex-M firmware and register UART_B as a UART adapter:

Remove dbg here:

https://github.com/FSEmbedded/…r/board/board_uart.c#L225

https://github.com/FSEmbedded/…/board/board_descr.c#L439

add uart iface here:

https://github.com/FSEmbedded/…ard_uart.c#L153C1-L172C19

I hope I was able to help 😊

FS 8ULP OSM-SF – Clarification on UART port to core mapping (A35 / M33)

Attachments

Share

Tags