F&S i.MX93 Yocto Release 2025.08.2 (fsimx93-Y2025.08.2)

This is a major release for F&S modules based on the i.MX93 SoC, and the NXP lf-6.6.52-2.2.2 release.

Supported Boards

• PicoCoreMX93
• efusMX93
• OSM-SF-MX93
• PicoCom93
• NetDCU93

Please see the new revision of following file

FSiMX93_Linux-First-Steps.pdf

for a description of how everything is installed and used. This doc sub-directory also contains other documentation, for example about the hardware of the boards and the starter kits.

Please note that Yocto releases use a 'Y' for the version number. The version counting is independent form other releases.

Content

The release consists of the following files and directories:

Warning The precompiled images are for testing and evaluation purposes only! DO NOT USE in production or mission-critical environments!

How to build

Use the latest F&S Development Machine from the F&S website To build the example release binaries, run:

Highlights

Here are some highlights of this release.

1. New Linux Kernel 6.6.147

The Linux kernel is now based on 6.6.147, which offers several new bug and security fixes.

3. New Yocto version 5.0.19 Scarthgap

Updating poky to Version 5.0.19 Scarthgap. Updating other layers to their latest commits.

The meta-fus layer is now split into meta-fus-bsp and meta-fus-sdk. The meta-fus-bsp layer adds basic board support, while meta-fus-sdk adds additional features, which are note necessary to run the board.

The meta-fus layer is now based on meta-freescale and not meta-imx. meta-freescale offers better long time support and more stable releases, while meta-imx supports the newest features but is not as stable and suitable for production. The meta-imx layers are still downloaded for reference, but not included into the build. If you need features from them, please consider adding the changes to your own meta-layer.

4. Improve linux-examples-fus

Update the examples to the new linux version.

5. New Docker based building system

The F&S releases now support Docker containers as default building machines. By using the Docker environment, the build process can be executed on any Linux host, as long as the Docker is installed. Starting FS_Development_Machine-Fedora-40_V0.2 Docker will be pre-installed and the development machines will not support support building the releases directly anymore.

If you do not want to use Docker, please check the Dockerfile for the dependencies. https://github.com/FSEmbedded/docker-fus/

1. Download manifest repository

   Code

   1. git clone -b fsimx93-Y2025.08.2 https://github.com/FSEmbedded/releases-fus.git

2. Prepare Yocto-Build environment Run setup-yocto to prepare your Yocto-Build environment. The script will read the repo manifest.xml file and syncs all repositories that are needed for Yocto.

   Code

   1. cd releases-fus/
   2. ./setup-yocto <yocto-buildir>

3. Prepare Docker-Environment The ./setup-yocto script is capable of setting up a Docker environment in which the bitbake program can be executed for the Yocto system. This command will open a docker shell, where you can execute all yocto commands as usual.

   Code

   1. ./setup-yocto <yocto-buildir> --docker
   2. cd yocto-fus/

6. New Version naming for F&S Linux, U-Boot and meta-fus

Linux and U-Boot and meta-fus now get their own version number to be more transparent and flexible. The Version numbers reflect the Version of the original package, if needed the NXP version and the F&S Version. For example the linux version name is composed like this

[Version Orig. Kernel]-[Version IMX]-[Version FS]

linux-v6.6.101-2.2.1-fus1.0

This way it is easier to recognize the applied patch levels and the same package versions can be used in multiple releases.

The actual packages versions are marked as annotated tags in the git history. The Name of the overall release (like fsimx93-Y2025.08) is still set as a light tag.

7. New CVE Tracker Tool fs-cve-tracker

The F&S CVE Tracker Tool can help you to keep track of the current CVE status of your yocto image. It will launch a local version of Dependency Track and upload the SBOM of your Yocto Build to it. Dependency Track will scan your SBOM for vulnerabilities, which can be downloaded in VEX format. The F&S CVE Tracker Tool can also be used to improve your VEX file by marking already fixed CVEs or sorting out CVEs which affect components that are not in your build configuration.

You can also use Dependency Track to audit the remaining CVEs an generate Audit Reports for your documentation.

For a quick start you can run the following command after your Yocto Build has finished:

This command will install Dependency Track to your system, upload the SBOM from your build and improve your vulnerabilities scan to sort out as many false positives as possible.

Please note that this may take a while on first run.

Known Issues

Changelog

