Posts by Ajith Ali

Hi Team,

Currently, SPI_A is working fine through the client interface with the following configuration from the M33 RPMsg:

spidev0_rpchip: spidev-rpbus-0 {

compatible = "spi_rpbus";

#address-cells = <1>;

#size-cells = <0>;

status = "disabled";

};

Likewise, we would like SPI_B to be accessible from the M33 in the same way as SPI_A.

As per F and S, both SPI_A (FLEXSPI) and SPI_B (LPSPI) belong to the Cortex-M33 domain, and SPI_B can also be controlled from Linux via RPMsg.

Could you please let us know what changes are required in the M33 RPMsg configuration, device tree, or any other settings to enable SPI_B support?

Thanks,

Ajith

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

Hello F&S Team,

I am currently evaluating SPI functionality on the FS OSM-SF i.MX8ULP mounted on the ADP-OSM-BB and would like some clarification regarding the SPI routing on this platform.

Device Tree Configuration

Current SPI configuration:

I have updated the SPI pinctrl configuration for LPSPI4

pinctrl_lpspi4: lpspi4grp {

fsl,pins = <

MX8ULP_PAD_PTF8__LPSPI4_SIN 0x42

MX8ULP_PAD_PTF9__LPSPI4_SOUT 0x42

MX8ULP_PAD_PTF10__LPSPI4_SCK 0x42

MX8ULP_PAD_PTF11__LPSPI4_PCS0 0x42

>;

};

&osm_spi_a {

pinctrl-names = "default";

pinctrl-0 = <&pinctrl_lpspi4>;

status = "okay";

spidev@0 {

compatible = "linux,spidev";

spi-max-frequency = <1000000>;

reg = <0>;

status = "okay";

};

};

/* This is the existing spi config for rpmsg M33 */

&osm_spi_b {

status = "okay";

spidev@0 {

compatible = "linux,spidev";

spi-max-frequency = <1000000>;

reg = <0>;

status = "okay";

};

};

Linux Enumeration

Linux successfully creates:

/dev/spidev1.0

/dev/spidev2.0

After boot:

readlink -f /sys/class/spi_master/spi2/device

returns:

/sys/devices/platform/soc@0/29000000.bus/293b0000.spi

indicating that spidev2.0 is associated with LPSPI4.

Runtime Verification

The pinctrl configuration is applied at runtime. From:

cat /sys/kernel/debug/pinctrl/298c0000.pinctrl/pinconf-pins

the following pads are configured:

PTF8

PTF9

PTF10

PTF11

Functional Observations

spidev1.0 is functional and visible on the logic analyzer.

For example:

echo -n -e '\xAA\x22' > /dev/spidev1.0

generates SPI activity that can be observed externally.

spidev2.0 also enumerates correctly and spidev_test executes without errors:

root@fsimx8ulp:/home#

root@fsimx8ulp:/home# ./spidev_test -D /dev/spidev2.0 -v

spi mode: 0x0

bits per word: 8

max speed: 500000 Hz (500 kHz)

TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D |......@.........................|

RX | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................................|

root@fsimx8ulp:/home#

However, no SPI activity is visible on the SPI header pins being monitored with the logic analyzer.

Runtime Verification

The pinctrl configuration appears to be applied correctly at runtime.

From:

cat /sys/kernel/debug/pinctrl/298c0000.pinctrl/pinconf-pins

the following pins are configured:

PTF8

PTF9

PTF10

PTF11

which matches the configured LPSPI4 pinmux shown above.

Information from Hardware Documentation

From the FS OSM-SF i.MX8ULP Hardware Documentation, SPI_A is documented as:

SPI_A_CS0# -> OSM Pin Y15

SPI_A_SCK -> OSM Pin U16

SPI_A_SDI -> OSM Pin U15

SPI_A_SDO -> OSM Pin V15

with the following CPU pad mapping:

SPI_A_CS0# -> PTC23

SPI_A_SCK -> PTC18

SPI_A_SDI -> PTC22

SPI_A_SDO -> PTC21

From the **ADP-OSM-BB Hardware Documentation**, these SPI_A signals are routed to connector **J1** as:

J1 Pin 64 -> SPI_A_SS0

J1 Pin 66 -> SPI_A_MISO

J1 Pin 68 -> SPI_A_MOSI

