Apalis TK1 PREEMPT_RT patch

Dear Ladies and Gentlemen,

I am trying to patch the Apalis TK1 kernel with the PREEMPT_RT patch. Unfortunately, the patch fails und ofc the kernel build as well. I will append the corresponding logs.

I followed the instructions here:

https://developer.toradex.com/knowledge-base/build-u-boot-and-linux-kernel-from-source-code#Image_Versions

and here

https://developer.toradex.com/knowledge-base/real-time-linux

using toradex_tk1_l4t_r21.5 as git branch. The RT patches i tried are:

https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/older/patch-3.10.39-rt40.patch.xz
https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/older/patch-3.10.44-rt46.patch.xz

We really need this RT patch, because the regular kernel using “low latency desktop” is not sufficient for our application. We need sub ms latency.

I used the following commands. All neccessary tools have been installed previously and installation is not listed next. Please note that I am using the OpenEmbedded Core cross-compiler.

git clone -b toradex_tk1_l4t_r21.5 git://git.toradex.com/linux-toradex.git

echo "export ARCH=arm" >> export_compiler

echo "export PATH=/media/adminuser/27be87fc-b3f8-4b89-99c7-db56730949a7/OpenEmbeddedCore/oe-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin:/media/adminuser/27be87fc-b3f8-4b89-99c7-db56730949a7/OpenEmbeddedCore/oe-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/arm-angstrom-linux-gnueabi/:$PATH" >> export_compiler

echo "export CROSS_COMPILE=arm-angstrom-linux-gnueabi-" >> export_compiler

source export_compiler

cd linux-toradex/

make apalis-tk1_defconfig

cd ..

wget https://www.kernel.org/pub/linux/kernel/projects/rt/3.10/older/patch-3.10.39-rt40.patch.xz

cd linux-toradex/

xzcat ../patch-3.10.39-rt40.patch.xz | patch -p1 --verbose > patch_log

make apalis-tk1_defconfig

make menuconfig (setting kernel features to fully preemptive)

make -j3 uImage LOADADDR=0x80008000 2>&1 | tee build.log

https://share.toradex.com/57p3d0c1qd0hfc4?direct

Kernel for TK1 is not an upstream kernel, It’s an 3.10.40 based kernel modified by nvidia. You’ll need to port the rt-patch yourself taking good care of interfaces added by nvidia. Please keep in mind that rt kernel is not decreasing latency (it may even increase it) it only decreases latency jitter.

Depending on your requirements you may also try the mainline Linux kernel e.g. also available via the following OpenEmbedded machine.

Dear Dominik and Marcel,

thanks for the reply. Unfortunately, I am very new at linux and I am unable to modify the kernel.

I just read that the standard kernel has some basic RT capabilities and maybe that will be sufficient. How can I grant an application the correpsonding access rights to use SCHED_SETSCHEDULER. I already created an realtime group granting it the right to set the rtprio all the way to 99. I added the root user to the group, but I still get “Operation not permitted” when trying to set the scheduling policy. Since there is no “sudo” on the angstrom, how can I run the application with the neccessary rights?

OK I already figured it out how to get the permission and how to set the RT priorities. Nevertheless, the problem persists. The timing improved quiet a bit, but I still got timing issues every once in a while.

To explain my problem in more detail: The application reacts to an GPIO event and is supposed to trigger a SPI read with 3600 bytes in length. The GPIO interrupt arrives every 25 ms and the SPI transfer must be completed before the next GPIO arrives. Therefore what I need is hard real time. With my current setup the SPI transfer is rarely started up to 30 ms after the GPIO arrived, which of course leads to data loss. This only occurs every few seconds or so, but we cannot tolerate any data loss.

Marcel, u mentioned using the mainline kernel. How can I compile and exchange the kernel for my toradex image? Thank you very much in advance.

Best Regards

I would suggest for you to re-test the same with the following mainline based demo image. BTW: You may also simply try our new Toradex Easy Installer which would have that image available to install out-of-the-box via Internet. If you need to modify the Linux kernel thereof have a look at the following OpenEmbedded recipe concerning configuration and patches we used. The following article on our developer website explains the basic procedure how to build/deploy the same.

Dear marcel,

thanks for the advice. I deployed the image to the TK1. Unfortunately, the demo image seems to have a wrong device tree. With the image I suddenly got 64 tty devices, which seems odd. SPI seems to be missing completely. Are you sure this image fits the Apalis TK1 with Ixora baseboard? How can I apply the RT patch to this image? I suppose I’ll have to get the mainline kernel separately and apply the path there. How do I exchange the kernel image with the patched one?

Best Regards

thanks for the advice.

You are very welcome.

I deployed the image to the TK1. Unfortunately, the demo image seems to have a wrong device tree. With the image I suddenly got 64 tty devices, which seems odd.

No, you are probably just looking at virtual ttys. E.g. on a regular Linux workstation I count more than a hundred of them.

SPI seems to be missing completely.

What exactly would you expect concerning SPI? In general I guess one will need to configure/compile/deploy resp. SPI device drivers.

Are you sure this image fits the Apalis TK1 with Ixora baseboard?

Yes, it actually fits the Apalis Evaluation Board which is even a super set of the Ixora. So one could probably further strip it down for production use.

How can I apply the RT patch to this image? I suppose I’ll have to get the mainline kernel separately and apply the path there.

Yes, just as anywhere else one would need resp. Linux kernel sources (e.g. my link to the recipe previously given) and apply any patches on top.

How do I exchange the kernel image with the patched one?

Either you deploy the complete BSP (e.g. my link concerning building/deployment previously given) or you simply copy resp. binary Linux kernel image and/or device tree blob directly to /run/media/root/BOOT on target.

Thanks Marcel. I was wondering about the ttys cuz the old image did not have those. It only had the 2 interfaces ttyTHS3 and ttyTHS2, if I remember correctly. Concerning the SPI, i was expecting that the same drivers would be loaded as before for the 2 interfaces present on the Apalis TK1, which are for the spidev0.0 and spidev1.0. Now I don’t have any spi devices probably cuz they are not mapped in the device tree.

Without these I can’t test if the performance improved. Isn’t there any RT based image for the TK1, that has the SPI devices and that I could use to just test if it even makes a difference? I don’t wanna get deeply involved into kernel compiling and patching, if it does not help in the end. I don’t have any experience with this, so it would take ages to get this done and then I really need to know if its worth it.

We could also switch to an Apalis imx6Q device, if that makes things easier.

With Embedded devices one usually has to customise them to its specific requirements. I’m afraid we do not have such a customisation matching your specific requirements available out-of-the-box. Of course such customisation is rather trivial for somebody working in this field. Alternatively you may involve one of our partner network companies. You may also try Apalis iMX6Q which is somewhat better/easier suited for somewhat simpler use cases which you may be targeting. Apalis TK1 makes most sense for advanced graphics/multimedia use cases really.