Using TORIZON OS7 PREEMPT RT

We have to make a multithread application on IMX6ULL, with one process using IO which needs to be realtime reactive, and share data between the other processes via shared memory.

For that, we’d like to use the TORIZON OS7 PREEMPT RT. But you continue to say that PREEMPT RT is experimental, and haven’t be fully tested.

Our products must be safe, and we can’t be allowed to have systems which could randomly scratch… So what is the level of confidence we can have in this OS ?

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


I understand your concern about the reliability of Torizon OS 7 with PREEMPT_RT for your safety-critical application on the iMX6ULL. Let me provide you with the current status and recommendations based on the official documentation.

Current Status of PREEMPT_RT Support

According to the official documentation, Torizon OS with PREEMPT_RT is currently in an experimental state(1)(2). Specifically:

  • The BSP Layers and Torizon OS distributions with the PREEMPT_RT patch haven’t been fully validated by Toradex(2)
  • Toradex has only run smoke tests and cyclictest to ensure the system boots properly and PREEMPT_RT patches work under stressful conditions(2)
  • Toradex only releases PREEMPT_RT BSPs and images in an experimental state and doesn’t guarantee any functionality and bug fixes(2)

Available PREEMPT_RT Images for iMX6ULL

For your iMX6ULL module, PREEMPT_RT images are available in the monthly releases(1):

  • Torizon OS 7.5.0-devel-202511+build.14 with PREEMPT_RT for Colibri iMX6ULL eMMC(1)
  • These images use a Linux kernel with the PREEMPT_RT real-time patch applied(1)

Recommendations for Safety-Critical Applications

Given your requirement for safe, reliable systems, here are the key considerations:

1. Validation Requirements

  • Any tuning, additional kernel configuration, and validation of RT performance for your specific use case must be done at your discretion(2)
  • You would need to perform comprehensive testing and validation for your particular application requirements

2. Alternative Approaches

  • Consider heterogeneous multicore processing if your iMX6ULL supports it - running real-time tasks on dedicated cores while using standard Linux for other processes
  • Evaluate whether the standard Torizon OS preemption models might meet your requirements:
    • CONFIG_PREEMPT: Preemptible Kernel (Low-Latency Desktop)(2)
    • CONFIG_PREEMPT_VOLUNTARY: Voluntary Kernel Preemption (Desktop)(2)

3. Testing Framework

The validation tests used by Toradex are available on their GitHub repository for reference(2), which could serve as a starting point for your own validation efforts.

Conclusion

For safety-critical applications, the current experimental status of PREEMPT_RT in Torizon OS means you would need to:

  1. Perform extensive validation and testing for your specific use case
  2. Accept responsibility for RT performance validation
  3. Consider alternative real-time solutions if the experimental status doesn’t meet your safety requirements

The level of confidence you can have depends entirely on the validation work you’re prepared to undertake, as Toradex currently provides no guarantees for PREEMPT_RT functionality.

Best regards,
Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

But will Toradex support that PREEMPT_RT Images for iMX6ULL (correcting bugs if any), or not ??

Greetings @Jch,

To clarify, all we do on the PREEMPT RT images is applying the standard Linux kernel patches for real time functionality.

We don’t test any specific real-time use-cases because when it comes to real-time timing it really depends on the exact use-case. We typically urge customers to try their specific use-case against the real time image to see actual results that are relative for what they will do in production.

We do heavily test the non-PREEMPT RT image, where the only difference is that there are no PREEMPT RT patches applied on the kernel. That is to say the PREEMPT RT image is “tested” in a way by extension of the non-PREEMPT RT image. We just don’t explicitly test the PREEMPT RT capabilities themselves since whatever test we do is usually not really applicable for actual real world use-cases that customers will actually do.

With that said, what else would you like to see from us regarding the PREEMPT RT images to give you further confidence for your product?

Best Regards,
Jeremias