Clarification Required on FS-OSM hardware and application note documents

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

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