BSP5 iMX8 Yocto with RT


I followed the guide in
to build a yocto linux image with real time patched Kernel.

I made sure the line DISTRO=“tdx-xwayland-rt” in local.conf.
However the built kernel seem to be not patched with RT

Linux apalis-imx8 5.4.47-rt28-5.0.0-devel+git.9e7307657fc1 #1 SMP Fri Oct 2 12:39:46 UTC 2020 aarch64 GNU/Linux

Is there something that should be done additionally?

Thank you in advance

Best regards, Majd

Hi @majd.m

Thanks for writing to the Toradex Community!

However the built kernel seem to be not patched with RT

Could you share the resulted kernel config in a text file?

Thanks and best regards,

Hi Jaski,

Thanks for the response, I uploaded the config file that is generated in

where: DISTRO = “tdx-xwayland-rt”

There is no CONFIG_PREEMPT_RT_FULL=y in that file (which is generated with yocto)

so I copied the kernel source from [oe-path]/build/tmp/work-shared/apalis-imx8/kernel-source
and added .config file with CONFIG_PREEMPT_RT_FULL=y inside, and then built the kernel
but the output of “uname -a” of the built kernel is still (no RT):

Linux apalis-imx8 5.4.47-rt28-5.0.0-devel+git.9e7307657fc1 #1 SMP PREEMPT Thu Oct 22 13:26:48 CEST 2020 aarch64 GNU/Linux

(for info: the kernel source in the above mentioned path seem to be already patched with RT kernel, because when I tried to patch it manually, a previous RT patch has been detected)

Best regards, Majd


Note that the config CONFIG_PREEMPT_RT_FULL no longer exists and it is now CONFIG_PREEMPT_RT.

However in order to enable it CONFIG_EXPERT needs also to be enabled which we missed to do. Could you try to enable them both?


Hi @max.tx,

Thank you alot for the hint. I added those flags to the config and it worked, the Kernel seem to be RT PREEMPT.

However now I got some problems in the new kernel, for example the chipselect signal of SPI doesnt work anymore! do you think that this problem has anything to do with the RT kernel?

Thanks again

Best regards, Majd

Hi @majd.m

If the ‘some problems’ go away if you exchange the kernel binary with the non-RT one then yes I’m sure it has to do with the RT kernel.

If you made other changes, e.g. changed the device tree these may or may not be considered the cause of the issues.


Could you need that patch to get over the SPI issue?

Hi @max.tx,

the patch worked! thank you!

Good to see that worked.

Thanks @max.tx.

Hi @majd.m,

In regarding the PREEMPT_RT on BSP 5, there is still much to improve.

Thanks for reporting this matter, I’m forwarding it to our BSP team.

Best regards,

André Curvello


Is there any news on this topic? Your last newsletter mentioned improvements on the RT-Performance, so I went ahead and tried it on a Apalis IM8 running the latest Toradex-rt Distro (Linux apalis-imx8 5.4.77-rt43-5.1.0-devel+git.a2f08dfd79ae #1 SMP PREEMPT_RT Mon Dec 28 16:05:41 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

But it still looks very bad:


we have done some cyclictests on the patched kernel 5.4. (that comes with BSP5.1)

Linux apalis-imx8 5.4.47-rt28-5.1.0-devel+git.43672b04da88 #3 SMP PREEMPT_RT Fri Nov 20 10:27:03 CET 2020 aarch64 aarch64 aarch64 GNU/Linux

we noticed that the real time responce on the Cortex A72 cores may have more delay than the responce on Cortex A53.


by comparing these results with the results from the RT kernel 4.14.170 from the BSP3.0b3 we find that the 4.14.170 's RT performance is much better.


could you help us interpreting the results?

Hi @m.sauer,

We conducted our own tests and we managed to find this results:


The latencies:

  • Min latency: 7us
  • Avg latency: 17us
  • Max latency: 282us

And in details:

root@apalis-imx8:~# cat /etc/issue
TDX Wayland with XWayland RT 5.1.0-devel-202012+build.5 (dunfell) \n \l

root@apalis-imx8:~# uname -a
Linux apalis-imx8 5.4.77-rt43-5.1.0-devel+git.8fc7bd5da76f #1 SMP PREEMPT_RT Mon Nov 30 08:44:04 UTC 2020 aarch64 GNU/Linux

# /dev/cpu_dma_latency set to 0us
# Histogram
# Total: 001800000 001799984 001799969 001799954 001799942 001799927
# Min Latencies: 00006 00007 00006 00007 00004 00004
# Avg Latencies: 00016 00017 00017 00017 00017 00015
# Max Latencies: 00131 00126 00145 00260 00282 00121
# Histogram Overflows: 00000 00000 00000 00000 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:
# Thread 2:
# Thread 3:
# Thread 4:
# Thread 5:

Please let me know if that helped.

Best regards,
André Curvello

Dear @andrecurvello.tx

the issue is solved for us, but your latencies look like you’ve got still a problem with your setup. Your lateny on core 4 is way to large.

This is what we see:

Kernel 5.4.77 RT
DVFS deactivated
test command: cyclictest –l100000000 -m -Sp90 -i200 -h400 -q

I’m glad to know that things are fine are your side, @m.sauer, and thanks for providing your graphics.

About our side, we’ll check what happened.

Any inputs here, @gustavo.tx?

Greetings @m.sauer and @andrecurvello.tx!

Would you be able to elaborate on what exactly improved your latency results? Was it the DVFS deactivation?

Did you run your tests while stressing the system?

Hi gustavo.tx,

Actually the DVFS on the CPUs was not correctly deactivated. So just the deactivating provided these results.

We ran the standard cyclictest without stressing the system.

Good to know.

Thanks for providing this information, @majd.m .

Best regards,
André Curvello