* [Xenomai-help] Adeos patch interference with Angstrom 2.6.29-r46 @ 2010-04-05 21:22 Bob Feretich 2010-04-05 22:18 ` Gilles Chanteperdrix 0 siblings, 1 reply; 6+ messages in thread From: Bob Feretich @ 2010-04-05 21:22 UTC (permalink / raw) To: xenomai 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] Adeos patch interference with Angstrom 2.6.29-r46 2010-04-05 21:22 [Xenomai-help] Adeos patch interference with Angstrom 2.6.29-r46 Bob Feretich @ 2010-04-05 22:18 ` Gilles Chanteperdrix 2010-04-06 20:46 ` Bob Feretich 0 siblings, 1 reply; 6+ messages in thread From: Gilles Chanteperdrix @ 2010-04-05 22:18 UTC (permalink / raw) To: Bob Feretich; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] Adeos patch interference with Angstrom 2.6.29-r46 2010-04-05 22:18 ` Gilles Chanteperdrix @ 2010-04-06 20:46 ` Bob Feretich 2010-04-06 20:55 ` Gilles Chanteperdrix 0 siblings, 1 reply; 6+ messages in thread From: Bob Feretich @ 2010-04-06 20:46 UTC (permalink / raw) To: xenomai [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] Adeos patch interference with Angstrom 2.6.29-r46 2010-04-06 20:46 ` Bob Feretich @ 2010-04-06 20:55 ` Gilles Chanteperdrix 2010-04-07 0:42 ` Bob Feretich 0 siblings, 1 reply; 6+ messages in thread From: Gilles Chanteperdrix @ 2010-04-06 20:55 UTC (permalink / raw) To: Bob Feretich; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] Adeos patch interference with Angstrom 2.6.29-r46 2010-04-06 20:55 ` Gilles Chanteperdrix @ 2010-04-07 0:42 ` Bob Feretich 2010-04-08 12:16 ` Gilles Chanteperdrix 0 siblings, 1 reply; 6+ messages in thread From: Bob Feretich @ 2010-04-07 0:42 UTC (permalink / raw) To: Gilles Chanteperdrix, xenomai [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] Adeos patch interference with Angstrom 2.6.29-r46 2010-04-07 0:42 ` Bob Feretich @ 2010-04-08 12:16 ` Gilles Chanteperdrix 0 siblings, 0 replies; 6+ messages in thread From: Gilles Chanteperdrix @ 2010-04-08 12:16 UTC (permalink / raw) To: Bob Feretich; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-04-08 12:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-05 21:22 [Xenomai-help] Adeos patch interference with Angstrom 2.6.29-r46 Bob Feretich 2010-04-05 22:18 ` Gilles Chanteperdrix 2010-04-06 20:46 ` Bob Feretich 2010-04-06 20:55 ` Gilles Chanteperdrix 2010-04-07 0:42 ` Bob Feretich 2010-04-08 12:16 ` Gilles Chanteperdrix
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.