Re: [Xenomai] Gilles Chanteperdrix, 1975-2016
I had the privilege to work with Gilles on a paper for the first (and only?) xenomai users meeting in Dresden in 2009. Our topic was the fast context switch extension (FCSE) for armv5 machines. Gilles made the FCSE actually work and creatively expanded the idea in a useful way. I was able to meet him in person in Dresden on that occasion, and I will remember him as a true gentleman with a good sense of humor. We are thankful for Gilles' many contributions and remember his kindness to those wanting to learn more about real time systems. Rest in Peace! Richard ___ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
[Xenomai] rtdm on mercury
Hallo list, I have been just getting to know xenomai-3 after a long time of xenomai abstinence. IIRC, there has been some talk in the past of supporting rtdm in mercury for both user space and drivers. But looking at the present state, I don't see any sign of this having been implemented. Am I missing something? [ background: wanting to write a driver for custom FPGA based hardware device, and the driver should work with and without cobalt. I have done this before by making the driver code portable to both normal kernel and rtdm. It would be nice to be able to write a pure rtdm driver and have it "just work" in a plain kernel. ] Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] RTnet in Xenomai 3, status and future
On Fri, Nov 21, 2014 at 10:48:39PM +0100, Gilles Chanteperdrix wrote: > On Fri, Nov 21, 2014 at 10:53:05AM +0100, Richard Cochran wrote: > > This is the reason that, every time I considered using rtnet, I ended > > up deciding against it. > > Well, on the other hand, picking one driver, and improving it for > the project which needs it was not an insurmountable task. Except when you have a napi driver. Then, although not insurmountable, it still is a formidable task. (But that is changing, now ;) > > this work is *long* overdue! > > Well, for it to be overdue, it would have to have been due in the > first place. And since as far as I know, nobody paid for it and was > expecting a result, and nobody ever promised anything (well up to > now, I kind of made the promise, now), I do not really think it was > due. Or maybe I am just misinterpreting the meaning of overdue. I did mean that you or anyone else owed anyone anything. I only meant to say that it was unfortunate that rtnet has stagnated, especially considering the wide industry interest in real time Ethernet. And for paying the bill, no one wants to pay for preempt_rt either! > Maybe the next step will be to integrate the support for PTP. In > that case, I hope we will get your help to do the job. Happy to help, if I can. If the drivers can stay close to mainline, then probably there isn't too much to do. The ptp stack itself does not need real time guarantees in order to operate. The one thing I can think of that might be needed is synchronization from the MAC clock to the xenomai system clock. Also, regarding rtnet, the i210 is an inexpensive card that allows transmission scheduling at given time. That might be something to take advantage of. Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] RTnet in Xenomai 3, status and future
Hi Gilles, On Fri, Nov 21, 2014 at 10:08:57AM +0100, Gilles Chanteperdrix wrote: > The drivers, on the other hand, are a bit more worrying. They are > based on seriously outdated versions of the corresponding Linux > drivers, with support for much less hardware, and probably missing > some bug fixes. So, putting the drivers into a better shape and > making it easy to track mainline changes will be my first priority. This is the reason that, every time I considered using rtnet, I ended up deciding against it. > Please feel free to send any reaction to this mail. Good luck, this work is *long* overdue! Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family
On Fri, Oct 10, 2014 at 05:10:37PM +0200, Gilles Chanteperdrix wrote: > Well, if it is someone's (other than Linus') tree, it is not mainline :-) Just to be clear: I think most everything has gone main line. But if anything is missing, check Uwe's tree. Also, you still need a simple boot loader and user land, so try this: http://git-public.pengutronix.de/?p=OSELAS.BSP-EnergyMicro-Gecko.git;a=summary Anyhow, about Cortex-R, I can offer this: 1. Cortex-M is now working in main line for efm32. 2. No one is interested in Linux Cortex-M (seems to me) 3. Cortex-R is not supported in any Linux at all (AFAICT) Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family
On Thu, Oct 02, 2014 at 04:48:16PM +0200, Gilles Chanteperdrix wrote: > On 10/02/2014 04:28 PM, mobin Motallebizadeh wrote: > > Hi > > can I build xenomai for armv7-r architecture? > > I can't see this mentioned anywhere (surprisingly!) > > Is it same as other MMU-less archs(nios II ,e.g.)? > > The first question to ask is: do you have a Linux kernel for this > processor? because Xenomai needs Linux to run. There is some main line support for Cortex-M3, for the Energy Micro development kit. See Uwe Kleine-König's tree at http://git.pengutronix.de/?p=ukl/linux.git I have never heard of Linux running on a Cortex-R at all. HTH, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] [Linuxptp-users] offset explosion and irregular phc offsets
(Adding xenomai onto CC) On Mon, Aug 12, 2013 at 11:26:33AM +0100, Julien Houles wrote: > Dear Richard, > > Thank you very much for your answer ! > > > > Xenomai is great technology, but using it will introduce a *third* > > clock into every host: the PHC, the Linux system clock, and the > > Xenomai system clock. Probably you will want to directly synchronize > > the Xenomai time with the PHC (= development effort). > > I thought that the CLOCK_REALTIME argument you use with the > clock_gettime function in phc2sys was pointing to the nucleus system > clock thanks to the XenomaiPosix skin, Are you compiling phc2sys with the posix skin? That won't work, because then: clock_gettime(CLOCK_REALTIME) - xenomai clock clock_adjtime(CLOCK_REALTIME) - linux clock This might explain the strange jumps that you are seeing. > it's the same clock I use when I poll with the rtdm_clock_read > function in my driver to send packets at the right time. Xenomai recently added a read-only CLOCK_HOST_REALTIME for getting the Linux system time in a Xenomai program. Remember that Xenomai CLOCK_REALTIME and Linux CLOCK_REALTIME are separate clocks. > > It sounds like you are using Xenomai for real time Ethernet packet > > scheduling. An alternative solution would be to use the Intel i210 > > PCIe card. It is not expensive, and it has a special feature, namely > > real time transmission scheduling (but you would have to write a > > driver for this yourself). You can synchronize the i210 using PTP and > > then transmit during a globally synchronized time slot. > > Yes, an Intel engineer informed me about this new chip. But I > couldn't find any cheap motherboard proposing several ethernet ports > with i210 (I need at least 150 ports at a very low price !). And I > don't want to introduce additionnal traffic to the ports I use for > data transfer, I would like to reproduce the exact traffic the > camera would generate. It's very difficult to find out documentation > about AVB, therefore I didn't really understand how it works. You can download the AVB standard for free from the IEEE website. > > This chain will not work very well. The multi-port nodes (like board 2) > > do not have their port clocks synchronized. I guess that using phc2sys > > to synchronize them with introduce several hundred nanoseconds time > > error per node. For good chaining performance, you really want to have > > the PHC clocks synchronized in hardware. > > Thank you for this information. But it seems to work with the three > boards I have (am I mistaken ?). The offsets I get with phc2sys > applied to the 2 ports clocks are very low ~ a few tens nanoseconds > and it's the same for the ptp clock of board 3 (event better if I > increase the pch2sys frequency on board 2). But It probably won't be > the same with 50 boards... This is only the apparent offset within the ptp4l program. The actual offset is unknown to the program, but you can measure it using a PPS, for example (but your hardware doesn't have this). > > You might be able to break your network into ten chains of five, > > connected by a 16 port transparent switch, for example. > > Yes. > > > Have you looked at the white rabbit project? > > Yes. White Rabbit is a competitor for the inter-telescopes > synchronization in my project. But as I need a low cost architecture > for a simulator which will have a short living time, I can't use > White Rabbit. > > > > > Could we use a mechanism built on a ethernet hub or switch (regular > > > switch, > > > not a IEEE1588 one because too expensive)? We’ll only use these links for > > > a synchronization purpose. Can we expect a constant delay with a store and > > > forward switch? Or should we use a hub? > > > You can try a normal switch, but they will introduce variable packet > > delays. I have read about using a managed switch with prioritized PTP > > queues instead of a PTP switch. However, I expect that you will need > > special PTP hardware in order to meet your requirements. > > In my idea, I would like to use an ethernet HUB (not a switch). As > the delay between master and slaves will remain constant, in a first > phase I would evaluate it for each port and memorize it. In a second > phase, as the communication would only go from the master to the > slaves, the master would only send Sync and follow up messages. It > would be easy to synchronize the slaves (no other data transmission > on the synchronization links) to the master. Do you think it's > possible (modifying code doesn't frighten me) ? Sounds like it is worth a try. > And I still have the two problems I talked about in my last message : > > - after a certain amount of time, the offset I get with ptp4l or > phc2sys (in a regular use of them with only two boards) increases > suddenly to very high values (tipically 69950604426874) > - when I start to use phc2sys with a new board (just to synchronize > the CLOCK_REATIME to a ptp clock), offsets have an order of
Re: [Xenomai] About the timer interrupt in beaglebone
On Fri, Jan 04, 2013 at 03:16:12PM +0100, Gilles Chanteperdrix wrote: > > https://lkml.org/lkml/2011/2/3/43 Also, that patch says "RFC". After getting no feedback, I would have resubmitted a "bugfix" or something more assertive in the subject line. Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
On Fri, Jan 04, 2013 at 03:16:12PM +0100, Gilles Chanteperdrix wrote: > On 01/04/2013 11:04 AM, Richard Cochran wrote: > > FCSE is a special, esoteric case I think. New drivers are not so hard > > to get merged, but you are right about the iterations. > > Is it? Still working on that consumer device I have another example of > patch that never made it to mainline. Maybe simply different communities > have different goals? > > http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-January/021885.html > > https://lkml.org/lkml/2011/2/3/43 Looks like this patch didn't go to the arm list, the arm maintainer, or the soc mainainter, and it probably should have. In any case, if a patch gets ignored, then it is okay to nag* the gate keepers until they respond. The squeaky wheel gets the grease, you know. I was able to push the beaglebone to the present (v3.8-rc2) state of actually booting with Ethernet working only by kicking and screaming on the arm list. The real problem there is the TI people who are posting the the lists, but fail to follow through, saying things like "it is already working" (but only with their out of tree patches) and "we submitted a patch that will appear soon" (but the patch is only on some omap list an not in maintainer tree) and "yes, we got driver merged into the tree, but it is not our fault that it doesn't actually work." The TI people are clearly focused on their arago-whatever trees, and they are not gettings things done for mainline. That is the whole problem. Thanks, Richard * Post to the arm list. That is the one that counts. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
On Fri, Jan 04, 2013 at 10:50:07AM +0100, Gilles Chanteperdrix wrote: > > Well, at some point you can still decide to abandon the vendor driver > and start from scratch. Well, yes, you will probably only do this when you have to. And then you will cry a tear for your wasted efforts :,( > Thanks to the stable kernel releases, a kernel still gets updates for > security fixes. But not for TI's out of tree bugs. > A product I have worked on around three years ago used > the 2.6.32 kernel from the "arago" tree, this looks old, but on the > other hand, the debian stable distribution default kernel running on the > xenomai.org server is also based on the 2.6.32 kernel. But does debian have as many custom patches as TI? I would guess not. > I agree with that too, and I would like to help mainline the support for > the TI processors I am using at work, but the fact is that at work, I do > not really have time to do it, because the drivers for the TI processor > I am working with (the TI processors for video encoding, ex-DaVinci > family) represent big masses of code, and getting code into mainline > means many iterations, especially for someone who does not do it often, > and at home, well, most of the time I devote to free-software > contributions is devoted to the xenomai project. Maybe I was discouraged > by the attempt of contributing the FCSE patch too. FCSE is a special, esoteric case I think. New drivers are not so hard to get merged, but you are right about the iterations. > The effort should come from TI, because if the support for new > processors directly lands into mainline, we will no longer have to > choose between the vendor kernel and the mainline kernel. I guess that > is the point of having created Linaro. Yep, but TI is only willing to spend so much effort. It is frustrating to watch how they and other vendors go about their Linux support. Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
On Thu, Jan 03, 2013 at 09:19:37PM +0100, Gilles Chanteperdrix wrote: > Of course some of the code they contain is not really acceptable in > mainline, but at least it is there and takes less time to debug than it > would if starting from scratch. That it takes "less time" is only sometimes true. > Just trying to give a different opinion from Richard. I actually agree with you, Gilles. If you are developing a consumer device - with a three year product lifetime - that will never receive a firmware upgrade - where time to market is most important then the TI kernel is the best choice. But if you want to build, let's say, a platform for a family of products with a five to ten year scope, then maybe using TI's heavily modified v3.2 kernel is not best way. In any case, what is clearly best for the community is having mainline support. I myself am interested in and am willing to help out with xenomai on the beaglebone, but I will not waste my time with the TI kernel. It is just too far away for me. Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
On Thu, Jan 03, 2013 at 10:18:15AM +0100, Michael Haberler wrote: > > fine, but my requirement is a working Xenomai kernel with - in the minimum - > GPIO, PRU, PWM, cape support, and I dont see that combination of Xenomai and > v.3.8 around the corner anyday soon > > what would you then suggest as an alternative base for getting Xenomai to run > on the beaglebone with the above laundry list? I guess that the best way forward would be: 1. Try vanilla v3.8 and see if the drivers you need are working. 2. If so, then help to update the arm ipipe patch to v3.8. But of course, it depends on how much time and effort you are willing to spend. Just be aware that if you develop on top of some random, hacked up vendor kernel, then it probably will end up as a dead end, and you efforts might be wasted. I wouldn't necessarily say that updating ipipe is harder than chasing and fixing TI's hacks. HTH, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
On Wed, Jan 02, 2013 at 10:40:05AM +0100, Henri Roosen wrote: > > My decision to base the port on the Arago project was also that it looked > 'most TI official' to me. TI ships an evaluation disk with the AM335x-evm > board that is based on this project. The arago thing has gazillions of hacks, must of which are never going mainline. I would avoid it if at all possible. I have been pushing to get the beaglebone working "out of the box" in mainline Linux, and as of v3.8-rc2 it does work with a ramfs and Ethernet networking. However, I don't know which other drivers are still not working on that board. HTH, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] IO-APIC latencies
On Mon, Sep 17, 2012 at 12:00:01PM +0200, Gilles Chanteperdrix wrote: > > The point is: people may want to use Xenomai on atoms. We do not really > know on what kind of x86 people run xenomai, knowing that would help us > directing our efforts. FWIW, I was once involved in a project where we looked at atom and considered running xenomai on it. I would think that improving worst case latency on atom by 10 or 20 usec would be well worth the effort. Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Xenomai installation on P1020RDB
On Fri, Jul 20, 2012 at 08:25:22PM +0200, Wolfgang Grandegger wrote: > > I tested Xenomai recently on a P2020 with mainline Linux 3.2.x with the > new iPipe-Patch and got very good latency results, especially with CPU > isolation: 65 us without and *8* us with CPU isolation. [I'm still puzzled > about the good results with CPU isolation. Maybe that's due to the new > iPipe-Patch. Need to re-test when time permits). I have listed the results > below. Almost a year ago, around Linux 2.6.38 or so, I measured 13 us maximum latency on the P2020 RBD when using CPU isolation. Thanks, Richard ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
