Hello,
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,
Jaski
Hi Jaski,
Thanks for the response, I uploaded the config file that is generated in
[oe-path]/build/tmp/work-shared/apalis-imx8/kernel-build-artifacts/.config
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
Hi
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?
Max
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.
Max
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:
Hello,
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.
[upload|4X5+EeM8fVKb8d73tJdjIL6XrcM=]
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.
[upload|J0Xjoe3Q0BAyH2fo35Sq27tJCxw=]
could you help us interpreting the results?
Hi @m.sauer,
We conducted our own tests and we managed to find this results:
The latencies:
And in details:
root@apalis-imx8:~# cat /etc/issue
TDX Wayland with XWayland RT 5.1.0-devel-202012+build.5 (dunfell) \n \l
Apalis-iMX8_Reference-Minimal-Image-rt
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.