Hallo,
attached you will find the results of Xemonai latency measurements on
various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors,
from low to high end covering a worst case latency range from 25 to 225
us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU.
Here are
On 10/17/2005 05:42 PM Fillod Stephane wrote:
> Hi Philippe,
>
> Sorry for the late report, Xenomai appears to work fine on a Freescale
> e500
> board (MPC8541E) under Linux 2.6.13. Xenomai version was v1.9.9, ie. the
> daily
> snapshot as of today. Here are some preliminary figures (CPU 800MHz, B
On 10/18/2005 01:44 PM Philippe Gerum wrote:
> Philippe Gerum wrote:
>> Wolfgang Grandegger wrote:
>>
>>> Hallo,
>>>
>>> attached you will find the results of Xemonai latency measurements on
>>> various embedded PowerPC boards using MPC 8x
On 10/18/2005 08:14 PM Philippe Gerum wrote:
> Wolfgang Grandegger wrote:
>> On 10/18/2005 01:44 PM Philippe Gerum wrote:
>>
>>>Philippe Gerum wrote:
>>>
>>>>Wolfgang Grandegger wrote:
>>>>
>>>>
>>>>>Hal
On 10/17/2005 05:42 PM Fillod Stephane wrote:
> Hi Philippe,
>
> Sorry for the late report, Xenomai appears to work fine on a Freescale
> e500
> board (MPC8541E) under Linux 2.6.13. Xenomai version was v1.9.9, ie. the
> daily
> snapshot as of today. Here are some preliminary figures (CPU 800MHz, B
Hello,
the output of the cache calibrator indicated, that TLB misses on the MPC
860 might influence latencies substantially.
Looking closer to the Linux 2.6 kernel revealed, that TLB entries for
the kernel space (0xc000) are not pinned by default for the MPC 860
(like in 2.4). I enabled this
Philippe Gerum wrote:
Hannes Mayer wrote:
Ciao Philippe!
prepare-kernel.sh works well - I'd suggest to ask the user for
the 3 needed parameters, instead of supplying them as parameters.
e.g.
# scripts/prepare-kernel.sh
Linux directory: [default: /usr/src/linux] :
Adeos-patch: [default: none] :
Hannes Mayer wrote:
Wolfgang Grandegger wrote:
[...]
I have realized the same error building out of the source tree for
PowerPC. The problem is, that the link is pointing to itself. Apart
from that, the ksrc part works fine (at least I can boot the ipipe
kernel).
If I remove the sym-link
Philippe Gerum wrote:
Here is an update regarding the way things progress on the v2.1 branch:
o The build system has been deeply revamped, so that we now fully leave
the burden of building Xenomai's kernel support to Linux. To this end,
the code tree has been reorganized in two major sections
Hallo,
when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I
stumbeld over the following problem:
In "linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h" there is
defined:
#define ulong "i"
#define uint "i"
This makes trouble when a driver uses the types uint
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > Likely not this time (keep it cold anyway, who knows); I
strongly suspect a bug in > > > xnarch_switch_to() for all archs but
x86
> > > >
Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S have
broken the build of Xenomai with linuxppc_2_4_devel on PPC:
#include does not exist
Symbols like SAVE_NVGPRS do not exist
For the time being, I will stick with an older version for testing RTnet
(where I'm
Philippe Gerum wrote:
Wolfgang Grandegger wrote:
Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S have
broken the build of Xenomai with linuxppc_2_4_devel on PPC:
#include does not exist
Symbols like SAVE_NVGPRS do not exist
Fixed.
Thanks. Attached is
Philippe Gerum wrote:
Wolfgang Grandegger wrote:
Philippe Gerum wrote:
Wolfgang Grandegger wrote:
Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S
have broken the build of Xenomai with linuxppc_2_4_devel on PPC:
#include does not exist
Symbols like
Wolfgang Denk wrote:
Dear Philippe,
in message <[EMAIL PROTECTED]> you wrote:
We try to find a way to wrap class_device_create properly depending on the kernel
version Xeno is compiled against. The parent device class argument in this call
(2nd in order) seems to show up in 2.6.15 for kernel.
Hello,
attached you will find the results of my todays Xenomai latency
measurements on various PowerPC boards with Linux 2.4 and 2.6.
Wolfgang.
New latency tests with Xenomai on various PowerPC boards
Board : Processor CPU-Clk Bus-Cl
Hello,
with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai
does not distinguish between a normal IRQ enable and an IRQ unmask at
the end of an ISR (to reenable the IRQ). In the latter case the IRQ
should be enabled on PowerPC as shown:
if (rthal_irq_descp(irq)->handle
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Hello,
>
> with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai
> does not distinguish between a normal IRQ enable and an IRQ unmask at
> the end of an ISR (to reenable the IRQ). In the latt
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Therefore we need a dedicated function to re-enable interrupts in the
> ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more
> obvious. On non-PPC archs it would translate to *_irq_enable. I
> re
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Therefore we need a dedicated function to re-enable interrupts in the
> ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more
> obvious. On non-PPC archs it would translate to *_irq_enable. I
> re
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>
> Philippe Gerum wrote:
> > Gilles Chanteperdrix wrote:
> >> Wolfgang Grandegger wrote:
> >> > Therefore we need a dedicated function to re-enable interrupts in
> >> the
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>
> Philippe Gerum wrote:
> > Jan Kiszka wrote:
> >> Wolfgang Grandegger wrote:
> >>
> >>>> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> >>>>
> &g
Hello,
Dmitry Adamushko wrote:
Hi,
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA ->
XN_ISR_EDGE), a few cleanups and updated comments.
Functionally, the support for shared interrupts (a few flags) to the
rtd
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
Dmitry Adamushko wrote:
Hi,
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA ->
XN_ISR_EDGE), a few cleanups and updated comments.
Functionally, the supp
Hello,
Dmitry Adamushko wrote:
Hi,
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA ->
XN_ISR_EDGE), a few cleanups and updated comments.
Functionally, the support for shared interrupts (a few flags) to the
rtd
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
Dmitry Adamushko wrote:
Hi,
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA ->
XN_ISR_EDGE), a few cleanups and updated comments.
Functionally, the supp
Hallo,
when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I
stumbeld over the following problem:
In "linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h" there is
defined:
#define ulong "i"
#define uint "i"
This makes trouble when a driver uses the types uint
Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S have
broken the build of Xenomai with linuxppc_2_4_devel on PPC:
#include does not exist
Symbols like SAVE_NVGPRS do not exist
For the time being, I will stick with an older version for testing RTnet
(where I'm
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > Likely not this time (keep it cold anyway, who knows); I
strongly suspect a bug in > > > xnarch_switch_to() for all archs but
x86
> > > >
Philippe Gerum wrote:
Wolfgang Grandegger wrote:
Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S have
broken the build of Xenomai with linuxppc_2_4_devel on PPC:
#include does not exist
Symbols like SAVE_NVGPRS do not exist
Fixed.
Thanks. Attached is
Philippe Gerum wrote:
Wolfgang Grandegger wrote:
Philippe Gerum wrote:
Wolfgang Grandegger wrote:
Hi Philippe,
I just realized that recent changes in ksrc/arch/powerpc/switch.S
have broken the build of Xenomai with linuxppc_2_4_devel on PPC:
#include does not exist
Symbols like
Wolfgang Denk wrote:
Dear Philippe,
in message <[EMAIL PROTECTED]> you wrote:
We try to find a way to wrap class_device_create properly depending on the kernel
version Xeno is compiled against. The parent device class argument in this call
(2nd in order) seems to show up in 2.6.15 for kernel.
Hello,
attached you will find the results of my todays Xenomai latency
measurements on various PowerPC boards with Linux 2.4 and 2.6.
Wolfgang.
New latency tests with Xenomai on various PowerPC boards
Board : Processor CPU-Clk Bus-Cl
Hello,
with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai
does not distinguish between a normal IRQ enable and an IRQ unmask at
the end of an ISR (to reenable the IRQ). In the latter case the IRQ
should be enabled on PowerPC as shown:
if (rthal_irq_descp(irq)->handle
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Hello,
>
> with RTnet over Xenomai and Linux 2.4 on PowerPC I realized that Xenomai
> does not distinguish between a normal IRQ enable and an IRQ unmask at
> the end of an ISR (to reenable the IRQ). In the latt
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Therefore we need a dedicated function to re-enable interrupts in the
> ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more
> obvious. On non-PPC archs it would translate to *_irq_enable. I
> re
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Therefore we need a dedicated function to re-enable interrupts in the
> ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more
> obvious. On non-PPC archs it would translate to *_irq_enable. I
> re
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>
> Philippe Gerum wrote:
> > Gilles Chanteperdrix wrote:
> >> Wolfgang Grandegger wrote:
> >> > Therefore we need a dedicated function to re-enable interrupts in
> >> the
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>
> Philippe Gerum wrote:
> > Jan Kiszka wrote:
> >> Wolfgang Grandegger wrote:
> >>
> >>>> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> >>>>
> &g
Philippe Gerum wrote:
Hannes Mayer wrote:
Ciao Philippe!
prepare-kernel.sh works well - I'd suggest to ask the user for
the 3 needed parameters, instead of supplying them as parameters.
e.g.
# scripts/prepare-kernel.sh
Linux directory: [default: /usr/src/linux] :
Adeos-patch: [default: none] :
Hannes Mayer wrote:
Wolfgang Grandegger wrote:
[...]
I have realized the same error building out of the source tree for
PowerPC. The problem is, that the link is pointing to itself. Apart
from that, the ksrc part works fine (at least I can boot the ipipe
kernel).
If I remove the sym-link
Philippe Gerum wrote:
Here is an update regarding the way things progress on the v2.1 branch:
o The build system has been deeply revamped, so that we now fully leave
the burden of building Xenomai's kernel support to Linux. To this end,
the code tree has been reorganized in two major sections
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 usin
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 usin
On 10/12/2005 02:51 PM Heikki Lindholm wrote:
> 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&#x
On 10/12/2005 03:16 PM Fillod Stephane wrote:
> Wolfgang Grandegger wrote:
>>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
>>>> gu
On 10/12/2005 04:39 PM Philippe Gerum wrote:
> Wolfgang Grandegger wrote:
>> 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
&
On 10/13/2005 11:11 AM Philippe Gerum wrote:
> Wolfgang Grandegger wrote:
>> On 10/12/2005 04:39 PM Philippe Gerum wrote:
>>
>>>Wolfgang Grandegger wrote:
>>>
>>>>We have linux-2.4.14-rc3 running on all AMCC eval boards (see
>>>>htt
On 10/13/2005 03:33 PM Philippe Gerum wrote:
> Paul wrote:
>> Hi Philippe
>>
>> On Thursday 13 October 2005 09:24, Philippe Gerum wrote:
>>
>>>- Regular automated benchmarking: What is Xenomai currently capable of, how
>>>stable is it, do we progress or regress over time and releases, arch by
>>>
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
"#i
On 10/15/2005 09:17 PM Heikki Lindholm wrote:
> 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
Hallo,
attached you will find the results of Xemonai latency measurements on
various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors,
from low to high end covering a worst case latency range from 25 to 225
us. It also includes a comparison with RTAI 3.0r5 on the slowest CPU.
Here are
On 10/17/2005 05:42 PM Fillod Stephane wrote:
> Hi Philippe,
>
> Sorry for the late report, Xenomai appears to work fine on a Freescale
> e500
> board (MPC8541E) under Linux 2.6.13. Xenomai version was v1.9.9, ie. the
> daily
> snapshot as of today. Here are some preliminary figures (CPU 800MHz, B
On 10/18/2005 01:44 PM Philippe Gerum wrote:
> Philippe Gerum wrote:
>> Wolfgang Grandegger wrote:
>>
>>> Hallo,
>>>
>>> attached you will find the results of Xemonai latency measurements on
>>> various embedded PowerPC boards using MPC 8x
On 10/18/2005 08:14 PM Philippe Gerum wrote:
> Wolfgang Grandegger wrote:
>> On 10/18/2005 01:44 PM Philippe Gerum wrote:
>>
>>>Philippe Gerum wrote:
>>>
>>>>Wolfgang Grandegger wrote:
>>>>
>>>>
>>>>>Hal
On 10/17/2005 05:42 PM Fillod Stephane wrote:
> Hi Philippe,
>
> Sorry for the late report, Xenomai appears to work fine on a Freescale
> e500
> board (MPC8541E) under Linux 2.6.13. Xenomai version was v1.9.9, ie. the
> daily
> snapshot as of today. Here are some preliminary figures (CPU 800MHz, B
Hello,
the output of the cache calibrator indicated, that TLB misses on the MPC
860 might influence latencies substantially.
Looking closer to the Linux 2.6 kernel revealed, that TLB entries for
the kernel space (0xc000) are not pinned by default for the MPC 860
(like in 2.4). I enabled this
Hello,
The new testsuite program cyclictest.c breaks compilation of Xenomai on
Linux 2.4 because SIGEV_THREAD_ID does not exist. Is it only suitable
for Linux 2.6 (with NTPL threads)?
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
htt
Jan Kiszka wrote:
Niklaus Giger wrote:
Am Samstag, 8. April 2006 10:44 schrieb Jan Kiszka:
Niklaus Giger wrote:
Hi everybody
<..>
This is a really great idea! Of course, I already have another test
candidate in mind: RTnet 8). Specifically the PPC environment would be
interesting, as our "bu
Niklaus Giger wrote:
Hi
I was busy improving the buildbot setup and achieved the following:
- added build slave for simulator
- added a buildbot for a TQM860L with Denx PPC 2.4 kernel. Cannot yet build
the RTnet code.
- patched buildbot to show names for shell build steps instead of the comman
Hello,
I just checked out Xenomai and realized the UVM build error below (while
building for PPC 405 with IPIPE tracer). "xnlock_put/get" seems not to
be dummy without SMP.
Wolfgang.
if ppc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I../../../../src/include -O2
-D_GNU_SOURCE -D_REENTRANT -D__XEN
Philippe Gerum wrote:
As promised, the I-pipe tracer has been ported to ppc. People working on
this architecture are invited to give it a try, it's a great tool to
find out where the cycles are actually going.
Just apply the tracer patch on top of the Adeos patch bearing the same
revision n
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Philippe Gerum wrote:
As promised, the I-pipe tracer has been ported to ppc. People working
on this architecture are invited to give it a try, it's a great tool
to find out where the cycles are actually going.
Just apply the tracer patch on t
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
[Daniel, I put you in the CC as you showed some interest in this topic.]
as I indicated a some weeks ago, I had a closer look at the code the
user space libs currently produce (on x86). The following considerations
are certainly not worth noticeable
Hello,
I propose to add the following commonly used RTDM inline functions to
rtdm_driver.h:
static inline int rtdm_safe_copy_from_user()
static inline int rtdm_safe_copy_to_user()
The attached patch also fixes a bug in rtdm_strncpy_from_user(). I think
__xn_access_ok() returns a non-zero
Hello,
I'm currently implementing a RTDM real-time CAN driver, which raises the
the problem of adding the driver to the Xenomai source tree. My first
idea was to provide RTCAN as a patch for Xenomai:
$ cd xenomai
$ patch -p1 < xenomai-rtcan-add-on.patch
$ scripts/prepare_kernel ...
..
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
I'm currently implementing a RTDM real-time CAN driver, which raises the
the problem of adding the driver to the Xenomai source tree. My first
idea was to provide RTCAN as a patch for Xenomai:
So you prefer to maintain RTCAN out-of-tr
Hello,
what is "prepare_kernel --output-patch" useful for?
Thanks.
Wolfgang.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Romain Lenglet wrote:
Wolfgang Grandegger wrote:
what is "prepare_kernel --output-patch" useful for?
It modifies the behavior of prepare_kernel, so that it does not
modify the kernel source tree (except that it must apply the
Adeos patch), but instead generates a patch file th
Hello,
with todays SVN version of Xenomai, the testsuite program
switchtest/switch.c does not compile because cpu_set_t and friends
(CPU_SET, ...) are not undefined. I'm using kernel version 2.4.25.
Any idea what goes wrong. I haven't found where cpu_set_t is declared,
not even in Linux 2.4.
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
with todays SVN version of Xenomai, the testsuite program
switchtest/switch.c does not compile because cpu_set_t and friends
(CPU_SET, ...) are not undefined. I'm using kernel version 2.4.25.
Any idea what goes wrong. I haven't f
ts to the Xenomai mailing
list "xenomai-help@gna.org".
Please report CAN related bugs and comments to the "Socketcan" mailing
list ([EMAIL PROTECTED]) or directly to the main authors
Wolfgang Grandegger ([EMAIL PROTECTED]) or Sebastian Smolorz
([EMAIL PROTECTED]).
Credits:
---
Bernhard Walle wrote:
Hi Wolfgang,
Wolfgang Grandegger <[EMAIL PROTECTED]> [2006-08-01]:
at "ftp://ftp.denx.de/pub/xenomai/rtcan"; you can find a first version of
RTCAN, an Open Source hard real-time protocol stack for CAN devices
based on BSD sockets. It is based on the SJA1
Jan Kiszka wrote:
Hi,
instead of replying directly to Wolfgang's announcement of their great
CAN stack I take the chance to start a generic thread on the future of
RTDM drivers *within* Xenomai.
If you look at the real-time Linux scene now and in the past, you may
find it fairly scattered. Spec
Philippe Gerum wrote:
Hi Wolfgang,
First of all, thx for the CAN stack. Great job.
On Thu, 2006-08-03 at 09:58 +0200, Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Now I would suggest to look at RTCAN (or what it will be called in the
end) and to discuss on this first concrete example how
Jan Kiszka wrote:
Hi Wolfgang,
Wolfgang Grandegger wrote:
Hello,
at "ftp://ftp.denx.de/pub/xenomai/rtcan"; you can find a first version of
RTCAN, an Open Source hard real-time protocol stack for CAN devices
based on BSD sockets. It is based on the SJA1000 socket-based CAN driver
f
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi Wolfgang,
Wolfgang Grandegger wrote:
Hello,
at "ftp://ftp.denx.de/pub/xenomai/rtcan"; you can find a first version of
RTCAN, an Open Source hard real-time protocol stack for CAN devices
based on BSD sockets. It i
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
- Well known issue: the RTCAN name. This should definitely get resolved
before we merge. Any feedback already?
I contacted the author. If I will not get an answer soon, I tend
changing the global name to RT-Socket-CAN (rtsocketcan).
I would really
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
- Well known issue: the RTCAN name. This should definitely get resolved
before we merge. Any feedback already?
I contacted the author. If I will not get an answer soon, I tend
changing the global name to RT-Socket-CAN (rtsocketcan).
I would really
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
- Well known issue: the RTCAN name. This should definitely get
resolved
before we merge. Any feedback already?
I contacted the author. If I will not get an
Harkema, G.A. wrote:
Hello,
We are glad to present our new realtime USB stack based on Xenomai
2.2.0. You can find it at https://gna.org/projects/usb20rt/ as a
downloadable file and svn.
It is not bug free, but it’s a start. Please try the core and feel free
to make comments.
Cools, th
Hi Jan,
Jan Kiszka wrote:
Hi all,
I just hit enter, and all the nice CAN code is now in SVN head. We only
need a check-in of a bootstrap run with the fitting autotool versions.
Philippe, could you do this? [Meanwhile, one can also run it locally
after checking out from SVN.]
Great. I gave it
-08-23 Wolfgang Grandegger <[EMAIL PROTECTED]>
+
+ * ksrc/drivers/can/rtcan_dev.c, ksrc/drivers/can/rtcan_dev.h,
+ ksrc/drivers/can/rtcan_modules.c: Suppress handling of refcount
+ if module support is not enabled or modules cannot be unloaded.
+
+ * ksrc/drivers/can/mscan/rtcan_mscan.c,
Hi Jan,
Jan Kiszka wrote:
For review:
Here comes a tiny but fairly useful new CAN driver: a virtual CAN bus
consisting of 2..n devices (see module parameter). Transmission takes
places from the sender to all other devices on the bus, just like in
real life.
This driver was already helpful for
Hi Jan,
Jan Kiszka wrote:
For review:
This patch folds the rt-threads of rtcanrecv/send into the main thread,
assigns unique thread names, and lowers the priorities to some less
critical level. Furthermore, rtcanrecv is enhanced by a printout of the
CAN device and support for listening on all i
-09-03 10:14:22.0 +0200
+++ xenomai/ChangeLog 2006-09-03 14:43:39.0 +0200
@@ -1,3 +1,8 @@
+2006-09-03 Wolfgang Grandegger <[EMAIL PROTECTED]>
+
+ * ksrc/drivers/can/rtcan_dev.c (rtcan_dev_register): Bug fixed
+ when maximum number of devices is exeeded.
+
2006-08-31
Jan Kiszka wrote:
Hi Wolfgang,
in the process of preparing to merge rtdm_irq_enable into
rtdm_irq_request I would like to check if the attached patch is ok, thus
we could finally drop rtdm_irq_enable once the API is refactored. Please
check carefully when the first IRQs may happen and what the h
Jan Kiszka wrote:
Hi Wolfgang,
as one result of a hacking session on a PPC405 with SJA1000 on board I
applied two minor fixes to rtcan_isa.c to SVN, see end of mail for
reference. The first one gave an "interesting" effect on big-endian
because irq is an integer, the second one reveals that we s
Hi Matthias,
Matthias Fuchs wrote:
Hi Wolfgang,
Wolfgang Grandegger wrote:
You have to define the real CAN system clock, which is 16/2 = 8 Mhz for
most SJA 1000 hardware even if the oscillator is running at 16 MHz. I
will add some reasonable note to rtcan_dev.h
Is there any special reason for
Wolfgang Grandegger wrote:
Hi Matthias,
Matthias Fuchs wrote:
Hi Wolfgang,
Wolfgang Grandegger wrote:
You have to define the real CAN system clock, which is 16/2 = 8 Mhz for
most SJA 1000 hardware even if the oscillator is running at 16 MHz. I
will add some reasonable note to rtcan_dev.h
Is
Hi Matthias,
Matthias Fuchs wrote:
Hi,
I was trying to use some external hardware interupts on a PPC405 board
as part of a hacking session with Jan to bring up the rtcan driver on
this board.
Here are some versions:
Linux Kernel: 2.6.14
Adeos: 1.3-07
Xenomai: from svn
Matthias Fuchs wrote:
On Sunday 10 September 2006 13:02, Wolfgang Grandegger wrote:
Hi Matthias,
Matthias Fuchs wrote:
Hi,
I was trying to use some external hardware interupts on a PPC405 board
as part of a hacking session with Jan to bring up the rtcan driver on
this board.
Could you
Matthias Fuchs wrote:
Hello Philippe,
that helps. I will do some further testing.
Matthias
On Monday 11 September 2006 12:20, Philippe Gerum wrote:
It's likely an Adeos issue. Could you try this patch? TIA,
--- arch/ppc/syslib/ppc4xx_pic.c~ 2005-10-28 02:02:08.0 +0200
+++ arch
Philippe Gerum wrote:
On Mon, 2006-09-11 at 16:22 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2006-09-11 at 14:20 +0200, Wolfgang Grandegger wrote:
Matthias Fuchs wrote:
Hello Philippe,
that helps. I will do some further testing.
Matthias
On Monday 11 September 2006 12:20
Matthias Fuchs wrote:
On Monday 11 September 2006 17:46, Wolfgang Grandegger wrote:
A possible explanation is that configurations only using the timer IRQ
are not affected, since the decrementer is not subject to this issue
(the tick handler returns XN_ISR_NOENABLE anyway).
I run RT-Socket-CAN
Matthias Fuchs wrote:
On Monday 11 September 2006 20:13, Wolfgang Grandegger wrote:
In 2.6 the interrupts are disabled by default. Then the attached patch
for Xenomai should help.
Wolfgang.
Your patch also works fine. Now what's the recommended solution? I noticed
that Philippe al
ry mapped SJA1000 CAN controller
+ * This code has been tested on esd's CPCI405/EPPC405 PPC405 systems.
+ *
+ * This driver is derived from the rtcan-isa driver by
+ * Wolfgang Grandegger and Sebastian Smolorz.
+ *
+ * Copyright (C) 2006 Wolfgang Grandegger <[EMAIL PROTECTED]>
+ * Co
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Matthias,
Matthias Fuchs wrote:
Hi,
attached you will find a patch that adds support for memory mapped
SJA1000 CAN controllers as they often can be found on embedded boards.
The driver is based on the rtmen_isa driver.
What about using
Matthias Fuchs wrote:
Hi Wolfgang,
On Tuesday 12 September 2006 14:22, Wolfgang Grandegger wrote:
What about using request_mem_region()? While looking to the driver I now
... will be added, of course.
realize, that it's mainly duplicated code. Does it not make more sense
to make a com
Matthias Fuchs wrote:
Hi Jan,
I think there's is little typo in rtcan_dev.h:
Index: rtcan_dev.h
===
--- rtcan_dev.h (revision 1564)
+++ rtcan_dev.h (working copy)
@@ -45,7 +45,7 @@
/* Suppress handling of refcount if module supp
1 - 100 of 346 matches
Mail list logo
