I am using the TI OMAP3530 on a BeagleBoard. I need better real time support than vanilla Angstrom offers, so I am attempting to integrate Xenomai into it. The 2.6.29-R46 kernel version seems to be the latest supported by Angstrom for the BeagleBoard (as of two weeks ago). The distribution comes with a large number of patches. I know that Xenomai was tested against a vanilla kernel, but I believe that it is likely that if I omit all the Angstrom patches, some Angstrom functionality will be broken. I seems easier to start with a known working system and integrate one thing (Xenomai) into it than to try to rebuild all of Angstrom around a Xenomai patched kernel.

I plan to port a couple of my device drivers from the Linux environment to become real time drivers and write a real time user task that makes heavy use of the OMAP NEON and VFP units. The real time user task will asynchronously publish state/status to subscribed Linux applications. In general, I need to read a set of sensors and do some heavy number crunching on the results every millisecond. Actions requiring tens-of-milliseconds or less latency will be performed in the Xenomai environment.

More below...

On 4/5/2010 3:18 PM, Gilles Chanteperdrix wrote:

Bob Feretich wrote:

First, thanks for the help getting me started with Xenomai in 
openembedded. Special thanks to Felipe Brandao Cavalcanti for the files 
he posted. (I was sidetracked on another project, so I could not 
follow-up sooner.)

I added  adeos-ipipe-2.6.29-arm-1.13-04.patch to the end of the normal 
set of kernel patches to be applied against Angstrom 
linux-omap-2.6.29.bb recipe file (it builds the -r46 revision). There 
are conflicts with four Angstrom patches. There are two conflicts that I 
am concerned about. (The first two below.)


Hi,

first of all, the Adeos patch is made for the vanilla kernel, not for
patched versions, and validated with that kernel. So, I would recommend
you to upgrade the kernel, instead of using a kernel with backported
changes. Maintaining the Adeos patch is enough time consuming.

Second, on what processor do you intend to run Xenomai? Some of the
patches may not be needed at all for the processor you want to use, so
you should not even bother to try and apply them.

Addressed above.

Conflict with 
'0001-implement-TIF_RESTORE_SIGMASK-support-and-enable-the.patch'.
patching file arch/arm/include/asm/thread_info.h
Hunk #1 FAILED at 136.
Hunk #2 FAILED at 146.
2 out of 2 hunks FAILED -- rejects in file 
arch/arm/include/asm/thread_info.h
Adeos wants TIF_MMSWITCH_INT   20, but the other patch wants 
TIF_RESTORE_SIGMASK   20.
Can I define TIF_MMSWITCH_INT  as 21? Will that bother anything?

You need to inspect the code carefully to see if 21 is not used for
anything else.

I examined the patch closely. the value 21 is not used for anything else.

Conflict with 'no-cortex-deadlock.patch'.
patching file arch/arm/kernel/entry-common.S
Hunk #5 FAILED at 82.
Hunk #6 succeeded at 272 (offset 4 lines).
Hunk #8 succeeded at 494 (offset -6 lines).
1 out of 8 hunks FAILED -- rejects in file arch/arm/kernel/entry-common.S
Some Arm silicon require the "dmb" instruction in this fix to avoid 
deadlock. Does Xenomai account for this elsewhere?

What you see is what you get. All the changes made by Xenomai are
available in the Adeos patch. Without seeing the code I can not tell. Is
the processor you want to use affected by this patch?

I determined that this patch is not needed. BeagleBoard Rev. B7 and above use ES3.0 silicon. This patch seems to be needed for ES2.0 and earlier silicon.

Conflict with '/cache/l1cache-shift.patch'
patching file arch/arm/mm/Kconfig
Hunk #1 FAILED at 717.
1 out of 1 hunk FAILED -- rejects in file arch/arm/mm/Kconfig
No real conflict, the other patch just added a config entry that the 
Adeos patch wasn't expecting.

I'm sure that the above patch is not a problem.

Conflict with 'vfp/03-vfp-corruption.patch'
patching file arch/arm/vfp/vfphw.S
Hunk #5 succeeded at 136 with fuzz 1.
Hunk #6 FAILED at 156.
1 out of 6 hunks FAILED -- rejects in file arch/arm/vfp/vfphw.S
I allowed the #ifdef CONFIG_PREEMPT segment to match before the Adeos 
insertion.

Risky business, we patch a bit the vfp support, and are going to patch
it even further in next revisions. Here again, without the code, I can
not tell.

Your statement concerns me. I need NEON/VFP support and here are four patches applied to it by the distribution.
           file://vfp/02-vfp-ptrace.patch;patch=1 \
           file://vfp/03-vfp-corruption.patch;patch=1 \
           file://vfp/04-vfp-threads.patch;patch=1 \
           file://vfp/05-vfp-signal-handlers.patch;patch=1 \
Are these patches well known? Can you identify them from the above?

The specific area of detected conflict is with vfp/03-vfp-corruption.patch.
The conflicting part of the patch just seems to be decrementing a preemption counter.
@@ -154,16 +156,18 @@ look_for_VFP_exceptions:      @ Fall into hand on to next handler - appropriate coproc instr      @ not recognised by VFP +    enable_irq_cond      DBGSTR    "not VFP" #ifdef CONFIG_PREEMPT     get_thread_info    r10     ldr    r4, [r10, #TI_PREEMPT]    @ get preempt count     sub    r11, r4, #1        @ decrement it     str    r11, [r10, #TI_PREEMPT] #endif      mov    pc, lr

The #ifdef/#endif block were the unexpected statements. I think that moving the enable_irq_cond after the #ifdef block is probably the correct thing to do. I am assuming hat Xenomai is trying to enable some kind of interrupt just before this segment returns.

Regards,
Bob Feretich