[SOLVED] How to make Yocto to patch the kernel with Preempt-RT? for STM32MP1

[A.M.]

Hi!

STM32MP1 provides a real-time core, and we use it for the hard-real time. But additionally, we would need the application running on the two fast cores to also be real-time. (with softer constraints but still better than standard scheduling on Linux).

For this, I added to the yocto project, at (not the best place, but just trying to make it to work for now):

Layers/meta-st/meta-st-openstlinux/conf/distro/openstlinux-weston.conf

PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
COMPATIBLE_MACHINE = "(stm32mp1)"

But then, I get the following errors:

ERROR: Nothing PROVIDES 'quilt-native'

quilt-native was skipped: incompatible with machine stm32mp1 (not in COMPATIBLE_MACHINE)

ERROR: Required build target 'st-image-weston' has no buildable providers.

Missing or unbuildable dependency chain was: ['st-image-weston', 'quilt-native']

[Bernard PUEL]

Hi, an x-linux expansion package is available to get the linux real time patches from the linux foundation project. This expansion package is a yocto layer you have just to add to your openstlinux yocto project.

This package should be available publicly soon. But it is also available in private github.

So if you are interested to get it now, I will send you an invitation to join this private github.

Just let me know.

[A.M.]

First of all, thank you for taking the time to answer.

Getting access to that layer would be fantastic, so yes, I am interested indeed.

[Bernard PUEL]

This is done.

[A.M.]

Trying this code, it seems to be an issue with libc build:

ERROR: glibc-2.35-r0 do_compile: oe_runmake failed
ERROR: glibc-2.35-r0 do_compile: ExecutionError('/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/temp/run.do_compile.2259', 1, None, None)

Seems related with undefined `____strtof_l_internal`

Not sure where this comes from.

Log data follows:
| DEBUG: Executing python function autotools_aclocals
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
| DEBUG: Python function autotools_aclocals finished
| DEBUG: Executing shell function do_compile
...
 
| make -j 4 subdir=mathvec -C mathvec ..=../ others
| make[2]: Entering directory '/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/git/mathvec'
| make[2]: Nothing to be done for 'others'.
| make[2]: Leaving directory '/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/git/mathvec'
| make -j 4 subdir=support -C support ..=../ others
| make[2]: Entering directory '/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/git/support'
| arm-ostl-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/recipe-sysroot -o /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/build-arm-ostl-linux-gnueabi/support/test-run-command -nostdlib -nostartfiles -static -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fmacro-prefix-map=/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0=/usr/src/debug/glibc/2.35-r0 -fdebug-prefix-map=/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0=/usr/src/debug/glibc/2.35-r0 -fdebug-prefix-map=/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/recipe-sysroot= -fdebug-prefix-map=/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/recipe-sysroot-native= -fuse-ld=bfd /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/build-arm-ostl-linux-gnueabi/csu/crt1.o /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/build-arm-ostl-linux-gnueabi/csu/crti.o `arm-ostl-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/recipe-sysroot --print-file-name=crtbeginT.o` /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/build-arm-ostl-linux-gnueabi/support/test-run-command.o /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/build-arm-ostl-linux-gnueabi/elf/static-stubs.o /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/build-arm-ostl-linux-gnueabi/support/libsupport_nonshared.a -Wl,-z,now -Wl,--start-group /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/build-arm-ostl-linux-gnueabi/libc.a -lgcc /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/build-arm-ostl-linux-gnueabi/elf/libgcc-stubs.a -Wl,--end-group `arm-ostl-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/recipe-sysroot --print-file-name=crtend.o` /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/build-arm-ostl-linux-gnueabi/csu/crtn.o
| /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/recipe-sysroot-native/usr/bin/arm-ostl-linux-gnueabi/../../libexec/arm-ostl-linux-gnueabi/gcc/arm-ostl-linux-gnueabi/11.3.0/ld.bfd: /root_yocto_folder/build-openstlinuxX11-stm32mp15-rt/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/glibc/2.35-r0/build-arm-ostl-linux-gnueabi/libc.a(strtof.o): in function `__strtof_internal':
 
...
 
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
ERROR: Task (/root_yocto_folder/layers/openembedded-core/meta/recipes-core/glibc/glibc_2.35.bb:do_compile) failed with exit code '1'

Did you experienced this?

[Bernard PUEL]

No. Could you please describe from which SW setup you started before to apply the x-linux-rt meta layer ? Which version ? Which distribution ?

The meta layer is supposed to be applied on top of V4.1 OSTL.

[A.M.]

Hi!

It seems I had the MACHINE set as stm32mp1 in some places and stm32mp15 for the RT recipe,which caused the issue. I cleaned the build cache and now it went much further (still building).

I hope this layer will be made public soon :)

[Bernard PUEL]

ok great ! from V3 to V4, Some machines when to stm32mp1 to manage both stm32mp15 and stm32mp13 (was publicly announced this week).

[A.M.]

The build succeeded and I could install the image on the STM32MP157.

uname -a

Correctly indicates PREEMPT_RT

However, running the cyclictest does not gives really good results:

root@stm32mp1-rt:/# cyclictest --priority 99 -a
WARN: stat /dev/cpu_dma_latency failed: No such file or directory
policy: fifo: loadavg: 1.50 0.99 0.77 2/245 4452
 
T: 0 ( 4401) P:99 I:1000 C: 45745 Min: 16 Act: 51 Avg: 42 Max: 623

Did you also get similar numbers?

[Bernard PUEL]

You can check https://wiki.st.com/stm32mpu/wiki/X-LINUX-RT_OpenSTLinux_Expansion_Package.

Depending on your application the results can change but with minimal application you can be under 50us Max latency.

[A.M.]

CyclicTest must be run for at least few hours under stress to get significant max value. The -l=1000 seems too short to either get into the worse situations or to really stress the system. I went for 200000 and play with video/3D in the while.

I am happy to see the RT patch public :)

Thank you

[Bernard PUEL]

Yes you are right. Generally better to run for 10h test if you have high constraints on real time on your system. But moving linux to linux RT is just the first step if you have high realtime constraints. As you can see on the results (cyclictest), although the average latency is highly improved with linux rt, max latency reduction needs additionnal work. This work is some tuning depending on your system realtime constraints and your system features.

for exemple:

• systemd is bringing some high latency during boot and after (you could switch to sysvinit)
• dhcp same. Moving to static IP @ (when possible) will help ...