On Tue, Sep 27, 2011 at 07:25:07PM +0200, Jan Kiszka wrote:
It manages buffers for you, provides NIC drivers and interfaces to
either build the higher protocol layers in the kernel or in user space.
That's the mission, but I would not exclude that there is room for
improvements (lacking safe
On Tue, Sep 27, 2011 at 10:26:51AM +0200, Jan Kiszka wrote:
On 2011-09-26 13:41, Richard Cochran wrote:
- Simple to implement new drivers.
Compare my rtpacket.h with the rtnet driver headers to see what I
mean. Or, read rtnet/Documentation/README.drvporting and ask
yourself
On Tue, Sep 27, 2011 at 02:20:43PM +0200, Jan Kiszka wrote:
On 2011-09-27 14:01, Richard Cochran wrote:
Again, every MAC driver needs to be tastefully and wisely adapted. I
don't necessarily need to avoid coalescing. The goal (for me) is *not*
to provide deterministic Ethernet performance
On Tue, Sep 27, 2011 at 05:16:09PM +0200, Jan Kiszka wrote:
On 2011-09-27 17:10, Richard Cochran wrote:
On Tue, Sep 27, 2011 at 02:20:43PM +0200, Jan Kiszka wrote:
On 2011-09-27 14:01, Richard Cochran wrote:
Again, every MAC driver needs to be tastefully and wisely adapted. I
don't
On Tue, Sep 27, 2011 at 06:30:00PM +0200, Jan Kiszka wrote:
On 2011-09-27 18:26, Jan Kiszka wrote:
I was simply hoping to collect some new ideas how to address the driver
maintenance issue in a better way but without dropping key features
needed for RT networking. Something like let's add
On Tue, Sep 27, 2011 at 06:26:44PM +0200, Jan Kiszka wrote:
On 2011-09-27 18:05, Richard Cochran wrote:
That's a common misunderstanding: RTnet is a networking stack with many
_optional_ components (like RTmac, RTcfg etc.). I would bet that it's
more frequently used today in minimal setups
On Fri, Sep 23, 2011 at 03:50:42PM +0200, Jan Kiszka wrote:
On 2011-09-23 13:02, Richard Cochran wrote:
This patch adds a class driver for raw Ethernet drivers under
Xenomai. The goal is to support industrial protocols such as EtherCAT
and IEC 61850, where the stack is a user space program
, but I put it there just to get started. It really does not fit
to any of the other drivers, so it probably would need its own place
under ksrc/drivers.
Thanks in advance for your comments,
Richard
Richard Cochran (1):
Add a class driver for raw Ethernet packets.
include/rtdm/rtpacket.h
This patch adds a class driver for sending and receiving raw Ethernet
packets over a character device interface.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
include/rtdm/rtpacket.h | 99
ksrc/drivers/testing/Kconfig |8 +
ksrc/drivers/testing/Makefile
This commit completes the support for the xenomai packet interface in
the gianfar driver.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/net/gianfar.c|4 +++
drivers/net/gianfar.h|2 +
drivers/net/gianfar_rt.c | 60
This commit adds support for the xenomai packet interface to the gianfar
driver. Only the transmit path is implemented.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/net/Makefile |5 +
drivers/net/gianfar.c| 20 +--
drivers/net/gianfar.h| 74
will not work on later
versions (like in the p1020), since Freescale keeps changing their
hardware interfaces.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/net/gianfar.c | 85 +++--
drivers/net/gianfar.h | 14 ++-
drivers/net/gianfar_ethtool.c
on other eTSEC devices due
to slight implementation differences in the hardware!
If you really want to run this code, you might also apply the
following patch.
cd0ea241 gianfar: Fix crashes on RX path
Richard Cochran (4):
gianfar: reserve the first transmit queue
gianfar: reserve
This commit adjusts the code to use the second hardware transmit queue.
The idea is to keep the first queue open for later use as a fast path
for real time Ethernet packets.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/net/gianfar.c | 11 +++
1 files changed, 7
PS Applies to Xenomai 2.5.6.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On Thu, May 12, 2011 at 02:03:34AM +0200, Gilles Chanteperdrix wrote:
the issue on ixp looks like the last one to be fixed on arm. If you have
time, could you try the following program? It makes a very basic test,
but not having a big-endian ixp at end, I am wondering about very basic
On Wed, Apr 27, 2011 at 11:53:32PM +0200, Philippe Gerum wrote:
Yes, but that can't be easily summarized here. In short, we have a
serious problem with the sharing of the MMU context between the Linux
and Xenomai schedulers in the SMP case on powerpc.
BTW, I have been running xenomai 2.5 on
On Sun, Apr 24, 2011 at 10:15:00PM +0200, Gilles Chanteperdrix wrote:
some temporary results on the benchmark here:
http://www.xenomai.org/~gch/latency-at91sam9263.png
The worst case latency seems not to vary much over time, it looks like
it is decreasing a bit, but the differences may
On Fri, Apr 22, 2011 at 07:55:35AM +0200, Gilles Chanteperdrix wrote:
I also had a look at the culprit patch, reducing it to the bare minimum
(no useless whitespace changes and no function moves), and it boils down
to only two differences:
1- the fact that we use the generic clocksource
On Sun, Apr 10, 2011 at 01:22:08PM +0200, Gilles Chanteperdrix wrote:
To help debugging this, please run the kernel which crashes with I-pipe
enabled, without Xenomai, and the attached test, in order to see if the
tsc behaves correctly.
Getting back to this, I did try the test program with
On Tue, Apr 12, 2011 at 09:17:43AM +0200, Gilles Chanteperdrix wrote:
Not only that. The aim of the test is to trigger the worst case path. I
suspect you can not trigger it with a 10 minutes tests. As you probably
remember, I was once running Xenomai on IXP465, and the latency with
Xenomai 2.4
On Tue, Apr 12, 2011 at 09:17:43AM +0200, Gilles Chanteperdrix wrote:
What compiler are you using by the way?
I compiled this one myself using crosstool-ng. At the time I had first
tried gcc 4.3, but you advised me that it would not work for xenomai.
Target: armeb-unknown-linux-gnueabi
On Sun, Apr 10, 2011 at 11:34:14AM +0200, Gilles Chanteperdrix wrote:
Richard Cochran wrote:
I will try xenomai 2.5 with ipipe 2.6.35 next...
I meant to say, Xenomai 2.4 with ipipe 2.6.35, but this does not work
because the kernel definitions have changed:
include/asm-generic/xenomai/hal.h
On Sat, Apr 09, 2011 at 09:50:16PM +0200, Gilles Chanteperdrix wrote:
Just to have an idea where the issue come from, could you try reverting
all the changes which were made on the tsc and timer? i.e. revert to the
original ipipe_mach_get_tsc and ipipe_mach_set_dec?
The exact commit
On Sun, Apr 10, 2011 at 01:22:08PM +0200, Gilles Chanteperdrix wrote:
Also, about the performances, Xenomai 2.4 did not have the Xenomai
preemptible context switches. Maybe with FCSE, it results in reduced
latencies to disable this option in Xenomai 2.5.
So, are you saying that
After fixing the ipipe big endian issue, I have run into some more
problems on my arm ixp425. Ipipe kernel 2.6.31 with xenomai 2.5.6
boots and runs fine. Ipipe kernel .33 and .35 both boot, but freeze
when xenomai is enabled.
I tried building xenomai as modules, and I found that loading
On Sat, Apr 09, 2011 at 08:41:22PM +0200, Richard Cochran wrote:
I tried disabling various CONFIG options, and I found by accident that
enabling IPIPE_DEBUG allows the system to run just fine.
Update: It is not enough for me to enable IPIPE_DEBUG. The kernels
that boot have all
On Sat, Apr 09, 2011 at 09:50:16PM +0200, Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Richard Cochran wrote:
Update: It is not enough for me to enable IPIPE_DEBUG. The kernels
that boot have all of the XENO_OPT_DEBUG options enabled.
Disabling XENO_OPT_DEBUG results
On Thu, Apr 07, 2011 at 10:26:02PM +0200, Gilles Chanteperdrix wrote:
On my side, I meant to say, the issue is in the implementation of the
I-pipe one-shot timer, the function ipipe_mach_set_dec...
I couldn't find anything wrong there, but I did find this...
In ipipe_tsc_asm.S you have
In ipipe_tsc_asm.S you have at the end of the file...
/* User-space entry-point: r0 is the hardware counter virtual address */
#ifndef CONFIG_CPU_BIG_ENDIAN
/* Little endian */
...
#else /* Big endian */
/* Little endian */
1: ldrr1, .LCdec16_last_tsc + 4
ldrip, [r0]
ldrr2,
This commit replaces the CONFIG_CPU_ENDIAN_BE8 macro with the
more general CONFIG_CPU_BIG_ENDIAN one. Also we fix a typo.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
arch/arm/kernel/ipipe_tsc_asm.S | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git
On Fri, Apr 08, 2011 at 08:16:17AM +0200, Gilles Chanteperdrix wrote:
Yes, you can try changing the #ifdef. But note also that the big endian
code was never actually tested. So, you probably would be better
compiling a little user-space application to test this tsc code.
Yes, it worked. I sent
On Fri, Apr 08, 2011 at 08:35:37AM +0200, Gilles Chanteperdrix wrote:
Ok. Thanks queued. I will also add the hostrt stuff.
BTW, patch works for both 2.6.33 and 2.6.35.
Both are booting fine, now.
Thanks,
Richard
___
Xenomai-core mailing list
On Fri, Apr 08, 2011 at 08:35:03AM +0200, Gilles Chanteperdrix wrote:
- the TSC emulation code is factored, so that when porting to a new
port, we avoid copy-pasting the TSC emulation;
The ARM porting page on the wiki is out of date with regards to this.
- it is ready for multi-SOCs kernels
On Fri, Apr 08, 2011 at 02:58:33PM +0200, Jesper Christensen wrote:
I have ported the gianfar driver from linux to rtnet.
Can you publish this driver? I have been wanting to make a rtnet
gianfar myself.
Thanks,
Richard
___
Xenomai-core mailing list
I have been trying to bring my IXP425 based system up to date, and I
have found an apparent regression. Everything worked fine with ipipe
2.6.30 and Xenomai 2.4. With 2.6.31 an ipipe kernel still boots, but
starting with 2.6.33 the trouble begins (see below).
I see that Gilles refactored the TSC
On Thu, Apr 07, 2011 at 08:32:52PM +0200, Gilles Chanteperdrix wrote:
Richard Cochran wrote:
I have been trying to bring my IXP425 based system up to date, and I
have found an apparent regression. Everything worked fine with ipipe
2.6.30 and Xenomai 2.4. With 2.6.31 an ipipe kernel still
On Thu, Apr 07, 2011 at 09:02:58PM +0200, Richard Cochran wrote:
On Thu, Apr 07, 2011 at 08:32:52PM +0200, Gilles Chanteperdrix wrote:
I think the ixp is a 32 bits free-running counter with match register,
wich is a configuration I tested. So, I would tend to think that the
issue is rather
On Thu, Feb 25, 2010 at 05:48:08PM +0100, Philippe Gerum wrote:
You are welcome. Out of curiosity, what was unclear exactly?
We just had a nice discussion regarding powerpc support in
ipipe/mainline/denx. Now it is clear to me, what your plan is!
Thanks for your efforts,
Richard
On Tue, Feb 23, 2010 at 11:07:57AM +0100, Philippe Gerum wrote:
With ipipe-2.6.33 solely tracking mainline, only the few temporary trees
with not-mainlined-yet features/support will pull from the DENX tree to
get them.
Okay, its now clear to me. Thanks for the explanation.
Richard
Philippe,
After updating my ipipe git repo, I notice that you have done
something new with ipipe-2.6.32-powerpc, back in January. Previously,
the Denx bits appeared as squashed commits. Now, the Denx commits
appear individually.
I am curious, what's up with that?
Thanks,
Richard
On Tue, Jan 12, 2010 at 05:18:02PM -0500, Lennart Sorensen wrote:
Well I have not been able to find the magic invocation that lets me take
the DENX tree (which I have had around for a long time just to look at
occationally, whenever I was trying to get an ipipe patch to apply),
apply the ipipe
Those who accord, Say Hear, Hear, +1 or Me too, depending on their
geological or social situation.
+1
Me too
Hear, Hear
(an American in Austria)
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
On Wed, Nov 04, 2009 at 11:16:21PM +0100, Philippe Gerum wrote:
Core 0 waits for core 1 to acknowledge the critical IPI, but that
lazybones prefers to sleep. Likely because it did not receive the IPI in
question, actually (it should raise a bit in __ipipe_cpu_sync_map, see
On Fri, Nov 06, 2009 at 09:26:58AM +0100, Philippe Gerum wrote:
Ouch. I just can't believe this went unnoticed for that long... Well, no
wonder why then, the critical IPI never gets registered, so never
detected by the pipeline core in __ipipe_grab_irq. Thanks for the heads
up.
This may
On Wed, Nov 04, 2009 at 10:54:24AM +0100, Philippe Gerum wrote:
The issue is more likely in the interrupt pipeline. When Xenomai is
compiled as modules, does the system lock up when loading the nucleus,
Yes.
I looked at this problem using my shiny new BDI3000.
mpcl8572select 0
Target
On Wed, Nov 04, 2009 at 12:26:45PM +0100, Philippe Gerum wrote:
Ok, this is a porting issue. The critical IPI (IPIPE_CRITICAL_IPI) does
not seem to be properly handled on this platform.
I'll try and pull this apart some more...
I was able to get SMP to boot, by accident.
Using the
On Wed, Nov 04, 2009 at 03:08:32PM +0100, Richard Cochran wrote:
On Wed, Nov 04, 2009 at 12:26:45PM +0100, Philippe Gerum wrote:
Ok, this is a porting issue. The critical IPI (IPIPE_CRITICAL_IPI) does
not seem to be properly handled on this platform.
Okay, after playing with the BDI3000
I have compiled and run ipipe-2.6.30.3-powerpc-2.7-02 and Xenomai
v2.4.9.1 (well, actually c4c3c82791951df998ac4dc463f79a76884577b6), on
two similar Freescale boards, the MPC8572DS and the P2020DS. Both are
dual core, and both run fine using vanilla Linux 2.6.30 with SMP.
If I enable ipipe only,
On Tue, Nov 03, 2009 at 03:44:24PM +0100, Philippe Gerum wrote:
On Tue, 2009-11-03 at 14:34 +0100, Richard Cochran wrote:
If I enable ipipe only, I can still boot SMP. If Xenomai is enabled,
then the machine freezes as soon as Xenomai is started. (As a module,
Xenomai locks the machine when
A certain xenomai project on ARM Linux of mine has been working fine
using gcc 3.4.5. I wanted to use a more recent compiler and the EABI,
so I used a default setting from crosstool-NG-1.4.1, which produces
gcc version 4.3.2.
However, I get the following result running the trivial-periodic
-Original Message- From: Sebastian Smolorz
Sent: Friday, September 28, 2007 6:48 PM
Nevertheless, here comes our git repository:
http://git.opensource.emlix.com
Thank you for that. I will take a look...
Still a lot of work to do but we are ready to do it and are
confident of
-Original Message- From: [EMAIL PROTECTED]
Sent: Monday, September 24, 2007 7:48 PM
So, please try to find out more details about the requirements and
limitations, let us know about them even if some realisation turns
out to be too much for a student job. Maybe other will jump on
I know that this is a bit off topic, yet perhaps some on this list
have interest or knowledge in this area. I am also posting this idea
to the linux-arm-kernel list.
I would like to implement the ARM FCSE under Linux, using the Intel
IXP425 board. Before I start, I would like to ask:
1. Has any
-Original Message- From: Gilles Chanteperdrix
*IXP4XX_OSRT1 = LATCH | ONE_SHOT_ENABLE;
In fact, should not this be:
*IXP4XX_OSRT1 =
(last_jiffy_time + LATCH - *IXP4XX_OSTS) |
ONE_SHOT_ENABLE;
Nope, we are using GP Timer 1. It counts
This patch adds Adeos support for the Intel IXP425 processor. It may
also work on the IXP465, but I only tested it on the 425. The patch
is against a vanilla 2.6.19 kernel.
Enjoy,
Richard
Richard Cochran (Mr), Software
-Original Message- From: Gilles Chanteperdrix
For reasons explained on the wiki, I would rather see
ixp4xx_timer_interrupt implemented as:
if (__ipipe_mach_timerstolen) {
/* If some other domain has taken over the timer, then
* do nothing (ipipe
57 matches
Mail list logo
