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

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

[Bob Feretich]

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.)

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?

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?

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.

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.

Please advise.

Regards,
Bob Feretich

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

[Gilles Chanteperdrix]

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.

> 
> 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.

> 
> 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?

> 
> 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.
> 
> 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.

-- 
					    Gilles.

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

[Bob Feretich]

[-- 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 --]

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

[Gilles Chanteperdrix]

Bob Feretich wrote:
> 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?

These URLs are relative to your system, I can not load the corresponding
file from this mail. But yes, these patches sound familiar to me and at
least some of then have been integrated in later versions of the Linux
kernel. The beagle board is supported by the mainline kernel, you have
no reason to use a distribution-specific fork.

Also note that the VFP support is broken in the Adeos I-pipe patch for
Linux 2.6.29. It has been fixed in the upcoming Adeos I-pipe patch for
Linux 2.6.31. Patch for 2.6.33, and maybe 2.6.32 should follow soon.


-- 
					    Gilles.

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

[Bob Feretich]

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

I'll move to the mainline kernel.
When do you expect a patch that supports the OMAP VFP will be available?

Regards,
Bob

On 4/6/2010 1:55 PM, Gilles Chanteperdrix wrote:
> Bob Feretich wrote:
>   
>> 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?
>>     
>
> These URLs are relative to your system, I can not load the corresponding
> file from this mail. But yes, these patches sound familiar to me and at
> least some of then have been integrated in later versions of the Linux
> kernel. The beagle board is supported by the mainline kernel, you have
> no reason to use a distribution-specific fork.
>
> Also note that the VFP support is broken in the Adeos I-pipe patch for
> Linux 2.6.29. It has been fixed in the upcoming Adeos I-pipe patch for
> Linux 2.6.31. Patch for 2.6.33, and maybe 2.6.32 should follow soon.
>
>
>   

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

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

[Gilles Chanteperdrix]

Bob Feretich wrote:
> I'll move to the mainline kernel.
> When do you expect a patch that supports the OMAP VFP will be available?

You can have a preview here:
http://sisyphus.hd.free.fr/~gilles/pub/adeos-ipipe-2.6.31-arm-1.15-01.patch

I am working on it, and have some more work to do, so, 1.15-02 will
probably be released in the next days (say, less than a week from now).

-- 
					    Gilles.