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
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 frequen
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'
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 ta
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 prov
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/Documentatio
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 &q
PS Applies to Xenomai 2.5.6.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
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
---
drivers/net/gianfar.c | 11 +++
1 files changed, 7 insertions(+), 4
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 the
not work on later
versions (like in the p1020), since Freescale keeps changing their
hardware interfaces.
Signed-off-by: Richard Cochran
---
drivers/net/gianfar.c | 85 +++--
drivers/net/gianfar.h | 14 ++-
drivers/net/gianfar_ethtool.c | 163
This commit adds support for the xenomai packet interface to the gianfar
driver. Only the transmit path is implemented.
Signed-off-by: Richard Cochran
---
drivers/net/Makefile |5 +
drivers/net/gianfar.c| 20 +--
drivers/net/gianfar.h| 74 +++
drivers/net
This commit completes the support for the xenomai packet interface in
the gianfar driver.
Signed-off-by: Richard Cochran
---
drivers/net/gianfar.c|4 +++
drivers/net/gianfar.h|2 +
drivers/net/gianfar_rt.c | 60 ++---
3 files changed, 62
the source
tree, 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/
This patch adds a class driver for sending and receiving raw Ethernet
packets over a character device interface.
Signed-off-by: Richard Cochran
---
include/rtdm/rtpacket.h | 99
ksrc/drivers/testing/Kconfig |8 +
ksrc/drivers/testing/Makefile |3 +
ksrc/drivers
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
> assum
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 ma
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 c
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
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 i
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
Configu
On Mon, Apr 11, 2011 at 11:26:33PM +0200, Gilles Chanteperdrix wrote:
> Wait a minute. You are comparing results obtained after 2 or 3, or 10
> minutes of runtime? I am not sure such results are meaningful. I do my
> benchmarks with the noltp_hell test:
> http://git.xenomai.org/?p=mkrootfs.git;a=bl
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-generi
On Mon, Apr 11, 2011 at 08:52:04AM +0200, Jesper Christensen wrote:
> I have made a number of changes to rtnet (scatter gather support, icmp
> fixes etc.) so maybe i could send you a tar ball of the entire directory?
Yes, please do.
thanks,
Richard
> On 2011-04-08 21:15, Richard Coch
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 XENO_HW_UN
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 exac
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.
> &g
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 a
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
xeno_nucle
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 li
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 kernel
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
Xenomai-
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 se
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
---
arch/arm/kernel/ipipe_tsc_asm.S | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kernel
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, .Ld
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
#
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 t
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
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, 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 Fri, Nov 06, 2009 at 10:32:00AM +0100, Philippe Gerum wrote:
> On Fri, 2009-11-06 at 10:20 +0100, Richard Cochran wrote:
> > Yes, works fine now. Thanks for your help.
I am working again on PowerPC, and I now notice that I spoke too
soon. I had fixed the problem for myself, in a diff
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 ip
> 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, Dec 02, 2009 at 02:23:39PM +0100, Gilles Chanteperdrix wrote:
> This issue has been discussed several times, but never a lot. We have a
> simple solution: starting with 2.4 (if I remember correctly) xenomai
> provides clock_settime, so you can simply rely on clock_gettime, and
> call clock_
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 ma
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
> __ipipe_do_criti
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 w
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 B
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.
mpcl8572>select 0
Target
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,
> &
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,
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
example
> -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: Sebastian Smolorz
> Sent: Wednesday, September 26, 2007 11:28 AM
>
> We consider to set up a git repository so that you and all
> interested people will be able to clone from it. If anyone feels
> prepared to contribute code to this project we either can provide
>
> -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
> -Original Message- From: Gilles Chanteperdrix >
> The feature was already dropped, it is deprecated in ARMv6.
Doesn't ARMv6 have a new cache design based on physical addresses?
I thought I saw this somewhere...
Richard
___
Xenomai-core mail
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 w
Here is the corrected patch, based on Gilles' comments.
I hope sending this as an attachment is ok. I am a former Mutt user,
now forced to use **tl**k, and I can never tell when this program
wraps the lines...
Richard
Ri
> -Original Message- From: Gilles Chanteperdrix
>
> The reason for not looping is that Adeos never looses interrupts. If
> we leave the loop and Linux gets delayed, then the lost ticks will
> be accounted for twice: one time because Xenomai will have posted
> the missed timer interrupts, o
> -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
> -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
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
> From: Gilles Chanteperdrix
> > What am I doing wrong?
>
> Maybe you only defined the open_rt callback for your driver and are
> trying to open the driver from a non realt-time thread ?
Thanks, that was it.
Richard
___
Xenomai-core mailing list
Xenom
run the 'latency'
test program.
What am I doing wrong?
I include some diagnostics, below...
Thanks,
Richard
--------
Richard Cochran (Mr), Software Development
OMICRON electronics GmbH, Oberes Ried 1, A-6833 Klaus / Au
67 matches
Mail list logo
