[Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Hi, I've downloaded latest Adeos/Ipipe patch for PPC and unfortunately this latest doesn't (yet) support the ARCH=powerpc architecture from kernel but only the PPC one. I've tried porting the changes to support the PPC_MERGE and be able to still use Xenomai on 2.6.18 with ARCH=powerpc. Attached is a patch that has to be applied after regular adeos-2.6.18-ppc patch to extends supports for PowerPC. Please consider it for review only right now as it might not yet compiles to the end (i'm facing problems with includes inter-race which required me to change the radix-tree.h header file which is something i don't want to). I also have problems booting my latest kernel with this patch on (but booting regular 2.6.18 in merged PowerPC architecture already is a hassle atm) and I'd like you to help me know whether it cames from my patch's content or not. FYI, I've tried to port all Adeos architecture dependant parts but i only focused on PPC32 (PPC64 support might be in but i won't test on it). I'm also trying to boot an MPC8349 chip but i don't think I'll have to address anything with it as it used to work with Xenomai on 2.6.14. Thanks for the review, Ben diff -NEwabur -x '*~' -x linux.orig -x '*.rej' linux.orig/arch/powerpc/Kconfig linux.edit/arch/powerpc/Kconfig --- linux.orig/arch/powerpc/Kconfig 2006-09-20 05:42:06.0 +0200 +++ linux.edit/arch/powerpc/Kconfig 2006-11-23 13:31:29.0 +0100 @@ -590,6 +590,8 @@ menu Kernel options +source kernel/ipipe/Kconfig + config HIGHMEM bool High memory support depends on PPC32 diff -NEwabur -x '*~' -x linux.orig -x '*.rej' linux.orig/arch/powerpc/kernel/entry_32.S linux.edit/arch/powerpc/kernel/entry_32.S --- linux.orig/arch/powerpc/kernel/entry_32.S 2006-09-20 05:42:06.0 +0200 +++ linux.edit/arch/powerpc/kernel/entry_32.S 2006-11-23 13:39:27.0 +0100 @@ -132,8 +132,23 @@ * check for stack overflow */ lwz r9,THREAD_INFO-THREAD(r12) +#ifdef CONFIG_IPIPE + /* Allow for private kernel-based stacks: those must not cause + the stack overflow detection to trigger when some activity has + been preempted over them. We just check if the kernel stack is + not treading on the memory area ranging from + current-thread_info to current-thread, which is coarser + than the vanilla implementation, but likely sensitive enough + to catch overflows soon enough though.*/ + addir12,r9,THREAD + cmplw 0,r1,r9 + cmplw 1,r1,r12 + crand 1,1,4 + bgt-stack_ovf /* if r9 r1 r9+THREAD */ +#else /* CONFIG_IPIPE */ cmplw r1,r9 /* if r1 = current-thread_info */ ble-stack_ovf /* then the kernel stack overflowed */ +#endif /* CONFIG_IPIPE */ 5: #ifdef CONFIG_6xx tophys(r9,r9) /* check local flags */ @@ -198,6 +213,21 @@ lwz r11,_CCR(r1)/* Clear SO bit in CR */ rlwinm r11,r11,0,4,2 stw r11,_CCR(r1) +#ifdef CONFIG_IPIPE + addir3,r1,GPR0 + bl __ipipe_syscall_root + cmpwi r3,0 + lwz r3,GPR3(r1) + lwz r0,GPR0(r1) + lwz r4,GPR4(r1) + lwz r5,GPR5(r1) + lwz r6,GPR6(r1) + lwz r7,GPR7(r1) + lwz r8,GPR8(r1) + lwz r9,GPR9(r1) + bgt .ipipe_end_syscall + blt ret_from_syscall +#endif /* CONFIG_IPIPE */ #ifdef SHOW_SYSCALLS bl do_show_syscall #endif /* SHOW_SYSCALLS */ @@ -260,11 +290,34 @@ SYNC RFI +#ifdef CONFIG_IPIPE +.ipipe_end_syscall: + LOAD_MSR_KERNEL(r10,MSR_KERNEL) /* doesn't include MSR_EE */ + SYNC + MTMSRD(r10) + b syscall_exit_cont +#endif /* CONFIG_IPIPE */ + 66:li r3,-ENOSYS b ret_from_syscall .globl ret_from_fork ret_from_fork: +#ifdef CONFIG_IPIPE +#ifdef CONFIG_IPIPE_TRACE_IRQSOFF + stwur1,-4(r1) + stw r3,0(r1) + lis r3,(0x8000)@h + ori r3,r3,(0x8000)@l + bl ipipe_trace_end + lwz r3,0(r1) + addir1,r1,4 +#endif /* CONFIG_IPIPE_TRACE_IRQSOFF */ + LOAD_MSR_KERNEL(r10,MSR_KERNEL) + ori r10,r10,MSR_EE + SYNC + MTMSRD(r10) +#endif /* CONFIG_IPIPE */ REST_NVGPRS(r1) bl schedule_tail li r3,0 @@ -630,6 +683,12 @@ SYNC/* Some chip revs have problems here... */ MTMSRD(r10) /* disable interrupts */ +#ifdef CONFIG_IPIPE +bl __ipipe_check_root +cmpwi r3, 0 +beq- restore +#endif /* CONFIG_IPIPE */ + lwz r3,_MSR(r1) /* Returning to user mode? */ andi. r0,r3,MSR_PR beq resume_kernel @@ -665,11 +724,37 @@ beq+restore andi. r0,r3,MSR_EE/* interrupts off? */ beq restore /*
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Sun, 26 Nov 2006 20:10:17 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: - NR_IRQS is not defined. This is a problem with the include weirdness due to radix-tree.h, IIRC. It is set to 512 for all PowerPC archs, puh, that's overkill (but not our problem for the time being). Indeed it seemed so. On my private tree, i've fixed/redefined it to 512 to have it compile (ugly hack though). _ipipe_grab_irq(): special IRQ numbers have changed. Check for NO_IRQ_IGNORE in the attached patch. Also the new IRQ handling needs a more detailed review (check irq.c in the powerpc tree). - disarm_decr[] has disappeared. It was used to disable the programming of the decrementer in arch/ppc/kernel/time.c:timer_interrupt(). It needs an appropriate replacement in the powerpc tree. A quick, untested hack is in the attached patch. I'll try to check on that. Hope this helps you to get a bit further (kernel booted). Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Mon, 27 Nov 2006 13:11:23 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Benjamin Zores wrote: On Mon, 27 Nov 2006 12:21:25 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Well, I hack a bit my patch to make it compile and the kernel already booted. Though it hangs when loading the SATA driver. I have no idea why atm. Problems with IRQs? Probably, as when unplugging the SATA drive, the boot goes further but then hang at USB detection (both are handlign IRQs a lot i guess). Would be interesting if someone could test on other board than just mine. As I pointed out in my previous mail, the IRQ handling is not yet correct for powerpc. Try to correct his first. The 2.6.19 having been released out, and working much better on my card than the vanilla 2.6.18 used to be, I'm now more kind to adapt my patch to this latest kernel. However the IRQ handling API seem to have changed a lot and i was wondering if some work on porting Adeos (x86/ppc, not yet powerpc of course) patches already have been started by someone here ? (i.e. something i can work from to adapt my new patch) Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Tue, 05 Dec 2006 11:17:07 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: I have now a preliminary patch for adeos-ipipe-2.6.19-ppc-1.5-00. The porting was rather straight-forward, as the ppc tree does not use the new genirq interface, in contrast to the powerpc tree (that's what you have realized as well). Well, i guess the old ppc arch is bound to die sooner or later. New developments should always be done against powerpc arch imho. Therefore the port of the powerpc tree should be based on Philippe's new adeos-ipipe-2.6.19-i386-1.6-00. Unfortunately, I still do not have a board by hand supported by the powerpc tree. I haven't had much much time investigating the problem till now. But from what i've seen from Philippe's splitted patches, many of them that were supposed to be generic (i.e. don't have i386 in their name) still have references to x86 changes. Is it a normal behavior ? (about dev board, no one's developing on lite5200 or sth like that ?) Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Tue, 05 Dec 2006 14:09:38 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Unfortunately, generic applies only to the Linux part. I realized, that the new IPIPE support for the genirqs requires even more arch-specific modifications than the old interface :-( on PowerPC. That's pretty bad news :-( Have you ever worked with that board under 2.6? It is not even well supported by the old ppc tree and you need patches, which are available somewhere but still require extra tweaking. I have such a board on my table and if I'm lucky, I will get U-Boot with OF support up and booting Linux PowerPC 2.6.19 ... but I need plenty of luck. Nope, but i've seen recent commits for better support on kernel git for upcoming 2.6.20. Btw, Freescale have GIT trees for UBoot with support for many of their CPUs (and support for OF as well). See http://opensource.freescale.com/ Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] ADEOS IPIPE PPC patches upgrade
On Mon, 18 Dec 2006 13:12:54 +0100 Wolfgang Grandegger [EMAIL PROTECTED] wrote: Hallo, attached is patch for Xenomai upgrading the ADEOS IPIPE patches for the PPC tree. Here is the ChangeLog entry: 2006-12-18 Wolfgang Grandegger [EMAIL PROTECTED] * ksrc/arch/powerpc/patches: Upgrade to 2.6.14-ppc-1.5-02, 2.6.18-ppc-1.5-01 and 2.6.19-ppc-1.5-01. These patches fix the problems with PIC for Galileo's GT64260 reported by Antonio Barbalace and add support for 2.6.19. Hi, Got the same for 2.6.19 on powerpc arch ? Or should I try to port it as I did for 2.6.18 ? Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Adeos PowerPC port over 2.6.21
Philippe Gerum wrote: Benjamin, On Tue, 2007-08-07 at 14:03 +0200, Benjamin ZORES wrote: Benjamin ZORES wrote: Benjamin ZORES wrote: Hi, I've seen that Adeos has been officially ported to PowerPC architecture. Please find an update of the adeos-ipipe-2.6.20-powerpc-1.6-02 to Linux 2.6.21 (.5) kernel, in case somebody's interested in it. Sorry for the delay in replying, I was caught on the dark 64bit side of the powerpc world. I won't do this again, I mean, delaying, not 64bit fiddling. Ok, maybe I'll do, but I will apologize again. Merged in both branches. Thanks a lot, Hi, It's definitely not a problem. I work in OSS too so I know what delaying answers on ML means ;-) I'm just glad it has been commited. Thx ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Adeos PowerPC patch differences
Philippe Gerum wrote: Yes. I have tested 2.6.22-DENX over two Freescale boards, namely mpc52xx and mpc8548, using this very same setup. Btw, you will need to pick 2.0-01 which landed today in the repo, since I fixed a couple of issues (one being serious) there. Thanks for the info about 2.0 issue. And is the DENX patch specific to DENX tree or can it be applied/used from vanilla kernel tree ? It should apply to the vanilla tree without too much fuss, but the reference tree for the I-pipe/powerpc work is the DENX one, AFAIC. FYI, Adeos 2.0 / Xenomai 2.4 works fine on my PowerPC boards too. BTW, 2.6.23-rc5 patch does not apply as it on -rc7 and -rc8 (for ppc64 part at least). Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Adeos PowerPC patch differences
Wolfgang Grandegger wrote: Benjamin ZORES wrote: Philippe Gerum wrote: Yes. I have tested 2.6.22-DENX over two Freescale boards, namely mpc52xx and mpc8548, using this very same setup. Btw, you will need to pick 2.0-01 which landed today in the repo, since I fixed a couple of issues (one being serious) there. Thanks for the info about 2.0 issue. And is the DENX patch specific to DENX tree or can it be applied/used from vanilla kernel tree ? It should apply to the vanilla tree without too much fuss, but the reference tree for the I-pipe/powerpc work is the DENX one, AFAIC. FYI, Adeos 2.0 / Xenomai 2.4 works fine on my PowerPC boards too. BTW, 2.6.23-rc5 patch does not apply as it on -rc7 and -rc8 (for ppc64 part at least). Because head_4xx.S has been renamed to head_40x.S in arch/powerpc/kernel recently :-(. Wolfgang. No, it was due to changes in code in time.c and process.c iirc. Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Adeos PowerPC patch differences
Wolfgang Grandegger wrote: Benjamin ZORES wrote: Wolfgang Grandegger wrote: Benjamin ZORES wrote: Philippe Gerum wrote: Yes. I have tested 2.6.22-DENX over two Freescale boards, namely mpc52xx and mpc8548, using this very same setup. Btw, you will need to pick 2.0-01 which landed today in the repo, since I fixed a couple of issues (one being serious) there. Thanks for the info about 2.0 issue. And is the DENX patch specific to DENX tree or can it be applied/used from vanilla kernel tree ? It should apply to the vanilla tree without too much fuss, but the reference tree for the I-pipe/powerpc work is the DENX one, AFAIC. FYI, Adeos 2.0 / Xenomai 2.4 works fine on my PowerPC boards too. BTW, 2.6.23-rc5 patch does not apply as it on -rc7 and -rc8 (for ppc64 part at least). Because head_4xx.S has been renamed to head_40x.S in arch/powerpc/kernel recently :-(. Wolfgang. No, it was due to changes in code in time.c and process.c iirc. I applied adeos-ipipe-2.6.23-rc5-powerpc-DENX-2.0-01.patch to the 2.6.23-rc7 version of linux-2.6-denx. Seems you are using the official kernel linux-2.6 tree. Absolutely. Sorry for not having stated this before. Anyhow, it's easy to fix. Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RTAI Skin FIFO handler running as non-RT task
Hi, I've been playing with the RTAI skin as I wanted a FIFO implementation close to the one that used to exist in RTLinux. I've setup an input handler to the FIFO, and this handler is trying to acquire some Xenomai RT mutex that was previously (successfully) created by an RT task. Acquisition of the handler always fails with -EPERM. So I've checked the handler status through rtdm_in_rt_context () function and it seems that the handler is always called from a non-RT context, which obviously seems to be the reason of the permission denied result. Is there a reason for the handler not being RT ? Or any way to make it RT ? Also, I'm using Xenomai native skin everywhere in my application, except from FIFO handling which requires me to use RTAI skin for this input handler. Native skin (through pipes) do not seem to provide capabilities to set an handler. Is there a good reason for that ? And is there another way to simulate such a handler than creating a dedicated task that would be wakeup each time something is written to the FIFO ? Thanks for any help on this, Regards, Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Timing Issues on x86_32 SMP
Gilles Chanteperdrix a écrit : On Tue, May 6, 2008 at 10:11 AM, Benjamin ZORES [EMAIL PROTECTED] wrote: Why not x86_64 ? Cause I don't need 64 bits. Have you run the latency test to know if you have no hardware issue ? Do you have a quick way to start this test ? Regards, Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PowerPC] Registers Corruption at Context Switch
Hi, I'm facing a problem with the PowerPC version of Xenomai/Adeos that I have difficulties to identify the exact source. I'm running a Xenomai RT kernel thread that use to crash sometimes due to potential register corruption. Problem occurs after a context switch and, in some cases, if the task gets interrupted and reschedule, its registers values are not the same as they used to be before context switch. The code is a bit complex and so, makes use of register that is generally rarely used (GPR r26 to be accurate). Driver is compiled with -02 and compiling with -O0 (so disabling optimizations and so, not using r26) works fine but is not what I'm looking for. Can someone tell me where exactly in Adeos/Xenomai is context switching actually performed and where are the registers save/restore functions ? I've seen there is specific code for FPU registers handling but can't find the equivalent for GPR. FYI, I'm running on PowerPC 603e core with Linux 2.6.23, Adeos 2.0-09 (latest) and Xenomai 2.3.4 (latest). I've seen there are adeos updates (but for updated kernels) but is there some ChangeLog of Adeos changes ? Maybe this is a known bug that has been fixed in updated Adeos release ? Thx to anyone who can help me on this, Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PowerPC] Registers Corruption at Context Switch
Philippe Gerum a écrit : FYI, I'm running on PowerPC 603e core with Linux 2.6.23, Adeos 2.0-09 (latest) and Xenomai 2.3.4 (latest). read Xenomai 2.4.4 here, of course ... See arch/powerpc/switch_32.S, rthal_switch_threads(), for the part that does the actual stack switching. Note that this code is obfuscated by the fact that we have to handle so-called hybrid switching, between Xenomai kernel threads (which do not rely on a task_struct), and Linux tasks (Xenomai userland, Linux kthreads, or regular userland Linux). Fortunately, what is saved on the stack in any case is easy to find out. Ok, I've dig a bit more at sources and found out something strange. In xenomai arch/powerpc/xenomai/switch_32.S in rthal_thread_switch() we have: #ifdef CONFIG_SMP sync #endif /* CONFIG_SMP */ lwzr1,KSP(r4)/* Load new stack pointer */ mrr3,r2 lwzr0,PGDIR(r4) cmpwi r0, 0 beq-same_current tophys(r0,r4) CLR_TOP32(r0) mtsprSPRN_SPRG3,r0/* Update current THREAD phys addr */ addir2,r4,-THREAD/* Update current */ same_current: ** While, in arch/powerpc/kernel/entry_32.S in _switch() we have: ** #ifdef CONFIG_SMP /* We need a sync somewhere here to make sure that if the * previous task gets rescheduled on another CPU, it sees all * stores it has performed on this one. */ sync #endif /* CONFIG_SMP */ tophys(r0,r4) CLR_TOP32(r0) mtsprSPRN_SPRG3,r0/* Update current THREAD phys addr */ lwzr1,KSP(r4)/* Load new stack pointer */ /* save the old current 'last' for return value */ mrr3,r2 addir2,r4,-THREAD/* Update current */ As we can see, the code differs from kernel, as tophys(r0,r4) CLR_TOP32(r0) mtsprSPRN_SPRG3,r0/* Update current THREAD phys addr */ is done _before_ loading new stack pointer in kernel and _after_ doing so in xenomai. Is there a good reason for that or is this unintended ?? Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PowerPC] Registers Corruption at Context Switch
Philippe Gerum a écrit : See arch/powerpc/switch_32.S, rthal_switch_threads(), for the part that does the actual stack switching. Note that this code is obfuscated by the fact that we have to handle so-called hybrid switching, between Xenomai kernel threads (which do not rely on a task_struct), and Linux tasks (Xenomai userland, Linux kthreads, or regular userland Linux). Fortunately, what is saved on the stack in any case is easy to find out. Thx for the info. Can you tell me why GPR registers would be saved there and FPU ones in another function ? Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Error propagating ISR to Linux domain
Hi,
I've encountered a little problem when trying to propagate an ISR from
Xenomai to Linux context.
To sum up clearly, I'm writing an RT kernel module that drives a PCI card.
I've registered a nucleus ISR handler on the IRQ attributed to this card.
On some systems, this IRQ is dedicated to this PCI card only.
Though, on others, it is shared with other peripherals.
Hence, I need to forward/propagate this IRQ to Linux domain for other
drivers to handle it
when the IRQ has not been initiated by my PCI card.
My RT ISR code looks like the following:
int my_isr_handler (xnintr_t *irq)
{
... /* handling */
return XN_ISR_HANDLED | XN_ISR_PROPAGATE;
}
While this code works perfectly when the IRQ number is really shared
among peripherals,
when I use it on system where this IRQ is dedicated to RT only (i.e. not
used by Linux),
then, the IRQ is never acknowledged.
In other words, I see a bug when returning XN_ISR_PROPAGATE on a system
where
no Linux driver has registered a handler for this IRQ.
Is this something known and is there some workaround (I'm using 2.6.23 +
lastest Adeos + Xenomai 2.4.4 on x86_32) ???
A quick and dirty workaround is to create a dummy Linux IRQ handler
(doing so acknowledge my propagated IRQ) but:
- if it returns IRQ_NONE, then Linux discard the IRQ line after having
missed 10 of them (on system where the IRQ is dedicated)
- if it returns IRQ_HANDLED, then I have no guarantee that this dumym
handler won't get called before the legacy drivers that need it.
Or maybe there is a way in Xenomai to know that any subdomain (like
Linux) has registered a handler for this given IRQ ??
Any help would be appreciated,
Ben
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
