Add support for Xenomai on Toradex SoMs #239
Conversation
Add recipes to build Xenomai 3 and 4 on top of the Linux Kernel 6.12. Signed-off-by: Leonardo Graboski Veiga <[email protected]>
Add distros that allow to build Xenomai 3 and 4 on Toradex hardware. Signed-off-by: Leonardo Graboski Veiga <[email protected]>
Some distro data was in the intel-corei7-64.inc file, which is specific to the machine. This makes it confusing to adjust config that is applicable to the Xenomai distros. Some of the configs will still be applicable only to the machine-distro couple, but the reason for the overrides is the distro, so it sounds more suitable to leave the configs in a distro file. Signed-off-by: Leonardo Graboski Veiga <[email protected]>
The Xenomai 6.12 recipes before this commit are only applicable to Toradex BSPs. This adaptation makes it possible to use it for intel-corei7-64 (x86) architecture as well. A big caveat is that it must stick to kernel 6.6 because intel only has 6.12 on master but not on scarthgap. This leads to several overrides. Signed-off-by: Leonardo Graboski Veiga <[email protected]>
|
Adding this PR as a draft because I still have to do some runtime tests especially to check the kernel command-line arguments, but I already would like to start getting feedback on the Yocto part of things. |
There was a problem hiding this comment.
This distro is building upstream kernel for all devices, or is only for the devices we use upstream kernel? I understand it's the first, right? Since upstream DISTROOVERRIDES is being added.
Couldn't we just name these torizon-xenomai[3|4]?
There was a problem hiding this comment.
This distro is building upstream kernel for all devices, or is only for the devices we use upstream kernel? I understand it's the first, right? Since upstream DISTROOVERRIDES is being added.
For intel-corei7-64, the upstream override does not apply. This is why I had to do this:
PREFERRED_PROVIDER_virtual/kernel:xenomai4 = "linux-xenomai-4"
PREFERRED_PROVIDER_virtual/kernel:xenomai4:upstream = "linux-xenomai-4"
For Toradex machines, I'm explicitly using the upstream kernel recipe as base:
# Use BSP kernel recipe as the base
BASE_KERNEL_CONFIG:aarch64:tdx = "recipes-kernel/linux/linux-toradex-upstream_6.12.bb"
In the end, I could try to actually not use the upstream override for Toradex BSPs, even if I use the linux-toradex-upstream. But then we come to your second question, which is more conceptual than practical.
Couldn't we just name these torizon-xenomai[3|4]?
These Xenomai kernels aren't technically upstream because they are a fork of the upstream + the Xenomai patches applied:
- https://source.denx.de/Xenomai/xenomai4/linux-evl (Xenomai 4)
- https://source.denx.de/Xenomai/linux-dovetail + https://source.denx.de/Xenomai/xenomai (Xenomai 3)
But, from our perspective, what we call downstream are the SoC vendor BSPs, at least so far. And these Xenomai are not based on the SoC vendor BSPs. They are "just" some patches on top of upstream kernel.
We have PREEMPT_RT variants of the upstream kernel, which looks more similar to this Xenoami case than a downstream.
And we still called those linux-toradex-upstream-rt https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-kernel/linux/linux-toradex-upstream-rt_6.6.bb?h=scarthgap-7.x.y - or at least we did before PREEMPT_RT was merged into the upstream.
I mean, whatever you guys decide, I'm in. I don't have a strong preference.
There was a problem hiding this comment.
p.s. would the question apply the other way around? I mean, for x86 the Xenomai recipe is using the "upstream" kernel plus the patches, instead of the linux-intel which uses github.com/intel/linux-intel-lts
I don't know if we can consider this kernel Intel's downstream, or just a fork of the upstream.
But if we consider it Intel's downstream, I think that for the sake of alignment, then we should have:
- Either: set
torizon-upstream-xenomaiand renames/common-torizon-xenomai/common-torizon-upstream-xenomai/ - Or: set
torizon-xenomaiand keepcommon-torizon-xenomai
There was a problem hiding this comment.
I'd try to keep the naming pattern at least for distros targeting our SoMs; so I'd go with torizon-upstream-xenomai.
For common-torizon I don't have any preference. If we don't foresee the possibility of providing both downstream and upstream distros or if the meaning of these terms is too blurry I wouldn't necessarily use those words in the distro file name. Thus even the current common-torizon-xenomai would be okay.
| @@ -0,0 +1,82 @@ | |||
| SUMMARY = "Linux kernel with Xenomai 3 Dovetail and the Cobalt core patches" | |||
There was a problem hiding this comment.
Minor point. Could some of the common aspects of this file and linux-xenomai-4_6.12.bb be factored out to some common include file?
There was a problem hiding this comment.
Sure. I'll put some thinking into it and come back with a proposal
| XENOMAI_KERNEL_ARGS = "audit=0 clocksource=arch_sys_counter nohz_full=1,3 \ | ||
| irqaffinity=0 isolcpus=1,3 rcu_nocbs=1,3 rcu_nocb_poll=1024 \ | ||
| nosoftlockup numa_balancing=disable hugepages=1024 " |
There was a problem hiding this comment.
Doesn't this indentation add several spaces to the OSTree commit metadata? (since the OSTREE_KERNEL_ARGS variable is passed verbatim to ostree (https://github.com/torizon/meta-toradex-torizon/blob/scarthgap-7.x.y/classes/torizon_base_image_type.inc#L89))
| PREFERRED_PROVIDER_virtual/kernel:xenomai4:upstream = "linux-xenomai-4" | ||
| PREFERRED_PROVIDER_virtual/dtb:xenomai4:upstream = "device-tree-overlays-mainline" | ||
| LINUX_VERSION_EXTENSION:xenomai4:upstream ?= "-torizon-${LINUX_KERNEL_TYPE}-xenomai4" |
There was a problem hiding this comment.
Could you clarify why you need both :xenomai4 and :upstream overrides on these assignments? Looking at the distro config both overrides are added together so either override would do the job, no?
However, using one or the other might make more sense: in this stretch of code I'd imagine something like this:
PREFERRED_PROVIDER_virtual/kernel:xenomai4 = "linux-xenomai-4"
PREFERRED_PROVIDER_virtual/dtb:upstream = "device-tree-overlays-mainline"
LINUX_VERSION_EXTENSION:xenomai4 ?= "-torizon-${LINUX_KERNEL_TYPE}-xenomai4"
The xenomai specific assignments use :xenomai4 while the DTB provider selection depends on :upstream, not on the fact that we're using xenomai. Doesn't this work?
This PR adds support for building the Linux kernel based on version 6.12 with the Xenomai patches, both for Xenomai 3 and 4.
It makes it in a way that the recipe also accommodate the x86 machine intel-corei7-64, which already has support for building Xenomai on top of the kernel versions 5.4 and 5.10.
The biggest caveat for the moment is that 6.12 is not supported by meta-intel on scarthgap, therefore there are overrides to build 6.6 for intel-corei7-64. I initially did it this way so it's easy to drop these overrides on master and on upcoming versions of Yocto. Also, it may be possible to backport the 6.12 Intel kernel and drop the overrides.
Like other variants of software that can be built for Toradex hardware (Podman and RT are examples), these Xenomai distros should be considered experimental.