Re: [Xenomai-help] Adeos patch interference with Angstrom 2.6.29-r46

[Bob Feretich <bob.feretich@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 5832 bytes --]

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




[-- Attachment #2: Type: text/html, Size: 7315 bytes --]