Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
>> the i386/x86_64 merge which just happened upstream, without having to
>> fiddle at the same time with the slew of other core changes which will
>> hit the street before 2.6.24 is released. You need the latest trunk/ to
>> configure Xenomai for this kernel properly, or at least update those two
>> files:
>>
>> - scripts/prepare_kernel.sh
>> - ksrc/arch/i386/Kconfig.
>>
>> Please check if this patch runs your x86 hw reasonably well, while I'm
>> busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
>> to have a unified x86* tree for Xenomai 2.4 which has to work with all
>> supported kernel releases, including 2.6.24. Yes, I know we are in -rc
>> phase, but such merge should mostly reshuffle the directory layout, and
>> not the implementation per se, otherwise, it will have to wait for 2.5.
>
> [While building the new toy...] Hmm, I'm not a big fan of this schedule.
> Unless we want to delay Xenomai 2.4 for even more months, we will not be
> able to develop the unification against any stable kernel (the
> unification is not yet done with 2.6.24-rc1!).
>
> *IF* such an internal refactoring of Xenomai is actually that
> straightforward, why not postpone it until some later 2.4 release? I
> would rather prefer to role out something matured, also
> build-system-wise, now instead of risking to generate new regressions.
> But to make concreter: Do you plan to just create hal_32.c and hal_64.c,
> or do you then also want to merge both into hal.c?
>
>> At the end of the day (i.e. sometime during the v2.4 maintenance cycle),
>> we should have the I-pipe/x86_64 merged with the I-pipe/i386 support,
>> leading to the I-pipe/x86-2.0 series, on top of 2.6.24, and all of that
>> usable with a unified ia32/64 Xenomai support, which is basically what
>> we already have now on the powerpc side of the universe.
>>
>> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.24-rc1-i386-1.10-11.patch
>>
>> PS: slightly tested here. Looks ok, sun is still shining, birds are
>> still singing, hardware is not burning - yet.
>>
>
> Will let you know the result from my box soon.
Appears to work fine here as well, including SMP. Just one oddity so
far: /sys/module/xeno_nucleus is missing, thus a way to tune module
parameters of the built-in nucleus. xeno_hal or xeno_native, e.g., are
there. Strange.
But beyond this, I really like 2.6.24 - my new notebook finally
generates sound with its built-in speakers! 8)
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come
Philippe Gerum wrote:
> The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
> the i386/x86_64 merge which just happened upstream, without having to
> fiddle at the same time with the slew of other core changes which will
> hit the street before 2.6.24 is released. You need the latest trunk/ to
> configure Xenomai for this kernel properly, or at least update those two
> files:
>
> - scripts/prepare_kernel.sh
> - ksrc/arch/i386/Kconfig.
>
> Please check if this patch runs your x86 hw reasonably well, while I'm
> busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
> to have a unified x86* tree for Xenomai 2.4 which has to work with all
> supported kernel releases, including 2.6.24. Yes, I know we are in -rc
> phase, but such merge should mostly reshuffle the directory layout, and
> not the implementation per se, otherwise, it will have to wait for 2.5.
[While building the new toy...] Hmm, I'm not a big fan of this schedule.
Unless we want to delay Xenomai 2.4 for even more months, we will not be
able to develop the unification against any stable kernel (the
unification is not yet done with 2.6.24-rc1!).
*IF* such an internal refactoring of Xenomai is actually that
straightforward, why not postpone it until some later 2.4 release? I
would rather prefer to role out something matured, also
build-system-wise, now instead of risking to generate new regressions.
But to make concreter: Do you plan to just create hal_32.c and hal_64.c,
or do you then also want to merge both into hal.c?
>
> At the end of the day (i.e. sometime during the v2.4 maintenance cycle),
> we should have the I-pipe/x86_64 merged with the I-pipe/i386 support,
> leading to the I-pipe/x86-2.0 series, on top of 2.6.24, and all of that
> usable with a unified ia32/64 Xenomai support, which is basically what
> we already have now on the powerpc side of the universe.
>
> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.24-rc1-i386-1.10-11.patch
>
> PS: slightly tested here. Looks ok, sun is still shining, birds are
> still singing, hardware is not burning - yet.
>
Will let you know the result from my box soon.
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come
Philippe Gerum wrote:
> The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
> the i386/x86_64 merge which just happened upstream, without having to
> fiddle at the same time with the slew of other core changes which will
> hit the street before 2.6.24 is released. You need the latest trunk/ to
> configure Xenomai for this kernel properly, or at least update those two
> files:
>
> - scripts/prepare_kernel.sh
> - ksrc/arch/i386/Kconfig.
>
> Please check if this patch runs your x86 hw reasonably well, while I'm
> busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
> to have a unified x86* tree for Xenomai 2.4 which has to work with all
> supported kernel releases, including 2.6.24. Yes, I know we are in -rc
> phase, but such merge should mostly reshuffle the directory layout, and
> not the implementation per se, otherwise, it will have to wait for 2.5.
>
> At the end of the day (i.e. sometime during the v2.4 maintenance cycle),
> we should have the I-pipe/x86_64 merged with the I-pipe/i386 support,
> leading to the I-pipe/x86-2.0 series, on top of 2.6.24, and all of that
> usable with a unified ia32/64
i386/x86_64 I mean...
Xenomai support, which is basically what
> we already have now on the powerpc side of the universe.
>
> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.24-rc1-i386-1.10-11.patch
>
> PS: slightly tested here. Looks ok, sun is still shining, birds are
> still singing, hardware is not burning - yet.
>
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] I-pipe/i386 fix for oldish IO-APICs
If you happen to use Xenomai on fairly old x86 hardware with the IO-APIC support enabled, you may want to upgrade your I-pipe version to one of those listed below. Symptom: random lockup, more likely under high interrupt load Cause: mishandling of some hardware erratum affecting some IO-APIC versions (notably v17). http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.23-i386-1.10-11.patch http://download.gna.org/adeos/patches/v2.6/i386/older/adeos-ipipe-2.6.22-i386-1.10-11.patch http://download.gna.org/adeos/patches/v2.6/i386/older/adeos-ipipe-2.6.20-i386-1.10-10.patch -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] I-pipe/i386 for 2.6.24-rc1 - x86/x86_64 merge to come
The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
the i386/x86_64 merge which just happened upstream, without having to
fiddle at the same time with the slew of other core changes which will
hit the street before 2.6.24 is released. You need the latest trunk/ to
configure Xenomai for this kernel properly, or at least update those two
files:
- scripts/prepare_kernel.sh
- ksrc/arch/i386/Kconfig.
Please check if this patch runs your x86 hw reasonably well, while I'm
busy merging ksrc/arch/{i386, x86_64} on the Xenomai side. The plan is
to have a unified x86* tree for Xenomai 2.4 which has to work with all
supported kernel releases, including 2.6.24. Yes, I know we are in -rc
phase, but such merge should mostly reshuffle the directory layout, and
not the implementation per se, otherwise, it will have to wait for 2.5.
At the end of the day (i.e. sometime during the v2.4 maintenance cycle),
we should have the I-pipe/x86_64 merged with the I-pipe/i386 support,
leading to the I-pipe/x86-2.0 series, on top of 2.6.24, and all of that
usable with a unified ia32/64 Xenomai support, which is basically what
we already have now on the powerpc side of the universe.
http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.24-rc1-i386-1.10-11.patch
PS: slightly tested here. Looks ok, sun is still shining, birds are
still singing, hardware is not burning - yet.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] clocktest and cyclictest work but irqloop crashes
Steven A. Falco wrote: > Hmmm. IRQ4 is "PCI ExternalCommand Write"? But I'm not using PCI. > Here is the output: > > # ./irqloop > NULL ->unmask handler, IRQ 4, chip Mgmfff... Ok, regardless of whether the IRQ number is valid or not, it would be great that Xenomai avoids jumping out of the window like this when no IC chip descriptor is associated. Will fix, thanks. > Test mode:user-space task > Port type:serial > Port address: 0x3f8 > Port IRQ: 4 > > Received IRQs: 0 > Acknowledged IRQs: 0 > Xenomai: POSIX: destroyed thread c0f80320 > > > Philippe Gerum wrote: >> Steven A. Falco wrote: >> >>> I am testing kernel 2.6.23 ARCH=powerpc with Xenomai 2.4-rc4. The >>> clocktest and cyclictest work perfectly with the uic/spinlock patches. >>> However, the irqloop test fails with the Oops shown below. >>> >>> >> >> Please try the patch below. It looks like the chip descriptor does not >> implement >> any unmask handler, which seems odd. This patch should tell us a bit more >> about >> this issue. >> >> -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] clocktest and cyclictest work but irqloop crashes
My apologies - I didn't realize I had to change that configuration. I'll look into it. The 405GP UART is a 16550 clone but the registers are at ef600300 in memory space, and the IRQ is 0. This information is captured in the board-specific .dts file - it looks like the .dts info is made available in /sysfs. That said, I think there is more going on here. Without Xenomai, I am able to ping the loopback address. With Xenomai, I get a crash, also involving a "kernel access of bad area". Note: in both cases I am able to mount my root filesystem over NFS, so the kernel is able to use the network, but user-land (or at least ping) is not. Here is what the ping crash looks like: # ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes Unable to handle kernel paging request for data at address 0x0008 Faulting instruction address: 0xc01b4968 Oops: Kernel access of bad area, sig: 11 [#1] Netdec Modules linked in: NIP: c01b4968 LR: c01b4fc8 CTR: c0172e88 REGS: c0e479e0 TRAP: 0300 Not tainted (2.6.23) MSR: 00029030 CR: 42000422 XER: DEAR: 0008, ESR: TASK = c06cb420[660] 'ping' THREAD: c0e46000 GPR00: c0e47a90 c06cb420 0008 0001 7f01 7f01 0002 GPR08: c0f21e00 c02a1680 c02a c0f21e10 100d25f0 00ff9900 0001 GPR16: 00a0 c06dbf68 c023 c029 c0e47b78 fffee72a c02e7d88 GPR24: c02e7da8 0040 c02a1680 c02e9208 0001 c06c0040 c034fbe0 c0f21e10 NIP [c01b4968] __raw_v4_lookup+0x10/0x84 LR [c01b4fc8] raw_v4_input+0xb0/0x15c Call Trace: [c0e47a90] [c01b4f94] raw_v4_input+0x7c/0x15c (unreliable) [c0e47ab0] [c01949b0] ip_local_deliver+0xb0/0x188 [c0e47ad0] [c0194cc4] ip_rcv+0x23c/0x4a4 [c0e47b00] [c017b774] netif_receive_skb+0x220/0x2dc [c0e47b30] [c017deb4] process_backlog+0xb0/0x190 [c0e47b70] [c017e03c] net_rx_action+0xa8/0x19c [c0e47bb0] [c0023294] __do_softirq+0x80/0xfc [c0e47be0] [c0004e8c] do_softirq+0x74/0x78 [c0e47bf0] [c0023050] local_bh_enable+0x70/0x98 [c0e47c00] [c017e768] dev_queue_xmit+0x9c/0x2c8 [c0e47c20] [c0184e68] neigh_resolve_output+0xe4/0x258 [c0e47c50] [c0199310] ip_output+0x2c4/0x328 [c0e47c70] [c01987f8] ip_push_pending_frames+0x280/0x40c [c0e47c90] [c01b5928] raw_sendmsg+0x684/0x71c [c0e47d10] [c01be83c] inet_sendmsg+0x50/0x78 [c0e47d30] [c016f3cc] sock_sendmsg+0xac/0xf4 [c0e47e20] [c016f75c] sys_sendto+0xcc/0x108 [c0e47f00] [c01700c4] sys_socketcall+0x138/0x1d8 [c0e47f40] [c000d98c] ret_from_syscall+0x0/0x3c Instruction dump: 7d2b0194 913f 915f0004 80010014 83e1000c 7c0803a6 38210010 4e800020 2c03 4da20020 34630008 41820070 <8123> 2f09 419a0008 7c004a2c Kernel panic - not syncing: Fatal exception in interrupt Rebooting in 1 seconds..<0>System Halted, OK to turn off power Steve Jan Kiszka wrote: Steven A. Falco wrote: Hmmm. IRQ4 is "PCI ExternalCommand Write"? But I'm not using PCI. Here is the output: # ./irqloop NULL ->unmask handler, IRQ 4, chip Test mode:user-space task Port type:serial Port address: 0x3f8 Port IRQ: 4 Well, irqloop is preconfigured for boring x86 PCs, not thrilling PowerPC platforms :). It assumes there is a 16550-based UART at the given address using the given IRQ, but I would bet this doesn't apply to your board. Please check doc/txt/irqbench.txt on the requirements. What interface do you plan to use for the IRQ latency test? Maybe it is possible to extend the benchmark driver. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] clocktest and cyclictest work but irqloop crashes
Steven A. Falco wrote: > Hmmm. IRQ4 is "PCI ExternalCommand Write"? But I'm not using PCI. > Here is the output: > > # ./irqloop > NULL ->unmask handler, IRQ 4, chip > Test mode:user-space task > Port type:serial > Port address: 0x3f8 > Port IRQ: 4 Well, irqloop is preconfigured for boring x86 PCs, not thrilling PowerPC platforms :). It assumes there is a 16550-based UART at the given address using the given IRQ, but I would bet this doesn't apply to your board. Please check doc/txt/irqbench.txt on the requirements. What interface do you plan to use for the IRQ latency test? Maybe it is possible to extend the benchmark driver. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] clocktest and cyclictest work but irqloop crashes
Hmmm. IRQ4 is "PCI ExternalCommand Write"? But I'm not using PCI. Here is the output: # ./irqloop NULL ->unmask handler, IRQ 4, chip Test mode:user-space task Port type:serial Port address: 0x3f8 Port IRQ: 4 Received IRQs: 0 Acknowledged IRQs: 0 Xenomai: POSIX: destroyed thread c0f80320 Philippe Gerum wrote: Steven A. Falco wrote: I am testing kernel 2.6.23 ARCH=powerpc with Xenomai 2.4-rc4. The clocktest and cyclictest work perfectly with the uic/spinlock patches. However, the irqloop test fails with the Oops shown below. Please try the patch below. It looks like the chip descriptor does not implement any unmask handler, which seems odd. This patch should tell us a bit more about this issue. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] clocktest and cyclictest work but irqloop crashes
Steven A. Falco wrote:
> I am testing kernel 2.6.23 ARCH=powerpc with Xenomai 2.4-rc4. The
> clocktest and cyclictest work perfectly with the uic/spinlock patches.
> However, the irqloop test fails with the Oops shown below.
>
Please try the patch below. It looks like the chip descriptor does not implement
any unmask handler, which seems odd. This patch should tell us a bit more about
this issue.
--
Philippe.
Index: ksrc/arch/powerpc/hal.c
===
--- ksrc/arch/powerpc/hal.c (revision 3095)
+++ ksrc/arch/powerpc/hal.c (working copy)
@@ -245,6 +245,11 @@
rthal_irq_desc_status(irq) &= ~IRQ_DISABLED;
+if (rthal_irq_handlerp(irq)->unmask == NULL) {
+ printk("NULL ->unmask handler, IRQ %d, chip %s\n", irq, rthal_irq_handlerp(irq)->typename);
+ return 0;
+}
+
return rthal_irq_chip_enable(irq);
}
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] clocktest and cyclictest work but irqloop crashes
I am testing kernel 2.6.23 ARCH=powerpc with Xenomai 2.4-rc4. The
clocktest and cyclictest work perfectly with the uic/spinlock patches.
However, the irqloop test fails with the Oops shown below.
Steve
# modprobe xeno_irqbench
# lsmod
Module Size Used byNot tainted
xeno_irqbench 9668 0
# /usr/xenomai/bin/irqloop
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x
Oops: Kernel access of bad area, sig: 11 [#1]
Netdec
Modules linked in: xeno_irqbench
NIP: LR: c016d368 CTR:
REGS: c0f3dd20 TRAP: 0400 Not tainted (2.6.23)
MSR: 00029030 CR: 24000488 XER:
TASK = c032dc00[665] 'irqloop' THREAD: c0f3c000
GPR00: c0f3ddd0 c032dc00 0004 c0049e50 c02b
GPR08: c0296868 c028e0cc 03ff 1001a8d8 00ff9900
0001
GPR16: c02c c0f3df50 c02ba360 c02a 0040 fff0 0010
c0296868
GPR24: c02a c02b c0d54898 0018 c0f3de2c
c0d50040
NIP [] 0x0
LR [c016d368] rthal_irq_enable+0x4c/0x64
Call Trace:
[c0f3ddd0] [c0049ad8] xnintr_attach+0xd8/0xf0 (unreliable)
[c0f3dde0] [c0049860] xnintr_enable+0x14/0x24
[c0f3ddf0] [c007cf90] rtdm_irq_request+0x6c/0x94
[c0f3de10] [c201acbc] rt_irqbench_ioctl_nrt+0x5c0/0x654 [xeno_irqbench]
[c0f3de60] [c007bef8] __rt_dev_ioctl+0x80/0x138
[c0f3dea0] [c007de4c] sys_rtdm_ioctl+0x20/0x30
[c0f3deb0] [c0054a80] losyscall_event+0xc8/0x1d0
[c0f3dee0] [c0046d7c] __ipipe_dispatch_event+0xa4/0x208
[c0f3df30] [c0007cc8] __ipipe_syscall_root+0x40/0xf0
[c0f3df40] [c000d92c] DoSyscall+0x20/0x5c
Instruction dump:
Segmentation fault
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Proposed arch/powerpc/sysdev/uic.c patch
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
Steven A. Falco wrote:
> I applied the uic patch:
>
> diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
> index eeb38e2..5a38086 100644
> --- a/arch/powerpc/sysdev/uic.c
> +++ b/arch/powerpc/sysdev/uic.c
> @@ -48,7 +48,7 @@ struct uic {
> int index;
> int dcrbase;
>
> -spinlock_t lock;
> +ipipe_spinlock_t lock;
>
> /* The remapper for this UIC */
> struct irq_host*irqhost;
>
> However, this would not compile because of a type mismatch. I have
> added the attached patch, and it now compiles and runs. But I'm not
> sure if this is the right way to fix it. Comments?
>
This will work for the purpose of running an I-pipe enabled kernel, but
would fail with CONFIG_IPIPE disabled. Since we need to provide both,
I'm going to work on the proper patch for fixing the issue both ways.
Still, your patch will work as expected for running Xenomai.
>>> To be consequent, we would have to wrap spin_lock_init just like the
>>> other operations. Suggestion (not really tested):
>>>
>> Thanks. I have committed a tested variant.
>
> The additional #ifdef CONFIG_IPIPE for spin_lock_init should be
> redundant, in theory. What makes it necessary in practice?
>
Nothing, actually. Fixing your previous patch this way work do it:
- *(__ipipe_spinlock_t *)(lock) = IPIPE_SPIN_LOCK_UNLOCKED; \
+ *(ipipe_spinlock_t *)(lock) = IPIPE_SPIN_LOCK_UNLOCKED; \
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Proposed arch/powerpc/sysdev/uic.c patch
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Steven A. Falco wrote:
I applied the uic patch:
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index eeb38e2..5a38086 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -48,7 +48,7 @@ struct uic {
int index;
int dcrbase;
-spinlock_t lock;
+ipipe_spinlock_t lock;
/* The remapper for this UIC */
struct irq_host*irqhost;
However, this would not compile because of a type mismatch. I have
added the attached patch, and it now compiles and runs. But I'm not
sure if this is the right way to fix it. Comments?
>>> This will work for the purpose of running an I-pipe enabled kernel, but
>>> would fail with CONFIG_IPIPE disabled. Since we need to provide both,
>>> I'm going to work on the proper patch for fixing the issue both ways.
>>> Still, your patch will work as expected for running Xenomai.
>> To be consequent, we would have to wrap spin_lock_init just like the
>> other operations. Suggestion (not really tested):
>>
>
> Thanks. I have committed a tested variant.
The additional #ifdef CONFIG_IPIPE for spin_lock_init should be
redundant, in theory. What makes it necessary in practice?
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Compile-time patch for mm_struct
Steven A. Falco wrote: > Thank you very much. I hate to make extra work for you - is there a git > repository for adeos-ipipe that I should be pulling from? > git://www.denx.de/git/ipipe-2.6 > Steve > > > Philippe Gerum wrote: >> Philippe Gerum wrote: >> >>> Steven A. Falco wrote: >>> I needed the following patch to fix a forward reference (caught by gcc 4.1.1). I posted this as part of an earlier discussion, but I then realized that it might be overlooked, so I'm reposting it as a new thread: >>> Thanks. This one was caught a few days back and only recently merged. I >>> guess >>> it's time to roll out a new 2.6.23/powerpc I-pipe patch. >>> >>> >> >> http://download.gna.org/adeos/patches/v2.6/powerpc/adeos-ipipe-2.6.23-powerpc-DENX-2.0-03.patch >> >> -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
