Re: [Xenomai-core] MPC8641D and CONFIG_PPC_MERGE
Jeff Koftinoff kirjoitti: Thank you for your responses, Wolfgang. I still have some confusion; I was able to build and run a xenomai 2.2.0 patched linux 2.6.14 kernel on a Apple EMac, which has a 7447A processor in it - with no changes, and was able to get good latency results in my tests. I think the older kernels still supported Apple hardware under the ppc arch, but in the more recent kernels it's moved to the powerpc arch. I am currently playing with a 8641D dual core power pc, it is basically two 7448 processors in one package which is almost identical to the 7447A, along with peripherals (ethernet/serial/pcie). Yet I can't seem to get xenomai compiled for it, even in non-smp mode. The 8641D needs a newer kernel than 2.6.14 ( 2.6.19 is okay ). What should I do? If you have followed Linux kernel development and understand the new genirq stuff (and eventually irq threads), or are willing to dig into it, then why not start a brave porting effort and try to, for example, first make your eMac work on newer kernels with adeos/xenomai stuff applied. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] MPC8641D and CONFIG_PPC_MERGE
Jeff Koftinoff kirjoitti: Hi Everyone. I would really like to get Xenomai working on the new Freescale 8641D dual core G4. I see that for linux 2.6.19, Xenomai does not support CONFIG_PPC_MERGE or architectures=powerpc instead of 'ppc'. Weren't there some experimental powerpc ports already posted some time ago (by Wolfgang, I think)? See the list archive. Please forgive my ignorance; What exactly is the difference between arch=ppc and arch=powerpc? What is involved in changing adeos to work under arch=powerpc on the 8641D in single core mode? How much more work is involved in changing adeos to support SMP on powerpc? The 64-bit powerpc target is under powerpc and supports SMP. The work required somewhat depends on the specific architecture implementation of SMP, but shouldn't be too difficult. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Add fptest for powerpc
This adds powerpc version of fptest.h. It just stores and loads the raw
integer into/from FPU registers without converting to proper IEEE form.
Converting would have added unneccessary complexity. As a side note, the
ppc barfs on the test with 1000 != 10. :I
-- hl
diff -Nru xenomai.orig/include/asm-powerpc/fptest.h
xenomai/include/asm-powerpc/fptest.h
--- xenomai.orig/include/asm-powerpc/fptest.h 2006-06-10 10:29:29.335736000
+
+++ xenomai/include/asm-powerpc/fptest.h2006-06-10 16:12:09.395132000
+
@@ -10,11 +10,94 @@
static inline void fp_regs_set(unsigned val)
{
+ uint64_t fpval = val;
+ __asm__ __volatile__(lfd 0, %0\n
+ fmr 1, 0\n
+ fmr 2, 0\n
+ fmr 3, 0\n
+ fmr 4, 0\n
+ fmr 5, 0\n
+ fmr 6, 0\n
+ fmr 7, 0\n
+ fmr 8, 0\n
+ fmr 9, 0\n
+ fmr 10, 0\n
+ fmr 11, 0\n
+ fmr 12, 0\n
+ fmr 13, 0\n
+ fmr 14, 0\n
+ fmr 15, 0\n
+ fmr 16, 0\n
+ fmr 17, 0\n
+ fmr 18, 0\n
+ fmr 19, 0\n
+ fmr 20, 0\n
+ fmr 21, 0\n
+ fmr 22, 0\n
+ fmr 23, 0\n
+ fmr 24, 0\n
+ fmr 25, 0\n
+ fmr 26, 0\n
+ fmr 27, 0\n
+ fmr 28, 0\n
+ fmr 29, 0\n
+ fmr 30, 0\n
+ fmr 31, 0\n
+ :
+ : m (fpval));
}
+#define FPTEST_REGVAL(n) { \
+ uint64_t t; \
+ __asm__ __volatile__( stfd #n , %0 : =m (t));\
+ e[n] = (unsigned)t; \
+ }
+
static inline int fp_regs_check(unsigned val)
{
-return 0;
+ unsigned i, failed = 0;
+ uint32_t e[32];
+
+ FPTEST_REGVAL(0);
+ FPTEST_REGVAL(1);
+ FPTEST_REGVAL(2);
+ FPTEST_REGVAL(3);
+ FPTEST_REGVAL(4);
+ FPTEST_REGVAL(5);
+ FPTEST_REGVAL(6);
+ FPTEST_REGVAL(7);
+ FPTEST_REGVAL(8);
+ FPTEST_REGVAL(9);
+ FPTEST_REGVAL(10);
+ FPTEST_REGVAL(11);
+ FPTEST_REGVAL(12);
+ FPTEST_REGVAL(13);
+ FPTEST_REGVAL(14);
+ FPTEST_REGVAL(15);
+ FPTEST_REGVAL(16);
+ FPTEST_REGVAL(17);
+ FPTEST_REGVAL(18);
+ FPTEST_REGVAL(19);
+ FPTEST_REGVAL(20);
+ FPTEST_REGVAL(21);
+ FPTEST_REGVAL(22);
+ FPTEST_REGVAL(23);
+ FPTEST_REGVAL(24);
+ FPTEST_REGVAL(25);
+ FPTEST_REGVAL(26);
+ FPTEST_REGVAL(27);
+ FPTEST_REGVAL(28);
+ FPTEST_REGVAL(29);
+ FPTEST_REGVAL(30);
+ FPTEST_REGVAL(31);
+
+ for (i = 0; i 32; i++)
+ if (e[i] != val) {
+ printk(r%d: %u != %u\n, i, e[i], val);
+ failed = 1;
+ }
+
+ return failed;
}
#endif /* FPTEST_H */
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add fptest for powerpc
Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: This adds powerpc version of fptest.h. It just stores and loads the raw integer into/from FPU registers without converting to proper IEEE form. Converting would have added unneccessary complexity. As a side note, the ppc barfs on the test with 1000 != 10. :I Ok, this test tool is far from being user-friendly :-) Just to be sure, I have tested the latest revision on x86 and it still runs fine, so I guess there really is a bug in power pc fpu switching code. Now, if we decode a bit, the integer passed to fp_regs_set and fp_regs_check are 1000 * iterations + task_index, so 1000 is task 0, iteration 1 10 is task 10, iteration 0. It means that task 10 after returning from its first context switch, is getting the context of task 0 before its second context switch. Now the thing to try is to reduce the number of threads involved, since by default there are 23 threads, so you should add a printk for each context switch in the kernel driver (and now that I think about it this printk should be activable with an ioctl), and try and reduce the list of threads by removing threads which do not appear between the serie of switches from task 0 to task 10. The correspondance between the task numbers and their type is not easy, but /proc/xenomai/sched and switch --help should help... Task 0 is the idle taks, an ordinary Linux task Task 10 is of type rtup_ufpp here, which means that it is a real-time task in primary mode using the FPU in primary mode. I probably don't have time for debugging for some days now, but if any of the code goes through sigreturn path, it might be a kernel bug that's fixed in 2.6.16. -- hl ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] unit testing context switches.
Gilles Chanteperdrix kirjoitti:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
--- /dev/null2006-05-03 22:25:59.0 +0200
+++ include/rtdm/rttesting.h 2006-06-07 18:50:14.0 +0200
@@ -0,0 +1,188 @@
...
+ *
+ * @{
+ */
+
+#ifndef _RTBENCHMARK_H
+#define _RTBENCHMARK_H
Hmm, there might be further renamings required. Could you double-check
(e.g. grep -ri benchmark)?
This particular define should be fixed in the version that I commited.
I also put dummy asm/fptest.h for all other architectures than x86, I
would now need volunteers with other hardware than x86 to implement
asm/fptest.h for their platform and run the test.
A little explanation of what work should be done: two functions
fp_regs_set and fp_regs_check should be implemented. fp_regs_set should
set all fp registers to the integer value passed as
argument. fp_regs_check should check that all fp registers are set to
the integer value passed as argument, print the incorrect registers if
any and return 1 if some register value is incorrect.
IMO setting every reg to a different value would be better, or like I
did, calculate some value using every reg and only check the final
result. That would also make pointer (to the fpu save area)
corruptions/miscalculations and interruptions to the fpu save/restore
routines better visible.
-- hl
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] unit testing context switches.
Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: Yes, Altivec is separate from the FPU. Hopefully nobody uses FPU in the kernel - AFAIK currently not, but you never know about closed-source drivers and such. Whereas, Altivec, I think, is something that should, eventually, be supported by the real-time domain, too. Adding Altivec support is very similar to the existing fpu support, and being that it has to tackle the kernel-using-altivec issue anyway, it's probably nicer to add fpu kernel support as well. Only problem is that it will increase the context switch time. Maybe we could add an XNSIMD flag for Altivec and SSE, distinct from XNFPU, so that only the task that really use SIMD instructions would pay the price of the switch ? Sounds like a plan to me. Actually that is a bad idea on x86, because the fxsave instruction that saves the whole FP context, including SSE registers, is faster than the fsave instruction that only save the regular FP registers. We are discussing about operations that take around 500 ns on a 1GHz PIII with cold cache. If the SSE saving instruction is faster and the hit basically goes to the rt-app that uses SSE, why is it a bad idea (other than being slow)? Who cares if there's an extraneous FPU save? I would be curious to know how many cycles the FP and altivec registers save take on power pc. Well, FPU is 32 64-bit registers and AltiVec is 32 128-bit registers. Each load/store needs a separate instruction, which is usually just one cycle, but compared to normal context switch, FPU is about 2x and AltiVec about 4x. So, with both enabled, context switch would total around 7 times the normal time. Some savings might be possible by enforcing usage of VRSAVE register (tells which regs are actually used), but Linux doesn't use that and I'm not sure if gcc supports that either. -- hl ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] unit testing context switches.
Gilles Chanteperdrix kirjoitti: Gilles Chanteperdrix wrote: Heikki Lindholm wrote: Gilles Chanteperdrix kirjoitti: Now that the big context switches bugs have been solved, here is a patch that adds a unit test for context switches and FPU switches with various type of threads (kernel, user, user in secondary mode, not using FPU, using FPU, etc...). As is the case of the latency test there is a small RTDM driver in kernel-space, put in the benchmark class, even though this test is for unit testing, not for benchmarking. Some months back when I was debugging an FPU bug on the ppc, I made similar test cases. Do you test the Linux side at all (does linux user/kernel task's fpu state get messed)? No, currently the only Linux regular task, the idle task, does not use FPU, but it may be changed easily. Though, I'm not sure if any driver uses FPU in linux kernel, but at least the PPC Altivec unit is used by RAID drivers. Btw. at least back then, Xenomai would have messed FPU state for a linux kernel task. x86 has the same issue: RAID driver use mmx, sse or sse2, and manually disable preemption, clear the ts bit, save the FPU registers contents before using mmx, sse or sse2, and restore the original state when done. If Xenomai ever preempts at that point, and the underlying task has not use its FPU, the contents of the FPU registers will be lost. The only fix I see is to change the FPU switching code to only rely on the state of the FPU hardware FPU bits, and not on the status bits of the interrupted task. Actually, only the mmx code is problematic because mmx registers are aliased to the regular floating point registers. sse and sse2 use distinct registers, so as long as real-time code does not use SSE registers, there is no problem. Altivec seems to be in the same case as SSE, or am I missing something ? Yes, Altivec is separate from the FPU. Hopefully nobody uses FPU in the kernel - AFAIK currently not, but you never know about closed-source drivers and such. Whereas, Altivec, I think, is something that should, eventually, be supported by the real-time domain, too. Adding Altivec support is very similar to the existing fpu support, and being that it has to tackle the kernel-using-altivec issue anyway, it's probably nicer to add fpu kernel support as well. Only problem is that it will increase the context switch time. I'd remember that using the FPU bits (instead of task state) from the processor will pretty much cause saving state on every transition to xeno, because of the kernel's lazy usage model (on UP; SMP will do that anyway). -- hl ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG?] dead code in ipipe_grab_irq
Anders Blomdell kirjoitti:
In the following code (ppc), shouldn't first be either declared static
or deleted? To me it looks like first is always equal to one when the
else clause is evaluated.
You're right. first doesn't need to be there at all, it's probably an
old copy of something in the kernel.
asmlinkage int __ipipe_grab_irq(struct pt_regs *regs)
{
extern int ppc_spurious_interrupts;
ipipe_declare_cpuid;
int irq, first = 1;
if ((irq = ppc_md.get_irq(regs)) = 0) {
__ipipe_handle_irq(irq, regs);
first = 0;
} else if (irq != -2 first)
ppc_spurious_interrupts++;
ipipe_load_cpuid();
return (ipipe_percpu_domain[cpuid] == ipipe_root_domain
!test_bit(IPIPE_STALL_FLAG,
ipipe_root_domain-cpudata[cpuid].status));
}
Regards
Anders Blomdell
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] merge powerpc fpu.S and fpu_64.S
Currently the two powerpc fpu*.S assembly sections are so similar that there's really no need for two of them. Merge them into a common fpu.S. Tested on a G5. -- Heikki Lindholm diff -Nru xenomai/ksrc/arch/powerpc/fpu.S xenomai-devel/ksrc/arch/powerpc/fpu.S --- xenomai/ksrc/arch/powerpc/fpu.S 2005-11-18 20:55:24.0 +0200 +++ xenomai-devel/ksrc/arch/powerpc/fpu.S 2006-01-13 12:35:49.0 +0200 @@ -19,9 +19,24 @@ #include linux/config.h #include asm/processor.h -#include asm/cputable.h #include asm/ppc_asm.h +#ifdef CONFIG_PPC601_SYNC_FIX +#define SYNC \ +BEGIN_FTR_SECTION \ + sync; \ + isync; \ +END_FTR_SECTION_IFSET(CPU_FTR_601) +#else /* !CONFIG_PPC601_SYNC_FIX */ +#defineSYNC +#endif /* CONFIG_PPC601_SYNC_FIX */ + +#if defined(CONFIG_PPC64) || defined(CONFIG_PPC64BRIDGE) +#define MTMSRD(r) .long (0x7c000164 + ((r) 21)) /* mtmsrd */ +#else +#define MTMSRD(r) mtmsr r +#endif /* CONFIG_PPC64 || CONFIG_PPC64BRIDGE */ + #define RTHAL_FPSAVE(n, base) stfd n,8*(n)(base) #define RTHAL_FPSAVE2(n, base) RTHAL_FPSAVE(n, base); RTHAL_FPSAVE(n+1, base) #define RTHAL_FPSAVE4(n, base) RTHAL_FPSAVE2(n, base); RTHAL_FPSAVE2(n+2, base) diff -Nru xenomai/ksrc/arch/powerpc/fpu_64.S xenomai-devel/ksrc/arch/powerpc/fpu_64.S --- xenomai/ksrc/arch/powerpc/fpu_64.S 2005-11-18 20:55:24.0 +0200 +++ xenomai-devel/ksrc/arch/powerpc/fpu_64.S1970-01-01 02:00:00.0 +0200 @@ -1,71 +0,0 @@ -/* - * Copyright (C) 2001,2002,2003,2004 Philippe Gerum. - * - * 64-bit PowerPC adoption - * copyright (C) 2005 Taneli Vähäkangas and Heikki Lindholm - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation, Inc., 675 Mass Ave, Cambridge MA 02139, - * USA; either version 2 of the License, or (at your option) any later - * version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - */ - -#include linux/config.h -#include asm/processor.h -#include asm/ppc_asm.h - -#define RTHAL_FPSAVE(n, base) stfd n,8*(n)(base) -#define RTHAL_FPSAVE2(n, base) RTHAL_FPSAVE(n, base); RTHAL_FPSAVE(n+1, base) -#define RTHAL_FPSAVE4(n, base) RTHAL_FPSAVE2(n, base); RTHAL_FPSAVE2(n+2, base) -#define RTHAL_FPSAVE8(n, base) RTHAL_FPSAVE4(n, base); RTHAL_FPSAVE4(n+4, base) -#define RTHAL_FPSAVE16(n, base)RTHAL_FPSAVE8(n, base); RTHAL_FPSAVE8(n+8, base) -#define RTHAL_FPSAVE32(n, base)RTHAL_FPSAVE16(n, base); RTHAL_FPSAVE16(n+16, base) - -/* r3 = tcb-fpuenv */ -_GLOBAL(rthal_save_fpu) - mfmsr r5 - ori r5,r5,MSR_FP/* Re-enable use of FPU. */ - mtmsrd r5 /* Enable use of fpu. */ - isync - RTHAL_FPSAVE32(0,r3) - mffsfr0 - stfdfr0,8*32(r3) - blr - -#define RTHAL_FPLOAD(n, base) lfd n,8*(n)(base) -#define RTHAL_FPLOAD2(n, base) RTHAL_FPLOAD(n, base); RTHAL_FPLOAD(n+1, base) -#define RTHAL_FPLOAD4(n, base) RTHAL_FPLOAD2(n, base); RTHAL_FPLOAD2(n+2, base) -#define RTHAL_FPLOAD8(n, base) RTHAL_FPLOAD4(n, base); RTHAL_FPLOAD4(n+4, base) -#define RTHAL_FPLOAD16(n, base)RTHAL_FPLOAD8(n, base); RTHAL_FPLOAD8(n+8, base) -#define RTHAL_FPLOAD32(n, base)RTHAL_FPLOAD16(n, base); RTHAL_FPLOAD16(n+16, base) - -/* r3 = tcb-fpuenv */ -_GLOBAL(rthal_init_fpu) - mfmsr r5 - ori r5,r5,MSR_FP|MSR_FE1/* RT kernel threads always operate in */ - li r4,MSR_FE0 /* imprecise non-recoverable exception mode. */ - andcr5,r5,r4 - mtmsrd r5 - - /* Fallback wanted. */ - -/* r3 = tcb-fpuenv */ -_GLOBAL(rthal_restore_fpu) - mfmsr r5 - ori r5,r5,MSR_FP/* Re-enable use of FPU. */ - mtmsrd r5 /* Enable use of fpu. */ - isync - lfd fr0,8*32(r3) - mtfsf 0xff,0 - RTHAL_FPLOAD32(0,r3) - blr diff -Nru xenomai/ksrc/arch/powerpc/Makefile xenomai-devel/ksrc/arch/powerpc/Makefile --- xenomai/ksrc/arch/powerpc/Makefile 2006-01-12 15:25:59.0 +0200 +++ xenomai-devel/ksrc/arch/powerpc/Makefile2006-01-13 12:23:00.0 +0200 @@ -5,13 +5,12 @@ obj-$(CONFIG_XENOMAI) += xeno_hal.o xeno_hal-y := hal.o +xeno_hal-$(CONFIG_XENO_HW_FPU) += fpu.o ifeq ($(CONFIG_PPC64),y) xeno_hal-$(CONFIG_PPC64) += switch_64.o -xeno_hal-$(CONFIG_XENO_HW_FPU) += fpu_64.o else xeno_hal
[Xenomai-core] [PATCH] merge powerpc fpu.S and fpu_64.S
Currently the two powerpc fpu*.S assembly sections are so similar that there's really no need for two of them. Merge them into a common fpu.S. Tested on a G5. -- Heikki Lindholm diff -Nru xenomai/ksrc/arch/powerpc/fpu.S xenomai-devel/ksrc/arch/powerpc/fpu.S --- xenomai/ksrc/arch/powerpc/fpu.S 2005-11-18 20:55:24.0 +0200 +++ xenomai-devel/ksrc/arch/powerpc/fpu.S 2006-01-13 12:35:49.0 +0200 @@ -19,9 +19,24 @@ #include linux/config.h #include asm/processor.h -#include asm/cputable.h #include asm/ppc_asm.h +#ifdef CONFIG_PPC601_SYNC_FIX +#define SYNC \ +BEGIN_FTR_SECTION \ + sync; \ + isync; \ +END_FTR_SECTION_IFSET(CPU_FTR_601) +#else /* !CONFIG_PPC601_SYNC_FIX */ +#defineSYNC +#endif /* CONFIG_PPC601_SYNC_FIX */ + +#if defined(CONFIG_PPC64) || defined(CONFIG_PPC64BRIDGE) +#define MTMSRD(r) .long (0x7c000164 + ((r) 21)) /* mtmsrd */ +#else +#define MTMSRD(r) mtmsr r +#endif /* CONFIG_PPC64 || CONFIG_PPC64BRIDGE */ + #define RTHAL_FPSAVE(n, base) stfd n,8*(n)(base) #define RTHAL_FPSAVE2(n, base) RTHAL_FPSAVE(n, base); RTHAL_FPSAVE(n+1, base) #define RTHAL_FPSAVE4(n, base) RTHAL_FPSAVE2(n, base); RTHAL_FPSAVE2(n+2, base) diff -Nru xenomai/ksrc/arch/powerpc/fpu_64.S xenomai-devel/ksrc/arch/powerpc/fpu_64.S --- xenomai/ksrc/arch/powerpc/fpu_64.S 2005-11-18 20:55:24.0 +0200 +++ xenomai-devel/ksrc/arch/powerpc/fpu_64.S1970-01-01 02:00:00.0 +0200 @@ -1,71 +0,0 @@ -/* - * Copyright (C) 2001,2002,2003,2004 Philippe Gerum. - * - * 64-bit PowerPC adoption - * copyright (C) 2005 Taneli Vähäkangas and Heikki Lindholm - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation, Inc., 675 Mass Ave, Cambridge MA 02139, - * USA; either version 2 of the License, or (at your option) any later - * version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - */ - -#include linux/config.h -#include asm/processor.h -#include asm/ppc_asm.h - -#define RTHAL_FPSAVE(n, base) stfd n,8*(n)(base) -#define RTHAL_FPSAVE2(n, base) RTHAL_FPSAVE(n, base); RTHAL_FPSAVE(n+1, base) -#define RTHAL_FPSAVE4(n, base) RTHAL_FPSAVE2(n, base); RTHAL_FPSAVE2(n+2, base) -#define RTHAL_FPSAVE8(n, base) RTHAL_FPSAVE4(n, base); RTHAL_FPSAVE4(n+4, base) -#define RTHAL_FPSAVE16(n, base)RTHAL_FPSAVE8(n, base); RTHAL_FPSAVE8(n+8, base) -#define RTHAL_FPSAVE32(n, base)RTHAL_FPSAVE16(n, base); RTHAL_FPSAVE16(n+16, base) - -/* r3 = tcb-fpuenv */ -_GLOBAL(rthal_save_fpu) - mfmsr r5 - ori r5,r5,MSR_FP/* Re-enable use of FPU. */ - mtmsrd r5 /* Enable use of fpu. */ - isync - RTHAL_FPSAVE32(0,r3) - mffsfr0 - stfdfr0,8*32(r3) - blr - -#define RTHAL_FPLOAD(n, base) lfd n,8*(n)(base) -#define RTHAL_FPLOAD2(n, base) RTHAL_FPLOAD(n, base); RTHAL_FPLOAD(n+1, base) -#define RTHAL_FPLOAD4(n, base) RTHAL_FPLOAD2(n, base); RTHAL_FPLOAD2(n+2, base) -#define RTHAL_FPLOAD8(n, base) RTHAL_FPLOAD4(n, base); RTHAL_FPLOAD4(n+4, base) -#define RTHAL_FPLOAD16(n, base)RTHAL_FPLOAD8(n, base); RTHAL_FPLOAD8(n+8, base) -#define RTHAL_FPLOAD32(n, base)RTHAL_FPLOAD16(n, base); RTHAL_FPLOAD16(n+16, base) - -/* r3 = tcb-fpuenv */ -_GLOBAL(rthal_init_fpu) - mfmsr r5 - ori r5,r5,MSR_FP|MSR_FE1/* RT kernel threads always operate in */ - li r4,MSR_FE0 /* imprecise non-recoverable exception mode. */ - andcr5,r5,r4 - mtmsrd r5 - - /* Fallback wanted. */ - -/* r3 = tcb-fpuenv */ -_GLOBAL(rthal_restore_fpu) - mfmsr r5 - ori r5,r5,MSR_FP/* Re-enable use of FPU. */ - mtmsrd r5 /* Enable use of fpu. */ - isync - lfd fr0,8*32(r3) - mtfsf 0xff,0 - RTHAL_FPLOAD32(0,r3) - blr diff -Nru xenomai/ksrc/arch/powerpc/Makefile xenomai-devel/ksrc/arch/powerpc/Makefile --- xenomai/ksrc/arch/powerpc/Makefile 2006-01-12 15:25:59.0 +0200 +++ xenomai-devel/ksrc/arch/powerpc/Makefile2006-01-13 12:23:00.0 +0200 @@ -5,13 +5,12 @@ obj-$(CONFIG_XENOMAI) += xeno_hal.o xeno_hal-y := hal.o +xeno_hal-$(CONFIG_XENO_HW_FPU) += fpu.o ifeq ($(CONFIG_PPC64),y) xeno_hal-$(CONFIG_PPC64) += switch_64.o -xeno_hal-$(CONFIG_XENO_HW_FPU) += fpu_64.o else xeno_hal
[Xenomai-core] [PATCH] Fix ppc64 thread switching
Add some polish, eg. make it work, for the recent thread switching
changes for the ppc64.
-- Heikki Lindholm
diff -Nru xenomai/include/asm-powerpc/hal.h
xenomai-devel/include/asm-powerpc/hal.h
--- xenomai/include/asm-powerpc/hal.h 2006-01-11 11:55:17.0 +0200
+++ xenomai-devel/include/asm-powerpc/hal.h 2006-01-12 15:29:03.0
+0200
@@ -165,8 +165,14 @@
#define RTHAL_SWITCH_FRAME_SIZE (STACK_FRAME_OVERHEAD + sizeof(struct
pt_regs))
+#ifdef CONFIG_PPC64
+asmlinkage void rthal_thread_switch(struct thread_struct *prev,
+ struct thread_struct *next,
+ int kernel_thread);
+#else /* !CONFIG_PPC64 */
asmlinkage void rthal_thread_switch(struct thread_struct *prev,
struct thread_struct *next);
+#endif /* CONFIG_PPC64 */
asmlinkage void rthal_thread_trampoline(void);
diff -Nru xenomai/include/asm-powerpc/system.h
xenomai-devel/include/asm-powerpc/system.h
--- xenomai/include/asm-powerpc/system.h2006-01-11 11:55:17.0
+0200
+++ xenomai-devel/include/asm-powerpc/system.h 2006-01-12 15:35:31.0
+0200
@@ -239,8 +239,13 @@
#endif /* CONFIG_PPC64 */
}
+#ifdef CONFIG_PPC64
+rthal_thread_switch(out_tcb-tsp, in_tcb-tsp,
+ in_tcb-user_task == NULL ? 1 : 0);
+#else /* !CONFIG_PPC64 */
rthal_thread_switch(out_tcb-tsp, in_tcb-tsp);
-
+#endif /* CONFIG_PPC64 */
+
barrier();
}
@@ -299,12 +304,23 @@
ksp = (unsigned long *)((unsigned long)tcb-stackbase + tcb-stacksize -
RTHAL_SWITCH_FRAME_SIZE - 32);
childregs = (struct pt_regs *)ksp;
memset(childregs,0,sizeof(*childregs));
-childregs-nip = (unsigned long)rthal_thread_trampoline;
+childregs-nip = ((unsigned long *)rthal_thread_trampoline)[0];
+childregs-gpr[2] = ((unsigned long *)rthal_thread_trampoline)[1];
childregs-gpr[14] = flags ~(MSR_EE | MSR_FP);
childregs-gpr[15] = ((unsigned long *)xnarch_thread_trampoline)[0]; /*
lr = entry addr. */
childregs-gpr[16] = ((unsigned long *)xnarch_thread_trampoline)[1]; /*
r2 = TOC base. */
childregs-gpr[17] = (unsigned long)tcb;
tcb-ts.ksp = (unsigned long)childregs - STACK_FRAME_OVERHEAD;
+if (cpu_has_feature(CPU_FTR_SLB)) { /* from process.c/copy_thread */
+ unsigned long sp_vsid = get_kernel_vsid(tcb-ts.ksp);
+
+ sp_vsid = SLB_VSID_SHIFT;
+ sp_vsid |= SLB_VSID_KERNEL;
+ if (cpu_has_feature(CPU_FTR_16M_PAGE))
+ sp_vsid |= SLB_VSID_L;
+
+ tcb-ts.ksp_vsid = sp_vsid;
+}
#else /* !CONFIG_PPC64 */
ksp = (unsigned long *)((unsigned long)tcb-stackbase + tcb-stacksize -
RTHAL_SWITCH_FRAME_SIZE - 4);
childregs = (struct pt_regs *)ksp;
@@ -415,7 +431,7 @@
tcb-user_task = NULL;
tcb-active_task = NULL;
tcb-tsp = tcb-ts;
-/* Note: .pgdir(ppc32)/.VSID(ppc64) == NULL for a Xenomai kthread. */
+/* Note: .pgdir(ppc32) == NULL for a Xenomai kthread. */
memset(tcb-ts,0,sizeof(tcb-ts));
#ifdef CONFIG_XENO_HW_FPU
tcb-user_fpu_owner = NULL;
diff -Nru xenomai/ksrc/arch/powerpc/switch_64.S
xenomai-devel/ksrc/arch/powerpc/switch_64.S
--- xenomai/ksrc/arch/powerpc/switch_64.S 2006-01-11 11:55:22.0
+0200
+++ xenomai-devel/ksrc/arch/powerpc/switch_64.S 2006-01-12 15:30:18.0
+0200
@@ -33,7 +33,7 @@
#include asm/mmu.h
/*
- * void rthal_thread_switch(struct thread_struct *prev, struct thread_struct
*next)
+ * void rthal_thread_switch(struct thread_struct *prev, struct thread_struct
*next, int kernel_thread)
*/
.align 7
_GLOBAL(rthal_thread_switch)
@@ -68,17 +68,12 @@
ld r8,KSP(r4) /* new stack pointer */
- lwz r0,KSP_VSID(r4)
-cmpwi r0, 0
-bne+ change_current
- mr r1,r8 /* start using new stack pointer */
- b same_current
+ cmpwi cr5,r5,0/* is it a kernel thread */
+bne- cr5,10f /* if so, don't touch 'current' */
-change_current:
-
addir6,r4,-THREAD /* Convert THREAD to 'current' */
std r6,PACACURRENT(r13) /* Set new 'current' */
-
+10:
BEGIN_FTR_SECTION
clrrdi r6,r8,28/* get its ESID */
clrrdi r9,r1,28/* get current sp ESID */
@@ -98,16 +93,16 @@
2:
END_FTR_SECTION_IFSET(CPU_FTR_SLB)
+ bne-cr5,11f /* kernel thread: don't touch 'current' */
clrrdi r7,r8,THREAD_SHIFT /* base of new stack */
/* Note: this uses SWITCH_FRAME_SIZE rather than INT_FRAME_SIZE
because we don't need to leave the 288-byte ABI gap at the
top of the kernel stack. */
addir7,r7,THREAD_SIZE-SWITCH_FRAME_SIZE
-
- mr r1,r8 /* start using new stack pointer */
std r7,PACAKSAVE(r13)
-
-same_current:
+
+11:
+ mr r1,r8 /* start using new
Re: [Xenomai-core] latency kernel part crashes on ppc64
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? To get this clearly: You tested the old klatency(+front-end) on latest xeno and it worked? Or does this parse the old klatency worked over old xeno on PPC64? Comparing the old test with the new framework, the major difference is that the old one only knew a single kernel RT-task. Its front-end was reading from a pipe and was therefore a pure linux program. Now we have two RT-tasks, one is even a shadow, and they use RT-IPC. Not sure if this really means that the bug must be in the benchmark suite... Nope, it should work as it is. But as Stelian also reported problems on his fresh ARM port with the in-kernel test, I cannot exclude that there /might/ be a problem in the benchmark. As I don't have any ppc64 hanging around somewhere, we will have to go through this together. Things I would like to know: Dammit, I hoped you'd whip up a fix just from me noting a problem. Well, all right then, I'll play along...;) o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. o Are there any details / backtraces available with the crash? Becaktrace limits to xnpod_schedule if I remember right. o Does -t2 work? Umm. Probably not. See below. Arrgh, probably - when it's so easy to test... Shoot! The probably operator was incorrect, -t 2 did work. -- hl ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latency kernel part crashes on ppc64
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? Nope, it should work as it is. But as Stelian also reported problems on his fresh ARM port with the in-kernel test, I cannot exclude that there /might/ be a problem in the benchmark. As I don't have any ppc64 hanging around somewhere, we will have to go through this together. Things I would like to know: Dammit, I hoped you'd whip up a fix just from me noting a problem. Well, all right then, I'll play along...;) o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. o Are there any details / backtraces available with the crash? Becaktrace limits to xnpod_schedule if I remember right. o Does -t2 work? Umm. Probably not. See below. o What happens if your disable rtdm_event_pulse(ctx-result_event); in eval_outer_loop (thus no signalling of intermediate results during the test)? Does it still crash, maybe later during cleanup now? Doesn't freeze and can be exited with ctrl-c and even re-run. One odd thing (probably unrelated) is that the first two ioctls get called in what seems like wrong order, eg. START_TMTEST first ends up in tmbench_ioctl_rt and then _nrt and INTERM_RESULT ends up first in _nrt and then _rt. -- Heikki Lindholm
Re: [Xenomai-core] latency kernel part crashes on ppc64
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? To get this clearly: You tested the old klatency(+front-end) on latest xeno and it worked? Or does this parse the old klatency worked over old xeno on PPC64? Comparing the old test with the new framework, the major difference is that the old one only knew a single kernel RT-task. Its front-end was reading from a pipe and was therefore a pure linux program. Now we have two RT-tasks, one is even a shadow, and they use RT-IPC. Not sure if this really means that the bug must be in the benchmark suite... Nope, it should work as it is. But as Stelian also reported problems on his fresh ARM port with the in-kernel test, I cannot exclude that there /might/ be a problem in the benchmark. As I don't have any ppc64 hanging around somewhere, we will have to go through this together. Things I would like to know: Dammit, I hoped you'd whip up a fix just from me noting a problem. Well, all right then, I'll play along...;) o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. o Are there any details / backtraces available with the crash? Becaktrace limits to xnpod_schedule if I remember right. o Does -t2 work? Umm. Probably not. See below. Arrgh, probably - when it's so easy to test... Shoot! The probably operator was incorrect, -t 2 did work. -- hl
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Heikki Lindholm kirjoitti: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. Additionally, there's also a Linux bug, which might cause corruption in 2.6.14 PREEMPT: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9f232a125bf86b0dae09f8ea4a0553535cf6b658 For solid performance that should also be applied on top of the I-pipe patch. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. Just tried. At least svn r380 compiled and worked fine for me. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Philippe Gerum kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. Merged in r383, thanks. On a related note, how do you think patches to Linux kernel that don't fit into I-pipe should be handled? Put into patches directory separately? There are now at least two instances for 2.6.14/ppc: the fpu bug that I already posted on this thread and the ppc64 UP building bug that effectively makes impossible to build I-pipe 2.6.14 for UP on ppc64. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Heikki Lindholm kirjoitti: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. Additionally, there's also a Linux bug, which might cause corruption in 2.6.14 PREEMPT: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9f232a125bf86b0dae09f8ea4a0553535cf6b658 For solid performance that should also be applied on top of the I-pipe patch. -- Heikki Lindholm
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. Just tried. At least svn r380 compiled and worked fine for me. -- Heikki Lindholm
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Philippe Gerum kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee having trouble with X and Xenomai, give this a shot. Merged in r383, thanks. On a related note, how do you think patches to Linux kernel that don't fit into I-pipe should be handled? Put into patches directory separately? There are now at least two instances for 2.6.14/ppc: the fpu bug that I already posted on this thread and the ppc64 UP building bug that effectively makes impossible to build I-pipe 2.6.14 for UP on ppc64. -- Heikki Lindholm
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. I'd say this has been unchanged since the beginning (0.9?). Then, what latency are we talking about? My last modifications went to src/testsuite/latency. Did you mean ksrc/skins/native/demos/latency.c? Sorry, I misinterpreted in a hurry. I was (still) talking about the fpu ;) It might be that the latency test didn't compile, because I didn't even enable the rtdm measuring device in kernel config or something(?). I'll try again. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Fix ppc fpu support
Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but
not yet set last_task_used_math to NULL. As a result the tasks MSR_FP
will get set, although it should be cleared. If the task happens to hit
one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU
state might be saved to the task. The attached patch should fix this. I
couldn't try it on most recent Xenomai trunk, because latency wouldn't
build anymore. However, I see no reason it shouldn't work. All thee
having trouble with X and Xenomai, give this a shot.
-- Heikki Lindholm
diff -Nru xenomai/include/asm-powerpc/system.h
xenomai-devel/include/asm-powerpc/system.h
--- xenomai/include/asm-powerpc/system.h2006-01-06 15:55:19.0
+0200
+++ xenomai-devel/include/asm-powerpc/system.h 2006-01-06 16:44:53.0
+0200
@@ -55,6 +55,7 @@
rthal_fpenv_t fpuenv __attribute__ ((aligned (16)));
rthal_fpenv_t *fpup; /* Pointer to the FPU backup area */
struct task_struct *user_fpu_owner;
+unsigned long user_fpu_owner_prev_msr;
/* Pointer the the FPU owner in userspace:
- NULL for RT K threads,
- last_task_used_math for Linux US threads (only current or NULL when
MP)
@@ -368,7 +369,10 @@
rthal_save_fpu(tcb-fpup);
if(tcb-user_fpu_owner tcb-user_fpu_owner-thread.regs)
+{
+tcb-user_fpu_owner_prev_msr =
tcb-user_fpu_owner-thread.regs-msr;
tcb-user_fpu_owner-thread.regs-msr = ~MSR_FP;
+}
}
#endif /* CONFIG_XENO_HW_FPU */
@@ -383,7 +387,13 @@
{
rthal_restore_fpu(tcb-fpup);
-if(tcb-user_fpu_owner tcb-user_fpu_owner-thread.regs)
+ /* Note: Only enable FP in MSR, if it was enabled when we saved the
+* fpu state. We might have preempted Linux when it had disabled FP
+* for the thread, but not yet set last_task_used_math to NULL
+*/
+if(tcb-user_fpu_owner
+ tcb-user_fpu_owner-thread.regs
+ ((tcb-user_fpu_owner_prev_msr MSR_FP) != 0))
tcb-user_fpu_owner-thread.regs-msr |= MSR_FP;
}
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. I'd say this has been unchanged since the beginning (0.9?). -- hl
Re: [Xenomai-core] [PATCH] Fix ppc fpu support
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set, the wrong FPU state might be saved to the task. The attached patch should fix this. I couldn't try it on most recent Xenomai trunk, because latency wouldn't build anymore. However, I see no reason it shouldn't work. All thee Is it still broken with latest revision 376? Philippe had merged the fix for my mess, and it worked at least for 2.6 on my box again. I'd say this has been unchanged since the beginning (0.9?). Then, what latency are we talking about? My last modifications went to src/testsuite/latency. Did you mean ksrc/skins/native/demos/latency.c? Sorry, I misinterpreted in a hurry. I was (still) talking about the fpu ;) It might be that the latency test didn't compile, because I didn't even enable the rtdm measuring device in kernel config or something(?). I'll try again. -- Heikki Lindholm
[Xenomai-core] [PATCH] Clean-up powerpc SMP timer support
Follow-up for the previously posted powerpc SMP timer support code.
It's better to let each processor set its own disarm_decr. Additionally,
cuts down unused code from UP build. Tested on a G5 SMP UP.
-- Heikki Lindholm
diff -Nru xenomai.orig/ksrc/arch/powerpc/hal.c xenomai/ksrc/arch/powerpc/hal.c
--- xenomai.orig/ksrc/arch/powerpc/hal.c2005-12-07 19:22:11.0
+0200
+++ xenomai/ksrc/arch/powerpc/hal.c 2005-12-09 16:19:11.110664000 +0200
@@ -131,6 +131,7 @@
}
static void rthal_critical_sync(void) {
+#ifdef CONFIG_SMP
rthal_declare_cpuid;
rthal_load_cpuid();
@@ -139,20 +140,24 @@
/* timer_request */
if (rthal_periodic_p[cpuid])
rthal_set_local_cpu_timer();
-
+ else
+ disarm_decr[cpuid] = 1;
break;
case 2:
/* timer_release */
if (rthal_periodic_p[cpuid])
rthal_set_local_cpu_timer();
else
+ disarm_decr[cpuid] = 0;
set_dec(tb_ticks_per_jiffy);
break;
case 3:
/* cancel action */
+ disarm_decr[cpuid] = 0;
break;
}
+#endif /* CONFIG_SMP */
}
static void rthal_smp_relay_tick(unsigned irq, void *cookie)
@@ -183,7 +188,6 @@
else {
/* Oneshot setup. */
for_each_present_cpu(i) {
- disarm_decr[i] = 1;
rthal_periodic_p[i] = 0;
}
#ifdef CONFIG_40x
@@ -191,10 +195,10 @@
#endif /* CONFIG_40x */
rthal_timer_program_shot(tb_ticks_per_jiffy);
}
+ rthal_load_cpuid();
+
if (err)
goto out;
-
- rthal_load_cpuid();
rthal_irq_release(RTHAL_TIMER_IRQ);
if ((err = rthal_irq_request(RTHAL_TIMER_IRQ,
@@ -225,14 +229,14 @@
if (rthal_periodic_p[cpuid])
rthal_set_local_cpu_timer();
+ else
+ disarm_decr[cpuid] = 1;
out:
if (err) {
rthal_sync_op = 3;
__ipipe_decr_ticks = tb_ticks_per_jiffy;
- for_each_present_cpu(i) {
- disarm_decr[i] = 0;
- }
+ disarm_decr[cpuid] = 0;
}
rthal_critical_exit(flags);
@@ -253,10 +257,6 @@
if (rthal_periodic_p[cpuid])
rthal_set_cpu_timers_unsafe(0);
else {
- int i;
- for_each_present_cpu(i) {
- disarm_decr[i] = 0;
- }
#ifdef CONFIG_40x
mtspr(SPRN_TCR,mfspr(SPRN_TCR)|TCR_ARE); /* Auto-reload on. */
mtspr(SPRN_PIT,tb_ticks_per_jiffy);
@@ -273,6 +273,8 @@
if (rthal_periodic_p[cpuid])
rthal_set_local_cpu_timer();
+ else
+ disarm_decr[cpuid] = 0;
rthal_critical_exit(flags);
}
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Clean-up powerpc SMP timer support
Follow-up for the previously posted powerpc SMP timer support code.
It's better to let each processor set its own disarm_decr. Additionally,
cuts down unused code from UP build. Tested on a G5 SMP UP.
-- Heikki Lindholm
diff -Nru xenomai.orig/ksrc/arch/powerpc/hal.c xenomai/ksrc/arch/powerpc/hal.c
--- xenomai.orig/ksrc/arch/powerpc/hal.c2005-12-07 19:22:11.0
+0200
+++ xenomai/ksrc/arch/powerpc/hal.c 2005-12-09 16:19:11.110664000 +0200
@@ -131,6 +131,7 @@
}
static void rthal_critical_sync(void) {
+#ifdef CONFIG_SMP
rthal_declare_cpuid;
rthal_load_cpuid();
@@ -139,20 +140,24 @@
/* timer_request */
if (rthal_periodic_p[cpuid])
rthal_set_local_cpu_timer();
-
+ else
+ disarm_decr[cpuid] = 1;
break;
case 2:
/* timer_release */
if (rthal_periodic_p[cpuid])
rthal_set_local_cpu_timer();
else
+ disarm_decr[cpuid] = 0;
set_dec(tb_ticks_per_jiffy);
break;
case 3:
/* cancel action */
+ disarm_decr[cpuid] = 0;
break;
}
+#endif /* CONFIG_SMP */
}
static void rthal_smp_relay_tick(unsigned irq, void *cookie)
@@ -183,7 +188,6 @@
else {
/* Oneshot setup. */
for_each_present_cpu(i) {
- disarm_decr[i] = 1;
rthal_periodic_p[i] = 0;
}
#ifdef CONFIG_40x
@@ -191,10 +195,10 @@
#endif /* CONFIG_40x */
rthal_timer_program_shot(tb_ticks_per_jiffy);
}
+ rthal_load_cpuid();
+
if (err)
goto out;
-
- rthal_load_cpuid();
rthal_irq_release(RTHAL_TIMER_IRQ);
if ((err = rthal_irq_request(RTHAL_TIMER_IRQ,
@@ -225,14 +229,14 @@
if (rthal_periodic_p[cpuid])
rthal_set_local_cpu_timer();
+ else
+ disarm_decr[cpuid] = 1;
out:
if (err) {
rthal_sync_op = 3;
__ipipe_decr_ticks = tb_ticks_per_jiffy;
- for_each_present_cpu(i) {
- disarm_decr[i] = 0;
- }
+ disarm_decr[cpuid] = 0;
}
rthal_critical_exit(flags);
@@ -253,10 +257,6 @@
if (rthal_periodic_p[cpuid])
rthal_set_cpu_timers_unsafe(0);
else {
- int i;
- for_each_present_cpu(i) {
- disarm_decr[i] = 0;
- }
#ifdef CONFIG_40x
mtspr(SPRN_TCR,mfspr(SPRN_TCR)|TCR_ARE); /* Auto-reload on. */
mtspr(SPRN_PIT,tb_ticks_per_jiffy);
@@ -273,6 +273,8 @@
if (rthal_periodic_p[cpuid])
rthal_set_local_cpu_timer();
+ else
+ disarm_decr[cpuid] = 0;
rthal_critical_exit(flags);
}
[Xenomai-core] [PATCH] Xenomai 2.1: Add SMP timer support for powerpc
Add SMP timer support code for the powerpc arch in Xenomai 2.1. Still a
bit rough, but I'll clean it up as I go. Compiled and tested on G5 UP,
SMP (I-pipe 2.6.14 0.9-02) and G4 UP (I-pipe 2.6.14 1.0-07). Doesn't
seem to break anything. On a G5, SMP seems to bring a 2-3usec latency
penalty.
-- Heikki Lindholm
diff -Nru xenomai/include/asm-powerpc/hal.h
xenomai-devel/include/asm-powerpc/hal.h
--- xenomai/include/asm-powerpc/hal.h 2005-12-04 12:21:36.0 +0200
+++ xenomai-devel/include/asm-powerpc/hal.h 2005-12-06 13:15:35.0
+0200
@@ -138,6 +138,10 @@
#define RTHAL_TIMER_IRQ ADEOS_TIMER_VIRQ
#else /* !CONFIG_ADEOS_CORE */
#define RTHAL_TIMER_IRQ IPIPE_TIMER_VIRQ
+#ifdef CONFIG_SMP
+#define RTHAL_TIMER_IPIIPIPE_SERVICE_IPI3
+#define RTHAL_HOST_TIMER_IPI IPIPE_SERVICE_IPI4
+#endif /* CONFIG_SMP */
#endif /* CONFIG_ADEOS_CORE */
#define rthal_irq_descp(irq) (irq_desc[(irq)])
@@ -204,7 +208,7 @@
#ifdef CONFIG_40x
mtspr(SPRN_PIT,delay);
#else /* !CONFIG_40x */
-set_dec(delay);
+set_dec((int)delay); /* decrementer is only 32-bits */
#endif /* CONFIG_40x */
}
diff -Nru xenomai/include/asm-powerpc/system.h
xenomai-devel/include/asm-powerpc/system.h
--- xenomai/include/asm-powerpc/system.h2005-12-04 12:21:36.0
+0200
+++ xenomai-devel/include/asm-powerpc/system.h 2005-12-06 13:18:11.0
+0200
@@ -581,12 +581,11 @@
}
static inline int xnarch_send_timer_ipi (xnarch_cpumask_t mask)
-
{
#ifdef CONFIG_SMP
-return -1; /* FIXME */
+ return rthal_send_ipi(RTHAL_TIMER_IPI, mask);
#else /* ! CONFIG_SMP */
-return 0;
+ return 0;
#endif /* CONFIG_SMP */
}
@@ -595,9 +594,12 @@
#ifdef XENO_INTR_MODULE
static inline void xnarch_relay_tick (void)
-
{
-rthal_irq_host_pend(RTHAL_TIMER_IRQ);
+#ifdef CONFIG_SMP
+ rthal_send_ipi(RTHAL_HOST_TIMER_IPI, cpu_online_map);
+#else /* !CONFIG_SMP */
+ rthal_irq_host_pend(RTHAL_TIMER_IRQ);
+#endif /* CONFIG_SMP */
}
static inline void xnarch_announce_tick(void)
diff -Nru xenomai/ksrc/arch/powerpc/hal.c xenomai-devel/ksrc/arch/powerpc/hal.c
--- xenomai/ksrc/arch/powerpc/hal.c 2005-12-04 12:21:43.0 +0200
+++ xenomai-devel/ksrc/arch/powerpc/hal.c 2005-12-06 13:33:54.0
+0200
@@ -31,6 +31,8 @@
*
[EMAIL PROTECTED]/
+#undef DEBUG
+
#include linux/version.h
#include linux/slab.h
#include linux/errno.h
@@ -51,6 +53,12 @@
#endif /* CONFIG_PROC_FS */
#include stdarg.h
+#ifdef DEBUG
+#define DBG(fmt...) udbg_printf(fmt)
+#else
+#define DBG(fmt...)
+#endif
+
static struct {
unsigned long flags;
@@ -58,69 +66,215 @@
} rthal_linux_irq[IPIPE_NR_XIRQS];
-static int rthal_periodic_p;
+static int rthal_periodic_p[RTHAL_NR_CPUS];
-int rthal_timer_request (void (*handler)(void),
-unsigned long nstick)
+/* the following two functions are very much alike to the I-pipe tune_timer
+ * implementation, but tuned for crtitical_enter/exit usage
+ *
+ * rthal_set_local_timer might come useful with processor hotplug events
+ */
+static void rthal_set_local_cpu_timer(void)
{
-unsigned long flags;
-int err;
+ long ticks;
+ rthal_declare_cpuid;
-flags = rthal_critical_enter(NULL);
+ rthal_load_cpuid();
-if (nstick 0)
- {
- /* Periodic setup --
- Use the built-in Adeos service directly. */
- err = rthal_set_timer(nstick);
- rthal_periodic_p = 1;
- }
-else
- {
- /* Oneshot setup. */
- disarm_decr[rthal_processor_id()] = 1;
- rthal_periodic_p = 0;
+ disarm_decr[cpuid] = (__ipipe_decr_ticks != tb_ticks_per_jiffy);
#ifdef CONFIG_40x
-mtspr(SPRN_TCR,mfspr(SPRN_TCR) ~TCR_ARE); /* Auto-reload off. */
-#endif /* CONFIG_40x */
- rthal_timer_program_shot(tb_ticks_per_jiffy);
+ /* Enable and set auto-reload. */
+ mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
+ mtspr(SPRN_PIT, __ipipe_decr_ticks);
+#else /* !CONFIG_40x */
+ ticks = (long)(__ipipe_decr_next[cpuid] - __ipipe_read_timebase());
+ set_dec(ticks 0 ? ticks : 0);
+#endif /* CONFIG_40x */
+ DBG(rthal_set_local_cpu_timer(%d): %ld\n, cpuid, ticks);
+}
+
+static int rthal_set_cpu_timers_unsafe(unsigned long ns)
+{
+ unsigned long ticks;
+ unsigned long offset, previous_tb;
+ int i;
+ rthal_declare_cpuid;
+
+ DBG(rthal_set_cpu_timers_unsafe: %lu\n, ns);
+
+ if (ns == 0)
+ ticks = tb_ticks_per_jiffy;
+ else {
+ ticks = ns * tb_ticks_per_jiffy / (10 / HZ);
+
+ if (ticks tb_ticks_per_jiffy) {
+ DBG(rthal_set_cpu_timers_unsafe: -EINVAL (%lu)\n,
ticks);
+ return -EINVAL;
+ }
}
-rthal_irq_release(RTHAL_TIMER_IRQ);
-
-err = rthal_irq_request(RTHAL_TIMER_IRQ,
- (rthal_irq_handler_t)handler
[Xenomai-core] I-pipe ppc64 0.9-02
Updated ppc64 I-pipe patch for 2.6.14. Changes: * sync with ppc 1.0-07 * send IPI to self fixed * additional IPI (#4) for xenomai SMP timer implementation Also at the usual http://www.cs.helsinki.fi/group/nonsto/rtaippc64.html Philippe, please put this in Xenomai 2.1. -- Heikki Lindholm diff -Nru linux-2.6.14/arch/ppc64/Kconfig linux-2.6.14-adeos-ipipe-ppc64-0.9-02-dev/arch/ppc64/Kconfig --- linux-2.6.14/arch/ppc64/Kconfig 2005-10-28 03:02:08.0 +0300 +++ linux-2.6.14-adeos-ipipe-ppc64-0.9-02-dev/arch/ppc64/Kconfig 2005-11-04 08:56:30.0 +0200 @@ -227,6 +227,8 @@ depends on SMP default 32 +source kernel/ipipe/Kconfig + config HMT bool Hardware multithreading depends on SMP PPC_PSERIES BROKEN diff -Nru linux-2.6.14/arch/ppc64/kernel/entry.S linux-2.6.14-adeos-ipipe-ppc64-0.9-02-dev/arch/ppc64/kernel/entry.S --- linux-2.6.14/arch/ppc64/kernel/entry.S 2005-10-28 03:02:08.0 +0300 +++ linux-2.6.14-adeos-ipipe-ppc64-0.9-02-dev/arch/ppc64/kernel/entry.S 2005-11-04 10:28:59.0 +0200 @@ -35,6 +35,14 @@ #define DO_SOFT_DISABLE #endif +#ifdef CONFIG_IPIPE +#define STALL_ROOT_CONDbl __ipipe_stall_root_raw +#define UNSTALL_ROOT_COND bl __ipipe_unstall_root_raw +#else /* !CONFIG_IPIPE */ +#define STALL_ROOT_COND +#define UNSTALL_ROOT_COND +#endif /* CONFIG_IPIPE */ + /* * System calls. */ @@ -108,6 +116,23 @@ ori r11,r11,MSR_EE mtmsrd r11,1 +#ifdef CONFIG_IPIPE + addir3,r1,GPR0 + bl .__ipipe_syscall_root + cmpdi r3,0 + ld r0,GPR0(r1) + ld r3,GPR3(r1) + ld r4,GPR4(r1) + ld r5,GPR5(r1) + ld r6,GPR6(r1) + ld r7,GPR7(r1) + ld r8,GPR8(r1) + ld r9,GPR9(r1) + bgt ipipe_end_syscall + blt syscall_exit + addir9,r1,STACK_FRAME_OVERHEAD +#endif /* CONFIG_IPIPE */ + #ifdef SHOW_SYSCALLS bl .do_show_syscall REST_GPR(0,r1) @@ -196,6 +221,35 @@ rfid b . /* prevent speculative execution */ +#ifdef CONFIG_IPIPE + .globl ipipe_end_syscall +ipipe_end_syscall: + mfmsr r10 + rldicl r10,r10,48,1 + rotldi r10,r10,16 + mtmsrd r10,1 + ld r5,_CCR(r1) + ld r8,_MSR(r1) + ld r7,_NIP(r1) + stdcx. r0,0,r1 /* to clear pending reservations */ + andi. r6,r8,MSR_PR + ld r4,_LINK(r1) + beq-1f /* only restore r13 if */ + ld r13,GPR13(r1) /* returning to usermode */ +1: ld r2,GPR2(r1) + li r12,MSR_RI + mfmsr r10 + andcr10,r10,r12 + mtmsrd r10,1 /* clear MSR.RI */ + ld r1,GPR1(r1) + mtlrr4 + mtcrr5 + mtspr SRR0,r7 + mtspr SRR1,r8 + rfid + b . /* prevent speculative execution */ +#endif /* CONFIG_IPIPE */ + syscall_enosys: li r3,-ENOSYS std r3,RESULT(r1) @@ -470,6 +524,13 @@ rotldi r9,r9,16 mtmsrd r9,1/* Update machine state */ +#ifdef CONFIG_IPIPE + bl .__ipipe_check_root + cmpdi r3,0 + mfmsr r10 /* this is used later, might be messed */ + beq-restore +#endif /* CONFIG_IPIPE */ + #ifdef CONFIG_PREEMPT clrrdi r9,r1,THREAD_SHIFT /* current_thread_info() */ li r0,_TIF_NEED_RESCHED/* bits to check */ @@ -843,3 +904,11 @@ blr #endif /* CONFIG_PPC_MULTIPLATFORM */ + +#ifdef CONFIG_IPIPE + +_GLOBAL(__ipipe_ret_from_except_lite) + cmpdi r3,0 + bne+.ret_from_except_lite + b restore +#endif /* CONFIG_IPIPE */ diff -Nru linux-2.6.14/arch/ppc64/kernel/head.S linux-2.6.14-adeos-ipipe-ppc64-0.9-02-dev/arch/ppc64/kernel/head.S --- linux-2.6.14/arch/ppc64/kernel/head.S 2005-10-28 03:02:08.0 +0300 +++ linux-2.6.14-adeos-ipipe-ppc64-0.9-02-dev/arch/ppc64/kernel/head.S 2005-11-04 10:36:08.0 +0200 @@ -376,6 +376,18 @@ bl hdlr; \ b .ret_from_except_lite +#ifdef CONFIG_IPIPE +#define IPIPE_EXCEPTION_COMMON_LITE(trap, label, hdlr) \ + .align 7; \ + .globl label##_common; \ +label##_common:\ + EXCEPTION_PROLOG_COMMON(trap, PACA_EXGEN); \ + DISABLE_INTS; \ + addir3,r1,STACK_FRAME_OVERHEAD; \ + bl hdlr; \ + b .__ipipe_ret_from_except_lite +#endif /* CONFIG_IPIPE */ + /* * Start of pSeries system interrupt routines */ @@ -685,7 +697,11 @@ bl .machine_check_exception b
[Xenomai-core] [PATCH] Small build system fix for Xenomai 2.1
The prepare-kernel.sh script doesn't link assembly files to the kernel
at all. This should fix it.
-- Heikki Lindholm
diff -Nru xenomai.orig/scripts/prepare-kernel.sh
xenomai/scripts/prepare-kernel.sh
--- xenomai.orig/scripts/prepare-kernel.sh 2005-11-14 20:04:19.0
+0200
+++ xenomai/scripts/prepare-kernel.sh 2005-11-16 13:03:27.0 +0200
@@ -4,7 +4,7 @@
do_links() {
rm -fr $2
( cd $1
- find . \( -name Makefile -o -name Kconfig -o -name '*.[ch]' \) |
+ find . \( -name Makefile -o -name Kconfig -o -name '*.[chS]' \) |
while read f; do
d=`dirname $f`
mkdir -p $2/$d ln -s $1/$f $2/$f
[Xenomai-core] [PATCH] Xenomai stable ppc64 I-pipe sync
Sync the ppc64 arch of the stable tree to work with I-pipe kernel also. -- Heikki Lindholm diff -Nru xenomai/arch/ppc64/hal/switch.S xenomai-devel/arch/ppc64/hal/switch.S --- xenomai/arch/ppc64/hal/switch.S 2005-10-11 10:32:30.0 +0300 +++ xenomai-devel/arch/ppc64/hal/switch.S 2005-11-08 12:49:18.0 +0200 @@ -26,7 +26,6 @@ #include asm/processor.h #include asm/cputable.h #include asm/page.h -#include asm/offsets.h #include asm/ppc_asm.h #include xeno_config.h diff -Nru xenomai/include/nucleus/asm-ppc64/hal.h xenomai-devel/include/nucleus/asm-ppc64/hal.h --- xenomai/include/nucleus/asm-ppc64/hal.h 2005-10-11 10:30:03.0 +0300 +++ xenomai-devel/include/nucleus/asm-ppc64/hal.h 2005-11-08 11:32:17.0 +0200 @@ -98,7 +98,11 @@ #include nucleus/asm/atomic.h #include asm/processor.h +#ifdef CONFIG_ADEOS_CORE #define RTHAL_TIMER_IRQ ADEOS_TIMER_VIRQ +#else /* !CONFIG_ADEOS_CORE */ +#define RTHAL_TIMER_IRQ IPIPE_TIMER_VIRQ +#endif /* CONFIG_ADEOS_CORE */ #define rthal_irq_descp(irq) (irq_desc[(irq)]) diff -Nru xenomai/include/nucleus/asm-ppc64/system.h xenomai-devel/include/nucleus/asm-ppc64/system.h --- xenomai/include/nucleus/asm-ppc64/system.h 2005-11-01 11:04:04.0 +0200 +++ xenomai-devel/include/nucleus/asm-ppc64/system.h2005-11-08 11:35:38.0 +0200 @@ -31,10 +31,12 @@ #include linux/config.h #include linux/ptrace.h +#ifdef CONFIG_ADEOS_CORE #if ADEOS_RELEASE_NUMBER 0x02060201 #error Adeos 2.6r2c1/ppc64 or above is required to run this software; please upgrade. #error See http://download.gna.org/adeos/patches/v2.6/ppc64/; #endif +#endif /* CONFIG_ADEOS_CORE */ #define XNARCH_DEFAULT_TICK 100 /* ns, i.e. 1ms */ #define XNARCH_HOST_TICK(10UL/HZ) @@ -102,11 +104,19 @@ /* The following predicates are only usable over a regular Linux stack *context. */ +#ifdef CONFIG_ADEOS_CORE #define xnarch_fault_pf_p(fi) ((fi)-exception == ADEOS_ACCESS_TRAP) #define xnarch_fault_bp_p(fi) ((current-ptrace PT_PTRACED) \ ((fi)-exception == ADEOS_IABR_TRAP || \ (fi)-exception == ADEOS_SSTEP_TRAP || \ (fi)-exception == ADEOS_PERFMON_TRAP)) +#else /* !CONFIG_ADEOS_CORE */ +#define xnarch_fault_pf_p(fi) ((fi)-exception == IPIPE_TRAP_ACCESS) +#define xnarch_fault_bp_p(fi) ((current-ptrace PT_PTRACED) \ + ((fi)-exception == IPIPE_TRAP_IABR || \ + (fi)-exception == IPIPE_TRAP_SSTEP || \ + (fi)-exception == IPIPE_TRAP_PERFMON)) +#endif /* CONFIG_ADEOS_CORE */ #define xnarch_fault_notify(fi) (!xnarch_fault_bp_p(fi)) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Adeos (oldgen) 2.6.10 ppc64 r3
A new Adeos patch for the 2.6.10 ppc64 (r3) with minor paranoia reduction. Also from: http://www.cs.helsinki.fi/group/nonsto/rtaippc64.html -- Heikki Lindholm
[Xenomai-core] Re: Adeos (oldgen) 2.6.10 ppc64 r3
A new Adeos patch for the 2.6.10 ppc64 (r3) with minor paranoia reduction.
Also from:
http://www.cs.helsinki.fi/group/nonsto/rtaippc64.html
-- Heikki Lindholm
diff -Nru linux-2.6.10/adeos/generic.c
linux-2.6.10-adeos-ppc64-r3/adeos/generic.c
--- linux-2.6.10/adeos/generic.c1970-01-01 02:00:00.0 +0200
+++ linux-2.6.10-adeos-ppc64-r3/adeos/generic.c 2005-11-13 11:45:31.0
+0200
@@ -0,0 +1,640 @@
+/*
+ * linux/adeos/generic.c
+ *
+ * Copyright (C) 2002 Philippe Gerum.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, Inc., 675 Mass Ave, Cambridge MA 02139,
+ * USA; either version 2 of the License, or (at your option) any later
+ * version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Architecture-independent ADEOS services.
+ */
+
+#include linux/version.h
+#include linux/module.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/irq.h
+
+MODULE_DESCRIPTION(Adeos nanokernel);
+MODULE_AUTHOR(Philippe Gerum);
+MODULE_LICENSE(GPL);
+
+/* adeos_register_domain() -- Add a new domain to the system. All
+ client domains must call this routine to register themselves to
+ ADEOS before using its services. */
+
+int adeos_register_domain (adomain_t *adp, adattr_t *attr)
+
+{
+struct list_head *pos;
+unsigned long flags;
+int n;
+
+if (adp_current != adp_root)
+ {
+ printk(KERN_WARNING Adeos: Only the root domain may register a new
domain.\n);
+ return -EPERM;
+ }
+
+flags = adeos_critical_enter(NULL);
+
+list_for_each(pos,__adeos_pipeline) {
+ adomain_t *_adp = list_entry(pos,adomain_t,p_link);
+ if (_adp-domid == attr-domid)
+break;
+}
+
+adeos_critical_exit(flags);
+
+if (pos != __adeos_pipeline)
+ /* A domain with the given id already exists -- fail. */
+ return -EBUSY;
+
+for (n = 0; n ADEOS_NR_CPUS; n++)
+ {
+ /* Each domain starts in sleeping state on every CPU. */
+ adp-cpudata[n].status = (1 IPIPE_SLEEP_FLAG);
+#ifdef CONFIG_ADEOS_THREADS
+ adp-estackbase[n] = 0;
+#endif /* CONFIG_ADEOS_THREADS */
+ }
+
+adp-name = attr-name;
+adp-priority = attr-priority;
+adp-domid = attr-domid;
+adp-dswitch = attr-dswitch;
+adp-flags = 0;
+adp-ptd_setfun = attr-ptdset;
+adp-ptd_getfun = attr-ptdget;
+adp-ptd_keymap = 0;
+adp-ptd_keycount = 0;
+adp-ptd_keymax = attr-nptdkeys;
+
+for (n = 0; n ADEOS_NR_EVENTS; n++)
+ /* Event handlers must be cleared before the i-pipe stage is
+ inserted since an exception may occur on behalf of the new
+ emerging domain. */
+ adp-events[n].handler = NULL;
+
+if (attr-entry != NULL)
+ __adeos_init_domain(adp,attr);
+
+/* Insert the domain in the interrupt pipeline last, so it won't
+ be resumed for processing interrupts until it has a valid stack
+ context. */
+
+__adeos_init_stage(adp);
+
+INIT_LIST_HEAD(adp-p_link);
+
+flags = adeos_critical_enter(NULL);
+
+list_for_each(pos,__adeos_pipeline) {
+ adomain_t *_adp = list_entry(pos,adomain_t,p_link);
+ if (adp-priority _adp-priority)
+break;
+}
+
+list_add_tail(adp-p_link,pos);
+
+adeos_critical_exit(flags);
+
+printk(KERN_WARNING Adeos: Domain %s registered.\n,adp-name);
+
+/* Finally, allow the new domain to perform its initialization
+ chores. */
+
+if (attr-entry != NULL)
+ {
+ adeos_declare_cpuid;
+
+ adeos_lock_cpu(flags);
+
+#ifdef CONFIG_ADEOS_THREADS
+ __adeos_switch_to(adp_root,adp,cpuid);
+#else /* !CONFIG_ADEOS_THREADS */
+ adp_cpu_current[cpuid] = adp;
+ attr-entry(1);
+ adp_cpu_current[cpuid] = adp_root;
+#endif /* CONFIG_ADEOS_THREADS */
+
+ adeos_load_cpuid(); /* Processor might have changed. */
+
+ if (adp_root-cpudata[cpuid].irq_pending_hi != 0
+ !test_bit(IPIPE_STALL_FLAG,adp_root-cpudata[cpuid].status))
+ __adeos_sync_stage(IPIPE_IRQMASK_ANY);
+
+ adeos_unlock_cpu(flags);
+ }
+
+return 0;
+}
+
+/* adeos_unregister_domain() -- Remove a domain from the system. All
+ client domains must call this routine to unregister themselves from
+ the ADEOS layer. */
+
+int adeos_unregister_domain (adomain_t *adp)
+
+{
+unsigned long flags;
+unsigned event;
+
+if (adp_current
[Xenomai-core] Adeos I-pipe 2.6.14 ppc64 0.9-01
First, and therefore experimental, Adeos I-pipe patch for the 2.6.14 ppc64 with SMP support. Note: Xenomai ppc64 still lacks proper SMP support. Note2: 2.6.14 needs patches to support UP build! Also from: http://www.cs.helsinki.fi/group/nonsto/rtaippc64.html -- Heikki Lindholm diff -Nru linux-2.6.14/arch/ppc64/Kconfig linux-2.6.14-adeos-ipipe-ppc64-0.9-01-dev/arch/ppc64/Kconfig --- linux-2.6.14/arch/ppc64/Kconfig 2005-10-28 03:02:08.0 +0300 +++ linux-2.6.14-adeos-ipipe-ppc64-0.9-01-dev/arch/ppc64/Kconfig 2005-11-04 08:56:30.0 +0200 @@ -227,6 +227,8 @@ depends on SMP default 32 +source kernel/ipipe/Kconfig + config HMT bool Hardware multithreading depends on SMP PPC_PSERIES BROKEN diff -Nru linux-2.6.14/arch/ppc64/kernel/entry.S linux-2.6.14-adeos-ipipe-ppc64-0.9-01-dev/arch/ppc64/kernel/entry.S --- linux-2.6.14/arch/ppc64/kernel/entry.S 2005-10-28 03:02:08.0 +0300 +++ linux-2.6.14-adeos-ipipe-ppc64-0.9-01-dev/arch/ppc64/kernel/entry.S 2005-11-04 10:28:59.0 +0200 @@ -35,6 +35,14 @@ #define DO_SOFT_DISABLE #endif +#ifdef CONFIG_IPIPE +#define STALL_ROOT_CONDbl __ipipe_stall_root_raw +#define UNSTALL_ROOT_COND bl __ipipe_unstall_root_raw +#else /* !CONFIG_IPIPE */ +#define STALL_ROOT_COND +#define UNSTALL_ROOT_COND +#endif /* CONFIG_IPIPE */ + /* * System calls. */ @@ -108,6 +116,23 @@ ori r11,r11,MSR_EE mtmsrd r11,1 +#ifdef CONFIG_IPIPE + addir3,r1,GPR0 + bl .__ipipe_syscall_root + cmpdi r3,0 + ld r0,GPR0(r1) + ld r3,GPR3(r1) + ld r4,GPR4(r1) + ld r5,GPR5(r1) + ld r6,GPR6(r1) + ld r7,GPR7(r1) + ld r8,GPR8(r1) + ld r9,GPR9(r1) + bgt ipipe_end_syscall + blt syscall_exit + addir9,r1,STACK_FRAME_OVERHEAD +#endif /* CONFIG_IPIPE */ + #ifdef SHOW_SYSCALLS bl .do_show_syscall REST_GPR(0,r1) @@ -196,6 +221,35 @@ rfid b . /* prevent speculative execution */ +#ifdef CONFIG_IPIPE + .globl ipipe_end_syscall +ipipe_end_syscall: + mfmsr r10 + rldicl r10,r10,48,1 + rotldi r10,r10,16 + mtmsrd r10,1 + ld r5,_CCR(r1) + ld r8,_MSR(r1) + ld r7,_NIP(r1) + stdcx. r0,0,r1 /* to clear pending reservations */ + andi. r6,r8,MSR_PR + ld r4,_LINK(r1) + beq-1f /* only restore r13 if */ + ld r13,GPR13(r1) /* returning to usermode */ +1: ld r2,GPR2(r1) + li r12,MSR_RI + mfmsr r10 + andcr10,r10,r12 + mtmsrd r10,1 /* clear MSR.RI */ + ld r1,GPR1(r1) + mtlrr4 + mtcrr5 + mtspr SRR0,r7 + mtspr SRR1,r8 + rfid + b . /* prevent speculative execution */ +#endif /* CONFIG_IPIPE */ + syscall_enosys: li r3,-ENOSYS std r3,RESULT(r1) @@ -470,6 +524,13 @@ rotldi r9,r9,16 mtmsrd r9,1/* Update machine state */ +#ifdef CONFIG_IPIPE + bl .__ipipe_check_root + cmpdi r3,0 + mfmsr r10 /* this is used later, might be messed */ + beq-restore +#endif /* CONFIG_IPIPE */ + #ifdef CONFIG_PREEMPT clrrdi r9,r1,THREAD_SHIFT /* current_thread_info() */ li r0,_TIF_NEED_RESCHED/* bits to check */ @@ -843,3 +904,11 @@ blr #endif /* CONFIG_PPC_MULTIPLATFORM */ + +#ifdef CONFIG_IPIPE + +_GLOBAL(__ipipe_ret_from_except_lite) + cmpdi r3,0 + bne+.ret_from_except_lite + b restore +#endif /* CONFIG_IPIPE */ diff -Nru linux-2.6.14/arch/ppc64/kernel/head.S linux-2.6.14-adeos-ipipe-ppc64-0.9-01-dev/arch/ppc64/kernel/head.S --- linux-2.6.14/arch/ppc64/kernel/head.S 2005-10-28 03:02:08.0 +0300 +++ linux-2.6.14-adeos-ipipe-ppc64-0.9-01-dev/arch/ppc64/kernel/head.S 2005-11-04 10:36:08.0 +0200 @@ -376,6 +376,18 @@ bl hdlr; \ b .ret_from_except_lite +#ifdef CONFIG_IPIPE +#define IPIPE_EXCEPTION_COMMON_LITE(trap, label, hdlr) \ + .align 7; \ + .globl label##_common; \ +label##_common:\ + EXCEPTION_PROLOG_COMMON(trap, PACA_EXGEN); \ + DISABLE_INTS; \ + addir3,r1,STACK_FRAME_OVERHEAD; \ + bl hdlr; \ + b .__ipipe_ret_from_except_lite +#endif /* CONFIG_IPIPE */ + /* * Start of pSeries system interrupt routines */ @@ -685,7 +697,11 @@ bl .machine_check_exception b .ret_from_except
[Xenomai-core] [PATCH: 3/3] powerpc merge
Alter makefiles to accomodate the new powerpc arch and forget the old
ppc and ppc64 ones. This is based on guesswork and will probably need
some clean(s)ing up by somebody more knowledgeable on the Xenomai
makefile system. The problem is that the makefiles need to map three
kernel archs (ppc,ppc64 and the future powerpc) to one xenomai arch
(powerpc).
-- Heikki Lindholm
diff -Nru --exclude=.svn xenomai-orig/arch/GNUmakefile.am
xenomai-devel/arch/GNUmakefile.am
--- xenomai-orig/arch/GNUmakefile.am2005-10-11 10:32:31.0 +0300
+++ xenomai-devel/arch/GNUmakefile.am 2005-10-23 11:32:19.0 +0300
@@ -3,10 +3,10 @@
endif
if CONFIG_PPC64
-ARCHDIR = ppc64
+ARCHDIR = powerpc
else
if CONFIG_PPC
-ARCHDIR = ppc
+ARCHDIR = powerpc
endif
endif
diff -Nru --exclude=.svn xenomai-orig/config/kconfig/Makefile.kconfig
xenomai-devel/config/kconfig/Makefile.kconfig
--- xenomai-orig/config/kconfig/Makefile.kconfig2005-10-11
10:32:11.0 +0300
+++ xenomai-devel/config/kconfig/Makefile.kconfig 2005-10-23
15:58:12.0 +0300
@@ -32,33 +32,40 @@
endif
endif
+ifeq ($(ARCH), ppc)
+ XENO_ARCH := powerpc
+endif
+ifeq ($(ARCH), ppc64)
+ XENO_ARCH := powerpc
+endif
+
LXDIALOG_OBJS := lxdialog/checklist.o lxdialog/menubox.o \
lxdialog/textbox.o lxdialog/yesno.o lxdialog/inputbox.o \
lxdialog/util.o lxdialog/lxdialog.o lxdialog/msgbox.o
xconfig: qconf
- @./qconf $(srctree)/arch/$(ARCH)/Kconfig
+ @./qconf $(srctree)/arch/$(XENO_ARCH)/Kconfig
gconfig: gconf
- @./gconf $(srctree)/arch/$(ARCH)/Kconfig
+ @./gconf $(srctree)/arch/$(XENO_ARCH)/Kconfig
menuconfig mconfig: mconf
- @./mconf $(srctree)/arch/$(ARCH)/Kconfig
+ @./mconf $(srctree)/arch/$(XENO_ARCH)/Kconfig
config: conf
- @./conf $(srctree)/arch/$(ARCH)/Kconfig
+ @./conf $(srctree)/arch/$(XENO_ARCH)/Kconfig
oldconfig: conf
- @./conf -o $(srctree)/arch/$(ARCH)/Kconfig
+ @./conf -o $(srctree)/arch/$(XENO_ARCH)/Kconfig
qconf: .qtinst
- $(MAKE) -f $(srcdir)/Makefile.kconfig qbuild srctree=$(srctree)
ARCH=$(ARCH)
+ $(MAKE) -f $(srcdir)/Makefile.kconfig qbuild srctree=$(srctree)
ARCH=$(ARCH) XENO_ARCH=$(XENO_ARCH)
qbuild: qconf.o kconfig_load.o libkconfig.so
$(CXX) -o qconf $^ -Wl,-rpath,$(this_dir) -L$(QTDIR)/lib
-Wl,-rpath,$(QTDIR)/lib -l$(QTLIB) -ldl
gconf: .gtkinst
- $(MAKE) -f $(srcdir)/Makefile.kconfig gbuild srctree=$(srctree)
ARCH=$(ARCH)
+ $(MAKE) -f $(srcdir)/Makefile.kconfig gbuild srctree=$(srctree)
ARCH=$(ARCH) XENO_ARCH=$(XENO_ARCH)
gbuild: gconf.o kconfig_load.o libkconfig.so
$(CC) -o gconf $^ -Wl,-rpath,$(this_dir) $(GLIBS)
diff -Nru --exclude=.svn xenomai-orig/configure.in xenomai-devel/configure.in
--- xenomai-orig/configure.in 2005-10-23 11:00:14.0 +0300
+++ xenomai-devel/configure.in 2005-10-23 15:58:41.0 +0300
@@ -48,21 +48,25 @@
case $host in
i*86*-*)
XENO_TARGET_ARCH=i386
+ XENO_KERNEL_TARGET_ARCH=i386
wanted_kernel_arch=CONFIG_X86
arch_have_sim=y
;;
powerpc-*|ppc-*)
- XENO_TARGET_ARCH=ppc
+ XENO_TARGET_ARCH=powerpc
+ XENO_KERNEL_TARGET_ARCH=ppc
wanted_kernel_arch=CONFIG_PPC
arch_have_sim=y
;;
powerpc64-*|ppc64-*)
- XENO_TARGET_ARCH=ppc64
+ XENO_TARGET_ARCH=powerpc
+ XENO_KERNEL_TARGET_ARCH=ppc64
wanted_kernel_arch=CONFIG_PPC64
arch_have_sim=y
;;
ia64-*)
XENO_TARGET_ARCH=ia64
+ XENO_KERNEL_TARGET_ARCH=ia64
wanted_kernel_arch=CONFIG_IA64
arch_have_sim=y
;;
@@ -226,7 +230,7 @@
AC_MSG_CHECKING([for interrupt pipeline extension])
if test -r $XENO_LINUX_SRCDIR/include/linux/ipipe.h; then
- v=`grep '^#define.*IPIPE_ARCH_STRING.*'
$XENO_LINUX_SRCDIR/include/asm-$XENO_TARGET_ARCH/ipipe.h|sed -e
's,.*\(.*\)$,\1,'`
+ v=`grep '^#define.*IPIPE_ARCH_STRING.*'
$XENO_LINUX_SRCDIR/include/asm-$XENO_KERNEL_TARGET_ARCH/ipipe.h|sed -e
's,.*\(.*\)$,\1,'`
AC_MSG_RESULT([Adeos newgen (I-pipe $v)])
if test x${CONFIG_IPIPE} = x; then
AC_MSG_ERROR([Please activate the Adeos support in $XENO_LINUX_DIR and
rebuild your kernel])
@@ -235,7 +239,7 @@
AC_MSG_ERROR([Please re-patch your kernel with the Adeos support])
fi
elif test -r $XENO_LINUX_SRCDIR/include/linux/adeos.h; then
- v=`grep '^#define.*ADEOS_ARCH_STRING.*'
$XENO_LINUX_SRCDIR/include/asm-$XENO_TARGET_ARCH/adeos.h|sed -e
's,.*\(.*\)$,\1,'`
+ v=`grep '^#define.*ADEOS_ARCH_STRING.*'
$XENO_LINUX_SRCDIR/include/asm-$XENO_KERNEL_TARGET_ARCH/adeos.h|sed -e
's,.*\(.*\)$,\1,'`
AC_MSG_RESULT([Adeos oldgen ($v)])
if test x${CONFIG_ADEOS_CORE} = x; then
AC_MSG_ERROR([Please activate the Adeos support in $XENO_LINUX_DIR and
rebuild your kernel])
@@ -309,7 +313,7 @@
HOST_EXTRACFLAGS += -DXENO_CFLAGS=\\$(CC) \$(CFLAGS)\
EOF
-CC=$CC make -s -C
Re: [Xenomai-core] [Fwd: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).]
Philippe Gerum kirjoitti: Resending here since this is a general project issue. Original Message Subject: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc). Date: Fri, 21 Oct 2005 18:45:59 +0200 From: Philippe Gerum [EMAIL PROTECTED] Organization: Xenomai To: Jan Kiszka [EMAIL PROTECTED] CC: xenomai-help@gna.org References: [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] Jan Kiszka wrote: Ignacio García Pérez wrote: ... P.S: As a side note, wouldn't be a good practice to expand tabs to spaces in all the code? My opinion is yes - but it's a nasty work. Would you provide such patches...? Actually, there is a more general problem with the current coding style used throughout the code base: it's mine, it's not that standard, and now thatmore people are contributing to it, I'm pondering whether we should just adoptthe conventional kernel coding style, without the ludicrous 8-space tabs, that is. I'm pro kernel style. Now the style is bit of a mixed bag, especially where there is code copied from somewhere else. I don't even have anything against them 8-spaced tab stops. -- Heikki Lindholm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch
Wolfgang Grandegger kirjoitti: Hello Philippe, I got Xenomai working on a Ocotea-Board (AMCC 440GX) and a low-end TQM855L-Module (MPC 855) under Linux 2.6.14-rc3 :-). The patch applied with a few hunks and one easy to fix reject and I had to correct two problems. One with FEW_CONTEXT (see attached patch) and the second with #include asm/offsets.h in xenomai/arch/ppc/hal/switch.S. The include file does not exist (any more) in the kernel tree and therefore I commented out the line. I'm going to perform latency tests on various 4xx and 8xx boards next week. Here are some preliminary figures of the TQM855L-Module (CPU 80 MHz, Bus 40 MHz, 4 kB I-Cache 4 kB D-Cache): If you happen to know some (semi-)comparable figures for the same boards using some commercial RTOS, it would be nice to know them also, for comparison. -- Heikki Lindholm
Re: [Xenomai-core] Bug tracker.
Gilles Chanteperdrix kirjoitti: Hi, GNA offers a bug tracking system which is undoubtely a useful tool for lots of projects. What about using it for the Xenomai project ? I'm not stronly opposing, but in my opinion it causes information to scatter in contrast to the ml. There'll be bug reports on the ml regardless of having or not having a bug tracking system in function. It's more difficult to follow/search two places than one. And this project isn't the size of openoffice or debian, so maybe the ml doesn't get cluttered by incoming bug reports. And finally, many bug reports already contain a reasonable fix and their tracking summarizes to Applied. There are benefits, too, of course, like forcing a good format for a report. -- Heikki Lindholm
Re: [Xenomai-core] Bug tracker.
Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: Gilles Chanteperdrix kirjoitti: Hi, GNA offers a bug tracking system which is undoubtely a useful tool for lots of projects. What about using it for the Xenomai project ? It's more difficult to follow/search two places than one. If for every real bug reported on the mailing list, there is a entry on the tracker ; there is only one place to search : the tracker, because it is a database, and much easier to search than mailing list archives, provided of course we add the important fields to the submission form. There's the if. What I've seen on sourceforge is that often times bugs that are reported on the ml don't appear in the tracker and vice versa, although the tracker can probably be configured to forward reports to ml, or? Who will type the ml-only reports to the tracker? Btw. would you only allow developers to file bugs into the tracker? And this project isn't the size of openoffice or debian, so maybe the ml doesn't get cluttered by incoming bug reports. Bug reports and FAQs do represent the vast majority of RTAI user mailing list traffic for example. Answering these is time consuming, so since our ressources are limited, any productivity tool is a good idea. If the bug tracker turns out to be time consuming, we will stop using it, but how do we know if we do not try ? As I said I'm not strongly opposing. Go ahead and give it a spin - not too difficult to back out from that. Although, on the USER side, I've never preferred a bts (login req/learn to use/etc) to ml (e-mail client). all the elements that would allow to solve the bug, so you have to ask the same questions over and over again. Isn't this what most of life is about anyway? :) -- Heikki Lindholm
Re: [Xenomai-core] Bug tracker.
Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: There's the if. What I've seen on sourceforge is that often times bugs that are reported on the ml don't appear in the tracker and vice versa, although the tracker can probably be configured to forward reports to ml, or? Who will type the ml-only reports to the tracker? Btw. would you only allow developers to file bugs into the tracker? I would use it as a one line answer to bug reports on the mailing list... I would prefer users to always post on the mailing list first, and if it looks like a real bug, a developer would ask the user to fill a bug report. That might work. As a case study of something to avoid: I know at least three persistent bugs in the firefox browser I'm using and I thought about reporting them, ending up in http://www.mozilla.org/support/firefox/bugs which in turn leads to many worksome steps and eventually to http://www.mozilla.org/quality/bug-writing-guidelines.html Blech! It seems easier to write a firefox from ground up than giving them a bug report --- and thus my observations stay unreported. Moral of the story: keep it simple! -- Heikki Lindholm
Re: [Xenomai-core] PATCH: fix ppc64 calibration
Wolfgang Grandegger kirjoitti: On 10/11/2005 05:11 PM Fillod Stephane wrote: Heikki Lindholm wrote: [..] Probably, but there are less than awesome 4xx boards around and I'd guess they might even be more likely targets than G4 based machines, for example. Some tuning might be needed. How many people are using Xenomai (or Fusion) on 4xx ? What are their typical sched latency ? Attached is the result of some latency measurements on the Ocotea eval board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately, the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless, it's difficult to provide a resonable default value. Why not simply using 0 and it's then up to the user to provide an appropriate value at configuration time? 0? No machine is that fast. For the 32-bit ppc it might be harder to provide a reasonable default, because of the broader scale of hardware, but I'd guess that 100MHz targets prefer to use a dedicated RTOS instead of Xenomai. For the 64-bit targets, I didn't find slower than 400 MHz machines and they were iSeries, which, I suppose, also aren't prime target for Xenomai. Regardless of what default value is used, there could be some examples provided by the config help to direct user to the right direction. What's the problem with Ebonys? I remember running at least 2.6.9 on Ebonys (440GP) and Walnuts (405). -- Heikki Lindholm
Re: [Xenomai-core] PATCH: fix ppc64 calibration
Wolfgang Grandegger kirjoitti: What's the problem with Ebonys? I remember running at least 2.6.9 on Ebonys (440GP) and Walnuts (405). We have linux-2.4.14-rc3 running on all AMCC eval boards (see http://www.denx.de). But the kernel supported by RTAI/Fusion, linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the missing support for U-Boot but there might be others. And it's simply not worth the effort to port it, I think. Now that you mention it, I remember I had to hack u-boot support in there back when I used the Ebonys. Maybe I'll see if I can get some numbers out of them later this week. -- Heikki Lindholm
Re: [Xenomai-core] Linux powerpc merger
Philippe Gerum kirjoitti: Heikki Lindholm wrote: Hello, As people following powerpc kernel mailing lists probably know, the Linux ppc and ppc64 architectures are merging into a single powerpc arch. I think the same should be done to fusion. Agreed. Let's closely follow the natural development path of the kernel incarnations we use for our ports; especially when such path is sensible. It would seem quite easy and there's already lots of redundant code there, but possible problems arise from being able to work with both the old unmerged kernels and the future merged arch kernels. Would the issues be located at the Adeos level, or would this leak to Xeno's arch-dep layer? Is there any ideas regarding or work being done on this front? I plan to restart working on the I-pipe/ppc patch shortly, so that we can both upgrade the Adeos architecture and the kernel version available for Xeno's ppc port. Since most of the work has been done already, we should synchronize and start crafting a patch for the ppc* combo after the initial I-pipe/ppc one. We could actually start by proactively (ugh!) merging the Xenomai ppc and ppc64 dirs into one powerpc dir like the kernel folks do and see if we can get it to work with the current separate ppc/ppc64 patches. I actually had this in mind when I noticed how much code would be unchanged for the ppc64 arch, but decided to do it separately anyway in case something bigger would have surfaced later, which it seems it didn't. -- Heikki Lindholm
Re: [Xenomai-core] Generated docs
Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: Gilles Chanteperdrix kirjoitti: Indeed. But this is the special attention I'm talking about ;) I'm still not convinced about the need 'em for the release reasoning. Let's put it this way: what trouble would it bring, if we had dist always generate docs for a release (and not have them in the repo)? Allows to share the load during releases: I generate the doc, using the generate-doc target in the doc directory, run svn commit to put them in the repository. Then Philippe runs svn update and make dist. As I said, it allows to have a separate maintenance of documentation and sources. Hehe. So Philippe's machine would choke, if it had to generate the docs, too(?) And since most(?) of the docs comes from the sources, you don't actually edit them by hand now do you? So what does maintaining mean here? Having the generated documentation in svn repository also allows us to copy it to the documentation directory of the download zone from a script run by cron. Ok, this makes sense. But could be done by other means, too, I guess. -- Heikki Lindholm
Re: [Xenomai-core] Generated docs
Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: Gilles Chanteperdrix kirjoitti: Heikki Lindholm wrote: Gilles Chanteperdrix kirjoitti: Indeed. But this is the special attention I'm talking about ;) I'm still not convinced about the need 'em for the release reasoning. Let's put it this way: what trouble would it bring, if we had dist always generate docs for a release (and not have them in the repo)? Allows to share the load during releases: I generate the doc, using the generate-doc target in the doc directory, run svn commit to put them in the repository. Then Philippe runs svn update and make dist. As I said, it allows to have a separate maintenance of documentation and sources. Hehe. So Philippe's machine would choke, if it had to generate the docs, too(?) And since most(?) of the docs comes from the sources, you don't actually edit them by hand now do you? So what does maintaining mean here? It means looking at the doc, if there are no anomalies, like warnings, parsing errors of doxygen, or typos in the text. Usually takes an hour or two. I admit I am not fast, but I think it would take some time for Philippe to do that too. Okay. Although, I would be stupid enough to trust that if it generates nicely for you it does so for Philippe, too, and not take the usual metaphysical factors into account. Assuming that some coordination is done to ensure that similar configurations are used - not too hard if both use the same distro, for example. -- hl
Re: [Xenomai-core] Generated docs
Gilles Chanteperdrix kirjoitti: Having the generated documentation in svn repository also allows us to copy it to the documentation directory of the download zone from a script run by cron. Ok, this makes sense. But could be done by other means, too, I guess. Automatically ? It could result in broken documentation on the web site, which is not quite user-friendly. Well, there are always other means. I don't know doxygen specifics, so I'll just shut up here. When the generated docs grow to some few hundreds of megs, maybe I'll raise this point again. Now that you answered publically to a discussion you started privately, I guess our readers will not understand anything :-) That'll be true. Or rather, I answered publicly/privately in random fashion --- there are just too many buttons on a mail client for my intellect. -- Heikki Lindholm
[Xenomai-core] PATCH: fix ppc64 calibration
The old calibration value was from some ancient ppc32 embedded board, I guess. This reflects the awesome power of them ppc64 boxen better :) -- Heikki Lindholm diff -Nru xenomai/include/nucleus/asm-ppc64/calibration.h xenomai-dev/include/nucleus/asm-ppc64/calibration.h --- xenomai/include/nucleus/asm-ppc64/calibration.h 2005-10-11 10:30:03.0 +0300 +++ xenomai-dev/include/nucleus/asm-ppc64/calibration.h 2005-10-11 17:10:11.0 +0300 @@ -32,7 +32,7 @@ #define __sched_latency CONFIG_XENO_HW_SCHED_LATENCY #else -#define __sched_latency 18500 +#define __sched_latency 1000 #endif /* CONFIG_XENO_HW_SCHED_LATENCY */
Re: [Xenomai-core] PATCH: fix ppc64 calibration
Fillod Stephane kirjoitti: Heikki Lindholm wrote: The old calibration value was from some ancient ppc32 embedded board, I guess. This reflects the awesome power of them ppc64 boxen better :) Actually, the ppc32 calibration value was from some ancient x86 machine, Damn, that has been heretic from the processor wars POV, then! Some swift action IS necessary. I guess. The same patch could be applied to asm-ppc/calibration.h. This reflects the awesome power of them ppc32 boxen better :) Probably, but there are less than awesome 4xx boards around and I'd guess they might even be more likely targets than G4 based machines, for example. Some tuning might be needed. -- Heikki Lindholm
Re: [Xenomai-core] PATCH: fix ppc64 calibration
Fillod Stephane kirjoitti: Heikki Lindholm wrote: [..] Probably, but there are less than awesome 4xx boards around and I'd guess they might even be more likely targets than G4 based machines, for example. Some tuning might be needed. How many people are using Xenomai (or Fusion) on 4xx ? No idea here, but my understanding is that these are popular embedded processors. What are their typical sched latency ? This one I could check for a 405 box. -- Heikki Lindholm
[Xenomai-core] Linux powerpc merger
Hello, As people following powerpc kernel mailing lists probably know, the Linux ppc and ppc64 architectures are merging into a single powerpc arch. I think the same should be done to fusion. It would seem quite easy and there's already lots of redundant code there, but possible problems arise from being able to work with both the old unmerged kernels and the future merged arch kernels. Is there any ideas regarding or work being done on this front? -- Heikki Lindholm