J1 Pin 70 -> SPI_A_SCLK

Additionally, the documentation notes that:

SPI_A_MISO and SPI_A_MOSI are exchangeable via jumper

Additional Observation

I also noticed that the pads currently assigned to LPSPI4 were originally part of the RGB interface pinmux.

For example:

pinctrl_rgb: rgbgrp {

fsl,pins = <

...

/* MX8ULP_PAD_PTF8__DPI0_D15 0x3

MX8ULP_PAD_PTF9__DPI0_D14 0x3

MX8ULP_PAD_PTF10__DPI0_D13 0x3

MX8ULP_PAD_PTF11__DPI0_D12 0x3 */

...

>;

};

These RGB entries were commented out before enabling LPSPI4.

Clarification Required

Could you please help clarify the following?

Are the pins

PTF8 -> LPSPI4_SIN

PTF9 -> LPSPI4_SOUT

PTF10 -> LPSPI4_SCK

PTF11 -> LPSPI4_PCS0

routed to any connector or test point on the ADP-OSM-BB?

1.If yes, could you please indicate where these signals are physically available?

2.Based on the hardware documentation, SPI_A is associated with:

PTC18/PTC21/PTC22/PTC23

Or by:

PTF8/PTF9/PTF10/PTF11

as per the reference from arch/arm64/boot/dts/F+S/picocoremx8ulp_rev110.dtsi

Could you please clarify the relationship between these two signal groups?

1.Is SPI_A on connector J1 (Pins 64, 66, 68, 70) expected to be driven by LPSPI4 from the A35/Linux domain, or is it connected through a different implementation?

2.Is the above LPSPI4 pinmux configuration the recommended configuration for accessing SPI externally from Linux on the ADP-OSM-BB?

Since spidev1.0 produces observable SPI traffic while spidev2.0 does not, could you please clarify the intended SPI routing architecture for Linux on this platform?

Any clarification on the physical routing and intended usage of SPI_A and LPSPI4 would be greatly appreciated.

Thank you for your support.

Best Regards,

Ajith Ali

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

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

Hi,

We are working on FS-OSM iMX8ULP EVK and we need latest hardware related documents to map with the software config like UART, i2c, SPI and other peripherals.

The documents which is provided in below link are not matching with the dts config provided.

Kindly provide the latest hardware documents like data sheet, reference manual, schematics and other related documents.

Thanks,

Ajith

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):

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

Thanks,

Ajith

We are using the F&S PicoCoreMX8ULP hardware and have successfully built the fsimx8ulp-Y2025.11.1 Yocto release for the platform.
While reviewing the hardware support, we referred to the PicoCoreMX8ULP_Hardware.pdf document, specifically Section 2.2.13, which describes the PMIC configuration. However, we could not find the corresponding PMIC configuration in any of the PicoCoreMX8ULP DTS/DTSI files provided with the Yocto BSP.
Could you please clarify the following?
PMIC-Related Questions

1. Is the PMIC located on the PicoCoreMX8ULP module itself or on the carrier board?
2. If the PMIC is present and managed by the BSP, could you please indicate the relevant DTS/DTSI file(s) where its configuration is defined?
3. If the PMIC configuration is not included by default, could you please provide the recommended PMIC DTS configuration and any related documentation?
4. Are there any board-specific overlays, BSP components, or reference designs that contain the PMIC settings?

UART_B / Bluetooth Questions
While reviewing the device tree, we noticed the following section:
/* UART_B is controlled by M33 */
&fs_uart_b {
status = "disabled";

bluetooth {
compatible = "nxp,88w8997-bt";
};
}
Based on this configuration, we would appreciate clarification on the following points:

1. Since UART_B is marked as being controlled by the Cortex-M33, is the 88W8997 BLE/Bluetooth controller managed entirely by the M33 core?
2. Does the A35/Linux communicate with the Bluetooth controller through RPMsg (or another IPC mechanism) via the M33, or is there any direct access from the A35 to the Bluetooth HCI interface?
3. If RPMsg (or another IPC mechanism) is used, could you please share any available documentation describing the communication architecture and data flow between the A35 and M33 cores for Bluetooth operation?

We would appreciate your guidance in understanding both the PMIC implementation and the Bluetooth/UART_B architecture for the PicoCoreMX8ULP platform.