The following list shows the most noticeable changes in this release in more detail since our last release for this platform. For a detailed description please check the respective git histories.

u-boot-v2024.04-fs1.8

• Add support for NetDCU93

linux-v6.6.147-2.2.2-fus1.1

• Update to version 6.6.147
• Add support NetDCU93

meta-fus-yocto-5.0.19-fus1.1

• Add additional test packages to the fus-image-sdt
• Improve remote desktop support
• Add OpenSSL Provider for SE050 security chip
• Update fus-image-std packages
• Update to Yocto 5.0.19
• Add F&S Release Name to fus-image-std
• Remove glmark2 from fus-image-std
• Only create SBOM for runtime-packages for now
• Add u-boot-fus explicitly to the CylconeDX SBOM
• Use NXP wlan driver as default driver

linux-examples-fus-fus1.1

• Port ADC test tool to i.MX93 using the recommended IIO framework
• Migrate gpio.c from deprecated sysfs to libgpiod
• Upgrade PWM control to Hz and percentage with polarity support

nboot-2026.09

• Add support for NetDCU93
• ELE-FW update to 2.0.5

Documentation

• FSiMX93_FirstSteps_eng.pdf
• LinuxOnFSBoards_eng.pdf

Please download the hardware documentation directly from our website. Then you always have the newest version.

For further support please contact us in the F&S Forum

Hi thadsri01 ,

I'm glad to hear that the display is working so far.

1. Maybe, accourding to elixir or our github, i can't find a defined mode for "midas,mdt0500b1ih-mipi", so i asume, you have defined one.
I can't say for sure whether the values for Clock, Sync, and porches are correct. You'll have to test different values and see how they affect the display.

2. In the past, we used a 1280x800 LVDS display with MIPI-to-LVDS conversion on the iMX8ULP via an IC (tc358775), which worked fine for us.

3. In the past, we didn't have any MIPI displays with the ILI9881C controller.

4. We have a 3.5-inch MIPI display with a resolution of 600x480 in our lineup of accessories, which uses an nv3051d controller.

5. Unfortunately, I'm not familiar with any displays here.


I would take a closer look at the MIPI flags. In our experience, we've often encountered difficulties when MIPI sync signals are active. Therefore, I'd recommend checking whether the MIPI_DSI_MODE_VIDEO_BURSTflag offers any benefits here.

Hi Bharath ,

your driver checks the voltages.

Try to set the properties again.
https://github.com/FSEmbedded/…x8ulp.dtsi#L518C1-L519C35

for vqmmc-supply set the following:

Let me know if it works

Hi @Bharath,

sdio-pwr ist just a enable GPIO of the OSM.
If your driver checks the voltage of 1v8, then i would recommend to remove following properties:
https://github.com/FSEmbedded/…x8ulp.dtsi#L518C1-L519C35

Please, note: The BBDSI does only provide 3.3V for VDD_SDCARD, and 1.8V for SD_A_VCC.

Hi thadsri01 ,

just like to ask, if you got dcnano-crtc error messages in dmesg.
Do you have kernel-messages with `dmesg | grep -i dcnano` ?
something like "failed to find pll clock rate"?

You may need to set a valid PixelCLK value in the driver that is compatible with the 8ULP.

Hi thadsri01 ,

1. In our BSP, GPIO_B_6 (PTF30) is a normal, unreserved GPIO.
In Our BSP. The Pad-Control is configured with 0x2 (internal Pull-Down).

We also use this pin on our OSM8ULP-SKIT for MIPI-Displays as a Touch-Reset, see:
https://github.com/FSEmbedded/…m-bb-ee0350et-2cp.dts#L26

2. The Sequencing depends on the Display and should be described in the Datasheets.

However the driver performs a defined sequencing:
https://elixir.bootlin.com/lin…el-ilitek-ili9881c.c#L873
First the regulator "power" is enabled, then the reset is performed.

3. We also use GPIO_B_6 for Touch reset for our EE0350ET Display, see github link

4. GPIO_B_2 is connected to J1 Pin 7 (GPIO_J1_7) on BBDSI

I hope i was able to help

Hi straxyll ,

Your HW-Configuration (OSM93-FERT1) shows, that the pads GPIO_IO12 up to GPIO_IO15 is configured as GPIO.
You can get the signals only via GPIO_A_2 up to GPIO_A_5.

