[Xenomai] Cobalt core and Yocto

Jeff Melvile jmelville at mitre.org
Tue Dec 19 22:46:38 CET 2017

Hi Steve,

On Tue, 19 Dec 2017, Steve Pavao wrote:

> Hi Jan,
> > On Dec 19, 2017, at 2:24 PM, Jan Kiszka <jan.kiszka at siemens.com> wrote:
> > 
> > On 2017-12-19 19:49, Steve Pavao wrote:
> >> Hi Lowell,
> >> 
> >> Thanks for that tip.  That’s what I was thinking I might need to do.
> >> 
> >> I guess the solution in Yocto terms is to rework my I-PIPE patch recipe to not directly apply the I-PIPE patch, but rather to call prepare-kernel.sh and allow it to apply the patch, plus do the other things it needs to do.  I guess that should happen in a do_configure() {} block.
> > 
> > Actually, I would move the kernel patching out of the xenomai recipe and
> > rather have one recipe for the userspace packages and a
> > xenomai-kernel.inc which appends the kernel preparation task with the
> > prepare-kernel.sh invocation. It would also bring in (once again) the
> > xenomai sources so that its kernel elements get pulled into the kernel
> > build. In your kernel recipe, you would simply include that file.
> > 
> > This way, the kernel could come from various sources, including
> > git.xenomai.org/ipipe.git, and just needs to have the I-pipe patch
> > already applied, either in it git source or by adding a corresponding
> > patch to the custom kernel recipe.
> > 
> > This seems similar to how ELDK modeled this:
> > http://git.denx.de/?p=eldk.git;a=tree;f=meta-eldk/recipes-kernel/xenomai;h=bf965c6d2fa5132413b498161c90f337be8fb174;hb=refs/heads/5.8-eldk <http://git.denx.de/?p=eldk.git;a=tree;f=meta-eldk/recipes-kernel/xenomai;h=bf965c6d2fa5132413b498161c90f337be8fb174;hb=refs/heads/5.8-eldk>
> Thanks for your advice, Jan.  I was hoping to keep things as simple as possible, though.  The ELDK example has a highly-customized bb recipe.
> Could I achieve my ends If I use my initial idea, which is to call the prepare-kernel.sh from a do_configure block, rather than directly applying the I-PIPE patch?  It seems like it won’t succeed, based on what you have said, perhaps because the recipe that calls prepare-kernel.sh is going to need to be more complex than simply calling that script.  (You mentioned about needing to pull in the xenomai sources once again).

Back on Xenomai 2.6, I created a bbappend for the kernel recipes that 
pulls in the Xenomai source in addition to the kernel source. It added a 
'prepare_xenomai_kernel_ task in between do_patch and do_kernel_configme. 
The extra task ran the prepare-kernel.sh script and some other cleanup. In 
our case we were actually appending the linux-xlnx recipes from 
meta-xilinx for their Zynq kernel fork. The task had to support pre/post 
versions of the I-pipe patch as well. The userspace libraries were a 
separate recipe. One of my colleagues has been working on transitioning 
our flow to Xenomai 3 for the Zynq UltraScale+ but other priorities keep 
popping up. 

> I think I need to hand this task off to a colleague who has some more Linux internals experience.
> > That is outdated now, unfortunately. Do you plan to publish your layer
> > afterwards? I suppose some people would be happy about a meta-xenomai
> > with support for Xenomai 3.
> I’d have to check with my organization.  Personally, I’d like to see anyone publish one, including us.  Anything that allows folks to start using Xenomai 3 more easily from within their highly-customized Poky environments would be helpful.

+1. I'll check in on the status of our Xenomai 3 work and what it would 
take to share what we have. I'd certainly like to see something reusable 
arise and would be willing to help.
> - Steve Pavao
> Korg R&D
> _______________________________________________
> Xenomai mailing list
> Xenomai at xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai


More information about the Xenomai mailing list