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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
.
-- 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
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
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
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
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
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
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
,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
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
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
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
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
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
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
of them later this week.
-- Heikki Lindholm
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
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
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
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
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
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
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
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
49 matches
Mail list logo