We also provide configurations with UART_C and UART_D, eg OSM93-FERT11 or OSM93-FERT12.

If you need a SoM with UART, then i would reccomend to write to support@fs-net.de
We're sure we can find a solution for you here

I can check this for you.

Could you run the following in U-Boot and send me the result?

=> fsimage board-cfg

Hi @Bharath,

usdhc1 is used as SDIO_A and is routed to J6 on BBDSI.

SD_B is not available

If the 1v8 levels are suitable for the EVK, you could try increasing the drive strength for the PinCtrls.

I hope i was able to help

Hi straxyll ,

The PADs for UART_C and UART_D are shared with GPIO_A.
From your description, I gather that the PAD is likely configured as GPIO_A via the mounting resistors.

GPIO_IO12 can be UART_D_TX or GPIO_A_5

GPIO_IO13 can be UART_D_RX or GPIO_A_4

GPIO_IO14 can be UART_C_TX or GPIO_A_3

GPIO_IO15 can be UART_C_RX or GPIO_A_2

The configuration of the pin assignment for UART_C or GPIO_A depends on our variant definition for the OSM93/91.

Hi Bharath,

The OSM 8ULP only provides 1v8 Voltage Level for SDIO.
To Support SD-Cards, the initialisation needs to be 3v3, even on UHS cards.

You will need a Level Converter especially for SDIO.

The OSM8ULP-SKIT currently does not provide such converters.
Only the Armstone8ULP comes with Level conversion for SD-Cards.

Hi Ajith Ali ,

You can only use SPI_B in linux, see:
https://github.com/FSEmbedded/…-mx8ulp.dtsi#L45C1-L45C31

I assume, that you are allready using SPI_B.

SPI_A (FLEXSPI) does not have a linux RPMSG driver and is currently not useable via Linux.
Also FLEXSPI is not compatible with generic SPI ICs. It is designed for xSPI-Flashes according to JEDEC JESD251D specification.

You can use the interface only via own Cortex-M Firmware in combination with a xSPI-Flash like NAND, NOR or psRAM.

I hope I’ve been able to help you here 😊

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 😊

Hi @Bharath,

SPI_A (FLEXSPI) and SPI_B (LPSPI) comes from the Cortex-M33 Domain.

SPI_B can be controlled in linux via rpmsg

Hi @Bharath,

1. We use currently MCUXpresso SDK 2.16

2. You can find the source code here:
https://github.com/FSEmbedded/realtimed

3. Yocto is unable to generate builds for different architectures as defined in the machine configuration. Therefore, Yocto uses only the precompiled binary file as the Cortex-M firmware.

4.You can find the configurations here:
https://github.com/FSEmbedded/…b/master/FreeRTOSConfig.h
https://github.com/FSEmbedded/…aster/armgcc/config.cmake

Hi Bharath ,

In general, xSPI interfaces, such as FlexSPI and other QSPI implementations, are not compatible with generic SPI interfaces. xSPI is specifically designed for Flash ICs according to the JEDEC JESD251D specification.

Currently, there is no Linux RPMSG driver available for this interface. FlexSPI can currently only be accessed through the Cortex-M core running FreeRTOS.

SPI_A on the OSM is implemented as QSPI according to the OSM Specification v1.2.

If your target application does not require RGB signals, LPSPI4 can be used on the custom carrier board, as described above.

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.

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.

Hi Ajith Ali ,

When you use the signals PTF8 - PTF11 for LPSPI4, then you use the RGB signals of the OSM-Module.

PTF8 -> RGB_B3

PTF9 -> RGB_B2

PTF10 -> RGB_B1

PTF11 -> RGB_B0

RGB is not routed on ADP-OSMBB2, therefore it is not accessable on PCoreBBDSI

SPI_A uses the FLEXSPI-IP of the 8ULP which is within the RT-Domain, not LPSPI4.

SPI_A is only usable with QSPI-Flash ICs within RTOS on Cortex-M.

Best Regards

Hi Ajith Ali ,

thanks fs-support_PG for your precise answer.
I don't have much more to add here.

The current release does not support Bluetooth.

To enable this, we would need to rewrite the tty-rpmsg driver as a serdev driver so that the Bluetooth driver can be used.

If Bluetooth on the PCore is relevant for your application, then we can work out a solution for you.

The best way to do this is to send us a message via our support email