[Xenomai] Gpio-core question

[Greg Gallagher]

Hi,
  I'm finishing up my work on a patch to add a RTDM gpio driver for
the zynq-7000 platform.  I ran into a situation where I needed to call
gpio_request in gpio-core because the zynq gpio driver uses the
gpio_request function to enable the gpio pins on the board.
A side effect that I found when testing is that the driver will fail to
load
if another application has exported a gpio pin via sysfs and likewise sysfs
won't allow anyone to export gpio pins once the rtdm gpio driver has been
loaded.
My implementation calls gpio_request on each pin as they are  registered
under /dev/rtdm.
I'm not sure if the above is an issue or not, if the RTDM driver has
claimed the
gpio pins then I think it would make sense for them not to be accessible by
applications
via sysfs.  If my assumption is not correct then maybe one option could be
to only call gpio_request on each pin as need, maybe via ioctl?

Any guidance would be appreciated,

Greg
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Greg Gallagher]

I really like the idea of having some TODO files, this would given new
comers to the project a place to start.
Improving the documentation and adding a quick start guide might help get
more people interested in using
Xenomai.  With more users hopefully that would lead to more contributors
and not just more feature requests.

To increase the presence of Xenomai would it make sense to have some
people focus on drivers and
maintenance for some popular community boards?  I personally focus on the
Xilinx Zynq platform,
but it might be useful to have people build and test images for  raspberry
pi boards, beaglebones and other
popular maker boards for every stable release of Xenomai.  I've posted my
steps on how to build Xenomai
for Zynq and will start to build and maintain pre-built binaries for Zynq
and run tests for the boards I have access to.
I find a lot of people that give me feedback on the Xenomai on Zynq seem to
just want to get started quickly
and go.  This really only addresses increasing Xenomai presence and would
increase the total work which
might not be what's desired right now.


On Wed, Nov 22, 2017 at 7:33 AM, Leopold Palomo-Avellaneda  wrote:

> Hi,
>
> yes, it's true. We have an Elmer and his cousin Wilbur is rear the door.
>
> Let me remark some points of your great email:
>
> - about the I/O frameworks
>
> On 21/11/17 18:11, Philippe Gerum wrote:
> > The
> > situation has reached a point where I see no alternative to dropping
> > them if the situation does not improve, ...
>
> - about your rule in the project:
>
> > I have not been scaling to the Xenomai
> > maintenance, development and documentation tasks, with the requirement
> > of running my business in parallel.
>
> - about how to solve it:
>
> > The solution to this serious problem is fitting the project to the
> > available resources by narrowing its goal, or conversely, by growing the
> > pool of contributors.
>
> - about the presence of Xenomai in the world:
>
> > to my current knowledge,
> > Xenomai is present in a broad range of applications and systems:
> > magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> > communication equipment, autonomous vehicles, control & automation
> > systems in various plants.
>
> - about where we came from:
>
> > On the sad side of the story, this project has virtually become a
> > one-man show the day Gilles - my long-time friend and hacking soul mate
> > - left us. That show is too big for me to run it alone ...
>
>
> And finally, if you let me talk about our Elmer.
>
> The I/O frameworks are IMHO are crucial. It has a very limited scenario to
> develop a RT system if it has no interaction with the external devices, or
> whatever. I have the hope ("A new hope" ;-)) that Siemens and Denx guys,
> continuing contributing to the project. Also, I have seen that new people
> have
> interest.
>
> But I would like to ask you directly Philippe some practical steps that
> could
> address to this challenge:
>
> - Would you be willing to move Xenomai to some platform like github, or
> similar?
> It will have some advantages like issues management, maintenance, (more
> visibility?), etc.
>
> - Would you be willing to delegate tasks of the project to other people,
> that
> maybe will not make it as good as you will do, like documentation, web
> site, or
> parts of code, but made then with an acceptable quality? And please, don't
> take
> bad, it's a difficult thing. I have to confess that for me, it's very
> difficult.
>
> - Would you be willing to guide new contributors and give them
> responsibilities
> of important parts of the code?
>
> - Would you be willing to have the role as coordinator and leader of the
> project
> changing from one man show to some more open project? will be it possible?
> I
> don't know if because license issues or whatever would let it...
>
> - Would you be willing to change the build system from autotools to another
> modern tool? (Ex CMake?) IMHO few people understand autotools and it's a
> barrier
> for the new contributors, at least in another opensource projects.
> However, I
> have to admit that the entry level in Xenomai is high, so, autotools
> should not
> be a problem.
>
> And yes, the lost of Gilles was a great blow, on a the personal level and
> for
> his contributions on the project.
>
> From my part, I can contribute if there's interest, in Debian (Ubuntu)
> packages.
> Also, in testing and trying to help in the RTnet part, as user that I'm.
> So, I
> could try to provide some preconfigured scenarios to the people that would
> like
> to entry in Xenomai.
>
> I have to admit that I'm a bit scared because we depend of Xenomai in some
> projects in my University. But, probably we could try to move to
> RT_PREMPT. But,
> because its history and my "affection" for the project I would prefer stay
> with
> it and try to help.
>
> Cheers,
>
> Leopold
>
> --
> --
> Linux User 152692 GPG: 05F4A7A949A2D9AA
> Catalonia
> 

Re: [Xenomai] matching patch version to kernel version

[Greg Gallagher]

Hi,
  In my experience I usually try to get the patch that is the closest
match to my kernel version.  So I would try
ipipe-core-4.9.51-x86-4.patch, you will probably have to do some hand
fixes to resolve any conflicts if the patch doesn't apply cleanly.
That's usually how I approach it.  There could be better ways but for
me that's the most straight forward.

Hope this helps,

Greg

On Wed, Nov 29, 2017 at 4:53 PM, Steve Pavao  wrote:
> Hi all,
>
> I am building Yocto poky linux for an Intel board at head in Master branch in 
> Yocto poky, which currently results in a kernel version 4.9.61.
>
> I see that the latest patch file in the xenomai download area is 
> ipipe-core-4.9.51-x86-4.patch.
>
> Will this patch work OK with the 4.9.61 kernel version, or should I use a 
> different approach to ensure a better match?
>
> Steve Pavao
> Korg R
>
>
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Gpio-core question

[Greg Gallagher]

Sure sounds good, I'll start tonight.

  Original Message  
From: r...@xenomai.org
Sent: November 30, 2017 3:50 AM
To: g...@embeddedgreg.com; xenomai@xenomai.org
Subject: Re: [Xenomai] Gpio-core question

On 11/29/2017 09:40 PM, Greg Gallagher wrote:
> Hi,
>   Sorry for the formatting in the last email I'm not sure what
> happened in my editor.  I've had some time to look into this issue.
> For my case that is outlined above it looks like we insert the fd into
> the tree in create instance, then when we fail the call to
> dev->ops.open, the fd is cleaned up with linux by using put_unused_fd
> but we never remove it from the tree.  On the next call to open we get
> the same fd back from get_unused_fd_flags we then call create_instance
> and fail because that fd is already in the tree from the previous
> attempt.  I'll test out my theory tonight.  If this is what is
> happening should the fd be removed from the tree in cleanup_instance?
> I can play around with xnid_remove and see if working it into
> cleanup_instance will solve the issue.

You are definitely right. There should be an undo operation of
rtdm_fd_enter() in __rtdm_dev_open() or __rtdm_dev_socket(), in the
fail_open and fail_socket cases resp., along with dropping the file
context via cleanup_instance().

Another option might be to make the undoing useless, by postponing the
indexing until ->open() / ->socket() has returned successfully. To do
that, we would have to split rtdm_fd_enter() in two functional steps
instead of a single routine:

1- assign the default handlers, initializing the fd-> fields
2- index the rtdm_fd struct in the xntree.

Then, we would keep on doing (1) at the end of create_instance(),
waiting for the ->open() / ->socket() handler to return successfully
before doing (2).

I don't see any reason for ->open() or ->socket() to depend on the fact
that rtdm_fd is already indexed on the ufd, which is a user-space handle
anyway.

Do you want to take a stab at implementing that stuff?

-- 
Philippe.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Gpio-core question

[Greg Gallagher]

Hi,
  Sorry for the formatting in the last email I'm not sure what
happened in my editor.  I've had some time to look into this issue.
For my case that is outlined above it looks like we insert the fd into
the tree in create instance, then when we fail the call to
dev->ops.open, the fd is cleaned up with linux by using put_unused_fd
but we never remove it from the tree.  On the next call to open we get
the same fd back from get_unused_fd_flags we then call create_instance
and fail because that fd is already in the tree from the previous
attempt.  I'll test out my theory tonight.  If this is what is
happening should the fd be removed from the tree in cleanup_instance?
I can play around with xnid_remove and see if working it into
cleanup_instance will solve the issue.

-Greg

On Wed, Nov 29, 2017 at 2:10 AM, Greg Gallagher <g...@embeddedgreg.com> wrote:
> Hi,
>   I was testing out my changes and came across some strange behaviour.
> I tried two approaches for my changes one where I add two ioctrl commands
> to request and release a pin and another where the driver requests and
> releases the pin
> without the user having to make a call to ioctl.  For the second approach
> I added an open call to the gpio driver to handle checking if the pin is
> available. During
> testing I found that if one pin fails to open all attempts to open any other
> pin will also
> fail.
>For example I have three pins 953, 954, 957.  I created a test where I
> open 953,
> then 954 and then 957.  For one test run I export 953 via sysfs, I expect
> the output of
> my test to fail to open 953 with EBUSY and then successfully open 954 and
> 957.
> I expect to see my open call executed three times.  What I actually see is
> all the pins
> fail to open.  The driver's open function is only executed once, after that
> it looks like
> open fails before the call to the drivers open function. The error returned
> for all attempts after
> the first failure  is EBUSY.  I experimented with the order in which the
> test opens pins and found
> that after open fails as expected (drivers open function is invoked and
> returns EBUSY) every
> other call to open also fails but doesn't invoke the drivers open function
> but returns EBUSY.
> I traced back through cobalt to see what was happening and found we are
> failing in the
> call to xnid_enter() in rtdm_fd_enter(). The function xnid_enter fails with
> EEXIST when trying
> to insert into the tree.  I'm not sure if I'm missing something in my open()
> function to handle
> cleaning up resources after an unsuccessful attempt to open a pin.
>   For my open call I used the open operations that are in the serial and spi
> drivers as a guide.
> If request_gpio() fails, I return that value from open(), I've included my
> code for open():
>
> int gpio_pin_open(struct rtdm_fd *fd, int oflags)
> {
> struct rtdm_gpio_chan *chan = rtdm_fd_to_private(fd);
> struct rtdm_device *dev = rtdm_fd_device(fd);
> unsigned int gpio = rtdm_fd_minor(fd);
> int ret = 0;
> struct rtdm_gpio_pin *pin;
>
> pin = container_of(dev, struct rtdm_gpio_pin, dev);
> ret = gpio_request(gpio, pin->name);
> if (ret) {
> printk(XENO_ERR "failed to request pin %d : %d\n", gpio, ret);
> return ret;
> } else {
> chan->requested = true;
> }
>
> return 0;
> }
>
> I can also post my test code if that helps, I'm not sure if this is a bug or
> if I'm missing some clean
> up code in my open function to handle unsuccessful attempts to open a pin.
>
> Thanks
>
> Greg
>
> On Fri, Nov 24, 2017 at 5:26 AM, Philippe Gerum <r...@xenomai.org> wrote:
>>
>> On 11/24/2017 06:37 AM, Greg Gallagher wrote:
>> > Hi,
>> >   I'm finishing up my work on a patch to add a RTDM gpio driver for
>> > the zynq-7000 platform.  I ran into a situation where I needed to call
>> > gpio_request in gpio-core because the zynq gpio driver uses the
>> > gpio_request function to enable the gpio pins on the board.
>> > A side effect that I found when testing is that the driver will fail
>> > to
>> > load
>> > if another application has exported a gpio pin via sysfs and likewise
>> > sysfs
>> > won't allow anyone to export gpio pins once the rtdm gpio driver has
>> > been
>> > loaded.
>> > My implementation calls gpio_request on each pin as they are  registered
>> > under /dev/rtdm.
>> > I'm not sure if the above is an issue or not, if the RTDM driver has
>> > claimed the
>> > gpio pins then I think it would make sense for them not to be accessible
>> > by
>> > applications
>> > via sysfs.  If my ass

Re: [Xenomai] Xenomai on Arm64

[Greg Gallagher]

What kernel are you using L4T or mainline?



Sent from my BlackBerry - the most secure mobile device - via the Rogers Network

  Original Message  
From: yuboch...@live.cn
Sent: December 17, 2017 9:44 AM
To: xenomai@xenomai.org
Subject: [Xenomai] Xenomai on Arm64

Hi,

I'm trying to patch Xenomai on Nvidia TX2, an Arm64 processor. When I used 
Xenomai 3.0.5 and ipipe-core-4.9.24-arm64-2.patch, I was not allowed config the 
kernel. As I understood, this is because Xenomai 3.0.5 doesn't fully support 
Arm64 (/kernel/cobalt/arch/arm64 is empty).

So I was wondering which versions of Xenomai and ipipe I should use? Stable 
release or versions under development?

Thank you!

Bocheng Yu
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Xenomai on Arm64

[Greg Gallagher]

I believe Arm64 is only in the next branch, but i'll leave that to someone else 
to confirm or correct.

Greg

  Original Message  
From: g...@embeddedgreg.com
Sent: December 17, 2017 10:24 AM
To: yuboch...@live.cn; xenomai@xenomai.org
Subject: Re: [Xenomai] Xenomai on Arm64

What kernel are you using L4T or mainline?


Sent from my BlackBerry - the most secure mobile device - via the Rogers Network

  Original Message  
From: yuboch...@live.cn
Sent: December 17, 2017 9:44 AM
To: xenomai@xenomai.org
Subject: [Xenomai] Xenomai on Arm64

Hi,

I'm trying to patch Xenomai on Nvidia TX2, an Arm64 processor. When I used 
Xenomai 3.0.5 and ipipe-core-4.9.24-arm64-2.patch, I was not allowed config the 
kernel. As I understood, this is because Xenomai 3.0.5 doesn't fully support 
Arm64 (/kernel/cobalt/arch/arm64 is empty).

So I was wondering which versions of Xenomai and ipipe I should use? Stable 
release or versions under development?

Thank you!

Bocheng Yu
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] (no subject)

[Greg Gallagher]

How did you install it in the first place? What platform are you using? X86, 
arm, ppc??

  Original Message  
From: samiraelmada...@gmail.com
Sent: December 17, 2017 11:49 AM
To: xenomai@xenomai.org
Subject: [Xenomai] (no subject)

please to uninstall xenomai or reconfigure it ,because it sounds like there
is a problem in the configuration so that when I execute ./latency I got
just the first three lines
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Xenomai on Arm64

[Greg Gallagher]

   Hi,
 So the best approach here would be to try to use a patch that is
   close to 4.4.15. Apply the ipipe patches and you'll have to resolve to
   conflicts by hand. I'm not sure how many conflicts you'll find.
   Thanks
   Greg

   From: yuboch...@live.cn
   Sent: December 17, 2017 12:22 PM
   To: g...@embeddedgreg.com; xenomai@xenomai.org
   Subject: Re: [Xenomai] Xenomai on Arm64

   Hi Greg,
   I'm using L4T. The feedback from 'uname -r' is:
   4.4.15-tegra
   Would that be a problem?
   Thank you!
   Bocheng Yu
 __

   From: Greg Gallagher <[1]g...@embeddedgreg.com>
   Sent: Sunday, December 17, 2017 10:24
   To: ?? ?; [2]xenomai@xenomai.org
   Subject: Re: [Xenomai] Xenomai on Arm64

   What kernel are you using L4T or mainline?
   Sent from my BlackBerry - the most secure mobile device - via the
   Rogers Network
 Original Message
   From: [3]yuboch...@live.cn
   Sent: December 17, 2017 9:44 AM
   To: [4]xenomai@xenomai.org
   Subject: [Xenomai] Xenomai on Arm64
   Hi,
   I'm trying to patch Xenomai on Nvidia TX2, an Arm64 processor. When I
   used Xenomai 3.0.5 and [5]ipipe-core-4.9.24-arm64-2.patch, I was not
   allowed config the kernel. As I understood, this is because Xenomai
   3.0.5 doesn't fully support Arm64 (/kernel/cobalt/arch/arm64 is empty).
   So I was wondering which versions of Xenomai and ipipe I should use?
   Stable release or versions under development?
   Thank you!
   Bocheng Yu
   ___
   Xenomai mailing list
   [6]Xenomai@xenomai.org
   [7]https://xenomai.org/mailman/listinfo/xenomai

References

   1. mailto:g...@embeddedgreg.com
   2. mailto:xenomai@xenomai.org
   3. mailto:yuboch...@live.cn
   4. mailto:xenomai@xenomai.org
   5. http://ipipe-core-4.9.24-arm64-2.patch/
   6. mailto:Xenomai@xenomai.org
   7. https://xenomai.org/mailman/listinfo/xenomai
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] rt_imx_uart

[Greg Gallagher]

Hi,
  I looked into why this driver isn't compiling, basically it needs to
be brought up to match the newer imx serial driver.  It's relying on
files and structures that existed in earlier versions of the kernel
before a reorganization happened (around 3.18 I think).  I have access
to a i.mx6 board and don't mind taking this on unless someone else as
already done it?

Thanks

Greg

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] rt-fprintf problem

[Greg Gallagher]

You'll have to be more specific then "it didn't work", is it possible
to post some code so we can see what you are trying to do?

-Greg

On Mon, Dec 18, 2017 at 7:12 PM, rajae rajae  wrote:
> Hello everyone please I have a question about rt-fprontf it didn't work
> ,should I call a specific function like rt_print_auto_init(1) or what
> exactly
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Cobalt core and Yocto

[Greg Gallagher]

Others might be able to give a more concrete answer, but usually I
check for the existence of /proc/xenomai as a very quick test.   You
can also run the autotune script and check that there are no errors in
the output.  If this is meant to be a smoke test it may worth while to
run the autotune script to calibrate the core clock timers and then
run the latency script to verify the latency on the system.  This will
also give you some feedback on if cobalt is up and running.

On Tue, Dec 19, 2017 at 11:51 AM, Steve Pavao  wrote:
> Hello -
>
> How should I adapt my Yocto poky recipes to make sure that Cobalt core boots? 
>  Right now, the only relevant information that appears on dmesg is:
>
> "Interrupt pipeline (release #4)”
>
> Here are my recipes, which work fine, but Cobalt core does not boot.  I must 
> need something else in my recipe(s).
>
> For I-PIPE Patch, my recipe file is linux-intel_4.9.bbappend:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI += "file://ipipe-core-4.9.51-x86-4.patch"
>
>
> For Xenomai 3 user libs, my recipe file is xenomai_3.0.6.bb:
>
> DESCRIPTION = "Provides userspace xenomai support and libraries needed to for 
> \
> real-time applications using the xenomai RTOS implementation (v3)"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = 
> "file://include/COPYING;md5=79ed705ccb9481bf9e7026b99f4e2b0e"
> SECTION = "xenomai"
> HOMEPAGE = "http://www.xenomai.org/;
> PR = "r0"
>
> SRC_URI = 
> "http://xenomai.org/downloads/xenomai/stable/latest/xenomai-3.0.6.tar.bz2;
>
> S = "${WORKDIR}/xenomai-${PV}"
>
> inherit autotools pkgconfig
>
> includedir = "/usr/include/xenomai"
>
> #Fixes QA Issues: non debug package contains .debug directory
> #FILES_${PN}-dbg += "/usr/bin/regression/posix/.debug"
> #FILES_${PN}-dbg += "/usr/bin/regression/native/.debug"
> #FILES_${PN}-dbg += "/usr/bin/regression/native+posix/.debug"
> #FILES_${PN}-dbg += "/usr/demo/.debug/*"
>
> #Fixes QA Error - Non-dev package contains symlink .so
> FILES_${PN}-dev += "/usr/lib/*.se"
>
> #Add directories to package for shipping
> FILES_${PN} += "/dev"
> FILES_${PN} += "/dev/*"
> FILES_${PN} += "/usr/bin/*"
> FILES_${PN} += "/usr/lib/*"
> FILES_${PN} += "/usr/sbin/*"
> FILES_${PN} += "/usr/include/*"
> FILES_${PN} += "/usr/lib/*"
> FILES_${PN} += "/usr/share/doc/*"
> FILES_${PN} += "/usr/share/man/*"
> FILES_${PN} += "/usr/demo/*"
>
> SRC_URI[md5sum] = "6017203d0992bb5334498c196bf6f25d"
> SRC_URI[sha256sum] = 
> "2c0dd3f0e36e4a10f97e0028989bb873e80f4d1ce212ac55fd3b28857c464f94"
>
> TARGET_CC_ARCH += "${LDFLAGS}”
>
>
> Thanks for any ideas.  Hopefully, I am pretty close with these recipes.
>
> - Steve Pavao
> Korg R
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Contributing to Xenomai

[Greg Gallagher]

Hi,
  I'm preparing a patch to enable RTDM gpio for the Xilinx Zynq 7000
platform.  First, is this something that would be of value to add to
mainline Xenomai?  I noticed there is a rtdm gpio driver for the bcm2835
(raspberry pi) and figured it may be nice for Zynq users to have a rtdm
gpio driver out of the box.
I've been digging online and I can't find any guidelines on how to
submit a patch to Xenomai.  On the mailing list I see most patches come
across with [PATCH] in the subject line, comments in the body, followed by
the patch.

Any help would be appreciated and sorry if I missed this information in a
FAQ somewhere.

Thanks

Greg
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Greg Gallagher]

Hi,
   I've been using Xenomai for a couple of years now and having been
preparing my first patch.
I'd love to help any way that is needed.  Documentation may be a good place
for me to start.  I'd also
be more than happy to help maintain some of the I/O frameworks.  I would
probably need a mentor
for guidance at the beginning.

Thanks

On Tue, Nov 21, 2017 at 12:11 PM, Philippe Gerum  wrote:

>
> As the GIT commit history shows, there has been no sustained effort in
> maintaining several of the Xenomai I/O frameworks for several months
> (e.g. RTnet, analogy), even years in some cases, despite obvious bugs
> are still haunting the code base according to the mailing list. The
> situation has reached a point where I see no alternative to dropping
> them if the situation does not improve, because there is absolutely no
> point in this project shipping bit rot software that won't ever be fixed.
>
> Unfortunately, this is only the tip of the iceberg. Let's face it, since
> Gilles passed away last year, I have not been scaling to the Xenomai
> maintenance, development and documentation tasks, with the requirement
> of running my business in parallel.
>
> The solution to this serious problem is fitting the project to the
> available resources by narrowing its goal, or conversely, by growing the
> pool of contributors.
>
> In addition, we can rework the most tricky part of the implementation to
> make it simpler to maintain, better documented, drastically lowering the
> barrier on entry for new contributors, which is what I've been working
> on for a year with the 4th generation of the interrupt pipeline.
> Progress on this front has been significant already, but once again
> limited by the time I have been able to devote to this development so far.
>
> For the past 16 years, this project has lived on various types of
> contributions from only a few committed people and companies. At this
> chance, let's mention that people who have been deploying Xenomai in
> industrial applications owe a lot to Wolfgang Denk from Denx
> Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
> the project in crucial ways directly or indirectly over the years, and
> still do.
>
> Xenomai as a dual kernel technology showcase has been quietly delivering
> on the promise of real-time Linux for more than a decade now, with
> marketing tools limited to showing decent code quality, good and
> reliable performance figures. As a result, to my current knowledge,
> Xenomai is present in a broad range of applications and systems:
> magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> communication equipment, autonomous vehicles, control & automation
> systems in various plants.
>
> On the sad side of the story, this project has virtually become a
> one-man show the day Gilles - my long-time friend and hacking soul mate
> - left us. That show is too big for me to run it alone, which entails
> maintaining:
>
> - the interrupt pipeline for 7 CPU architectures
> - the Cobalt co-kernel
> - 4 APIs, plus the "copperplate" mediating layer
> - several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI,
> GPIO
> - the documentation (which is currently unfriendly to newcomers, and
> stalled two years ago or so)
> - the website
> - the testing and release processes
>
> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.
>
> Thanks,
>
> --
> Philippe.
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH] Add How To Contribute Guide

[Greg Gallagher]

---
 How_To_Contribute.adoc | 57 ++
 1 file changed, 57 insertions(+)
 create mode 100644 How_To_Contribute.adoc

diff --git a/How_To_Contribute.adoc b/How_To_Contribute.adoc
new file mode 100644
index 000..60c366f
--- /dev/null
+++ b/How_To_Contribute.adoc
@@ -0,0 +1,57 @@
+How To Contribute
+=
+
+If you are interested in contributing to Xenomai here are some helpful hints 
on 
+how to get started. Start small, then progress as you get your feet wet.  There
+is no such thing as a minor contribution, there is no shame in making 
mistakes. 
+A contributor who submits a perfectible one-liner surely advances the project 
+further than any smart lurker.
+
+Things you will need:
+- Git
+- GCC for your platform
+- Xenomai source code
+- Linux tree patched with Ipipe
+- Autotools
+- Access to the Xenomai mailing list (xenomai@xenomai.org)
+
+Getting Set up:
+--
+Before starting to contribute you should have read the following documents:
+link:start-here[Getting Started]
+link:getting-the-xenomai-code[Getting The Code]
+link:installing-xenomai-3-x[Installing Xenomai]
+link:building-applications-with-xenomai-3-x[Building Applications]
+link:running-applications-with-xenomai-3-x[Running Applications]
+link:getting-help[Getting Help]
+
+Workflow
+
+The above mentioned documents will guide you through acquiring the source code,
+getting the development environment set up, and building Xenomai.  If you are 
+having issues getting your development environment setup or built, please 
review 
+the documents or consult the Xenomai mailing list.
+
+As a guideline for what branch to work on, the next branch is for new core 
features, 
+new CPU architecture ports or large scale changes. Only bug fixes and possibly 
new drivers should be pushed to stable-* branches. Any change that would 
prevent 
+applications based on earlier releases from the same branch from running on 
later ones 
+should not go into stable-* branches.  For example, an application built for 
the 3.0.2 release must build with no modifications on 3.0.6.
+
+Generally speaking, the kernel part of Xenomai (aka Cobalt core) aims at 
following the standard kernel coding style.
+
+After you make your changes, one thing to keep in mind is that when you 
+submit your patches to the the mailing list each patch should address exactly 
one 
+issue.  You may want to make one commit for every patch you wish to generate.  
This may 
+be a good workflow if you are addressing more than one issue during 
development. 
+
+When you are done development and testing you are ready to generate patches.  
+Use git format-patch to create a patch (or patch set) that you can submit for 
review.  
+
+Once you have generated your patch (or patches) you need to send them off to 
the 
+mailing list for review. This can be done using git send-email.  This may be 
+slightly tricky to set up. I suggest googling for the best way to set this up 
in 
+your gitconfig file that best suits your email provider and authentication 
method. 
+Once it is configured you can submit your patch to the mailing list.
+
+
+
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH] Split rtdm_fd_enter up, move the functionality where we store the fd until after the open() call succeeds. Calls where open() fail a fd is left in the tree even after the cleanup cod

[Greg Gallagher]

---
 include/cobalt/kernel/rtdm/fd.h |  2 ++
 kernel/cobalt/posix/mqueue.c|  7 ++-
 kernel/cobalt/posix/timerfd.c   |  4 
 kernel/cobalt/rtdm/core.c   | 12 +---
 kernel/cobalt/rtdm/fd.c | 24 
 5 files changed, 37 insertions(+), 12 deletions(-)

diff --git a/include/cobalt/kernel/rtdm/fd.h b/include/cobalt/kernel/rtdm/fd.h
index 086b04b..e504c0c 100644
--- a/include/cobalt/kernel/rtdm/fd.h
+++ b/include/cobalt/kernel/rtdm/fd.h
@@ -345,6 +345,8 @@ static inline int rtdm_fd_is_compat(const struct rtdm_fd 
*fd)
 int rtdm_fd_enter(struct rtdm_fd *rtdm_fd, int ufd,
  unsigned int magic, struct rtdm_fd_ops *ops);
 
+int rtdm_fd_register(struct rtdm_fd *fd, int ufd);
+
 struct rtdm_fd *rtdm_fd_get(int ufd, unsigned int magic);
 
 int rtdm_fd_lock(struct rtdm_fd *fd);
diff --git a/kernel/cobalt/posix/mqueue.c b/kernel/cobalt/posix/mqueue.c
index 6357d22..859e12e 100644
--- a/kernel/cobalt/posix/mqueue.c
+++ b/kernel/cobalt/posix/mqueue.c
@@ -267,6 +267,7 @@ static struct rtdm_fd_ops mqd_ops = {
 static inline int mqd_create(struct cobalt_mq *mq, unsigned long flags, int 
ufd)
 {
struct cobalt_mqd *mqd;
+   int ret;
 
if (cobalt_ppd_get(0) == _kernel_ppd)
return -EPERM;
@@ -278,7 +279,11 @@ static inline int mqd_create(struct cobalt_mq *mq, 
unsigned long flags, int ufd)
mqd->fd.oflags = flags;
mqd->mq = mq;
 
-   return rtdm_fd_enter(>fd, ufd, COBALT_MQD_MAGIC, _ops);
+   ret = rtdm_fd_enter(>fd, ufd, COBALT_MQD_MAGIC, _ops);
+   if (ret < 0)
+   return ret;
+
+   return rtdm_fd_register(>fd, ufd);
 }
 
 static int mq_open(int uqd, const char *name, int oflags,
diff --git a/kernel/cobalt/posix/timerfd.c b/kernel/cobalt/posix/timerfd.c
index 51e7605..217e68a 100644
--- a/kernel/cobalt/posix/timerfd.c
+++ b/kernel/cobalt/posix/timerfd.c
@@ -202,6 +202,10 @@ COBALT_SYSCALL(timerfd_create, lostage, (int clockid, int 
flags))
if (ret < 0)
goto fail;
 
+   ret = rtdm_fd_register(>fd, ufd);
+   if (ret < 0)
+   goto fail;
+
return ufd;
 fail:
xnselect_destroy(>read_select);
diff --git a/kernel/cobalt/rtdm/core.c b/kernel/cobalt/rtdm/core.c
index 05f273f..01d9caf 100644
--- a/kernel/cobalt/rtdm/core.c
+++ b/kernel/cobalt/rtdm/core.c
@@ -174,7 +174,7 @@ int __rtdm_dev_open(const char *path, int oflag)
 
context->fd.minor = dev->minor;
context->fd.oflags = oflag;
-
+   
trace_cobalt_fd_open(current, >fd, ufd, oflag);
 
if (dev->ops.open) {
@@ -185,9 +185,12 @@ int __rtdm_dev_open(const char *path, int oflag)
goto fail_open;
}
 
-   fd_install(ufd, filp);
-
trace_cobalt_fd_created(>fd, ufd);
+   ret = rtdm_fd_register(>fd, ufd);
+   if (ret < 0)
+   goto fail_open;
+
+   fd_install(ufd, filp);
 
return ufd;
 
@@ -238,6 +241,9 @@ int __rtdm_dev_socket(int protocol_family, int socket_type,
}
 
trace_cobalt_fd_created(>fd, ufd);
+   ret = rtdm_fd_register(>fd, ufd);
+   if (ret < 0)
+   goto fail_socket;
 
return ufd;
 
diff --git a/kernel/cobalt/rtdm/fd.c b/kernel/cobalt/rtdm/fd.c
index ffcd3aa..e355526 100644
--- a/kernel/cobalt/rtdm/fd.c
+++ b/kernel/cobalt/rtdm/fd.c
@@ -145,20 +145,13 @@ static inline void set_compat_bit(struct rtdm_fd *fd)
 int rtdm_fd_enter(struct rtdm_fd *fd, int ufd, unsigned int magic,
  struct rtdm_fd_ops *ops)
 {
-   struct rtdm_fd_index *idx;
struct cobalt_ppd *ppd;
-   spl_t s;
-   int ret;
-
+   
secondary_mode_only();
 
if (magic == 0)
return -EINVAL;
 
-   idx = kmalloc(sizeof(*idx), GFP_KERNEL);
-   if (idx == NULL)
-   return -ENOMEM;
-
assign_default_dual_handlers(ops->ioctl);
assign_default_dual_handlers(ops->read);
assign_default_dual_handlers(ops->write);
@@ -175,6 +168,21 @@ int rtdm_fd_enter(struct rtdm_fd *fd, int ufd, unsigned 
int magic,
fd->refs = 1;
set_compat_bit(fd);
 
+   return 0;
+}
+
+int rtdm_fd_register(struct rtdm_fd *fd, int ufd)
+{
+   struct rtdm_fd_index *idx;
+   struct cobalt_ppd *ppd;
+   spl_t s;
+   int ret = 0;
+
+   ppd = cobalt_ppd_get(0);
+   idx = kmalloc(sizeof(*idx), GFP_KERNEL);
+   if (idx == NULL)
+   return -ENOMEM;
+
idx->fd = fd;
 
xnlock_get_irqsave(_lock, s);
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH] Add zynq-7000 rtdm gpio driver.

[Greg Gallagher]

From: Greg Gallagher <ggallaghe...@gmail.com>

---
 For the zynq platform (and possibly others in the future) we need to modify 
 gpio-core to request gpio pins before using them. The open() function will 
 now request a gpio and fail if it's already reserved. This should make 
 the pin request transparent to the user. The ability to request and release 
 pins is also available in an ioctrl message.  Tested on Microzed Zynq-7010 
 platform and the raspberry pi 2 board.

---
 include/rtdm/uapi/gpio.h|  2 +
 kernel/drivers/gpio/Kconfig |  8 
 kernel/drivers/gpio/Makefile|  1 +
 kernel/drivers/gpio/gpio-core.c | 87 +++--
 kernel/drivers/gpio/gpio-zynq7000.c | 40 +
 5 files changed, 116 insertions(+), 22 deletions(-)
 create mode 100644 kernel/drivers/gpio/gpio-zynq7000.c

diff --git a/include/rtdm/uapi/gpio.h b/include/rtdm/uapi/gpio.h
index f846f48..b745f15 100644
--- a/include/rtdm/uapi/gpio.h
+++ b/include/rtdm/uapi/gpio.h
@@ -22,6 +22,8 @@
 #define GPIO_RTIOC_DIR_IN  _IO(RTDM_CLASS_GPIO, 1)
 #define GPIO_RTIOC_IRQEN   _IOW(RTDM_CLASS_GPIO, 2, int) /* GPIO 
trigger */
 #define GPIO_RTIOC_IRQDIS  _IO(RTDM_CLASS_GPIO, 3)
+#define GPIO_RTIOC_REQS_IO(RTDM_CLASS_GPIO, 4)
+#define GPIO_RTIOC_RELS_IO(RTDM_CLASS_GPIO, 5)
 
 #define GPIO_TRIGGER_NONE  0x0 /* unspecified */
 #define GPIO_TRIGGER_EDGE_RISING   0x1
diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
index 869392f..81fc442 100644
--- a/kernel/drivers/gpio/Kconfig
+++ b/kernel/drivers/gpio/Kconfig
@@ -33,6 +33,14 @@ config XENO_DRIVERS_GPIO_SUN8I_H3
Suitable for the GPIO controller available from Allwinner's H3
SoC, as found on the NanoPI boards.
 
+config XENO_DRIVERS_GPIO_ZYNQ7000
+   depends on ARCH_ZYNQ
+   bool "Support for Zynq7000 GPIOs"
+   help
+
+   Enables support for the GPIO controller available from
+   Xilinx's Zynq7000 SoC.
+
 config XENO_DRIVERS_GPIO_DEBUG
bool "Enable GPIO core debugging features"
 
diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
index 35ca52c..7f28403 100644
--- a/kernel/drivers/gpio/Makefile
+++ b/kernel/drivers/gpio/Makefile
@@ -8,3 +8,4 @@ xeno_gpio-y := gpio-core.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += gpio-bcm2835.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += gpio-mxc.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += gpio-sun8i-h3.o
+xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += gpio-zynq7000.o
diff --git a/kernel/drivers/gpio/gpio-core.c b/kernel/drivers/gpio/gpio-core.c
index 55594f6..40e6993 100644
--- a/kernel/drivers/gpio/gpio-core.c
+++ b/kernel/drivers/gpio/gpio-core.c
@@ -36,7 +36,8 @@ struct rtdm_gpio_pin {
 struct rtdm_gpio_chan {
int requested : 1,
has_direction : 1,
-   is_output : 1 ;
+   is_output : 1,
+is_interrupt : 1;
 };
 
 static int gpio_pin_interrupt(rtdm_irq_t *irqh)
@@ -60,12 +61,16 @@ static int request_gpio_irq(unsigned int gpio, struct 
rtdm_gpio_pin *pin,
if (trigger & ~GPIO_TRIGGER_MASK)
return -EINVAL;
 
-   ret = gpio_request(gpio, pin->name);
-   if (ret) {
-   if (ret != -EPROBE_DEFER)
-   printk(XENO_ERR "cannot request GPIO%d\n", gpio);
-   return ret;
-   }
+if (!chan->requested) {
+ret = gpio_request(gpio, pin->name);
+   if (ret) {
+if (ret != -EPROBE_DEFER)
+printk(XENO_ERR 
+   "can not request GPIO%d\n", gpio);
+   return ret;
+}
+   chan->requested = true;
+}
 
ret = gpio_direction_input(gpio);
if (ret) {
@@ -99,13 +104,14 @@ static int request_gpio_irq(unsigned int gpio, struct 
rtdm_gpio_pin *pin,
goto fail;
}
 
-   chan->requested = true;
 
rtdm_irq_enable(>irqh);
+chan->is_interrupt = true;
 
return 0;
 fail:
gpio_free(gpio);
+chan->requested = false;
 
return ret;
 }
@@ -116,6 +122,7 @@ static void release_gpio_irq(unsigned int gpio, struct 
rtdm_gpio_pin *pin,
rtdm_irq_free(>irqh);
gpio_free(gpio);
chan->requested = false;
+chan->is_interrupt = false;
 }
 
 static int gpio_pin_ioctl_nrt(struct rtdm_fd *fd,
@@ -134,32 +141,47 @@ static int gpio_pin_ioctl_nrt(struct rtdm_fd *fd,
ret = rtdm_safe_copy_from_user(fd, , arg, sizeof(val));
if (ret)
return ret;
-   ret = gpio_direction_output(gpio, val);
-   if (ret == 0) {
-   chan->has_direction = true;
-  

[Xenomai] [PATCH] Split rtdm_fd_enter up

[Greg Gallagher]

---
 split rtdm_fd_enter,  move the functionality where we store
 the fd until after the open() call succeeds.  Calls where open() fail a fd is
 left in the tree even after the cleanup code is executed.  If this fd number
 is used again we will fail the call to open until a different fd is used.
 This patch addresses this situation by not adding the fd into the tree until
 open has succeeded and the fd is valid.

---
 include/cobalt/kernel/rtdm/fd.h |  2 ++
 kernel/cobalt/posix/mqueue.c|  7 ++-
 kernel/cobalt/posix/timerfd.c   |  4 
 kernel/cobalt/rtdm/core.c   | 12 +---
 kernel/cobalt/rtdm/fd.c | 24 
 5 files changed, 37 insertions(+), 12 deletions(-)

diff --git a/include/cobalt/kernel/rtdm/fd.h b/include/cobalt/kernel/rtdm/fd.h
index 086b04b..e504c0c 100644
--- a/include/cobalt/kernel/rtdm/fd.h
+++ b/include/cobalt/kernel/rtdm/fd.h
@@ -345,6 +345,8 @@ static inline int rtdm_fd_is_compat(const struct rtdm_fd 
*fd)
 int rtdm_fd_enter(struct rtdm_fd *rtdm_fd, int ufd,
  unsigned int magic, struct rtdm_fd_ops *ops);
 
+int rtdm_fd_register(struct rtdm_fd *fd, int ufd);
+
 struct rtdm_fd *rtdm_fd_get(int ufd, unsigned int magic);
 
 int rtdm_fd_lock(struct rtdm_fd *fd);
diff --git a/kernel/cobalt/posix/mqueue.c b/kernel/cobalt/posix/mqueue.c
index 6357d22..859e12e 100644
--- a/kernel/cobalt/posix/mqueue.c
+++ b/kernel/cobalt/posix/mqueue.c
@@ -267,6 +267,7 @@ static struct rtdm_fd_ops mqd_ops = {
 static inline int mqd_create(struct cobalt_mq *mq, unsigned long flags, int 
ufd)
 {
struct cobalt_mqd *mqd;
+   int ret;
 
if (cobalt_ppd_get(0) == _kernel_ppd)
return -EPERM;
@@ -278,7 +279,11 @@ static inline int mqd_create(struct cobalt_mq *mq, 
unsigned long flags, int ufd)
mqd->fd.oflags = flags;
mqd->mq = mq;
 
-   return rtdm_fd_enter(>fd, ufd, COBALT_MQD_MAGIC, _ops);
+   ret = rtdm_fd_enter(>fd, ufd, COBALT_MQD_MAGIC, _ops);
+   if (ret < 0)
+   return ret;
+
+   return rtdm_fd_register(>fd, ufd);
 }
 
 static int mq_open(int uqd, const char *name, int oflags,
diff --git a/kernel/cobalt/posix/timerfd.c b/kernel/cobalt/posix/timerfd.c
index 51e7605..217e68a 100644
--- a/kernel/cobalt/posix/timerfd.c
+++ b/kernel/cobalt/posix/timerfd.c
@@ -202,6 +202,10 @@ COBALT_SYSCALL(timerfd_create, lostage, (int clockid, int 
flags))
if (ret < 0)
goto fail;
 
+   ret = rtdm_fd_register(>fd, ufd);
+   if (ret < 0)
+   goto fail;
+
return ufd;
 fail:
xnselect_destroy(>read_select);
diff --git a/kernel/cobalt/rtdm/core.c b/kernel/cobalt/rtdm/core.c
index 05f273f..01d9caf 100644
--- a/kernel/cobalt/rtdm/core.c
+++ b/kernel/cobalt/rtdm/core.c
@@ -174,7 +174,7 @@ int __rtdm_dev_open(const char *path, int oflag)
 
context->fd.minor = dev->minor;
context->fd.oflags = oflag;
-
+   
trace_cobalt_fd_open(current, >fd, ufd, oflag);
 
if (dev->ops.open) {
@@ -185,9 +185,12 @@ int __rtdm_dev_open(const char *path, int oflag)
goto fail_open;
}
 
-   fd_install(ufd, filp);
-
trace_cobalt_fd_created(>fd, ufd);
+   ret = rtdm_fd_register(>fd, ufd);
+   if (ret < 0)
+   goto fail_open;
+
+   fd_install(ufd, filp);
 
return ufd;
 
@@ -238,6 +241,9 @@ int __rtdm_dev_socket(int protocol_family, int socket_type,
}
 
trace_cobalt_fd_created(>fd, ufd);
+   ret = rtdm_fd_register(>fd, ufd);
+   if (ret < 0)
+   goto fail_socket;
 
return ufd;
 
diff --git a/kernel/cobalt/rtdm/fd.c b/kernel/cobalt/rtdm/fd.c
index ffcd3aa..e355526 100644
--- a/kernel/cobalt/rtdm/fd.c
+++ b/kernel/cobalt/rtdm/fd.c
@@ -145,20 +145,13 @@ static inline void set_compat_bit(struct rtdm_fd *fd)
 int rtdm_fd_enter(struct rtdm_fd *fd, int ufd, unsigned int magic,
  struct rtdm_fd_ops *ops)
 {
-   struct rtdm_fd_index *idx;
struct cobalt_ppd *ppd;
-   spl_t s;
-   int ret;
-
+   
secondary_mode_only();
 
if (magic == 0)
return -EINVAL;
 
-   idx = kmalloc(sizeof(*idx), GFP_KERNEL);
-   if (idx == NULL)
-   return -ENOMEM;
-
assign_default_dual_handlers(ops->ioctl);
assign_default_dual_handlers(ops->read);
assign_default_dual_handlers(ops->write);
@@ -175,6 +168,21 @@ int rtdm_fd_enter(struct rtdm_fd *fd, int ufd, unsigned 
int magic,
fd->refs = 1;
set_compat_bit(fd);
 
+   return 0;
+}
+
+int rtdm_fd_register(struct rtdm_fd *fd, int ufd)
+{
+   struct rtdm_fd_index *idx;
+   struct cobalt_ppd *ppd;
+   spl_t s;
+   int ret = 0;
+
+   ppd = cobalt_ppd_get(0);
+   idx = kmalloc(sizeof(*idx), GFP_KERNEL);
+   if (idx == NULL)
+   return -ENOMEM;
+
idx->fd = fd;
 
xnlock_get_irqsave(_lock, s);
-- 
2.7.4

[Xenomai] Contributing Doc

[Greg Gallagher]

Hi,
   I'm putting together a doc on how to contribute.  I've pasted it
below, if anyone has some time to review and let me know what I've
missed that would be great.
  I wasn't sure if all development should take place against the next
branch or not.  I'm also not sure if I linked the documents correctly
or not in the getting setup section.
  Once it's ready should this be sent to the mailing list as a patch
against xenomai-kbase repo?

Thanks

Greg



How To Contribute
=

If you are interested in contributing to Xenomai here are some helpful hints on
how to get started.

Things you will need:
- Git
- GCC for your platform
- Xenomai source code
- Linux tree patched with Ipipe
- Access to the Xenomai mailing list (xenomai@xenomai.org)

Getting Setup:
--
Before starting to contribute you should have read the following documents:
-link:Start_Here.adoc[]
-link:Getting_Xenomai.adoc[]
-link:Installing_Xenomai_3.x.adoc[]

Workflow

The above mentioned documents will guide you through acquiring the
source code, getting the development environment set up, and building
Xenomai.  If you are having issues getting your development
environment setup or built please review the documents or consult the
Xenomai mailing list.

To contribute to Xenomai, switch to the branch you'd like to make your
changes on (next branch?).  After you make your changes, one thing to
keep in mind is that when you submit your patches to the the mailing
list each patch should address exactly one issue.  You may want to
make one commit for every patch you wish to generate.  This may
be a good workflow if you are addressing more than one issue during development.

Once you are done development and testing you are ready to generate
patches.  Use git format-patch to create a patch (or patch set) that
you can submit for review.

Once we have generated our patch (or patches) we need to send them off
the the mailing list for review. This can be done using git
send-email.  This may be slightly tricky to set up, I suggest googling
for the best way to set this up in your gitconfig file that best suits
your email provider and authentication method. Once it is configured
you can submit your patch to the mailing list.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH] Fix up name collision, debug is already defined

[Greg Gallagher]

---
When compiling for x86 and enabling experimental intel net drivers I ran
into a compilation error where debug was defined previously.  Rename the 
debug variable to avoid the collision.

---
 kernel/drivers/net/drivers/experimental/e1000/e1000_main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/drivers/net/drivers/experimental/e1000/e1000_main.c 
b/kernel/drivers/net/drivers/experimental/e1000/e1000_main.c
index 66ecfce..acdc13c 100644
--- a/kernel/drivers/net/drivers/experimental/e1000/e1000_main.c
+++ b/kernel/drivers/net/drivers/experimental/e1000/e1000_main.c
@@ -421,9 +421,9 @@ module_param_array(cards, int, NULL, 0444);
 MODULE_PARM_DESC(cards, "array of cards to be supported (eg. 1,0,1)");
 
 
-static int debug = NETIF_MSG_DRV | NETIF_MSG_PROBE;
-module_param(debug, int, 0);
-MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+static int local_debug = NETIF_MSG_DRV | NETIF_MSG_PROBE;
+module_param(local_debug, int, 0);
+MODULE_PARM_DESC(local_debug, "Debug level (0=none,...,16=all)");
 
 /* The parameter 'pciif' might be used to use this driver for
  * PCI or PCIe only NICs.
@@ -1096,7 +1096,7 @@ static int e1000_probe(struct pci_dev *pdev,
adapter->netdev = netdev;
adapter->pdev = pdev;
adapter->hw.back = adapter;
-   adapter->msg_enable = (1 << debug) - 1;
+   adapter->msg_enable = (1 << local_debug) - 1;
 
err = -EIO;
adapter->hw.hw_addr = ioremap(pci_resource_start(pdev, BAR_0),
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Xenomai porting for proprietary drivers

[Greg Gallagher]

It's possible to port proprietary drivers, but the license is the same as the 
Linux kernel. Which means you must comply with the GPL license. 


Greg

  Original Message  
From: pintu.p...@gmail.com
Sent: May 7, 2018 6:16 AM
To: xenomai@xenomai.org
Subject: [Xenomai] Xenomai porting for proprietary drivers

Hi,

I heard that Xenomai porting is not possible for a proprietary
drivers. That means we cannot convert our internal drivers to Xenomai
RTDM interface.
Is this true ?

If this is true, is it mentioned somewhere ?
Is it because of some licensing issue ?


Thanks,
Pintu

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] RPi zero: high resolution clock not working

[Greg Gallagher]

Hi,
  To the best of my knowledge for raspberry pi zero you should be
using the bcm2835_defconfig for mainline.  I was working on this last
month when I had a little more time.  There are a couple things
missing right now for Xenomai-3 (Cobalt) to work on the bcm2835 based
pis.  Most of it has to do with the ipipe patches for the bcm2835.  We
are missing some modification for the bcm2835_timer driver to get it
to work with the ipipe.  I have made most of the changes and I am
currently debugging a IRQ storm that hangs the board up, I haven't had
much time in the last few weeks to get much progress on it, if you are
interested I can upload my patches tonight if you want to take a look.

-Greg

On Wed, May 9, 2018 at 8:50 AM, Gustav Johansson  wrote:
> Hi!
>
>
> I have managed to boot RPI zero with Cobalt on kernel version 4.9.51, with 
> ipipe #4.
>
> Im using the mainline. I used config multi_v7_defconfig and chose armv6 from 
> there.
>
> Im using the device tree bcm2835-rpi-zero.dtb
>
>
> During the boot I receives errors:
>
> [0.27] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps 
> every 2147483647500ns
> [0.74] clocksource: timer: mask: 0x max_cycles: 0x, 
> max_idle_ns: 1911260446275 ns
> [0.000698] Interrupt pipeline (release #4)
> [0.069805] clocksource: jiffies: mask: 0x max_cycles: 0x, 
> max_idle_ns: 1911260446275 ns
> [0.107627] PTP clock support registered
> [0.111409] clocksource: Switched to clocksource timer
> [0.180098] [Xenomai] scheduling class idle registered.
> [0.180287] [Xenomai] scheduling class rt registered.
> [0.180527] I-pipe: high-resolution clock not working
> [0.180726] [Xenomai] init failed, code -19
> [0.207251] clk: couldn't get clock 0 for /soc/pwm@7e20c000
> [0.572597] i2c-bcm2835 20805000.i2c: Could not read clock-frequency 
> property
> [5.063088] systemd[1]: System time before build time, advancing clock.
> [6.685798] systemd[1]: Mounting RPC Pipe File System...
>
>
> So the error tells me that the high-resolution clock is not working and 
> Xenomai failed the init with error code -19.
>
>
> The boot continues and I can use it as regular but /proc/xenomai does not 
> exist.
>
>
> Any ideas on ways I can make it work? I have included the dmesg log and 
> kernel config.
>
>
> Regards,
>
> Gustav
> -- next part --
> A non-text attachment was scrubbed...
> Name: dmesg.log
> Type: text/x-log
> Size: 17028 bytes
> Desc: dmesg.log
> URL: 
> 
> -- next part --
> A non-text attachment was scrubbed...
> Name: ATT07561.config
> Type: application/octet-stream
> Size: 134322 bytes
> Desc: ATT07561.config
> URL: 
> 
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] RPI, pinctrl-bcm2835 now working

[Greg Gallagher]

Hi,
  The gpio driver that controls /dev/rtdm/pinctrl-bcm2835 is the rtdm driver 
that works with the cobalt kernell. The Linux driver is still present and 
loaded but using it will cause the Xenomai to move to secondary mode. The 
source for the rtdm driver is in the Xenomai tree under kernel/drivers/gpio.
The driver does work, what isn't working for you? What gpiochip number is 
being used in sysfs? The pin numbers should be the same in both the rtdm case 
and the normal Linux case.  The base gpio number for mainline may be different 
then for the rpi distros. The mainline driver may be different then what is in 
the raspberry Pi tree but they shouldnt differ in functionality. 
If it's just different pin numbers that should not effect the functionality 
of the gpio pins.

Greg 

  Original Message  
From: gusjo...@kth.se
Sent: April 27, 2018 6:05 AM
To: Xenomai@xenomai.org
Subject: [Xenomai] RPI, pinctrl-bcm2835 now working

Hi!

I have now successfully booted the mainline kernel on RPi3. 
The problem I have now instead is the pinctrl-bcm2835 driver. 
In /dev/rtdm/pinctrl-bcm2835/ are the pins in wrong numbers, 
they start at 400+ and end at 500+. 

When I looked inside /drivers/pinctrl/bcm/pinctrl-bcm2835.c 
It is very different from the one in rpi-kernel. Im guessing 
that the driver pinctrl-bcm2835.c in the mainline is for the
older RPi's while rpi-kernel got the for the newer models.

Do you have any ideas on how I should continue?

Do you have a working pinctrl-bcm2835 driver on your RPi2?

Regards
Gustav 



From: Greg Gallagher <g...@embeddedgreg.com>
Sent: 24 April 2018 15:34
To: Gustav Johansson
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] Illegal instruction/bad syscall

Have you considered using mainline?  I'm not sure if anyone has been
testing the raspberry pi tree against stable xenomai-3.  I've
validated most of the xenomai-3 stable branch against raspberry pi 2b
(mainline) so I've looked at most of the bcm code recently and i
haven't git the syscall issue.  Some of the maintainers are also
looking to test ARM64 rpi3 so if you want to try getting the 64-bit
mainline kernel running on your board I can give you some help.

-Greg

On Tue, Apr 24, 2018 at 8:38 AM, Gustav Johansson <gusjo...@kth.se> wrote:
> Hi!
>
>
> I recently managed to run a cobalt core for raspberry pi 3, Im using ipipe #9 
> for arm,  kernel version 4.1.21, Xenomai 3.0.6.
>
>
> I managed to build the xenomai API but when I try every executable file, for 
> example latency test bench,  I get "illegal instruction", and in dmesg I get 
> "[Xenomai] bad syscall <0xff7000af> ...".
>
>
> The crosscompiler Im using is 
> https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian
>  and I have also tried compiling it on the RPI3 itself but Im getting the 
> same error.
>
>
> I have compared my kernel config next to Harco Kuppens  working image 
> (http://www.cs.ru.nl/lab/xenomai/) But the only difference is that I have 
> higher values in XENO_OPT_SYS_HEAP, XENO_PRIVATE_HEAPS, 
> XENO_OPT_SHARED_HEAPSZ, XENO_OPT_TIMERS.
>
>
> Im uploading a readme with the steps I have taken with the installation and 
> also my kernel config.
>
>
> Any ideas on why I get "Illegal instruction"?
>
>
> Regards
>
> Gustav Johansson
>
> -- next part --
> A non-text attachment was scrubbed...
> Name: rpi3_cobalt_4.1.21_config
> Type: application/octet-stream
> Size: 126604 bytes
> Desc: rpi3_cobalt_4.1.21_config
> URL: 
> <http://xenomai.org/pipermail/xenomai/attachments/20180424/fd49797a/attachment.obj>
> -- next part --
> A non-text attachment was scrubbed...
> Name: readme.md
> Type: text/markdown
> Size: 6403 bytes
> Desc: readme.md
> URL: 
> <http://xenomai.org/pipermail/xenomai/attachments/20180424/fd49797a/attachment.bin>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [SPAM] Re: Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and Linux 4.9.51 on Xilinx Zynq 7000 MPSOC

[Greg Gallagher]

I'll update my how-to this weekend and post my prebuilt images. I just need to 
make time to look into the 4.9.51 lock up. I'll post here with links once 
things are ready.


Greg


  Original Message  
From: jeff.w...@nta-inc.net
Sent: April 27, 2018 10:21 AM
To: xenomai@xenomai.org
Subject: Re: [Xenomai] [SPAM] Re: Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and 
Linux 4.9.51 on Xilinx Zynq 7000 MPSOC

On 04/27/2018 02:55 AM, Salvatore Barone wrote:
> It works! Thanks Greg!
> If you're interested, I can post a script that do all the work!

I, for one, would appreciate that.  I am sure there are others who would as 
well.  I am about to dust off an old Zynq-based Xenomai-2.6 project, and any 
hints as to the best set of kernel sources, i-pipe patches, config, and process 
for an up-to-date build would be helpful.

Many thanks,

-Jeff



CONFIDENTIALITY NOTICE: The contents of this e-mail message may be privileged, 
confidential, proprietary, Controlled Unclassified Information (CUI) or 
otherwise protected against disclosure or dissemination. This e-mail message 
and any files transmitted with it are intended solely for the use of the 
individual/individuals or entity/entities to whom they are addressed. If you 
are not the intended recipient of this message, any dissemination, 
distribution, printing or copying is strictly prohibited. If you have received 
this message in error, please e-mail or call the sender (jeff.w...@nta-inc.net, 
(256) 842-7041) and destroy all copies.


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] RTDM serial illicit call from head domain 'Xenomai'

[Greg Gallagher]

I won't say the driver is improperly written, this ioctl call may not
be expected to be used in a low latency situation.  Some code maybe
expected to be called at initialization time and then never again so
it doesn't impact RT operation.  The rt_imx_uart driver is part of the
Xenomai code base, I'm not 100% sure if this functions shouldn't be
called from an RTDM driver or if the author needs to be aware they
could just introduce latency when used in the rt context.
These panics aren't kernel or driver errors, we are creating them on
purpose to try to track down domain switches which could impact
latency.  So as long as your latency number are acceptable you don't
need to enable the debug flag to track down domain switches and these
panics can be ignored for now.

-Greg

On Sun, May 13, 2018 at 12:07 AM, Steve Freyder <st...@freyder.net> wrote:
> So the fundamental issue here seems to be "how bad is bad enough" when it
> comes to these mode switches.
>
> The write() call is wrapped with __RT(write)(...), so I assume it is doing
> an RTDM-based write request, and not a standard Linux write() syscall.  If
> I remove that wrapper, I get an EPERM error from the un-wrapped write()
> call.
>
> Had I not been running with a debug kernel,
> this would never have shown up at all as far as I have seen.  Perhaps this
> imx_uart driver is improperly coded - I assume it is not part of the
> standard
> Xenomai code base, is that correct?  Perhaps the writers of this driver
> improperly mixed functions that cause the code path inside the RTDM calling
> sequence to invoke code that should not really be getting invoked
> "by convention" but due to the specifics, it's known to be benign overall,
> and so when the debug code is enabled, it results in a false-positive detect
> of a generic problem scenario that in this specific case is truly always
> 100% benign.  If that's true, then I'm going to take this off my list of
> things to concern myself about.  It's only recently that we've been running
> kernels with this debug capability enabled, so I've never seen this before
> and we have never had any issues with it at all so that tends to suggest
> this
> is truly benign for these specific code paths.
>
> Thanks Greg,
> Steve
>
>
>
>
> On 5/12/2018 9:30 PM, Greg Gallagher wrote:
>
> I'll try to answer part of this. The detection of a cross domain call
> would come form the ipipe code in the kernel.  This is being called
> because the ipipe debug flags are on and it's detecting the switch
> from the root domain and then causing a panic so we can see the stack
> trace.
> I'm not sure why the ioctl call is causing this.  It looks like when
> we try to get the clock rate we start to access a normal Linux service
> which causes the stall and triggers the panic you see in your logs.
> I'm assuming in your write you aren't accessing a normal Linux
> resource so we don't see the attempt to switch domains and therefore
> no panic.
> Panics in general happen because the system is in a "bad" state, in
> this scenario it's not really "bad" we are just detecting the mode
> switch and then getting enough information to fix the issue.  This is
> why your system seems sane, but if you hit a worse panic then your
> system may not be stable enough to do anything.
>
> -Greg
>
> On Sat, May 12, 2018 at 5:53 PM, Steve Freyder <st...@freyder.net> wrote:
>
> Greetings again,
>
> Xenomai 3.0.6, armv7, imx6, imx_uart rtdm driver
>
> I've seen many postings about this, and about symbol wrapping, etc, etc.
> I'm still
> not understanding something very basic here, I'm sure.
>
> When I run a program built with --alchemy (no --posix) skin, and I execute
> these lines
> of code (error checking is omitted here but being done in the real program
> and not failing):
>
> #define SER_BAUD9600/**< Baud rate for SYNC interface */
> #define SYNC_DEVICE "rtser0"/**< serial device used for SYNC */
>
> static const struct rtser_config sync_config = {
> .config_mask   = 0x,
> .baud_rate = SER_BAUD,
> .parity= RTSER_NO_PARITY,
> .data_bits = RTSER_8_BITS,
> .stop_bits = RTSER_1_STOPB,
> .handshake = RTSER_NO_HAND,
> .fifo_depth= RTSER_FIFO_DEPTH_1,
> .rx_timeout= RTSER_TIMEOUT_NONE,
> .tx_timeout= 1e9,
> .event_timeout = 1e9,
> .timestamp_history = RTSER_DEF_TIMESTAMP_HISTORY,
> .event_mask= RTSER_EVENT_RXPEND,
> };
>
> fd = __RT(open)(SYNC_DEVICE,0) ;
>
> err = __RT(ioctl)(fd, RTSER_RTIOC_SET_CONFIG, _config);
>
> I g

Re: [Xenomai] RTDM serial illicit call from head domain 'Xenomai'

[Greg Gallagher]

I'll try to answer part of this. The detection of a cross domain call
would come form the ipipe code in the kernel.  This is being called
because the ipipe debug flags are on and it's detecting the switch
from the root domain and then causing a panic so we can see the stack
trace.
I'm not sure why the ioctl call is causing this.  It looks like when
we try to get the clock rate we start to access a normal Linux service
which causes the stall and triggers the panic you see in your logs.
I'm assuming in your write you aren't accessing a normal Linux
resource so we don't see the attempt to switch domains and therefore
no panic.
Panics in general happen because the system is in a "bad" state, in
this scenario it's not really "bad" we are just detecting the mode
switch and then getting enough information to fix the issue.  This is
why your system seems sane, but if you hit a worse panic then your
system may not be stable enough to do anything.

-Greg

On Sat, May 12, 2018 at 5:53 PM, Steve Freyder  wrote:
> Greetings again,
>
> Xenomai 3.0.6, armv7, imx6, imx_uart rtdm driver
>
> I've seen many postings about this, and about symbol wrapping, etc, etc.
> I'm still
> not understanding something very basic here, I'm sure.
>
> When I run a program built with --alchemy (no --posix) skin, and I execute
> these lines
> of code (error checking is omitted here but being done in the real program
> and not failing):
>
> #define SER_BAUD9600/**< Baud rate for SYNC interface */
> #define SYNC_DEVICE "rtser0"/**< serial device used for SYNC */
>
> static const struct rtser_config sync_config = {
> .config_mask   = 0x,
> .baud_rate = SER_BAUD,
> .parity= RTSER_NO_PARITY,
> .data_bits = RTSER_8_BITS,
> .stop_bits = RTSER_1_STOPB,
> .handshake = RTSER_NO_HAND,
> .fifo_depth= RTSER_FIFO_DEPTH_1,
> .rx_timeout= RTSER_TIMEOUT_NONE,
> .tx_timeout= 1e9,
> .event_timeout = 1e9,
> .timestamp_history = RTSER_DEF_TIMESTAMP_HISTORY,
> .event_mask= RTSER_EVENT_RXPEND,
> };
>
> fd = __RT(open)(SYNC_DEVICE,0) ;
>
> err = __RT(ioctl)(fd, RTSER_RTIOC_SET_CONFIG, _config);
>
> I get this traceback (once only per system boot):
>
> 
> [  411.088376] I-pipe: Detected illicit call from head domain 'Xenomai'
> [  411.088376] into a regular Linux service
> [  411.100666] CPU: 1 PID: 875 Comm: rtserE Not tainted
> 4.1.18_C01571-15S00-00.000.zimg+83fdace666 #1
> [  411.109644] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [  411.116189] Backtrace:
> [  411.118694] [<80014a64>] (dump_backtrace) from [<80014c9c>]
> (show_stack+0x20/0x24)
> [  411.126280]  r7: r6:0080 r5: r4:80b81c94
> [  411.132072] [<80014c7c>] (show_stack) from [<806b5f3c>]
> (dump_stack+0xa0/0xc4)
> [  411.139326] [<806b5e9c>] (dump_stack) from [<800ab000>]
> (ipipe_root_only+0x11c/0x188)
> [  411.147171]  r9:80c58300 r8: r7:80c45380 r6:80b34e6c r5:600d0013
> r4:809abba4
> [  411.155073] [<800aaee4>] (ipipe_root_only) from [<8001f5ac>]
> (ipipe_test_and_stall_root+0x18/0xc0)
> [  411.164046]  r10:bc5c0024 r9: r8:40480201 r7:0005 r6:2580
> r5:80bc154c
> [  411.172023]  r4:80ba5c9c r3:
> [  411.175675] [<8001f594>] (ipipe_test_and_stall_root) from [<806b8274>]
> (mutex_trylock+0x40/0x1ec)
> [  411.184561]  r7:0005 r6:2580 r5:80bc154c r4:80ba5c9c
> [  411.190358] [<806b8234>] (mutex_trylock) from [<80580d78>]
> (clk_prepare_lock+0x1c/0xfc)
> [  411.198376]  r7:0005 r6:2580 r5:bece7e50 r4:bec36480
> [  411.204164] [<80580d5c>] (clk_prepare_lock) from [<80581e8c>]
> (clk_core_get_rate+0x1c/0x70)
> [  411.212530]  r5:bece7e50 r4:bec36480
> [  411.216180] [<80581e70>] (clk_core_get_rate) from [<80581f04>]
> (clk_get_rate+0x24/0x28)
> [  411.224198]  r5:bece7e50 r4:bc5c2000
> [  411.227863] [<80581ee0>] (clk_get_rate) from [<7f08d2c4>]
> (rt_imx_uart_ioctl+0xa88/0xe5c [xeno_imx_uart])
> [  411.237464] [<7f08c83c>] (rt_imx_uart_ioctl [xeno_imx_uart]) from
> [<8010779c>] (rtdm_fd_ioctl+0xc0/0x218)
> [  411.247048]  r10:00011638 r9: r8:40480201 r7:0005 r6:bc5c
> r5:600d0013
> [  411.255025]  r4:80c58300
> [  411.257609] [<801076e0>] (rtdm_fd_ioctl) from [<8010dc70>]
> (CoBaLt_ioctl+0x18/0x1c)
> [  411.265280]  r3:00011638 r2:00011638 r1:40480201
> [  411.269989]  r10:bf648800 r9:c0943008 r8:8010dc58 r7:80b34e6c r6:0001
> r5:0052
> [  411.277964]  r4:bece7fb0
> [  411.280548] [<8010dc58>] (CoBaLt_ioctl) from [<8011efc4>]
> (ipipe_syscall_hook+0x174/0x380)
> [  411.288839] [<8011ee50>] (ipipe_syscall_hook) from [<800ad6d8>]
> (__ipipe_notify_syscall+0xa4/0x3e0)
> [  411.297899]  r10:bf648800 r9:80c45380 r8:80b34e6c r7:bf649800 r6:80c45380
> r5:0001
> [  411.305873]  

Re: [Xenomai] RTDM serial illicit call from head domain 'Xenomai'

[Greg Gallagher]

I can take a look at it this week. I'd like to trace through some of the 
drivers to get a better understanding of when or if they cause a domain switch.

  Original Message  
From: r...@xenomai.org
Sent: May 13, 2018 10:16 AM
To: g...@embeddedgreg.com; st...@freyder.net
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] RTDM serial illicit call from head domain 'Xenomai'

On 05/13/2018 07:02 AM, Greg Gallagher wrote:
> I won't say the driver is improperly written, this ioctl call may not
> be expected to be used in a low latency situation.  Some code maybe
> expected to be called at initialization time and then never again so
> it doesn't impact RT operation.  The rt_imx_uart driver is part of the
> Xenomai code base, I'm not 100% sure if this functions shouldn't be
> called from an RTDM driver or if the author needs to be aware they
> could just introduce latency when used in the rt context.
> These panics aren't kernel or driver errors, we are creating them on
> purpose to try to track down domain switches which could impact
> latency.  So as long as your latency number are acceptable you don't
> need to enable the debug flag to track down domain switches and these
> panics can be ignored for now.
>

I would recommend to fix the situation asap in the RTDM driver though
[1], because this may actually lead to crashes.

Those debug checks trap invalid re-entries of the regular kernel code
from the co-kernel (rt) context. This is an illustration of a possible
scenario involving such a bad re-entry:

   /* regular kernel context */
   spin_lock_irqsave(, flags);
  
 handle_rt_event();
    
    /* rt thread context. */
    ioctl(imx_fd, ...);
   /* invalid call of regular kernel code */
   spin_lock_irqsave(, flags);
   

IOW, we have to keep in mind that any IRQ routed to the real-time
co-kernel may preempt most of the regular kernel code, even though the
latter has [only virtually] disabled interrupts: making this event
possible is the purpose of the interrupt pipeline. The restriction which
is paired to this feature is that we may not re-enter the preempted
code, because the logic there still rightfully assumes this may not happen.

As a matter of fact, the interrupt pipeline potentially turns any device
IRQ as a NMI from the standpoint of a Linux kernel. In addition, the
co-kernel has its own scheduler to manage rt threads. In short, rt
activities are not serialized by the regular kernel locking scheme.

[1]
diff --git a/kernel/drivers/serial/rt_imx_uart.c
b/kernel/drivers/serial/rt_imx_uart.c
index 61836ae09..1aec219b7 100644
--- a/kernel/drivers/serial/rt_imx_uart.c
+++ b/kernel/drivers/serial/rt_imx_uart.c
@@ -963,6 +963,13 @@ static int rt_imx_uart_ioctl(struct rtdm_fd *fd,
struct rtser_config config_buf;
uint64_t *hist_buf = NULL;

+   /*
+   * We may call regular kernel services ahead, ask for
+   * re-entering secondary mode if need be.
+   */
+   if (rtdm_in_rt_context())
+   return -ENOSYS;
+
config = (struct rtser_config *)arg;

if (rtdm_fd_is_user(fd)) {
@@ -984,13 +991,6 @@ static int rt_imx_uart_ioctl(struct rtdm_fd *fd,
return -EINVAL;

if (config->config_mask & RTSER_SET_TIMESTAMP_HISTORY) {
-   /*
-   * Reflect the call to non-RT as we will likely
-   * allocate or free the buffer.
-   */
-   if (rtdm_in_rt_context())
-   return -ENOSYS;
-
if (config->timestamp_history &
RTSER_RX_TIMESTAMP_HISTORY)
hist_buf = kmalloc(IN_BUFFER_SIZE *
@@ -1000,7 +1000,8 @@ static int rt_imx_uart_ioctl(struct rtdm_fd *fd,

rt_imx_uart_set_config(ctx, config, _buf);

-   kfree(hist_buf);
+   if (hist_buf)
+   kfree(hist_buf);
break;
}

-- 
Philippe.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Xddp and socket: Address family not supported by protocol

[Greg Gallagher]

Do you have the module loaded or enabled in the kernel?

  Original Message  
From: libin.z...@envisioncn.com
Sent: May 17, 2018 9:13 AM
To: xenomai@xenomai.org
Subject: Re: [Xenomai] Xddp and socket: Address family not supported by protocol

Hi,

 Now,I install Xenomai-3.3 In Ubuntu 3.18.20,

 The latency test and cyclictest run good in my environment like that
[cid:image001.png@01D3EE1C.F980D020]

And execute the cmd :dmesg | grep -I xenomai,result like below:
[cid:image002.png@01D3EE1C.F980D020]

But when I run the demo test  iddp-label , the result is error ,the error 
message below:
socket: Address family not supported by protocol

So ,how can I make it right, can you help me ?

Thanks very much!


BR
tony




???(,?
This email message (including any attachments) is confidential and may be 
legally privileged. If you have received it by mistake, please notify the 
sender by return email and delete this message from your system. Any 
unauthorized use or dissemination of this message in whole or in part is 
strictly prohibited. Envision Energy Limited and all its subsidiaries shall not 
be liable for the improper or incomplete transmission of the information 
contained in this email nor for any delay in its receipt or damage to your 
system. Envision Energy Limited does not guarantee the integrity of this email 
message, nor that this email message is free of viruses, interceptions, or 
interference.
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16729 bytes
Desc: image001.png
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 12365 bytes
Desc: image002.png
URL: 

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Boot failed on arm64 - xenomai_init --> ipipe_send_ipi

[Greg Gallagher]

HI,
  What ipipe and kernel version are you using and what Xenomai branch
are you using?

-Greg

On Wed, May 16, 2018 at 2:13 PM, Auel, Kendall
 wrote:
> I'm trying to build a xenomai-enabled kernel for an arm64 (quad A53 cores). 
> Something is not configured correctly, but I haven't been able to get past a 
> stall during xenomai_init. Any ideas on what I'm doing wrong? Thanks.
>
> [0.729547] kvm [1]: 8-bit VMID
> [0.732121] kvm [1]: IDMAP page: 40c5e000
> [0.736134] kvm [1]: HYP VA range: 8000:
> [0.742609] kvm [1]: Hyp mode initialized successfully
> [0.747003] kvm [1]: GICv3: no GICV resource entry
> [0.751740] kvm [1]: disabling GICv2 emulation
> [0.756357] kvm [1]: GIC system register CPU interface enabled
> [0.762428] kvm [1]: vgic interrupt IRQ1
> [0.766021] kvm [1]: virtual timer IRQ4
> [0.775341] audit: initializing netlink subsys (disabled)
> [0.777914] audit: type=2000 audit(0.675:1): initialized
> [0.783729] [Xenomai] scheduling class idle registered.
> [0.788506] [Xenomai] scheduling class rt registered.
> [   21.795205] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [   21.798018]  2-...: (0 ticks this GP) idle=4c9/140/0 
> softirq=129/129 fqs=2428
> [   21.806295]  (detected by 1, t=5255 jiffies, g=-252, c=-253, q=106)
> [   21.812575] Task dump for CPU 2:
> [   21.815801] swapper/0   R  running task0 1  0 
> 0x0002
> [   21.822864] Call trace:
> [   21.825315] [] __switch_to+0x8c/0xa0
> [   21.830456] [] gic_raise_softirq+0x58/0x170
> [   21.836208] [] ipipe_send_ipi+0x24/0x30
> [   21.841615] [] ipipe_critical_enter+0x108/0x1a8
> [   21.847719] [] ipipe_select_timers+0x2d8/0x320
> [   21.853736] [] xenomai_init+0x158/0x4c4
> [   21.859141] [] do_one_initcall+0x38/0x128
> [   21.864724] [] kernel_init_freeable+0x1ac/0x24c
> [   21.870828] [] kernel_init+0x10/0x100
> [   21.876056] [] ret_from_fork+0x14/0x30
>
> Thanks,
> Kendall Auel, Senior Embedded Software Engineer
> 3D Systems, 26600 SW Parkway Ave., Suite 300, Dock 61, Wilsonville OR 97070, 
> USA
> Tel: +1 503 482 1970   Mobile: +1 503 939 6862   
> 3dsystems.com
>
> [3D-Systems-logo_primary_3-color_light-bkgrd_no-tm]
>
> This e-mail is intended for the exclusive use of the recipients named above 
> and may constitute privileged or confidential information or otherwise be 
> protected from disclosure. Dissemination, distribution, forwarding or copying 
> of this e-mail by anyone other than the intended recipients is prohibited. If 
> you have received this e-mail in error, please notify me immediately by reply 
> e-mail or telephone and completely delete or destroy any and all electronic 
> or other copies of the original message and any attachments to it. Thank you.
>
> -- next part --
> A non-text attachment was scrubbed...
> Name: image001.png
> Type: image/png
> Size: 10651 bytes
> Desc: image001.png
> URL: 
> 
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] RPi zero: high resolution clock not working

[Greg Gallagher]

I have the ipipe support for the bcm2835 done, I'll submit the patch
shortly.  Once that's in the ipipe-arm tree we can start building
xenomai for the rpi zero.

On Wed, May 9, 2018 at 8:50 AM, Gustav Johansson  wrote:
> Hi!
>
>
> I have managed to boot RPI zero with Cobalt on kernel version 4.9.51, with 
> ipipe #4.
>
> Im using the mainline. I used config multi_v7_defconfig and chose armv6 from 
> there.
>
> Im using the device tree bcm2835-rpi-zero.dtb
>
>
> During the boot I receives errors:
>
> [0.27] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps 
> every 2147483647500ns
> [0.74] clocksource: timer: mask: 0x max_cycles: 0x, 
> max_idle_ns: 1911260446275 ns
> [0.000698] Interrupt pipeline (release #4)
> [0.069805] clocksource: jiffies: mask: 0x max_cycles: 0x, 
> max_idle_ns: 1911260446275 ns
> [0.107627] PTP clock support registered
> [0.111409] clocksource: Switched to clocksource timer
> [0.180098] [Xenomai] scheduling class idle registered.
> [0.180287] [Xenomai] scheduling class rt registered.
> [0.180527] I-pipe: high-resolution clock not working
> [0.180726] [Xenomai] init failed, code -19
> [0.207251] clk: couldn't get clock 0 for /soc/pwm@7e20c000
> [0.572597] i2c-bcm2835 20805000.i2c: Could not read clock-frequency 
> property
> [5.063088] systemd[1]: System time before build time, advancing clock.
> [6.685798] systemd[1]: Mounting RPC Pipe File System...
>
>
> So the error tells me that the high-resolution clock is not working and 
> Xenomai failed the init with error code -19.
>
>
> The boot continues and I can use it as regular but /proc/xenomai does not 
> exist.
>
>
> Any ideas on ways I can make it work? I have included the dmesg log and 
> kernel config.
>
>
> Regards,
>
> Gustav
> -- next part --
> A non-text attachment was scrubbed...
> Name: dmesg.log
> Type: text/x-log
> Size: 17028 bytes
> Desc: dmesg.log
> URL: 
> 
> -- next part --
> A non-text attachment was scrubbed...
> Name: ATT07561.config
> Type: application/octet-stream
> Size: 134322 bytes
> Desc: ATT07561.config
> URL: 
> 
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Reference Images Alpha Release

[Greg Gallagher]

https://github.com/ggallagher31/xenomai-3-alpha-images/blob/master/README.md


Here is the first attempt of Xenomai-3 reference images, this is based
on 4.14 ipipe kernel and the rootfs is a Ubuntu based.  Xenomai was
built off the stable-3.0.x branch.  The images are currently hosted on
google drive which may change later but for now it should work.  Ping
me if there are access problems.

Currently only RPI2 is in included with a extremely simple RT app.
Zynq boards and gpio examples will be posted this weekend (yay long
weekend).

Please send any feedback or suggestion of improvements directly to me
g...@embeddedgreg.com

Thanks

Greg

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Boot failed on arm64 - xenomai_init --> ipipe_send_ipi

[Greg Gallagher]

I know Philippe put a change into the arm 32-bit ipipe for the new gic
in the imx7d which was causing a lock up.  I'm not sure if this is a
similar thing.

-Greg

On Wed, May 16, 2018 at 4:00 PM, Auel, Kendall
 wrote:
> Greg,
>
> The kernel is 4.9.51, modified by NXP for the i.MX8, the Xenomai branch is 
> "next", and the ipipe patch is ipipe-core-4.9.51-arm64-4.patch.
>
> Also, I modified the defconfig to turn off CONFIG_CPU_FREQ and 
> CONFIG_ACPI_PROCESSOR. I've also tried a version with PAGE_MIGRATION disabled 
> and got the same result.
>
> - Kendall
>
>>
>> HI,
>>   What ipipe and kernel version are you using and what Xenomai branch are
>> you using?
>>
>> -Greg
>>
>> On Wed, May 16, 2018 at 2:13 PM, Auel, Kendall
>>  wrote:
>> > I'm trying to build a xenomai-enabled kernel for an arm64 (quad A53 cores).
>> Something is not configured correctly, but I haven't been able to get past a
>> stall during xenomai_init. Any ideas on what I'm doing wrong? Thanks.
>> >
>> > [0.729547] kvm [1]: 8-bit VMID
>> > [0.732121] kvm [1]: IDMAP page: 40c5e000
>> > [0.736134] kvm [1]: HYP VA range: 8000:
>> > [0.742609] kvm [1]: Hyp mode initialized successfully
>> > [0.747003] kvm [1]: GICv3: no GICV resource entry
>> > [0.751740] kvm [1]: disabling GICv2 emulation
>> > [0.756357] kvm [1]: GIC system register CPU interface enabled
>> > [0.762428] kvm [1]: vgic interrupt IRQ1
>> > [0.766021] kvm [1]: virtual timer IRQ4
>> > [0.775341] audit: initializing netlink subsys (disabled)
>> > [0.777914] audit: type=2000 audit(0.675:1): initialized
>> > [0.783729] [Xenomai] scheduling class idle registered.
>> > [0.788506] [Xenomai] scheduling class rt registered.
>> > [   21.795205] INFO: rcu_preempt detected stalls on CPUs/tasks:
>> > [   21.798018]  2-...: (0 ticks this GP) idle=4c9/140/0
>> softirq=129/129 fqs=2428
>> > [   21.806295]  (detected by 1, t=5255 jiffies, g=-252, c=-253, q=106)
>> > [   21.812575] Task dump for CPU 2:
>> > [   21.815801] swapper/0   R  running task0 1  0 
>> > 0x0002
>> > [   21.822864] Call trace:
>> > [   21.825315] [] __switch_to+0x8c/0xa0
>> > [   21.830456] [] gic_raise_softirq+0x58/0x170
>> > [   21.836208] [] ipipe_send_ipi+0x24/0x30
>> > [   21.841615] [] ipipe_critical_enter+0x108/0x1a8
>> > [   21.847719] [] ipipe_select_timers+0x2d8/0x320
>> > [   21.853736] [] xenomai_init+0x158/0x4c4
>> > [   21.859141] [] do_one_initcall+0x38/0x128
>> > [   21.864724] [] kernel_init_freeable+0x1ac/0x24c
>> > [   21.870828] [] kernel_init+0x10/0x100
>> > [   21.876056] [] ret_from_fork+0x14/0x30
>> >
>> > Thanks,
>> > Kendall Auel, Senior Embedded Software Engineer 3D Systems, 26600 SW
>> > Parkway Ave., Suite 300, Dock 61, Wilsonville OR 97070, USA
>> > Tel: +1 503 482 1970   Mobile: +1 503 939 6862
>> 3dsystems.com
>> >
>> > [3D-Systems-logo_primary_3-color_light-bkgrd_no-tm]
>> >
>> > This e-mail is intended for the exclusive use of the recipients named above
>> and may constitute privileged or confidential information or otherwise be
>> protected from disclosure. Dissemination, distribution, forwarding or copying
>> of this e-mail by anyone other than the intended recipients is prohibited. If
>> you have received this e-mail in error, please notify me immediately by reply
>> e-mail or telephone and completely delete or destroy any and all electronic
>> or other copies of the original message and any attachments to it. Thank you.
>> >
>> > -- next part -- A non-text attachment was
>> > scrubbed...
>> > Name: image001.png
>> > Type: image/png
>> > Size: 10651 bytes
>> > Desc: image001.png
>> > URL:
>> >
>> > t
>> > tachment.png>
>> ___
>> > Xenomai mailing list
>> > Xenomai@xenomai.org
>> > https://xenomai.org/mailman/listinfo/xenomai
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Only 2 serial ports at a time with xeno_16550A driver

[Greg Gallagher]

This is highly likely, I'm not sure when this driver was last tested.
Are you able to put a patch together?  Has anyone else sense similar
behaviour?

-Greg

On Tue, May 22, 2018 at 2:31 PM, C Smith  wrote:
> I think I may have found a bug in the rtl_16550A driver when using shared
> interrupts. (I am on Xenomai 2.6.5. Kernel 3.18.20.)
>
> I think the interrupt handler is not sending an EOI to the lower (ISA 8259)
> interrupt controller, though it certainly is doing the right thing for
> higher IRQs above 16.
>
> I used a Moxa 4-port serial card in the PCI bus which has all 4 ports
> sharing IRQ 17. The rtl_16550A driver can use all 4 ports OK.
>
> But the rtl_16550A driver stalls after one interrupt when I use multiple
> serial ports on my motherboard where all the serial ports share IRQ 5. This
> is indicated by the fact that I can send one byte out the port, or I can
> get a single byte into the port, before the port can no longer send or
> receive anything further.
>
> I diffed the Xenomai 3.0.5 source versus the 2.6.5 rtl_16550A.c source and
> the code is very similar so the liability is in both branches I assume.
>
> -C Smith
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] INTR-REMAP issue while enabling GPIO interrupt as RTDM interrupt

[Greg Gallagher]

I'm probably not much help but something similar was on the list a while ago:

https://xenomai.org/pipermail/xenomai/2017-November/038014.html

On Thu, Jun 7, 2018 at 11:55 AM, Yan, Hongliang  wrote:
> Hi All,
>   I am trying to enable pinctrl-intel.c GPIO interrupt as RTDM interrupt. I 
> use rtdm_irq_request to replace devm_request_irq in probe function.
>   code is as following:
> ===
> #if 1
> if ((ret = rtdm_irq_request(_rtdm,
> irq, handler_interruption,
> 0,
> "test", NULL)) != 0) {
> printk("rtdm request error\n");
> }
>
> #else
> ret = devm_request_irq(pctrl->dev, irq, intel_gpio_irq, IRQF_SHARED,
>dev_name(pctrl->dev), pctrl);
> if (ret) {
> dev_err(pctrl->dev, "failed to request interrupt\n");
> goto fail;
> }
> #endif
> =
>   I check /proc/xenomai/irq, it shows GPIO interrupt has been registered as 
> XENOMAI interrupt.
> =
> [root@localhost devices]# cat /proc/xenomai/irq
>   IRQ CPU0CPU1CPU2CPU3
>14:   0   0   0   0 test
> 4352:   0   0   0   0 [sync]
> 4353:   0   0   0   1 [reschedule]
> 4354: 1007738  987012 1007340 1082939 [timer/0]
> 4355:   1   1   0   1 [timer-ipi]
> 4419:   0   0   0   0 [virtual]
> ===
> But once I trigger the GPIO interrupt, the interrupt handler can't be called. 
> Instead, it shows:
> <3>[  156.957511] DMAR: DRHD: handling fault status reg 2
> <3>[  156.957541] DMAR: INTR-REMAP: Request device [[f0:1f.0] fault index 0
> <3>[  156.957541] INTR-REMAP:[fault reason 37] Blocked a compatibility format 
> interrupt request
>
> I also list lspci -v, there is no device named f0:1f.0.
> Could someone help me with this? Did I miss something when request RTDM 
> interrupt?
>
> Best Regards,
>
> Archer Yan
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] ipipe-4.4.y LTS

[Greg Gallagher]

Are there still plans to have a ipipe patch for the CIP kernel?  I
think this was brought up at the last meet up?  Maybe the bigger
question (which is a lot more work) is do we plan on maintaining ipipe
for 4.4, 4.9 and older?

-Greg

On Mon, Jun 18, 2018 at 8:52 AM, Radu Rendec  wrote:
> Hi all,
>
> Are there any plans to maintain the ipipe-4.4.y branch and update it to
> later versions of kernel 4.4? It would be nice to have, since at this
> point kernel 4.4 has the longest projected EOL.
>
> Currently the latest thing that can be merged cleanly on top of
> ipipe-core-4.4.71-powerpc-8 is kernel 4.4.73, which is only 2 releases
> later than what's already in there.
>
> Thanks,
> Radu Rendec
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] rpi3 - very high negative latency for simple xeno task

[Greg Gallagher]

Hi Pintu,
   I just started doing some work recently with the RPI3 to see how
Xenomai performs, but I haven't made it too far at the moment.  How
did you tune the system?

-Greg

On Sun, Jun 17, 2018 at 10:07 AM, Pintu Kumar  wrote:
> Dear Greg,
>
> Do you have any comment about this?
> On Wed, Jun 6, 2018 at 11:11 AM Pintu Kumar  wrote:
>>
>> Hi,
>>
>> I have a simple demo program, which just create one rt_task (using
>> native API) and inside the task, I just rt_printf "some logs" for 10
>> times, with 100us interval.
>>
>> Today I checked this program first time on Raspberry Pi 3, Model B.
>> Xenomai: 3.0.6
>> ARCH = arm32
>> Kernel: 4.9.80 for rpi3
>>
>> Here is the output:
>> -
>> native $ sudo ./simple_xeno_task 10
>> main: creating task name: task0, priority: 99
>> Task: 0, Iteration: 10, Sleep duration: 100 us
>>
>> Task[0] - Avg Latency: -9.630 us
>> Task[0] - Max Latency: 0.052 us
>> Task[0] - Min Latency: -67.448 us
>> 1 32.552 -67.448
>> 2 75.261 -24.739
>> 3 97.657 -2.343
>> 4 99.479 -0.521
>> 5 99.791 -0.209
>> 6 99.740 -0.260
>> 7 100.052 0.052
>> 8 99.635 -0.365
>> 9 99.740 -0.260
>> 10 99.792 -0.208
>> ALL FINISHED...!!!
>> ---
>>
>> If you see, the first 2 iterations have very large negative values.
>> What could be the cause of this?
>> As per RTOS, I expect the output to be close to 100us always.
>>
>>
>> When I run the same program on x86_64 machine I get the below output:
>> 
>> ./simple_xeno_task 10
>> main: creating task name: task0, priority: 99
>> Task: 0, Iteration: 10, Sleep duration: 100 us
>>
>> Task[0] - Avg Latency: -0.680 us
>> Task[0] - Max Latency: 0.043 us
>> Task[0] - Min Latency: -5.868 us
>> 1 94.132 -5.868
>> 2 99.127 -0.873
>> 3 99.955 -0.045
>> 4 100.043 0.043
>> 5 99.990 -0.010
>> 6 99.959 -0.041
>> 7 100.017 0.017
>> 8 99.977 -0.023
>> 9 99.965 -0.035
>> 10 100.039 0.039
>> ALL FINISHED...!!!
>> 
>>
>> So, I wonder what could be the cause of negative latency on Rpi3 with 
>> Xenomai.
>>
>>
>> This is the latency output on Rpi3:
>> --
>> sudo /usr/xenomai/bin/latency
>> == Sampling period: 1000 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> warming up...
>> RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
>> RTH|lat min|lat avg|lat max|-overrun|---msw|---lat best|--lat 
>> worst
>> RTD|  0.625|  1.374|  5.312|   0| 0|  0.625|  
>> 5.312
>> RTD|  0.624|  1.376|  5.468|   0| 0|  0.624|  
>> 5.468
>> RTD|  0.624|  1.373|  5.676|   0| 0|  0.624|  
>> 5.676
>> RTD|  0.623|  1.372|  9.426|   0| 0|  0.623|  
>> 9.426
>> RTD|  0.467|  1.355|  4.582|   0| 0|  0.467|  
>> 9.426
>> RTD|  0.623|  1.384|  9.113|   0| 0|  0.467|  
>> 9.426
>> RTD|  0.622|  1.379|  5.935|   0| 0|  0.467|  
>> 9.426
>> RTD|  0.622|  1.359|  4.581|   0| 0|  0.467|  
>> 9.426
>> RTD|  0.622|  1.372|  7.028|   0| 0|  0.467|  
>> 9.426
>> RTD|  0.621|  1.361|  6.038|   0| 0|  0.467|  
>> 9.426
>> RTD|  0.621|  1.360|  4.267|   0| 0|  0.467|  
>> 9.426
>> RTD|  0.673|  1.364| 10.256|   0| 0|  0.467| 
>> 10.256
>> RTD|  0.672|  1.363|  6.453|   0| 0|  0.467| 
>> 10.256
>> RTD|  0.620|  1.352|  4.161|   0| 0|  0.467| 
>> 10.256
>> RTD|  0.619|  1.373|  7.234|   0| 0|  0.467| 
>> 10.256
>> RTD|  0.619|  1.352|  6.140|   0| 0|  0.467| 
>> 10.256
>> RTD|  0.671|  1.352|  4.733|   0| 0|  0.467| 
>> 10.256
>> RTD|  0.566|  1.363|  5.514|   0| 0|  0.467| 
>> 10.256
>> RTD|  0.618|  1.368|  6.712|   0| 0|  0.467| 
>> 10.256
>> RTD|  0.618|  1.353|  4.420|   0| 0|  0.467| 
>> 10.256
>> RTD|  0.617|  1.368|  6.815|   0| 0|  0.467| 
>> 10.256
>> ^C---|---|---|---||--|-
>>
>> --
>>
>>
>> Thanks,
>> Pintu
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xenomai modules - xeno_rtdm, xeno_hal, xeno_nucleus. not getting installed

[Greg Gallagher]

Did you turn them on in menuconfig when you built your kernel?

-Greg

On Mon, Jun 18, 2018 at 1:40 AM, Ashok kumar  wrote:
> Hi,
>
> I have patched xenomai -2.6.4 with linux 3.18.20 .
> and installed the patched kernel, and  compiled the xenomai library using 
> below
> commands
>
> cd /usr/src
> sudo mkdir build_xenomai-2.6.4
> cd build_xenomai-2.6.4
>
> sudo ../xenomai-2.6.4/configure --enable-shared --enable-smp --enable-x86-sep
> sudo make -j8
> sudo make install
>
> in /usr/xenomai/ I am not able to get the modules directory and xenomai 
> modules
> are not available ,xeno_rtdm,xeno_hal,xeno_nucleus.
>
> I used the below command to load the modules
>
> sudo modprobe xeno_rtdm,
> sudo modprobe xeno_hal
> sudo modprobe xeno_nucleus
>
> but the modules are not getting loaded.
>
>
> is there any modification should be done in the make file, or any
> other options should be enabled in the configure options
>
> kindly help me the get the xenomai modules available.
>
>
> Thank you
> R.Ashokkumar
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] how to install the following modules xeno_rtdm xeno_hal xeno_nucleus to use RTnet

[Greg Gallagher]

Do you have the modules enabled in the CONFIG? How are you configuring
your kernel?

-Greg

On Wed, Jun 13, 2018 at 1:06 AM, Ashok kumar  wrote:
> Hi,
>
> I am using xenomai -2.6.2.1 and I have patched the xenomai -2.6.2.1
> with linux kernel 3.4.6
> and I installed using the following commands
>
> sudo make-kpkg --bzimage --initrd --append-to-version=-xenomai-2.6.4
> -j8 kernel-image kernel-headers modules
> # Install kernel
> cd ..
> sudo dpkg -i linux-image-*.deb
> sudo dpkg -i linux-headers-*.deb
>
> sudo ../xenomai-2.6.4/configure --enable-shared --enable-smp --enable-x86-sep
> sudo make -j8
> sudo make install
>
> cd /etc/ld.so.conf.d/
> sudo touch xenomai.conf
> sudo sh -c "echo '/usr/xenomai/lib' >> xenomai.conf"
> sudo ldconfig
>
> echo "export PATH=$PATH:/usr/xenomai/bin" >> ~/.bashrc
> # echo "export 
> PATH=$PATH:/usr/xenomai/bin:/usr/xenomai/lib:/usr/xenomai/include"
>>> ~/.bashrc
> sudo su
> echo "export PATH=$PATH:/usr/xenomai/bin" >> ~/.bashrc
> # echo "export 
> PATH=$PATH:/usr/xenomai/bin:/usr/xenomai/lib:/usr/xenomai/include"
>>> ~/.bashr
> * 
> after installing xenomai-2.6.4 with linux kernel 3.4.6
> I am not able to get the module in the xenomai directory, to use  RTnet
>
> ‌I  required to load the modules  for RTnet operations
> sudo modprobe xeno_rtdm
> sudo modprobe xeno_hal
> sudo modprobe xeno_nucleus
>
> after executing this command I am using lsmod to view these modules
> ,but the modules are not getting loaded.
>
> In /usr/xenomai I am not able to see the modules.
>
> help me to get the following module xeno_rtdm, xeno_hal, xeno_nucleus
> install to use the rtnet
>
>
> Thank you
> R. Ashokkumar
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] How to print to dmesg buffer from an RT task

[Greg Gallagher]

You can try to write to /dev/kmsg, but this is a Linux resource so it
will impact which domain your thread is running on.  AFAIK user space
tasks shouldn't be logging to the kernel log for the most part.  One
solution I've seen is to create a driver (in your case RTDM driver) to
take in log messages and log them to the kernel log.

-Greg

On Wed, Jun 13, 2018 at 1:25 PM, C Smith  wrote:
> I'd like my Xenomai task to write to both stdout and also to the kernel's
> dmesg buffer.
> It is a periodic task started with rt_task_create().
> When I do rt_vfprintf(stdout, ...)
> it prints to stdout OK, but I also want to send the same string to the
> dmesg buffer, and
> I can't call printk() or rtdm_printk() because this task isn't a kernel
> module.
>
> (I'm using Xenomai 2.6.5 on x86.)
>
> Thanks
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xenomai modules - xeno_rtdm, xeno_hal, xeno_nucleus. not getting installed

[Greg Gallagher]

You can use RTNet with Xenomai-3, please look through the mail list,
there have been many threads about configuring RTNet and Xenomai-3.
RTNet is built into Xenomai-3, you don't need these modules.  The link
below has some good information on RTNet.

https://gitlab.denx.de/Xenomai/xenomai/wikis/Programming

For your module problem you need to look at the  make-kpkg command and
see how to use modules_image flag.  It should build your modules.

-Greg

On Tue, Jun 19, 2018 at 2:33 PM, Ashok kumar  wrote:
> I want to use xenomai with RTnet, so that I can use soem ethercat
> protocol for controlling applications for servo drive.
> for this I need to load the following modules.
>
> sudo modprobe xeno_rtdm.ko
> sudo modprobe xeno_hal.ko
> sudo modprobe xeno_nucleus.ko
>
> I followed this links to go with, but I got struck with the problem to
> get the modules installed,
> mainly rtdm modules which is used to open rteth0 for ethercat communication.
>
> https://gist.github.com/cbhust/62a01ff22007b9695ef1da2ccc16b993
>
> can you please help to solve the problems to configure and to build
> the kernel and installing the modules in x86_64 architecture.
>
> Thank you
>
>
> On Tue, Jun 19, 2018 at 11:11 PM, Greg Gallagher  
> wrote:
>> You won't need them for Xenomai-3 if you aren't using things like
>> rtnet, ipc or any driver that can be found in the Xenomai tree.  Are
>> you using a Debian system?  This tutorial will get you started:
>>
>> http://rtt-lwr.readthedocs.io/en/latest/rtpc/xenomai3.html
>>
>> You'll post later tonight my steps on building an x86 kernel.  With
>> the above tutorial you'll need to do the modules_image step to
>> generate an image for the modules.  If you explain what you are trying
>> to achieve I may be able to help you configure you system better.
>>
>> -Greg
>>
>> On Tue, Jun 19, 2018 at 1:26 PM, Ashok kumar  wrote:
>>> can you please provide me steps to
>>> configure and to build xenomai -3 in x86_64 architecture.
>>>
>>> to get the modules xeno_rtdm.ko,xeno_hal.ko,xeno_nucleus.ko.
>>>
>>> thank you
>>>
>>> On Tue, Jun 19, 2018 at 10:35 PM, Ashok kumar  
>>> wrote:
>>>> Ok I will go through the make-kpkg command can you please provide me
>>>> to how to build xenomai -3 in x86_64 architecture.
>>>>
>>>> to get the modules xeno_rtdm.ko,xeno_hal.ko,xeno_nucleus.ko.
>>>>
>>>>
>>>>
>>>> On Tue, Jun 19, 2018 at 10:24 PM, Greg Gallagher  
>>>> wrote:
>>>>> Look at the documentation for make-kpkg, you need to build the modules
>>>>> using 'modules_image'
>>>>>
>>>>> https://manpages.debian.org/jessie/kernel-package/make-kpkg.1.en.html
>>>>>
>>>>> I don't think this is a Xenomai problem, this is an issue with using 
>>>>> make-kpkg.
>>>>>
>>>>> There are other ways to build a kernel for x86_64 that you can follow.
>>>>> If this isn't an existing project I really recommend using Xenomai-3
>>>>> instead of the older version.
>>>>>
>>>>> -Greg
>>>>>
>>>>> On Tue, Jun 19, 2018 at 12:45 PM, Ashok kumar  
>>>>> wrote:
>>>>>> I have build  3.14.17-xenomai-2.6.4 and I have build
>>>>>> 3.14.17-xenomai-2.6.4 too using the links below
>>>>>>
>>>>>> https://github.com/lma-cfpp/cfppa-framework-old/wiki/Xenomai-Kernel
>>>>>> http://rtt-lwr.readthedocs.io/en/latest/rtpc/xenomai.html
>>>>>>
>>>>>> http://rtt-lwr.readthedocs.io/en/latest/adv-tutos/bicompil.html
>>>>>>
>>>>>> both gave me the same result, and I am using x86_64 architecture.
>>>>>>
>>>>>> On Tue, Jun 19, 2018 at 10:10 PM, Greg Gallagher  
>>>>>> wrote:
>>>>>>> You said before you are using 3.18.20?  Are you building for 3.18.20
>>>>>>> or 3.14.17? Are you seeing the object files in your build directory in
>>>>>>> the driver folder?
>>>>>>>
>>>>>>> On Tue, Jun 19, 2018 at 12:33 PM, Ashok kumar  
>>>>>>> wrote:
>>>>>>>> in my lib/module/
>>>>>>>>
>>>>>>>> I am able to get this folder 3.14.17-xenomai-2.6.4 ,
>>>>>>>> in this folder I am able to get xeno_rtdm.o,xeno_hal.o,xeno_nucleus.o.
>>>>>>>> some where in arch , drivers, ke

Re: [Xenomai] xenomai modules - xeno_rtdm, xeno_hal, xeno_nucleus. not getting installed

[Greg Gallagher]

Are you building the RTDM modules? Do you see them getting built in
the kernel output.

Please refrain from continuously posting the same question, we will
try to help you but it may take some time to respond.

-Greg

On Tue, Jun 19, 2018 at 5:44 AM, Ashok kumar  wrote:
> Hi,
>
> I have turned modules ON, I have attached the enable modules section
> in the kernel configuration
>
> thank you
> R.Ashokkumar
>
>
>
> On Mon, Jun 18, 2018 at 7:30 PM, Greg Gallagher  wrote:
>> Did you turn them on in menuconfig when you built your kernel?
>>
>> -Greg
>>
>> On Mon, Jun 18, 2018 at 1:40 AM, Ashok kumar  wrote:
>>> Hi,
>>>
>>> I have patched xenomai -2.6.4 with linux 3.18.20 .
>>> and installed the patched kernel, and  compiled the xenomai library using 
>>> below
>>> commands
>>>
>>> cd /usr/src
>>> sudo mkdir build_xenomai-2.6.4
>>> cd build_xenomai-2.6.4
>>>
>>> sudo ../xenomai-2.6.4/configure --enable-shared --enable-smp 
>>> --enable-x86-sep
>>> sudo make -j8
>>> sudo make install
>>>
>>> in /usr/xenomai/ I am not able to get the modules directory and xenomai 
>>> modules
>>> are not available ,xeno_rtdm,xeno_hal,xeno_nucleus.
>>>
>>> I used the below command to load the modules
>>>
>>> sudo modprobe xeno_rtdm,
>>> sudo modprobe xeno_hal
>>> sudo modprobe xeno_nucleus
>>>
>>> but the modules are not getting loaded.
>>>
>>>
>>> is there any modification should be done in the make file, or any
>>> other options should be enabled in the configure options
>>>
>>> kindly help me the get the xenomai modules available.
>>>
>>>
>>> Thank you
>>> R.Ashokkumar
>>>
>>> ___
>>> Xenomai mailing list
>>> Xenomai@xenomai.org
>>> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xenomai modules - xeno_rtdm, xeno_hal, xeno_nucleus. not getting installed

[Greg Gallagher]

When you install your package what do you see under /lib/modules ?

On Tue, Jun 19, 2018 at 12:13 PM, Ashok kumar  wrote:
> sudo make menuconfig
>
> make-kpkg --bzimage --initrd --append-to-version=-xenomai-2.6.4 -j8
> kernel-image kernel-headers modules
>
> On Tue, Jun 19, 2018 at 9:41 PM, Greg Gallagher  wrote:
>> What command are you using to build the kernel?
>>
>> On Tue, Jun 19, 2018 at 12:02 PM, Ashok kumar  
>> wrote:
>>> I too have followed the steps as mentioned in
>>> http://www.orocos.org/files/tut_install_orocos_hydro_xeno.txt
>>>
>>> in kernel config point number  7. Make appropriate changes to
>>> Real-time sub-system.
>>>
>>> I am using x86_64 architecture ,64 bit processor
>>> what features should I enable and disable to get these modules
>>> xeno_rtdm.ko,xeno_hal.ko,xeno_nucleus.ko.
>>> in Real-time sub-system. kernel configuration.
>>>
>>>
>>> # Configure and build kernel
>>> # 1. Processor type and features -> Processor family -- select proper
>>> #processor.
>>> # 2. Power management and ACPI options -> ACPI (Advanced Configuration and
>>> #Power Interface) Support -- turn of Processor.
>>> # 3. Power management and ACPI options -> CPU Frequency scaling -- turn off
>>> #CPU Frequency scaling.
>>> # 4. Power management and ACPI options -- turn off CPU idle PM support.
>>> # 5. Kernel hacking turn off KGDB: kernel debugger.
>>> # 6. Turn off Virtualization.
>>> # 7. Make appropriate changes to Real-time sub-system.
>>> # 8. Device Drivers -> IOMMU Hardware Support -- turn off
>>>
>>>
>>> On Tue, Jun 19, 2018 at 9:24 PM, Greg Gallagher  
>>> wrote:
>>>> Make sure you do your make step with 'make modules'.  I used this
>>>> tutorial [1] when i was building xenomai 2.6 a long time ago, it
>>>> should help you as well.
>>>>
>>>> [1] http://www.orocos.org/files/tut_install_orocos_hydro_xeno.txt
>>>>
>>>> On Tue, Jun 19, 2018 at 11:47 AM, Ashok kumar  
>>>> wrote:
>>>>> In menuconfig I have used
>>>>>
>>>>> the following
>>>>>
>>>>> * General setup
>>>>>   --> Local version - append to kernel release: -xenomai-2.6.5
>>>>>   --> Timers subsystem
>>>>>   --> High Resolution Timer Support (Enable)
>>>>> * Real-time sub-system
>>>>>   --> Xenomai (Enable)
>>>>>   --> Nucleus (Enable)
>>>>>   --> Pervasive real-time support in user-space (Enable)
>>>>> * Power management and ACPI options
>>>>>   --> Run-time PM core functionality (Disable)
>>>>>   --> ACPI (Advanced Configuration and Power Interface) Support
>>>>>   --> Processor (Disable)
>>>>>   --> CPU Frequency scaling
>>>>>   --> CPU Frequency scaling (Disable)
>>>>>   --> CPU idle
>>>>>   --> CPU idle PM support (Disable)
>>>>> * Pocessor type and features
>>>>>   --> Processor family
>>>>>   --> Core 2/newer Xeon (if \"cat /proc/cpuinfo | grep family\"
>>>>> returns 6, set as Generic otherwise)
>>>>> * Power management and ACPI options
>>>>>   --> Memory power savings
>>>>>   --> Intel chipset idle memory power saving driver (Disable)
>>>>> and in nucleus I have seleted RTDM drivers, in interfaces,drivers etc
>>>>>
>>>>> and I am using x86_64 processor configuration.
>>>>>
>>>>>
>>>>> On Tue, Jun 19, 2018 at 9:12 PM, Greg Gallagher  
>>>>> wrote:
>>>>>> Under the Xenomai section of menuconfig, do you have them selected as
>>>>>> modules you can load or built into the kernel?  Also you are using a
>>>>>> pretty old version on Xenomai, have you considered using Xenomai-3
>>>>>> instead?  I haven't used Xenomai 2.6 in a while so my support may be
>>>>>> rusty.
>>>>>>
>>>>>> On Tue, Jun 19, 2018 at 11:29 AM, Ashok kumar  
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am getting xeno_rtdm.o,xeno_hal.o,xeno_nucleus.o. file but I am not
>>>>>>> getting xeno_rtdm.ko, xeno_hal.ko, xeno_nucleus.ko
>>>>>>&g

Re: [Xenomai] xenomai modules - xeno_rtdm, xeno_hal, xeno_nucleus. not getting installed

[Greg Gallagher]

Under the Xenomai section of menuconfig, do you have them selected as
modules you can load or built into the kernel?  Also you are using a
pretty old version on Xenomai, have you considered using Xenomai-3
instead?  I haven't used Xenomai 2.6 in a while so my support may be
rusty.

On Tue, Jun 19, 2018 at 11:29 AM, Ashok kumar  wrote:
> Hi,
>
> I am getting xeno_rtdm.o,xeno_hal.o,xeno_nucleus.o. file but I am not
> getting xeno_rtdm.ko, xeno_hal.ko, xeno_nucleus.ko
>
> I should get .ko file to load it in kernel module .
>
> Thank you
>
>
> On Tue, Jun 19, 2018 at 8:47 PM, Greg Gallagher  wrote:
>> Are you building the RTDM modules? Do you see them getting built in
>> the kernel output.
>>
>> Please refrain from continuously posting the same question, we will
>> try to help you but it may take some time to respond.
>>
>> -Greg
>>
>> On Tue, Jun 19, 2018 at 5:44 AM, Ashok kumar  wrote:
>>> Hi,
>>>
>>> I have turned modules ON, I have attached the enable modules section
>>> in the kernel configuration
>>>
>>> thank you
>>> R.Ashokkumar
>>>
>>>
>>>
>>> On Mon, Jun 18, 2018 at 7:30 PM, Greg Gallagher  
>>> wrote:
>>>> Did you turn them on in menuconfig when you built your kernel?
>>>>
>>>> -Greg
>>>>
>>>> On Mon, Jun 18, 2018 at 1:40 AM, Ashok kumar  
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I have patched xenomai -2.6.4 with linux 3.18.20 .
>>>>> and installed the patched kernel, and  compiled the xenomai library using 
>>>>> below
>>>>> commands
>>>>>
>>>>> cd /usr/src
>>>>> sudo mkdir build_xenomai-2.6.4
>>>>> cd build_xenomai-2.6.4
>>>>>
>>>>> sudo ../xenomai-2.6.4/configure --enable-shared --enable-smp 
>>>>> --enable-x86-sep
>>>>> sudo make -j8
>>>>> sudo make install
>>>>>
>>>>> in /usr/xenomai/ I am not able to get the modules directory and xenomai 
>>>>> modules
>>>>> are not available ,xeno_rtdm,xeno_hal,xeno_nucleus.
>>>>>
>>>>> I used the below command to load the modules
>>>>>
>>>>> sudo modprobe xeno_rtdm,
>>>>> sudo modprobe xeno_hal
>>>>> sudo modprobe xeno_nucleus
>>>>>
>>>>> but the modules are not getting loaded.
>>>>>
>>>>>
>>>>> is there any modification should be done in the make file, or any
>>>>> other options should be enabled in the configure options
>>>>>
>>>>> kindly help me the get the xenomai modules available.
>>>>>
>>>>>
>>>>> Thank you
>>>>> R.Ashokkumar
>>>>>
>>>>> ___
>>>>> Xenomai mailing list
>>>>> Xenomai@xenomai.org
>>>>> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xenomai modules - xeno_rtdm, xeno_hal, xeno_nucleus. not getting installed

[Greg Gallagher]

Make sure you do your make step with 'make modules'.  I used this
tutorial [1] when i was building xenomai 2.6 a long time ago, it
should help you as well.

[1] http://www.orocos.org/files/tut_install_orocos_hydro_xeno.txt

On Tue, Jun 19, 2018 at 11:47 AM, Ashok kumar  wrote:
> In menuconfig I have used
>
> the following
>
> * General setup
>   --> Local version - append to kernel release: -xenomai-2.6.5
>   --> Timers subsystem
>   --> High Resolution Timer Support (Enable)
> * Real-time sub-system
>   --> Xenomai (Enable)
>   --> Nucleus (Enable)
>   --> Pervasive real-time support in user-space (Enable)
> * Power management and ACPI options
>   --> Run-time PM core functionality (Disable)
>   --> ACPI (Advanced Configuration and Power Interface) Support
>   --> Processor (Disable)
>   --> CPU Frequency scaling
>   --> CPU Frequency scaling (Disable)
>   --> CPU idle
>   --> CPU idle PM support (Disable)
> * Pocessor type and features
>   --> Processor family
>   --> Core 2/newer Xeon (if \"cat /proc/cpuinfo | grep family\"
> returns 6, set as Generic otherwise)
> * Power management and ACPI options
>   --> Memory power savings
>   --> Intel chipset idle memory power saving driver (Disable)
> and in nucleus I have seleted RTDM drivers, in interfaces,drivers etc
>
> and I am using x86_64 processor configuration.
>
>
> On Tue, Jun 19, 2018 at 9:12 PM, Greg Gallagher  wrote:
>> Under the Xenomai section of menuconfig, do you have them selected as
>> modules you can load or built into the kernel?  Also you are using a
>> pretty old version on Xenomai, have you considered using Xenomai-3
>> instead?  I haven't used Xenomai 2.6 in a while so my support may be
>> rusty.
>>
>> On Tue, Jun 19, 2018 at 11:29 AM, Ashok kumar  
>> wrote:
>>> Hi,
>>>
>>> I am getting xeno_rtdm.o,xeno_hal.o,xeno_nucleus.o. file but I am not
>>> getting xeno_rtdm.ko, xeno_hal.ko, xeno_nucleus.ko
>>>
>>> I should get .ko file to load it in kernel module .
>>>
>>> Thank you
>>>
>>>
>>> On Tue, Jun 19, 2018 at 8:47 PM, Greg Gallagher  
>>> wrote:
>>>> Are you building the RTDM modules? Do you see them getting built in
>>>> the kernel output.
>>>>
>>>> Please refrain from continuously posting the same question, we will
>>>> try to help you but it may take some time to respond.
>>>>
>>>> -Greg
>>>>
>>>> On Tue, Jun 19, 2018 at 5:44 AM, Ashok kumar  
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I have turned modules ON, I have attached the enable modules section
>>>>> in the kernel configuration
>>>>>
>>>>> thank you
>>>>> R.Ashokkumar
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 18, 2018 at 7:30 PM, Greg Gallagher  
>>>>> wrote:
>>>>>> Did you turn them on in menuconfig when you built your kernel?
>>>>>>
>>>>>> -Greg
>>>>>>
>>>>>> On Mon, Jun 18, 2018 at 1:40 AM, Ashok kumar  
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have patched xenomai -2.6.4 with linux 3.18.20 .
>>>>>>> and installed the patched kernel, and  compiled the xenomai library 
>>>>>>> using below
>>>>>>> commands
>>>>>>>
>>>>>>> cd /usr/src
>>>>>>> sudo mkdir build_xenomai-2.6.4
>>>>>>> cd build_xenomai-2.6.4
>>>>>>>
>>>>>>> sudo ../xenomai-2.6.4/configure --enable-shared --enable-smp 
>>>>>>> --enable-x86-sep
>>>>>>> sudo make -j8
>>>>>>> sudo make install
>>>>>>>
>>>>>>> in /usr/xenomai/ I am not able to get the modules directory and xenomai 
>>>>>>> modules
>>>>>>> are not available ,xeno_rtdm,xeno_hal,xeno_nucleus.
>>>>>>>
>>>>>>> I used the below command to load the modules
>>>>>>>
>>>>>>> sudo modprobe xeno_rtdm,
>>>>>>> sudo modprobe xeno_hal
>>>>>>> sudo modprobe xeno_nucleus
>>>>>>>
>>>>>>> but the modules are not getting loaded.
>>>>>>>
>>>>>>>
>>>>>>> is there any modification should be done in the make file, or any
>>>>>>> other options should be enabled in the configure options
>>>>>>>
>>>>>>> kindly help me the get the xenomai modules available.
>>>>>>>
>>>>>>>
>>>>>>> Thank you
>>>>>>> R.Ashokkumar
>>>>>>>
>>>>>>> ___
>>>>>>> Xenomai mailing list
>>>>>>> Xenomai@xenomai.org
>>>>>>> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xenomai modules - xeno_rtdm, xeno_hal, xeno_nucleus. not getting installed

[Greg Gallagher]

You said before you are using 3.18.20?  Are you building for 3.18.20
or 3.14.17? Are you seeing the object files in your build directory in
the driver folder?

On Tue, Jun 19, 2018 at 12:33 PM, Ashok kumar  wrote:
> in my lib/module/
>
> I am able to get this folder 3.14.17-xenomai-2.6.4 ,
> in this folder I am able to get xeno_rtdm.o,xeno_hal.o,xeno_nucleus.o.
> some where in arch , drivers, kernel directory , but I am not able to get
> xeno_rtdm.ko,xeno_hal.ko,xeno_nucleus.ko,
>
>
>
>
> On Tue, Jun 19, 2018 at 9:56 PM, Greg Gallagher  wrote:
>> When you install your package what do you see under /lib/modules ?
>>
>> On Tue, Jun 19, 2018 at 12:13 PM, Ashok kumar  
>> wrote:
>>> sudo make menuconfig
>>>
>>> make-kpkg --bzimage --initrd --append-to-version=-xenomai-2.6.4 -j8
>>> kernel-image kernel-headers modules
>>>
>>> On Tue, Jun 19, 2018 at 9:41 PM, Greg Gallagher  
>>> wrote:
>>>> What command are you using to build the kernel?
>>>>
>>>> On Tue, Jun 19, 2018 at 12:02 PM, Ashok kumar  
>>>> wrote:
>>>>> I too have followed the steps as mentioned in
>>>>> http://www.orocos.org/files/tut_install_orocos_hydro_xeno.txt
>>>>>
>>>>> in kernel config point number  7. Make appropriate changes to
>>>>> Real-time sub-system.
>>>>>
>>>>> I am using x86_64 architecture ,64 bit processor
>>>>> what features should I enable and disable to get these modules
>>>>> xeno_rtdm.ko,xeno_hal.ko,xeno_nucleus.ko.
>>>>> in Real-time sub-system. kernel configuration.
>>>>>
>>>>>
>>>>> # Configure and build kernel
>>>>> # 1. Processor type and features -> Processor family -- select proper
>>>>> #processor.
>>>>> # 2. Power management and ACPI options -> ACPI (Advanced Configuration and
>>>>> #Power Interface) Support -- turn of Processor.
>>>>> # 3. Power management and ACPI options -> CPU Frequency scaling -- turn 
>>>>> off
>>>>> #CPU Frequency scaling.
>>>>> # 4. Power management and ACPI options -- turn off CPU idle PM support.
>>>>> # 5. Kernel hacking turn off KGDB: kernel debugger.
>>>>> # 6. Turn off Virtualization.
>>>>> # 7. Make appropriate changes to Real-time sub-system.
>>>>> # 8. Device Drivers -> IOMMU Hardware Support -- turn off
>>>>>
>>>>>
>>>>> On Tue, Jun 19, 2018 at 9:24 PM, Greg Gallagher  
>>>>> wrote:
>>>>>> Make sure you do your make step with 'make modules'.  I used this
>>>>>> tutorial [1] when i was building xenomai 2.6 a long time ago, it
>>>>>> should help you as well.
>>>>>>
>>>>>> [1] http://www.orocos.org/files/tut_install_orocos_hydro_xeno.txt
>>>>>>
>>>>>> On Tue, Jun 19, 2018 at 11:47 AM, Ashok kumar  
>>>>>> wrote:
>>>>>>> In menuconfig I have used
>>>>>>>
>>>>>>> the following
>>>>>>>
>>>>>>> * General setup
>>>>>>>   --> Local version - append to kernel release: -xenomai-2.6.5
>>>>>>>   --> Timers subsystem
>>>>>>>   --> High Resolution Timer Support (Enable)
>>>>>>> * Real-time sub-system
>>>>>>>   --> Xenomai (Enable)
>>>>>>>   --> Nucleus (Enable)
>>>>>>>   --> Pervasive real-time support in user-space (Enable)
>>>>>>> * Power management and ACPI options
>>>>>>>   --> Run-time PM core functionality (Disable)
>>>>>>>   --> ACPI (Advanced Configuration and Power Interface) Support
>>>>>>>   --> Processor (Disable)
>>>>>>>   --> CPU Frequency scaling
>>>>>>>   --> CPU Frequency scaling (Disable)
>>>>>>>   --> CPU idle
>>>>>>>   --> CPU idle PM support (Disable)
>>>>>>> * Pocessor type and features
>>>>>>>   --> Processor family
>>>>>>>   --> Core 2/newer Xeon (if \"cat /proc/cpuinfo | grep family\"
>>>>>>> returns 6, set as Generic otherwise)
>>>>>>> * Power management and ACPI options
>>>>>>>   --&g

Re: [Xenomai] xenomai modules - xeno_rtdm, xeno_hal, xeno_nucleus. not getting installed

[Greg Gallagher]

You won't need them for Xenomai-3 if you aren't using things like
rtnet, ipc or any driver that can be found in the Xenomai tree.  Are
you using a Debian system?  This tutorial will get you started:

http://rtt-lwr.readthedocs.io/en/latest/rtpc/xenomai3.html

You'll post later tonight my steps on building an x86 kernel.  With
the above tutorial you'll need to do the modules_image step to
generate an image for the modules.  If you explain what you are trying
to achieve I may be able to help you configure you system better.

-Greg

On Tue, Jun 19, 2018 at 1:26 PM, Ashok kumar  wrote:
> can you please provide me steps to
> configure and to build xenomai -3 in x86_64 architecture.
>
> to get the modules xeno_rtdm.ko,xeno_hal.ko,xeno_nucleus.ko.
>
> thank you
>
> On Tue, Jun 19, 2018 at 10:35 PM, Ashok kumar  wrote:
>> Ok I will go through the make-kpkg command can you please provide me
>> to how to build xenomai -3 in x86_64 architecture.
>>
>> to get the modules xeno_rtdm.ko,xeno_hal.ko,xeno_nucleus.ko.
>>
>>
>>
>> On Tue, Jun 19, 2018 at 10:24 PM, Greg Gallagher  
>> wrote:
>>> Look at the documentation for make-kpkg, you need to build the modules
>>> using 'modules_image'
>>>
>>> https://manpages.debian.org/jessie/kernel-package/make-kpkg.1.en.html
>>>
>>> I don't think this is a Xenomai problem, this is an issue with using 
>>> make-kpkg.
>>>
>>> There are other ways to build a kernel for x86_64 that you can follow.
>>> If this isn't an existing project I really recommend using Xenomai-3
>>> instead of the older version.
>>>
>>> -Greg
>>>
>>> On Tue, Jun 19, 2018 at 12:45 PM, Ashok kumar  
>>> wrote:
>>>> I have build  3.14.17-xenomai-2.6.4 and I have build
>>>> 3.14.17-xenomai-2.6.4 too using the links below
>>>>
>>>> https://github.com/lma-cfpp/cfppa-framework-old/wiki/Xenomai-Kernel
>>>> http://rtt-lwr.readthedocs.io/en/latest/rtpc/xenomai.html
>>>>
>>>> http://rtt-lwr.readthedocs.io/en/latest/adv-tutos/bicompil.html
>>>>
>>>> both gave me the same result, and I am using x86_64 architecture.
>>>>
>>>> On Tue, Jun 19, 2018 at 10:10 PM, Greg Gallagher  
>>>> wrote:
>>>>> You said before you are using 3.18.20?  Are you building for 3.18.20
>>>>> or 3.14.17? Are you seeing the object files in your build directory in
>>>>> the driver folder?
>>>>>
>>>>> On Tue, Jun 19, 2018 at 12:33 PM, Ashok kumar  
>>>>> wrote:
>>>>>> in my lib/module/
>>>>>>
>>>>>> I am able to get this folder 3.14.17-xenomai-2.6.4 ,
>>>>>> in this folder I am able to get xeno_rtdm.o,xeno_hal.o,xeno_nucleus.o.
>>>>>> some where in arch , drivers, kernel directory , but I am not able to get
>>>>>> xeno_rtdm.ko,xeno_hal.ko,xeno_nucleus.ko,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 19, 2018 at 9:56 PM, Greg Gallagher  
>>>>>> wrote:
>>>>>>> When you install your package what do you see under /lib/modules ?
>>>>>>>
>>>>>>> On Tue, Jun 19, 2018 at 12:13 PM, Ashok kumar  
>>>>>>> wrote:
>>>>>>>> sudo make menuconfig
>>>>>>>>
>>>>>>>> make-kpkg --bzimage --initrd --append-to-version=-xenomai-2.6.4 -j8
>>>>>>>> kernel-image kernel-headers modules
>>>>>>>>
>>>>>>>> On Tue, Jun 19, 2018 at 9:41 PM, Greg Gallagher 
>>>>>>>>  wrote:
>>>>>>>>> What command are you using to build the kernel?
>>>>>>>>>
>>>>>>>>> On Tue, Jun 19, 2018 at 12:02 PM, Ashok kumar 
>>>>>>>>>  wrote:
>>>>>>>>>> I too have followed the steps as mentioned in
>>>>>>>>>> http://www.orocos.org/files/tut_install_orocos_hydro_xeno.txt
>>>>>>>>>>
>>>>>>>>>> in kernel config point number  7. Make appropriate changes to
>>>>>>>>>> Real-time sub-system.
>>>>>>>>>>
>>>>>>>>>> I am using x86_64 architecture ,64 bit processor
>>>>>>>>>> what features should I enable and disable to get these modules
>>>>>>

Re: [Xenomai] xenomai modules - xeno_rtdm, xeno_hal, xeno_nucleus. not getting installed

[Greg Gallagher]

Look at the documentation for make-kpkg, you need to build the modules
using 'modules_image'

https://manpages.debian.org/jessie/kernel-package/make-kpkg.1.en.html

I don't think this is a Xenomai problem, this is an issue with using make-kpkg.

There are other ways to build a kernel for x86_64 that you can follow.
If this isn't an existing project I really recommend using Xenomai-3
instead of the older version.

-Greg

On Tue, Jun 19, 2018 at 12:45 PM, Ashok kumar  wrote:
> I have build  3.14.17-xenomai-2.6.4 and I have build
> 3.14.17-xenomai-2.6.4 too using the links below
>
> https://github.com/lma-cfpp/cfppa-framework-old/wiki/Xenomai-Kernel
> http://rtt-lwr.readthedocs.io/en/latest/rtpc/xenomai.html
>
> http://rtt-lwr.readthedocs.io/en/latest/adv-tutos/bicompil.html
>
> both gave me the same result, and I am using x86_64 architecture.
>
> On Tue, Jun 19, 2018 at 10:10 PM, Greg Gallagher  
> wrote:
>> You said before you are using 3.18.20?  Are you building for 3.18.20
>> or 3.14.17? Are you seeing the object files in your build directory in
>> the driver folder?
>>
>> On Tue, Jun 19, 2018 at 12:33 PM, Ashok kumar  
>> wrote:
>>> in my lib/module/
>>>
>>> I am able to get this folder 3.14.17-xenomai-2.6.4 ,
>>> in this folder I am able to get xeno_rtdm.o,xeno_hal.o,xeno_nucleus.o.
>>> some where in arch , drivers, kernel directory , but I am not able to get
>>> xeno_rtdm.ko,xeno_hal.ko,xeno_nucleus.ko,
>>>
>>>
>>>
>>>
>>> On Tue, Jun 19, 2018 at 9:56 PM, Greg Gallagher  
>>> wrote:
>>>> When you install your package what do you see under /lib/modules ?
>>>>
>>>> On Tue, Jun 19, 2018 at 12:13 PM, Ashok kumar  
>>>> wrote:
>>>>> sudo make menuconfig
>>>>>
>>>>> make-kpkg --bzimage --initrd --append-to-version=-xenomai-2.6.4 -j8
>>>>> kernel-image kernel-headers modules
>>>>>
>>>>> On Tue, Jun 19, 2018 at 9:41 PM, Greg Gallagher  
>>>>> wrote:
>>>>>> What command are you using to build the kernel?
>>>>>>
>>>>>> On Tue, Jun 19, 2018 at 12:02 PM, Ashok kumar  
>>>>>> wrote:
>>>>>>> I too have followed the steps as mentioned in
>>>>>>> http://www.orocos.org/files/tut_install_orocos_hydro_xeno.txt
>>>>>>>
>>>>>>> in kernel config point number  7. Make appropriate changes to
>>>>>>> Real-time sub-system.
>>>>>>>
>>>>>>> I am using x86_64 architecture ,64 bit processor
>>>>>>> what features should I enable and disable to get these modules
>>>>>>> xeno_rtdm.ko,xeno_hal.ko,xeno_nucleus.ko.
>>>>>>> in Real-time sub-system. kernel configuration.
>>>>>>>
>>>>>>>
>>>>>>> # Configure and build kernel
>>>>>>> # 1. Processor type and features -> Processor family -- select proper
>>>>>>> #processor.
>>>>>>> # 2. Power management and ACPI options -> ACPI (Advanced Configuration 
>>>>>>> and
>>>>>>> #Power Interface) Support -- turn of Processor.
>>>>>>> # 3. Power management and ACPI options -> CPU Frequency scaling -- turn 
>>>>>>> off
>>>>>>> #CPU Frequency scaling.
>>>>>>> # 4. Power management and ACPI options -- turn off CPU idle PM support.
>>>>>>> # 5. Kernel hacking turn off KGDB: kernel debugger.
>>>>>>> # 6. Turn off Virtualization.
>>>>>>> # 7. Make appropriate changes to Real-time sub-system.
>>>>>>> # 8. Device Drivers -> IOMMU Hardware Support -- turn off
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 19, 2018 at 9:24 PM, Greg Gallagher  
>>>>>>> wrote:
>>>>>>>> Make sure you do your make step with 'make modules'.  I used this
>>>>>>>> tutorial [1] when i was building xenomai 2.6 a long time ago, it
>>>>>>>> should help you as well.
>>>>>>>>
>>>>>>>> [1] http://www.orocos.org/files/tut_install_orocos_hydro_xeno.txt
>>>>>>>>
>>>>>>>> On Tue, Jun 19, 2018 at 11:47 AM, Ashok kumar 
>>>>>>>>  wrote:
>>>>>>>>> In menuconfig I have used
>>>>>&g

Re: [Xenomai] Reference Images Alpha Release

[Greg Gallagher]

Okay, I briefly looked at a couple Debian options that I can script
the generation of the needed image.  I'll go down that path and see
what how that goes. I'll hopefully post an update in the next week or
so :)

-Greg

On Wed, May 30, 2018 at 12:59 PM, Jan Kiszka  wrote:
> On 2018-05-30 17:46, Greg Gallagher wrote:
>> I agree, after the first run of building the images myself I think
>> having the user generate the images would make more sense.  I'm
>> looking into doing that with an existing tool I think yocto may be a
>> good choice.  I've been generating some images with buildroot as well
>> which seems to be pretty straight forward to do and looks to only
>> require minimal changes.  The other long term goal for this would be
>> to make sure a certain set of boards are always sane and new users
>> just have to learn the new tools and not debug boot issues.  I'll
>> hopefully post an update to this soon, I just finished the work to
>> bring the bcm2835 to the 4.14 ipipe so it looks like we should be able
>> to try more raspberry pi builds.
>
> Going with a complete our-of-source image is surely an option and has a
> value (many users are still basing their development on such
> approaches). The disadvantage is that customizations require the user to
> rebuild everything. Generating a distro-based image (no, yocto is no
> distro) is much faster in this regard, both for rebuilds as well as
> extensions. That was my motivation to pick that Debian path for the
> Jailhouse demo/reference images.
>
> Jan
>
>>
>> -Greg
>>
>> On Wed, May 30, 2018 at 10:03 AM, Jan Kiszka  wrote:
>>> On 2018-05-18 04:00, Greg Gallagher wrote:
>>>> https://github.com/ggallagher31/xenomai-3-alpha-images/blob/master/README.md
>>>>
>>>>
>>>> Here is the first attempt of Xenomai-3 reference images, this is based
>>>> on 4.14 ipipe kernel and the rootfs is a Ubuntu based.  Xenomai was
>>>> built off the stable-3.0.x branch.  The images are currently hosted on
>>>> google drive which may change later but for now it should work.  Ping
>>>> me if there are access problems.
>>>>
>>>> Currently only RPI2 is in included with a extremely simple RT app.
>>>> Zynq boards and gpio examples will be posted this weekend (yay long
>>>> weekend).
>>>>
>>>> Please send any feedback or suggestion of improvements directly to me
>>>> g...@embeddedgreg.com
>>>>
>>>
>>> Thanks for taking actions here, Greg! I think this is a step in the
>>> right direction. I didn't have the time to try out the image yet, though.
>>>
>>> To my understanding, you are manually creating those images so far,
>>> right? Or did you also share somewhere some generation script or tool?
>>>
>>> I've started some similar effort for our Jailhouse hypervisor, but there
>>> with the idea to let the user build the images themselves:
>>>
>>> https://github.com/siemens/jailhouse-images
>>>
>>> This is currently limited to x86 and ARM64 (the latter is optional
>>> because the build is not yet optimized), and we do not have a real board
>>> in the portfolio yet, only QEMU / KVM. But that may change soon (I'm
>>> planning to look into enabling some OrangePi next - Raspis are way too
>>> broken for virtualization).
>>>
>>> Maybe such a generating approach could be valuable for us as well (once
>>> the remaining issues of that approach are solved). What do you think?
>>>
>>> Jan
>>>
>>> --
>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>>> Corporate Competence Center Embedded Linux
>
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Reference Images Alpha Release

[Greg Gallagher]

I agree, after the first run of building the images myself I think
having the user generate the images would make more sense.  I'm
looking into doing that with an existing tool I think yocto may be a
good choice.  I've been generating some images with buildroot as well
which seems to be pretty straight forward to do and looks to only
require minimal changes.  The other long term goal for this would be
to make sure a certain set of boards are always sane and new users
just have to learn the new tools and not debug boot issues.  I'll
hopefully post an update to this soon, I just finished the work to
bring the bcm2835 to the 4.14 ipipe so it looks like we should be able
to try more raspberry pi builds.

-Greg

On Wed, May 30, 2018 at 10:03 AM, Jan Kiszka  wrote:
> On 2018-05-18 04:00, Greg Gallagher wrote:
>> https://github.com/ggallagher31/xenomai-3-alpha-images/blob/master/README.md
>>
>>
>> Here is the first attempt of Xenomai-3 reference images, this is based
>> on 4.14 ipipe kernel and the rootfs is a Ubuntu based.  Xenomai was
>> built off the stable-3.0.x branch.  The images are currently hosted on
>> google drive which may change later but for now it should work.  Ping
>> me if there are access problems.
>>
>> Currently only RPI2 is in included with a extremely simple RT app.
>> Zynq boards and gpio examples will be posted this weekend (yay long
>> weekend).
>>
>> Please send any feedback or suggestion of improvements directly to me
>> g...@embeddedgreg.com
>>
>
> Thanks for taking actions here, Greg! I think this is a step in the
> right direction. I didn't have the time to try out the image yet, though.
>
> To my understanding, you are manually creating those images so far,
> right? Or did you also share somewhere some generation script or tool?
>
> I've started some similar effort for our Jailhouse hypervisor, but there
> with the idea to let the user build the images themselves:
>
> https://github.com/siemens/jailhouse-images
>
> This is currently limited to x86 and ARM64 (the latter is optional
> because the build is not yet optimized), and we do not have a real board
> in the portfolio yet, only QEMU / KVM. But that may change soon (I'm
> planning to look into enabling some OrangePi next - Raspis are way too
> broken for virtualization).
>
> Maybe such a generating approach could be valuable for us as well (once
> the remaining issues of that approach are solved). What do you think?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xenomai 3.0.6 on RPi3 overheating when idle

[Greg Gallagher]

I haven't tested Xenomai on RPI3 in 32-bit mode, I think someone else
tried it a while ago with out using Yocto and may be able to share his
experiences (Gustav?).  I haven't seen this issue on Raspberry pi 2b.
You can take a look at the output of ps and see if anything is using a
lot of the CPU.  I'm finishing up some RPI0 and 1 work now but I'll
hopefully move on to look at the rpi3 in the next couple of weeks.

-Greg

On Tue, May 29, 2018 at 4:37 PM, Steve Pavao  wrote:
> Hello,
>
> I’m having an overheating problem when running xenomai 3.0.6 on Raspberry Pi 
> 3 with the recipes and defconfig from 
> https://github.com/pficheux/meta-xenomai 
>  , but I’m using the altered kernel 
> setting CONFIG_HZ=1000.
>
> Under this configuration, the RPi3 overheats when idle.  I’d like to try to 
> understand why.  Is there perhaps a defconfig settting I need to adjust, so 
> that there will be not be so much heat-generating activity when the system is 
> idle?  I did not observe anything useful with ps.
>
> This is my first time successfully building and running xenomai on RPi3 
> 32-bit using yocto recipes and a defconfig.  I built in rocko branch.  I 
> notice there are many options in the defconfig which may affect operation. I 
> do not 100% understand all these options, but I have started googling them to 
> see if I can solve this issue.
>
> I appreciate any ideas you may have.
>
> Steve Pavao
> Korg R
>
> some of dmesg:
>
> [0.00] Linux version 4.9.45-xeno (oe-user@oe-host) (gcc version 7.3.0 
> (GCC) ) #2 SMP Tue May 29 19:19:23 UTC 2018
> [0.00] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
>
> [0.00] arm_arch_timer: Architected cp15 timer(s) running at 19.20MHz 
> (phys).
> [0.00] I-pipe, 19.200 MHz clocksource, wrap in 960767920505705 ms
> [0.00] clocksource: ipipe_tsc: mask: 0x max_cycles: 
> 0x46d987e47, max_idle_ns: 440795202767 ns
> [0.00] clocksource: arch_sys_counter: mask: 0xff 
> max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
> [0.07] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 
> 4398046511078ns
> [0.25] Switching to timer-based delay loop, resolution 52ns
> [0.001464] Interrupt pipeline (release #2)
>
> [0.164653] [Xenomai] scheduling class idle registered.
> [0.164676] [Xenomai] scheduling class rt registered.
> [0.164820] I-pipe: head domain Xenomai registered.
> [0.166498] [Xenomai] Cobalt v3.0.6 (Stellar Parallax)
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] ipipe 4.14 for ARM and X86

[Greg Gallagher]

I think there's still some ongoing work in both ARM and x86, Philippe
and Jan may be able to comment more on the timeline.  You can directly
clone the ipipe-arm tree and evaluate if it would work on your
platform.  There are still some issues with beaglebone/beagleboard in
4.14 that I'm looking into now.

-Greg

On Thu, May 31, 2018 at 8:20 AM, jimmyo  wrote:
> Hello,
>
> now we are testing ipipe 4.14 for both platforms.
> Everything seems to be ok.
>
> Is there a schedule/roadmap for a release?
>
> Thanks
>   Jimmy
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] beaglebone: arm: xeno-test gives segmentation fault - test dlopen failed

[Greg Gallagher]

Hi,
  I'll take a look at this tonight.  I'll confirm if this test  is
crashing on all platforms or just BB.  To disable I believe you'll
have to recompile the tests.

-Greg

On Tue, Jun 26, 2018 at 10:43 AM, Pintu Kumar  wrote:
> Dear Greg,
>
> Please let me know how to disable "dlopen" test in xenomai-next.
>
> I even tried, without dlopen parameter during ./configure but still I
> get the same issue.
> #  ./configure --enable-smp
>
> We did not face this issue earlier on xenomai-3 stable branch.
> So, I am planning to disable it right now.
> Please help!
>
>
> Thanks,
> Pintu
>
> On Tue, Jun 26, 2018 at 12:52 PM Pintu Kumar  wrote:
>>
>> Hi,
>> I am using Kernel 4.9.51 for beagle bone black with xenomai patches
>> from xenomai-next repo.
>>
>> I have installed xenomai-3-next using below:
>> # ./scripts/bootstrap
>> # ./configure --with-pic --with-core=cobalt --enable-smp --disable-tls
>> --enable-dlopen-libs
>> # make
>> # make install
>>
>> After that when I run xeno-test I get below error, and the test stopped.
>>
>> # root@bdk:~# /usr/xenomai/bin/xeno-test
>> 
>> 
>> vdso_access OK
>> xddp skipped (no kernel support)
>> Segmentation fault
>> /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1
>>
>> If you have any clue about this error, please let me know.
>>
>>
>> Thanks,
>> Pintu

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] beaglebone: arm: xeno-test gives segmentation fault - test dlopen failed

[Greg Gallagher]

I'm not that familiar with autotools (still learning), but I removed
this from configure.ac :

diff --git a/configure.ac b/configure.ac
index 4f9b1f9..a84dd14 100644
--- a/configure.ac
+++ b/configure.ac
@@ -881,7 +881,6 @@ AC_CONFIG_FILES([ \
testsuite/spitest/Makefile \
testsuite/smokey/Makefile \
testsuite/smokey/arith/Makefile \
-   testsuite/smokey/dlopen/Makefile \
testsuite/smokey/sched-quota/Makefile \
testsuite/smokey/sched-tp/Makefile \
testsuite/smokey/setsched/Makefile \

And I don't see the dlopen tests being built.  This may get you past
the test failing for now.  I'll add to the to do llist to test this
with the latest version of the stable branch.

-Greg

On Wed, Jun 27, 2018 at 9:21 AM, Pintu Kumar  wrote:
> Hi,
>
> Sorry, but both the below patches are already applied to my xenomai-next repo:
> build: link dlopen libs with "nodelete"
> smokey/dlopen: fix testcase
>
> Still I am facing dlopen issue.
> Is there any other patches I am missing?
>
>
> Thanks,
> Pintu
>
> On Wed, Jun 27, 2018 at 6:47 PM Pintu Kumar  wrote:
>>
>> Hi,
>>
>> One doubt, how do we clone 3.0.7 ?
>> Is it part of the following branches?
>>   remotes/origin/next
>>   remotes/origin/stable/v3.0.x
>>
>> I could not find any branch with the name 3.0.7.
>>
>> Is all 3 patches important, or only this is fine:
>> build: link dlopen libs with "nodelete"
>> smokey/dlopen: fix testcase
>>
>> Sorry, but can you list down all 3 commits.
>>
>>
>> Thanks,
>> Pintu
>>
>>
>>
>> Thanks,
>> Pintu
>> On Wed, Jun 27, 2018 at 6:30 PM Pintu Kumar  wrote:
>> >
>> > Dear Henning,
>> >
>> > Thanks so much for your reply.
>> > I am actually using xenomai-next branch.
>> > With last commit as:
>> > commit ffb68112e2342a62a1f70916a35a3d68e875b12c
>> > Author: Philippe Gerum 
>> > Date:   Mon May 21 12:54:59 2018 +0200
>> >
>> > scripts/prepare-kernel.sh: drop left overs from obsolete ports
>> >
>> > Anyways, I will check with your reference commits.
>> >
>> > Thanks,
>> > Pintu
>> > On Wed, Jun 27, 2018 at 6:07 PM Henning Schild
>> >  wrote:
>> > >
>> > > Hi Pintu,
>> > >
>> > > i guess you might be using v3.0.6. There are a couple of commits on top
>> > > of that
>> > > https://gitlab.denx.de/Xenomai/xenomai/commit/aa008686091484c88cbb809bc190133a98769a30
>> > > and 2 parents
>> > > All three are in v3.0.7, which hopefully solves your problem.
>> > >
>> > > regards,
>> > > Henning
>> > >
>> > > Am Wed, 27 Jun 2018 16:11:43 +0530
>> > > schrieb Pintu Kumar :
>> > >
>> > > > Dear Henning,
>> > > >
>> > > > I saw your commit regarding dlopen here:
>> > > > https://xenomai.org/pipermail/xenomai/2018-February/038351.html
>> > > >
>> > > > We are facing dlopen error with xeno-test on arm (beagle bone) and
>> > > > arm64 (hikey) boards.
>> > > > Segmentation fault
>> > > > /usr/xenomai/bin/smokey: test dlopen failed: Unknown error -1
>> > > >
>> > > > Do you have any clue regarding this issue.
>> > > > Earlier xeno-test worked for us, but after this commit xeno-test is
>> > > > failing.
>> > > >
>> > > > Currently we dont need dlopen test.
>> > > > So, please let us know how to disable dlopen test to pass the
>> > > > xeno-test report.
>> > > >
>> > > >
>> > > > Thanks,
>> > > > Pintu
>> > > >
>> > > >
>> > > >
>> > > > On Tue, Jun 26, 2018 at 11:07 PM Pintu Kumar 
>> > > > wrote:
>> > > > >
>> > > > > One more thing,
>> > > > > On x86 xeno-test works fine even with dlopen.
>> > > > >
>> > > > > This problem is seen only of arm and arm64 boards.
>> > > > >
>> > > > > Thanks,
>> > > > > Pintu
>> > > > > On Tue, Jun 26, 2018 at 10:16 PM Pintu Kumar 
>> > > > > wrote:
>> > > > > >
>> > > > > > Ok Greg thanks a lot.
>> > > > > >
>> > > > > > Yes, I can recompile it, but for now I want to get rid

Re: [Xenomai] KERNEL OOPS : hikey620: arm64 - while xecuting xeno-test

[Greg Gallagher]

This is an ipipe issue.  CPU4 seems to be stalled or starved.  I'm
doing some RPI3 testing and I haven't seen this yet.  Which board is
this? Is it from 96boards with the octacore A53?

-Greg

On Tue, Jun 26, 2018 at 7:56 AM, Pintu Kumar  wrote:
> Dear Greg/Philippe,
>
> I am running xeno-test on hikey620, with following details:
> - Kernel version: 4.9.51
> - ipipe: ipipe-core-4.9.51-arm64-4.patch
> - xenomai-3 : next branch
> - xenomai-3 commit until: scripts/prepare-kernel.sh: drop left overs
> from obsolete ports
> - version: 3.1-devel
>
> Build xenomai next using the following:
> # ./scripts/bootstrap
> # ./configure --with-pic --with-core=cobalt --enable-smp --disable-tls
> --enable-dlopen-libs
> # make -j8
> # make install
>
> => Enabled CONFIGS related to xeno-test in kernel:
> CONFIG_XENO_DRIVERS_RTIPC_BUFP CONFIG_XENO_OPT_BUFP_NRPORT=32
> CONFIG_XENO_DRIVERS_RTIPC_IDDP
> CONFIG_XENO_OPT_IDDP_NRPORT=32
> CONFIG_XENO_DRIVERS_RTDMTEST=m
> CONFIG_XENO_OPT_SCHED_TP
> CONFIG_XENO_OPT_SCHED_TP_NRPART=4
> CONFIG_XENO_DRIVERS_RTIPC_XDDP
>
> The run xeno-test:
> # /usr/xenomai/bin/xeno-test
>
> Some tests passed, but after sometime during smokey test, we get this
> back trace in kernel:
>
> If you have any pointers regarding this issue, please let me know.
>
> Thanks,
> Pintu
> ===
> [  487.848376] INFO: rcu_preempt self-detected stall on CPU[
> 487.848446] systemd[1]: systemd-journald.service: Main process exited,
> code=killed
> , status=6/ABRT
> [  487.848497] INFO: rcu_preempt self-detected stall on CPU
> [  487.848506]  6-...: (1 GPs behind) idle=99d/1/0 softirq=1452/1452 fqs=0
> [  487.848508]
> [  487.848513]  (t=29983 jiffies g=391 c=390 q=319)
> [  487.848519] rcu_preempt kthread starved for 29983 jiffies! g391
> c390 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
> [  487.848523] rcu_preempt S
> [  487.848527] 0 7  2 0x
> Call trace:
> [  487.848548] [] __switch_to+0x8c/0xa0
> [  487.848558] [] __schedule+0x1a8/0x5e8
> [  487.848563] [] schedule+0x3c/0xa8
> [  487.848569] [] schedule_timeout+0x128/0x280
> [  487.848576] [] rcu_gp_kthread+0x4dc/0x798
> [  487.848582] [] kthread+0xe0/0xf8
> [  487.848587] [] ret_from_fork+0x14/0x30
> [  487.848598] Task dump for CPU 3:
> [  487.848600] systemd-logind  R
> [  487.848602]   running task0  2294  1 0x0200
> Call trace:
> [  487.848611] [] __switch_to+0x8c/0xa0
> [  487.848617] [] __sys_recvmsg+0x40/0x80
> [  487.848621] [] 0x8000318b2648
> [  487.848623] Task dump for CPU 4:
> [  487.848625] swapper/4   R
> [  487.848627]   running task0 0  1 0x0002
> Call trace:
> [  487.848635] [] __switch_to+0x8c/0xa0
> [  487.848638] [] 0x80003311c200
> [  487.848640] Task dump for CPU 6:
> [  487.848642] swapper/6   R
> [  487.848643]   running task0 0  1 0x
> Call trace:
> [  487.848653] [] dump_backtrace+0x0/0x1b0
> [  487.848659] [] show_stack+0x14/0x20
> [  487.848665] [] sched_show_task+0xa0/0xf8
> [  487.848670] [] dump_cpu_task+0x40/0x50
> [  487.848676] [] rcu_dump_cpu_stacks+0xb4/0xe8
> [  487.848682] [] rcu_check_callbacks+0x810/0x9e0
> [  487.848688] [] update_process_times+0x34/0x60
> [  487.848693] [] update_root_process_times+0x48/0x58
> [  487.848700] [] tick_sched_handle.isra.4+0x5c/0x70
> [  487.848705] [] tick_sched_timer+0x44/0x90
> [  487.848710] [] __hrtimer_run_queues+0xec/0x170
> [  487.848715] [] hrtimer_interrupt+0xa0/0x1d8
> [  487.848720] [] tick_receive_broadcast+0x28/0x48
> [  487.848726] [] handle_IPI+0xa4/0x140
> [  487.848730] [] __ipipe_do_IPI+0x20/0x28
> [  487.848735] [] __ipipe_do_sync_stage+0x1ac/0x1d0
> [  487.848739] [] ipipe_unstall_root+0x44/0x50
> [  487.848745] [] cpuidle_enter_state+0x154/0x220
> [  487.848749] [] cpuidle_enter+0x18/0x20
> [  487.848754] [] call_cpuidle+0x44/0x88
> [  487.848759] [] cpu_startup_entry+0x190/0x1e8
> [  487.848763] [] secondary_start_kernel+0x164/0x1a0
> [  487.848766] [<009681a4>] 0x9681a4
> [  487.849172] systemd[1]: systemd-journald.service: Unit entered failed 
> state.
> [  487.849674] systemd[1]: systemd-journald.service: Failed with
> result 'signal'.
> [  487.851292] systemd[1]: systemd-journald.service: Service has no
> hold-off time, scheduling restart.
> [  487.852621] systemd[1]: Stopped Flush Journal to Persistent Storage.
> [  487.852792] systemd[1]: Stopping Flush Journal to Persistent Storage...
> [  487.852838] systemd[1]: Stopped Journal Service.
> [  487.854881] systemd[1]: Starting Journal Service...
> [  487.862458] systemd-journald[2553]: File
> /run/log/journal/7ed7bca1519a40c9b60c6577cb9072c1/system.journal
> corrupted or uncleanly shut down, r
> enaming and replacing.
> [  487.872215] systemd[1]: Started Journal Service.
> [  488.193484]  4-...: (2 GPs behind) idle=4b5/1/0 softirq=933/938 fqs=1
> [  488.24]   (t=29983 jiffies g=391 c=390 q=877)
> [  488.204710] Task dump for CPU 4:
> [  488.207931] swapper/4   R  

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

[Greg Gallagher]

I don't think Beaglebone is supported currently in RTNet.

On Wed, Jun 27, 2018 at 1:13 PM, Pintu Kumar  wrote:
> On Wed, Jun 27, 2018 at 9:47 PM Jan Kiszka  wrote:
>>
>> On 2018-06-27 16:12, Pintu Kumar wrote:
>> >> With nosmap, that particular issue should no longer occur (at least as
>> >> long as we can ask the kernel for this relaxation), so I suspect the
>> >> other effect you see now is something else.
>> >
>> > Just for the information, that issue occurred even on Beagle bone, and
>> > there is no smap on arm.
>> > However, it works on virtual box. how ?
>>
>> Does it work when you go back to Xenomai 3.0.6? Then it would be a
>> regression of the copy-to/from-userspace improvements done after that
>> release, you could start bisecting which commit introduced it.
>>
>
> Nope, I never had success with rtnet on arm architecture (mainly
> beagle bone), even with the old 3.0.6.
> At least earlier, on x86_64 (SkyLake), I saw the loopback part working
> with 3.0.6 and my old xenomai kernel 4.9.51 (without those rtnet
> fixes) and with "nosmap" in commandline.
>
> But now it looks like the situation becomes more worse.
> I will have to freshly look into it, but since I use prepare_kernel to
> apply as single patch, it might be painful to bisect it.
> Will try to find the root cause though
>
> Hoping for the best...
>
>> But I'm not sure right now if there isn't something similar to smap
>> (then just without a knob to turn it off) in the ARM architecture as well...
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] ipipe-4.4.y LTS

[Greg Gallagher]

I can run some tests on ARM boards I have.

-Greg

On Tue, Jun 19, 2018 at 3:09 AM, Jan Kiszka  wrote:
> On 2018-06-18 15:59, Greg Gallagher wrote:
>> Are there still plans to have a ipipe patch for the CIP kernel?  I
>> think this was brought up at the last meet up?  Maybe the bigger
>> question (which is a lot more work) is do we plan on maintaining ipipe
>> for 4.4, 4.9 and older?
>
> Yes, there are plans to go over 4.4-CIP. So far, I'm only maintaining
> based on 4.4-LTS, just tested on x86, pushed to
> https://lab.xenomai.org/ipipe-jki.git/log/?h=for-upstream/4.4-update.
> Would be happy to receive contributions in form of tests on other
> architectures!
>
> Jan
>
>>
>> -Greg
>>
>> On Mon, Jun 18, 2018 at 8:52 AM, Radu Rendec  wrote:
>>> Hi all,
>>>
>>> Are there any plans to maintain the ipipe-4.4.y branch and update it to
>>> later versions of kernel 4.4? It would be nice to have, since at this
>>> point kernel 4.4 has the longest projected EOL.
>>>
>>> Currently the latest thing that can be merged cleanly on top of
>>> ipipe-core-4.4.71-powerpc-8 is kernel 4.4.73, which is only 2 releases
>>> later than what's already in there.
>>>
>>> Thanks,
>>> Radu Rendec
>>>
>>> ___
>>> Xenomai mailing list
>>> Xenomai@xenomai.org
>>> https://xenomai.org/mailman/listinfo/xenomai
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] how to bring gpio to user space

[Greg Gallagher]

It looks like you are calling rtdm_dev_register twice, so the second
one complains that it already exists.  Take out the second call and
see what happens.


// rtdm_sem_init(, 0);// init the global semaphore
   rtdm_printk("gpio TRY register Driver \n");
   err=rtdm_dev_register();
if ((err=rtdm_dev_register())!=0){
// gpio_free(GPIO_PIN);
rtdm_printk("err number = %d\n",err);
if(err == -EINVAL)
rtdm_printk("err EINVAL = %d\n",err);
if(err == -EEXIST)
rtdm_printk("err EEXIST = %d\n",err);
 if(err == -ENOMEM)
rtdm_printk("err ENOMEM = %d\n",err);
 if(err == -EAGAIN)
rtdm_printk("err EAGAIN = %d\n",err);
 if(err == -ENOSYS)
rtdm_printk("err ENOSYS = %d\n",err);
 if(err == -ENXIO)
rtdm_printk("err ENXIO = %d\n",err);

kfree();
return err;
}

-Greg

On Wed, May 2, 2018 at 4:42 AM, Шевченко Тарас Григорьевич
 wrote:
> HI Community
> I try to register simple rtdm gpio driver
>
> but get the error EEXIST  ? could you explain what is wrong or missing ?
> and what daes it mean  "invalid opcode:  [#1] SMP" ?
>
> [ 1415.642644] gpio Driver Init
> [ 1415.642646] gpio TRY register Driver
> [ 1415.642881] err number = -17
> [ 1415.642885] err EEXIST = -17
> [ 1415.642922] [ cut here ]
> [ 1415.643010] kernel BUG at mm/slub.c:3873!
> [ 1415.643066] invalid opcode:  [#1] SMP
>

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] how to bring gpio to user space

[Greg Gallagher]

No problem, I think the rest of the log was from the panic and may not
be an issue after this fix.

On Wed, May 2, 2018 at 9:56 AM, Шевченко Тарас Григорьевич
<shevchenko.ta...@triolcorp.com.ua> wrote:
> yes, sorry for this and thanks for help
>
> С уважением и надеждой на сотрудничество,
> Шевченко Т.Г.
>
> - Исходное сообщение -----
> От: "Greg Gallagher" <g...@embeddedgreg.com>
> Кому: "Шевченко Тарас Григорьевич" <shevchenko.ta...@triolcorp.com.ua>
> Копия: "xenomai" <xenomai@xenomai.org>, "Olej" <o.tsiliu...@yandex.ru>
> Отправленные: Среда, 2 Май 2018 г 16:47:57
> Тема: Re: how to bring gpio to user space
>
> It looks like you are calling rtdm_dev_register twice, so the second
> one complains that it already exists.  Take out the second call and
> see what happens.
>
>
> // rtdm_sem_init(, 0);// init the global semaphore
>rtdm_printk("gpio TRY register Driver \n");
>err=rtdm_dev_register();
> if ((err=rtdm_dev_register())!=0){
> // gpio_free(GPIO_PIN);
> rtdm_printk("err number = %d\n",err);
> if(err == -EINVAL)
> rtdm_printk("err EINVAL = %d\n",err);
> if(err == -EEXIST)
> rtdm_printk("err EEXIST = %d\n",err);
>  if(err == -ENOMEM)
> rtdm_printk("err ENOMEM = %d\n",err);
>  if(err == -EAGAIN)
> rtdm_printk("err EAGAIN = %d\n",err);
>  if(err == -ENOSYS)
> rtdm_printk("err ENOSYS = %d\n",err);
>  if(err == -ENXIO)
> rtdm_printk("err ENXIO = %d\n",err);
>
> kfree();
> return err;
> }
>
> -Greg
>
> On Wed, May 2, 2018 at 4:42 AM, Шевченко Тарас Григорьевич
> <shevchenko.ta...@triolcorp.com.ua> wrote:
>> HI Community
>> I try to register simple rtdm gpio driver
>>
>> but get the error EEXIST  ? could you explain what is wrong or missing ?
>> and what daes it mean  "invalid opcode:  [#1] SMP" ?
>>
>> [ 1415.642644] gpio Driver Init
>> [ 1415.642646] gpio TRY register Driver
>> [ 1415.642881] err number = -17
>> [ 1415.642885] err EEXIST = -17
>> [ 1415.642922] [ cut here ]
>> [ 1415.643010] kernel BUG at mm/slub.c:3873!
>> [ 1415.643066] invalid opcode:  [#1] SMP
>>

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and Linux 4.9.51 on Xilinx Zynq 7000 MPSOC

[Greg Gallagher]

git clone git://git.xenomai.org/xenomai-3.git
git checkout stable-3.0.x

When was the last time you sync'd with the Linux stable tree?

On Thu, Apr 26, 2018 at 12:39 PM, Salvatore Barone
<salvator.bar...@gmail.com> wrote:
> Which repo sould I use?
>
>
> 2018-04-26 18:35 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>>
>> My email cutoff the last part of your panic, I can see the full log now.
>> Try using the latest git repo, so checkout the stable-3.0.x branch for
>> Xenomai.  The only difference between my test setup is I'm using the stable
>> branch.  I'll attempt to reproduce tonight if you still see the error.
>>
>> On Thu, Apr 26, 2018 at 12:29 PM, Salvatore Barone
>> <salvator.bar...@gmail.com> wrote:
>>>
>>> No, I'm patching the 4.9.51 mainline Linux Kernel with the 4.9.51 I-Pipe
>>> patch. I'm using Xenomai 3.0.6 library and Linaro latest debian root
>>> filesystem (2017 something)
>>>
>>> 2018-04-26 18:11 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>>>>
>>>>
>>>> Are you patching the Xilinx Linux kernel with the Xenomai patch? Have
>>>> you tried mainline?
>>>>
>>>> Greg
>>>> From: salvator.bar...@gmail.com
>>>> Sent: April 26, 2018 12:01 PM
>>>> To: g...@embeddedgreg.com
>>>> Cc: xenomai@xenomai.org
>>>> Subject: Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and Linux
>>>> 4.9.51 on Xilinx Zynq 7000 MPSOC
>>>>
>>>> Hi Greg! I've read all your blog post on this argument! With the xilinz
>>>> linux kernel i have no problem!
>>>>
>>>> Saluti,
>>>> Salvatore Barone.
>>>>
>>>> Il Gio 26 Apr 2018, 16:25 Greg Gallagher <g...@embeddedgreg.com> ha
>>>> scritto:
>>>>>
>>>>> If you load a non Xenomai kernel do you see the panic?  I think
>>>>> there's an issue with your rootfs. I've tested zynq running on 4.14
>>>>> ipipe and 4.9 ipipe with Xenomai 3.0.x stable using both a ubuntu and
>>>>> busybox file system with no issues.  I've tested on Zybo, Minized and
>>>>> the Zc702 board.  If it's a rootfs problem and not Xenomai related I
>>>>> can help you off list.  Try loading a non Xenomai kernel and see if
>>>>> the panic still exists.
>>>>>
>>>>>
>>>>> -Greg
>>>>>
>>>>> On Thu, Apr 26, 2018 at 10:10 AM, Salvatore Barone
>>>>> <salvator.bar...@gmail.com> wrote:
>>>>> > Hi all,
>>>>> > I'm trying to run Xenomai 3 on a Xilinx Zynq 7000 MPSOC (on a
>>>>> > Digilent Zybo
>>>>> > development board). I've read a lot of tutorial and documentation
>>>>> > before
>>>>> > posting here.
>>>>> > I run into a "kernel panic" and I cannot solve it.
>>>>> > I know to be annoying, but just to be not prone to misunderstanding,
>>>>> > I'm
>>>>> > going to report my personal walk-through below!
>>>>> >
>>>>> > In short: I've downloaded Linux stable sources from git, Xenomai 3
>>>>> > and
>>>>> > I-Pipe. I checkout the 4.9.51 branch, applied the I-Pipe patch as
>>>>> > follow
>>>>> > ---
>>>>> > git clone git://
>>>>> > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>>>>> > git clone git://git.xenomai.org/xenomai-3.git
>>>>> > wget -O $IPIPE
>>>>> >
>>>>> > https://xenomai.org/downloads/ipipe/v4.x/arm/ipipe-core-4.9.51-arm-4.patch
>>>>> > cd xenomai-3
>>>>> > ./scripts/prepare-kernel.sh
>>>>> > --linux=linux-stable --ipipe=../ipipe-core-4.9.51-arm-4.patch
>>>>> > --arch=arm
>>>>> > ---
>>>>> > Then, I copied the "xilinx_zynq_defconfig" file, from Xilinx, into
>>>>> > the
>>>>> > arch/arm/configs directory, and then
>>>>> > ---
>>>>> > export ARCH=arm
>>>>> > export CROSS_COMPILE=arm-linux-gnueabihf-
>>>>> > make xilinx_zynq_defconfig
>>>>> > make menuconfig
>>>>> > ---

Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and Linux 4.9.51 on Xilinx Zynq 7000 MPSOC

[Greg Gallagher]

My email cutoff the last part of your panic, I can see the full log now.
Try using the latest git repo, so checkout the stable-3.0.x branch for
Xenomai.  The only difference between my test setup is I'm using the stable
branch.  I'll attempt to reproduce tonight if you still see the error.

On Thu, Apr 26, 2018 at 12:29 PM, Salvatore Barone <
salvator.bar...@gmail.com> wrote:

> No, I'm patching the 4.9.51 mainline Linux Kernel with the 4.9.51 I-Pipe
> patch. I'm using Xenomai 3.0.6 library and Linaro latest debian root
> filesystem (2017 something)
>
> 2018-04-26 18:11 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>
>>
>> Are you patching the Xilinx Linux kernel with the Xenomai patch? Have you
>> tried mainline?
>>
>> Greg
>> *From:* salvator.bar...@gmail.com
>> *Sent:* April 26, 2018 12:01 PM
>> *To:* g...@embeddedgreg.com
>> *Cc:* xenomai@xenomai.org
>> *Subject:* Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and
>> Linux 4.9.51 on Xilinx Zynq 7000 MPSOC
>>
>> Hi Greg! I've read all your blog post on this argument! With the xilinz
>> linux kernel i have no problem!
>>
>> Saluti,
>> Salvatore Barone.
>>
>> Il Gio 26 Apr 2018, 16:25 Greg Gallagher <g...@embeddedgreg.com> ha
>> scritto:
>>
>>> If you load a non Xenomai kernel do you see the panic?  I think
>>> there's an issue with your rootfs. I've tested zynq running on 4.14
>>> ipipe and 4.9 ipipe with Xenomai 3.0.x stable using both a ubuntu and
>>> busybox file system with no issues.  I've tested on Zybo, Minized and
>>> the Zc702 board.  If it's a rootfs problem and not Xenomai related I
>>> can help you off list.  Try loading a non Xenomai kernel and see if
>>> the panic still exists.
>>>
>>>
>>> -Greg
>>>
>>> On Thu, Apr 26, 2018 at 10:10 AM, Salvatore Barone
>>> <salvator.bar...@gmail.com> wrote:
>>> > Hi all,
>>> > I'm trying to run Xenomai 3 on a Xilinx Zynq 7000 MPSOC (on a Digilent
>>> Zybo
>>> > development board). I've read a lot of tutorial and documentation
>>> before
>>> > posting here.
>>> > I run into a "kernel panic" and I cannot solve it.
>>> > I know to be annoying, but just to be not prone to misunderstanding,
>>> I'm
>>> > going to report my personal walk-through below!
>>> >
>>> > In short: I've downloaded Linux stable sources from git, Xenomai 3 and
>>> > I-Pipe. I checkout the 4.9.51 branch, applied the I-Pipe patch as
>>> follow
>>> > ---
>>> > git clone git://
>>> > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>>> > git clone git://git.xenomai.org/xenomai-3.git
>>> > wget -O $IPIPE
>>> > https://xenomai.org/downloads/ipipe/v4.x/arm/ipipe-core-4.9.
>>> 51-arm-4.patch
>>> > cd xenomai-3
>>> > ./scripts/prepare-kernel.sh
>>> > --linux=linux-stable --ipipe=../ipipe-core-4.9.51-arm-4.patch
>>> --arch=arm
>>> > ---
>>> > Then, I copied the "xilinx_zynq_defconfig" file, from Xilinx, into the
>>> > arch/arm/configs directory, and then
>>> > ---
>>> > export ARCH=arm
>>> > export CROSS_COMPILE=arm-linux-gnueabihf-
>>> > make xilinx_zynq_defconfig
>>> > make menuconfig
>>> > ---
>>> > I've
>>> > 1) disabled frequency scaling
>>> > 2) disabled CMA
>>> > 3) disabled kernel hacks
>>> > and then
>>> > ---
>>> > make
>>> > make UIMAGE_LOADADDR=0x8000 uImage modules
>>> > make modules_install INSTALL_MOD_PATH=$ZYNQ_MODULES
>>> > ---
>>> > So, I compiled the Xenomai 3 library
>>> > ---
>>> > cd xenomai3
>>> > git checkout tags/v3.0.6 -b xenomai_3.0.6
>>> > ./scripts/bootstrap
>>> > mkdir xeno3_build
>>> > cd xeno3_build
>>> > ../configure CFLAGS="-march=armv7-a -mfpu=vfp3 -mfloat-abi=hard"
>>> > LDFLAGS="-march=armv7-a" --build=x86_64-pc-linux-gnu
>>> > --host=arm-none-linux-gnueabi --with-core=cobalt --enable-smp
>>> --enable-tls
>>> > CC=arm-linu

Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and Linux 4.9.51 on Xilinx Zynq 7000 MPSOC

[Greg Gallagher]

You can clone this:
git://git.xenomai.org/ipipe-arm.git

Then when you patch the kernel with scripts/prepare-kernel.sh leave
--ipipe= blank or not add that argument.  If you add --verbose to
prepare-kernel you should see that the script detects the ipipe is
already present in the tree and then just creates the symlinks.  Or at
least that's how I think it works :)

-Greg

On Thu, Apr 26, 2018 at 12:58 PM, Salvatore Barone
<salvator.bar...@gmail.com> wrote:
> Thanks, but I have to got it by myself. It's a matter of principle now!
> Can I patch the 4.14 Xilinx Kernel with the 4.9.51 I-Pipe patch and get
> Xenomai working on it?
>
> 2018-04-26 18:56 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>>
>> okay, I will try to reproduce tonight.  If you need to be up and
>> running i can send you a 4.14 image, (4.14 kernel with Ubuntu 16.04
>> fs) to test out.
>>
>> -Greg
>>
>> On Thu, Apr 26, 2018 at 12:54 PM, Salvatore Barone
>> <salvator.bar...@gmail.com> wrote:
>> > Just before the last attempt! About two hours ago...
>> >
>> > 2018-04-26 18:43 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>> >>
>> >> git clone git://git.xenomai.org/xenomai-3.git
>> >> git checkout stable-3.0.x
>> >>
>> >> When was the last time you sync'd with the Linux stable tree?
>> >>
>> >> On Thu, Apr 26, 2018 at 12:39 PM, Salvatore Barone
>> >> <salvator.bar...@gmail.com> wrote:
>> >> > Which repo sould I use?
>> >> >
>> >> >
>> >> > 2018-04-26 18:35 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>> >> >>
>> >> >> My email cutoff the last part of your panic, I can see the full log
>> >> >> now.
>> >> >> Try using the latest git repo, so checkout the stable-3.0.x branch
>> >> >> for
>> >> >> Xenomai.  The only difference between my test setup is I'm using the
>> >> >> stable
>> >> >> branch.  I'll attempt to reproduce tonight if you still see the
>> >> >> error.
>> >> >>
>> >> >> On Thu, Apr 26, 2018 at 12:29 PM, Salvatore Barone
>> >> >> <salvator.bar...@gmail.com> wrote:
>> >> >>>
>> >> >>> No, I'm patching the 4.9.51 mainline Linux Kernel with the 4.9.51
>> >> >>> I-Pipe
>> >> >>> patch. I'm using Xenomai 3.0.6 library and Linaro latest debian
>> >> >>> root
>> >> >>> filesystem (2017 something)
>> >> >>>
>> >> >>> 2018-04-26 18:11 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>> >> >>>>
>> >> >>>>
>> >> >>>> Are you patching the Xilinx Linux kernel with the Xenomai patch?
>> >> >>>> Have
>> >> >>>> you tried mainline?
>> >> >>>>
>> >> >>>> Greg
>> >> >>>> From: salvator.bar...@gmail.com
>> >> >>>> Sent: April 26, 2018 12:01 PM
>> >> >>>> To: g...@embeddedgreg.com
>> >> >>>> Cc: xenomai@xenomai.org
>> >> >>>> Subject: Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and
>> >> >>>> Linux
>> >> >>>> 4.9.51 on Xilinx Zynq 7000 MPSOC
>> >> >>>>
>> >> >>>> Hi Greg! I've read all your blog post on this argument! With the
>> >> >>>> xilinz
>> >> >>>> linux kernel i have no problem!
>> >> >>>>
>> >> >>>> Saluti,
>> >> >>>> Salvatore Barone.
>> >> >>>>
>> >> >>>> Il Gio 26 Apr 2018, 16:25 Greg Gallagher <g...@embeddedgreg.com>
>> >> >>>> ha
>> >> >>>> scritto:
>> >> >>>>>
>> >> >>>>> If you load a non Xenomai kernel do you see the panic?  I think
>> >> >>>>> there's an issue with your rootfs. I've tested zynq running on
>> >> >>>>> 4.14
>> >> >>>>> ipipe and 4.9 ipipe with Xenomai 3.0.x stable using both a ubuntu
>> >> >>>>> and
>> >> >>>>> busybox file system with no issues.  I've tested on Zybo, Minized
>> >> >>>>> and
>> >> >

Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and Linux 4.9.51 on Xilinx Zynq 7000 MPSOC

[Greg Gallagher]

Sounds good, and I will test out the 4.9.51 patch tonight and see what
happens.

On Thu, Apr 26, 2018 at 1:05 PM, Salvatore Barone
<salvator.bar...@gmail.com> wrote:
> Ok, I'll try.
>
> I keep you updated
> Thanks a lot!
>
> 2018-04-26 19:02 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>>
>> You can clone this:
>> git://git.xenomai.org/ipipe-arm.git
>>
>> Then when you patch the kernel with scripts/prepare-kernel.sh leave
>> --ipipe= blank or not add that argument.  If you add --verbose to
>> prepare-kernel you should see that the script detects the ipipe is
>> already present in the tree and then just creates the symlinks.  Or at
>> least that's how I think it works :)
>>
>> -Greg
>>
>> On Thu, Apr 26, 2018 at 12:58 PM, Salvatore Barone
>> <salvator.bar...@gmail.com> wrote:
>> > Thanks, but I have to got it by myself. It's a matter of principle now!
>> > Can I patch the 4.14 Xilinx Kernel with the 4.9.51 I-Pipe patch and get
>> > Xenomai working on it?
>> >
>> > 2018-04-26 18:56 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>> >>
>> >> okay, I will try to reproduce tonight.  If you need to be up and
>> >> running i can send you a 4.14 image, (4.14 kernel with Ubuntu 16.04
>> >> fs) to test out.
>> >>
>> >> -Greg
>> >>
>> >> On Thu, Apr 26, 2018 at 12:54 PM, Salvatore Barone
>> >> <salvator.bar...@gmail.com> wrote:
>> >> > Just before the last attempt! About two hours ago...
>> >> >
>> >> > 2018-04-26 18:43 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>> >> >>
>> >> >> git clone git://git.xenomai.org/xenomai-3.git
>> >> >> git checkout stable-3.0.x
>> >> >>
>> >> >> When was the last time you sync'd with the Linux stable tree?
>> >> >>
>> >> >> On Thu, Apr 26, 2018 at 12:39 PM, Salvatore Barone
>> >> >> <salvator.bar...@gmail.com> wrote:
>> >> >> > Which repo sould I use?
>> >> >> >
>> >> >> >
>> >> >> > 2018-04-26 18:35 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>> >> >> >>
>> >> >> >> My email cutoff the last part of your panic, I can see the full
>> >> >> >> log
>> >> >> >> now.
>> >> >> >> Try using the latest git repo, so checkout the stable-3.0.x
>> >> >> >> branch
>> >> >> >> for
>> >> >> >> Xenomai.  The only difference between my test setup is I'm using
>> >> >> >> the
>> >> >> >> stable
>> >> >> >> branch.  I'll attempt to reproduce tonight if you still see the
>> >> >> >> error.
>> >> >> >>
>> >> >> >> On Thu, Apr 26, 2018 at 12:29 PM, Salvatore Barone
>> >> >> >> <salvator.bar...@gmail.com> wrote:
>> >> >> >>>
>> >> >> >>> No, I'm patching the 4.9.51 mainline Linux Kernel with the
>> >> >> >>> 4.9.51
>> >> >> >>> I-Pipe
>> >> >> >>> patch. I'm using Xenomai 3.0.6 library and Linaro latest debian
>> >> >> >>> root
>> >> >> >>> filesystem (2017 something)
>> >> >> >>>
>> >> >> >>> 2018-04-26 18:11 GMT+02:00 Greg Gallagher
>> >> >> >>> <g...@embeddedgreg.com>:
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> Are you patching the Xilinx Linux kernel with the Xenomai
>> >> >> >>>> patch?
>> >> >> >>>> Have
>> >> >> >>>> you tried mainline?
>> >> >> >>>>
>> >> >> >>>> Greg
>> >> >> >>>> From: salvator.bar...@gmail.com
>> >> >> >>>> Sent: April 26, 2018 12:01 PM
>> >> >> >>>> To: g...@embeddedgreg.com
>> >> >> >>>> Cc: xenomai@xenomai.org
>> >> >> >>>> Subject: Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51
>> >> >> >>>> and
>> >> >> >>>> L

Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and Linux 4.9.51 on Xilinx Zynq 7000 MPSOC

[Greg Gallagher]

   Are you patching the Xilinx Linux kernel with the Xenomai patch? Have
   you tried mainline?
   Greg

   From: salvator.bar...@gmail.com
   Sent: April 26, 2018 12:01 PM
   To: g...@embeddedgreg.com
   Cc: xenomai@xenomai.org
   Subject: Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and
   Linux 4.9.51 on Xilinx Zynq 7000 MPSOC

   Hi Greg! I've read all your blog post on this argument! With the xilinz
   linux kernel i have no problem!
   Saluti,
   Salvatore Barone.
   Il Gio 26 Apr 2018, 16:25 Greg Gallagher <[1]g...@embeddedgreg.com> ha
   scritto:

 If you load a non Xenomai kernel do you see the panic?  I think
 there's an issue with your rootfs. I've tested zynq running on 4.14
 ipipe and 4.9 ipipe with Xenomai 3.0.x stable using both a ubuntu
 and
 busybox file system with no issues.  I've tested on Zybo, Minized
 and
 the Zc702 board.  If it's a rootfs problem and not Xenomai related I
 can help you off list.  Try loading a non Xenomai kernel and see if
 the panic still exists.
 -Greg
 On Thu, Apr 26, 2018 at 10:10 AM, Salvatore Barone
 <[2]salvator.bar...@gmail.com> wrote:
 > Hi all,
 > I'm trying to run Xenomai 3 on a Xilinx Zynq 7000 MPSOC (on a
 Digilent Zybo
 > development board). I've read a lot of tutorial and documentation
 before
 > posting here.
 > I run into a "kernel panic" and I cannot solve it.
 > I know to be annoying, but just to be not prone to
 misunderstanding, I'm
 > going to report my personal walk-through below!
 >
 > In short: I've downloaded Linux stable sources from git, Xenomai 3
 and
 > I-Pipe. I checkout the 4.9.51 branch, applied the I-Pipe patch as
 follow
 > ---
 > git clone git://
 > [3]git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
 > git clone git://[4]git.xenomai.org/xenomai-3.git
 > wget -O $IPIPE
 >
 [5]https://xenomai.org/downloads/ipipe/v4.x/arm/ipipe-core-4.9.51-ar
 m-4.patch
 > cd xenomai-3
 > ./scripts/[6]prepare-kernel.sh
 > --linux=linux-stable --ipipe=../[7]ipipe-core-4.9.51-arm-4.patch
 --arch=arm
 > ---
 > Then, I copied the "xilinx_zynq_defconfig" file, from Xilinx, into
 the
 > arch/arm/configs directory, and then
 > ---
 > export ARCH=arm
 > export CROSS_COMPILE=arm-linux-gnueabihf-
 > make xilinx_zynq_defconfig
 > make menuconfig
 > ---
 > I've
 > 1) disabled frequency scaling
 > 2) disabled CMA
 > 3) disabled kernel hacks
 > and then
 > ---
 > make
 > make UIMAGE_LOADADDR=0x8000 uImage modules
 > make modules_install INSTALL_MOD_PATH=$ZYNQ_MODULES
 > ---
 > So, I compiled the Xenomai 3 library
 > ---
 > cd xenomai3
 > git checkout tags/v3.0.6 -b xenomai_3.0.6
 > ./scripts/bootstrap
 > mkdir xeno3_build
 > cd xeno3_build
 > ../configure CFLAGS="-march=armv7-a -mfpu=vfp3 -mfloat-abi=hard"
 > LDFLAGS="-march=armv7-a" --build=x86_64-pc-linux-gnu
 > --host=arm-none-linux-gnueabi --with-core=cobalt --enable-smp
 --enable-tls
 > CC=arm-linux-gnueabihf-gcc LD=arm-linux-gnueabihf-ld
 > make DESTDIR=$XENO_ZYNQ_STAGE install
 > -
 >
 > All work as expected.
 > I used linaro latest root fs, adding the xenomai3 library and
 kernel
 > modules, but, at the system boot, I run into "kernel panic".
 > Dump follows
 > -
 > [16:06:07:495] EXT4-fs (mmcblk0p2): recovery completeaa
 > [16:06:07:495] EXT4-fs (mmcblk0p2): mounted filesystem with
 ordered data
 > mode. Opts: (null)aa
 > [16:06:07:495] VFS: Mounted root (ext4 filesystem) on device 179:
 [8]2.aa
 > [16:06:07:511] devtmpfs: mountedaa
 > [16:06:07:511] Freeing unused kernel memory: 1024K (c090 -
 c0a0)aa
 > [16:06:07:591] random: fast init doneaa
 > [16:06:07:639] /sbin/init: /lib/arm-linux-gnueabihf/
 [9]libseccomp.so.2: no
 > version information available (required by /sbin/init)aa
 > [16:06:07:655] /sbin/init: /lib/arm-linux-gnueabihf/
 [10]libseccomp.so.2: no
 > version information available (required by /sbin/init)aa
 > [16:06:07:655] /sbin/init: /lib/arm-linux-gnueabihf/
 [11]libseccomp.so.2: no
 > version information av

Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and Linux 4.9.51 on Xilinx Zynq 7000 MPSOC

[Greg Gallagher]

okay, I will try to reproduce tonight.  If you need to be up and
running i can send you a 4.14 image, (4.14 kernel with Ubuntu 16.04
fs) to test out.

-Greg

On Thu, Apr 26, 2018 at 12:54 PM, Salvatore Barone
<salvator.bar...@gmail.com> wrote:
> Just before the last attempt! About two hours ago...
>
> 2018-04-26 18:43 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>>
>> git clone git://git.xenomai.org/xenomai-3.git
>> git checkout stable-3.0.x
>>
>> When was the last time you sync'd with the Linux stable tree?
>>
>> On Thu, Apr 26, 2018 at 12:39 PM, Salvatore Barone
>> <salvator.bar...@gmail.com> wrote:
>> > Which repo sould I use?
>> >
>> >
>> > 2018-04-26 18:35 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>> >>
>> >> My email cutoff the last part of your panic, I can see the full log
>> >> now.
>> >> Try using the latest git repo, so checkout the stable-3.0.x branch for
>> >> Xenomai.  The only difference between my test setup is I'm using the
>> >> stable
>> >> branch.  I'll attempt to reproduce tonight if you still see the error.
>> >>
>> >> On Thu, Apr 26, 2018 at 12:29 PM, Salvatore Barone
>> >> <salvator.bar...@gmail.com> wrote:
>> >>>
>> >>> No, I'm patching the 4.9.51 mainline Linux Kernel with the 4.9.51
>> >>> I-Pipe
>> >>> patch. I'm using Xenomai 3.0.6 library and Linaro latest debian root
>> >>> filesystem (2017 something)
>> >>>
>> >>> 2018-04-26 18:11 GMT+02:00 Greg Gallagher <g...@embeddedgreg.com>:
>> >>>>
>> >>>>
>> >>>> Are you patching the Xilinx Linux kernel with the Xenomai patch? Have
>> >>>> you tried mainline?
>> >>>>
>> >>>> Greg
>> >>>> From: salvator.bar...@gmail.com
>> >>>> Sent: April 26, 2018 12:01 PM
>> >>>> To: g...@embeddedgreg.com
>> >>>> Cc: xenomai@xenomai.org
>> >>>> Subject: Re: [Xenomai] Issue with Xenomai 3.0.6, I-Pipe 4.9.51 and
>> >>>> Linux
>> >>>> 4.9.51 on Xilinx Zynq 7000 MPSOC
>> >>>>
>> >>>> Hi Greg! I've read all your blog post on this argument! With the
>> >>>> xilinz
>> >>>> linux kernel i have no problem!
>> >>>>
>> >>>> Saluti,
>> >>>> Salvatore Barone.
>> >>>>
>> >>>> Il Gio 26 Apr 2018, 16:25 Greg Gallagher <g...@embeddedgreg.com> ha
>> >>>> scritto:
>> >>>>>
>> >>>>> If you load a non Xenomai kernel do you see the panic?  I think
>> >>>>> there's an issue with your rootfs. I've tested zynq running on 4.14
>> >>>>> ipipe and 4.9 ipipe with Xenomai 3.0.x stable using both a ubuntu
>> >>>>> and
>> >>>>> busybox file system with no issues.  I've tested on Zybo, Minized
>> >>>>> and
>> >>>>> the Zc702 board.  If it's a rootfs problem and not Xenomai related I
>> >>>>> can help you off list.  Try loading a non Xenomai kernel and see if
>> >>>>> the panic still exists.
>> >>>>>
>> >>>>>
>> >>>>> -Greg
>> >>>>>
>> >>>>> On Thu, Apr 26, 2018 at 10:10 AM, Salvatore Barone
>> >>>>> <salvator.bar...@gmail.com> wrote:
>> >>>>> > Hi all,
>> >>>>> > I'm trying to run Xenomai 3 on a Xilinx Zynq 7000 MPSOC (on a
>> >>>>> > Digilent Zybo
>> >>>>> > development board). I've read a lot of tutorial and documentation
>> >>>>> > before
>> >>>>> > posting here.
>> >>>>> > I run into a "kernel panic" and I cannot solve it.
>> >>>>> > I know to be annoying, but just to be not prone to
>> >>>>> > misunderstanding,
>> >>>>> > I'm
>> >>>>> > going to report my personal walk-through below!
>> >>>>> >
>> >>>>> > In short: I've downloaded Linux stable sources from git, Xenomai 3
>> >>>>> > and
>> >>>>> > I-Pipe. I checkout the 4.9.51 branch, applied the I-Pipe patch as
>> >>>>> > follow

Re: [Xenomai] Shared memory between RT and NRT tasks (Posix Skin)

[Greg Gallagher]

Have you considered using xddp sockets instead?  How large is the
memory you are sharing?

-Greg

On Thu, May 3, 2018 at 1:49 PM, Virendra Kate  wrote:
> Hello,
>
> I am trying to create a shared memory between a RT (Cobalt) and a NRT
> (Linux) task. I went through the " A Tour of the Native API " document
> which pointed me towards the alchemy (previously "native") API.
>
> Currently we are using the Posix skin as it has better performance. This
> link:
> http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__posix__shm.html
> indicates
> that the typical posix share memory API was available for Xenoami Cobalt in
> version 2.4.
>
> Since the shared memory section is missing in the Xenomai 3 documentation
> and I couldn't find the --wrap shm_open() etc. flags in the
> "cobalt.wrappers" file I was wondering if this functionality is supported
> in Xenomai 3 Posix skin.
>
> At this point I am avoiding the use of message queues.
>
> Any help is appreciated.
>
> Thanks,
> Virendra Kate
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Shared memory between RT and NRT tasks (Posix Skin)

[Greg Gallagher]

I can continue to do some digging, but I've only really used xddp.
I'm sure someone on the list can help out.

On Thu, May 3, 2018 at 2:33 PM, Virendra Kate <virendrak...@gmail.com> wrote:
> I am still looking into xddp but might not be the best solution for us.
>
> The shared memory is 16MB big.
>
> -Virendra
>
> On Thu, May 3, 2018 at 10:51 AM, Greg Gallagher <g...@embeddedgreg.com> wrote:
>> Have you considered using xddp sockets instead?  How large is the
>> memory you are sharing?
>>
>> -Greg
>>
>> On Thu, May 3, 2018 at 1:49 PM, Virendra Kate <virendrak...@gmail.com> wrote:
>>> Hello,
>>>
>>> I am trying to create a shared memory between a RT (Cobalt) and a NRT
>>> (Linux) task. I went through the " A Tour of the Native API " document
>>> which pointed me towards the alchemy (previously "native") API.
>>>
>>> Currently we are using the Posix skin as it has better performance. This
>>> link:
>>> http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__posix__shm.html
>>> indicates
>>> that the typical posix share memory API was available for Xenoami Cobalt in
>>> version 2.4.
>>>
>>> Since the shared memory section is missing in the Xenomai 3 documentation
>>> and I couldn't find the --wrap shm_open() etc. flags in the
>>> "cobalt.wrappers" file I was wondering if this functionality is supported
>>> in Xenomai 3 Posix skin.
>>>
>>> At this point I am avoiding the use of message queues.
>>>
>>> Any help is appreciated.
>>>
>>> Thanks,
>>> Virendra Kate
>>> ___
>>> Xenomai mailing list
>>> Xenomai@xenomai.org
>>> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

From: Wolfgang Netbal <wolfgang.net...@sigmatek.at>

This patch is based on one that was submitted by Michael Welling back in Feb
2016 but a formal patch was never submitted.  The original thread that this
patch was derived from is located here 
https://xenomai.org/pipermail/xenomai/2016-February/035924.html


Fixed up kernel style errors and I added a couple small changes and tested on a 
imx7d board.  
One quick note, the IMX7D define may not really be needed since most imx7 uarts 
look to be 
compatible with imx6. 

Signed-off-by: Greg Gallagher <g...@embeddedgreg.com>
---
 kernel/drivers/serial/rt_imx_uart.c | 337 
 1 file changed, 229 insertions(+), 108 deletions(-)

diff --git a/kernel/drivers/serial/rt_imx_uart.c 
b/kernel/drivers/serial/rt_imx_uart.c
index 092cecc..2c93789 100644
--- a/kernel/drivers/serial/rt_imx_uart.c
+++ b/kernel/drivers/serial/rt_imx_uart.c
@@ -36,8 +36,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -65,7 +67,10 @@ MODULE_LICENSE("GPL");
 #define UBMR   0xa8 /* BRM Modulator Register */
 #define UBRC   0xac /* Baud Rate Count Register */
 #define MX2_ONEMS 0xb0 /* One Millisecond register */
-#define UTS (cpu_is_mx1() ? 0xd0 : 0xb4) /* UART Test Register */
+#define IMX1_UTS 0xd0 /* UART Test Register on i.mx1 */
+#define IMX21_UTS 0xb4 /* UART Test Register on all other i.mx*/
+
+
 
 /* UART Control Register Bit Fields.*/
 #define URXD_CHARRDY   (1<<15)
@@ -143,7 +148,7 @@ MODULE_LICENSE("GPL");
 #define USR1_DTRD  (1<<7)  /* DTR Delta */
 #define USR1_RXDS  (1<<6)  /* Receiver idle interrupt flag */
 #define USR1_AIRINT(1<<5)  /* Async IR wake interrupt flag */
-#define USR1_AWAKE (1<<4)  /* Aysnc wake interrupt flag */
+#define USR1_AWAKE (1<<4)  /* Async wake interrupt flag */
 #define USR2_ADET  (1<<15) /* Auto baud rate detect complete */
 #define USR2_TXFE  (1<<14) /* Transmit buffer FIFO empty */
 #define USR2_DTRF  (1<<13) /* DTR edge interrupt flag */
@@ -189,9 +194,25 @@ MODULE_LICENSE("GPL");
 #define RT_IMX_UART_MAX5
 
 static int tx_fifo[RT_IMX_UART_MAX];
-compat_module_param_array(tx_fifo, int, RT_IMX_UART_MAX, 0400);
+module_param_array(tx_fifo, int, NULL, 0400);
 MODULE_PARM_DESC(tx_fifo, "Transmitter FIFO size");
 
+/* i.MX21 type uart runs on all i.mx except i.MX1 and i.MX6q */
+enum imx_uart_type {
+   IMX1_UART,
+   IMX21_UART,
+   IMX53_UART,
+   IMX6Q_UART,
+   IMX7D_UART,
+};
+
+/* device type dependent stuff */
+struct imx_uart_data {
+   unsigned int uts_reg;
+   enum imx_uart_type devtype;
+};
+
+
 struct rt_imx_uart_port {
unsigned char __iomem *membase; /* read/write[bwl] */
resource_size_t mapbase;/* for ioremap */
@@ -200,11 +221,79 @@ struct rt_imx_uart_port {
unsigned int have_rtscts;
unsigned int use_dcedte;
unsigned int use_hwflow;
-   struct clk *clk;/* clock id for UART clock */
+   struct clk *clk_ipg;/* clock id for UART clock */
+   struct clk *clk_per;/* clock id for UART clock */
+   const struct imx_uart_data *devdata;
unsigned int uartclk;   /* base uart clock */
struct rtdm_device rtdm_dev;/* RTDM device structure */
 };
 
+
+static struct imx_uart_data imx_uart_devdata[] = {
+   [IMX1_UART] = {
+   .uts_reg = IMX1_UTS,
+   .devtype = IMX1_UART,
+   },
+   [IMX21_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX21_UART,
+   },
+   [IMX53_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX53_UART,
+   },
+   [IMX6Q_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX6Q_UART,
+   },
+   [IMX7D_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX7D_UART,
+   },
+};
+
+static const struct platform_device_id rt_imx_uart_id_table[] = {
+   {
+   .name = "imx1-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX1_UART],
+   }, {
+   .name = "imx21-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX21_UART],
+   }, {
+   .name = "imx53-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX53_UART],
+   }, {
+   .name = "imx6q-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX6Q_UART],
+   }, {
+   .name = "imx-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX7D_UART],
+   }, {
+   /* sentinel */
+   }
+};
+MODULE_DEVICE_TABLE(platform, rt_imx_uart_id_table);
+
+static c

[Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

---
 kernel/drivers/serial/rt_imx_uart.c | 299 
 1 file changed, 204 insertions(+), 95 deletions(-)

diff --git a/kernel/drivers/serial/rt_imx_uart.c 
b/kernel/drivers/serial/rt_imx_uart.c
index 092cecc..db63df6 100644
--- a/kernel/drivers/serial/rt_imx_uart.c
+++ b/kernel/drivers/serial/rt_imx_uart.c
@@ -36,8 +36,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -65,7 +67,10 @@ MODULE_LICENSE("GPL");
 #define UBMR   0xa8 /* BRM Modulator Register */
 #define UBRC   0xac /* Baud Rate Count Register */
 #define MX2_ONEMS 0xb0 /* One Millisecond register */
-#define UTS (cpu_is_mx1() ? 0xd0 : 0xb4) /* UART Test Register */
+#define IMX1_UTS 0xd0 /* UART Test Register on i.mx1 */
+#define IMX21_UTS 0xb4 /* UART Test Register on all other i.mx*/
+
+
 
 /* UART Control Register Bit Fields.*/
 #define URXD_CHARRDY   (1<<15)
@@ -189,9 +194,25 @@ MODULE_LICENSE("GPL");
 #define RT_IMX_UART_MAX5
 
 static int tx_fifo[RT_IMX_UART_MAX];
-compat_module_param_array(tx_fifo, int, RT_IMX_UART_MAX, 0400);
+module_param_array(tx_fifo, int, NULL, 0400);
 MODULE_PARM_DESC(tx_fifo, "Transmitter FIFO size");
 
+/* i.MX21 type uart runs on all i.mx except i.MX1 and i.MX6q */
+enum imx_uart_type {
+   IMX1_UART,
+   IMX21_UART,
+   IMX53_UART,
+   IMX6Q_UART,
+IMX7D_UART,
+};
+
+/* device type dependent stuff */
+struct imx_uart_data {
+   unsigned uts_reg;
+   enum imx_uart_type devtype;
+};
+
+
 struct rt_imx_uart_port {
unsigned char __iomem *membase; /* read/write[bwl] */
resource_size_t mapbase;/* for ioremap */
@@ -200,11 +221,69 @@ struct rt_imx_uart_port {
unsigned int have_rtscts;
unsigned int use_dcedte;
unsigned int use_hwflow;
-   struct clk *clk;/* clock id for UART clock */
-   unsigned int uartclk;   /* base uart clock */
+   struct clk *clk_ipg;/* clock id for UART clock */
+   struct clk *clk_per;/* clock id for UART clock */
+const struct imx_uart_data *devdata;
+unsigned int uartclk;  /* base uart clock */
struct rtdm_device rtdm_dev;/* RTDM device structure */
 };
 
+
+static struct imx_uart_data imx_uart_devdata[] = {
+   [IMX1_UART] = {
+   .uts_reg = IMX1_UTS,
+   .devtype = IMX1_UART,
+   },
+   [IMX21_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX21_UART,
+   },
+   [IMX53_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX53_UART,
+   },
+   [IMX6Q_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX6Q_UART,
+   },
+[IMX7D_UART] = {
+.uts_reg = IMX21_UTS,
+.devtype = IMX7D_UART,
+},
+};
+
+static const struct platform_device_id rt_imx_uart_id_table[] = {
+{
+   .name = "imx1-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX1_UART],
+   }, {
+   .name = "imx21-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX21_UART],
+   }, {
+   .name = "imx53-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX53_UART],
+   }, {
+   .name = "imx6q-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX6Q_UART],
+   }, {
+.name = "imx-uart",
+.driver_data = (kernel_ulong_t) _uart_devdata[IMX7D_UART],
+}, {
+   /* sentinel */
+   }
+};
+MODULE_DEVICE_TABLE(platform, rt_imx_uart_id_table);
+
+static const struct of_device_id rt_imx_uart_dt_ids[] = {
+   { .compatible = "fsl,imx7d-uart", .data = 
_uart_devdata[IMX7D_UART], },
+{ .compatible = "fsl,imx6q-uart", .data = 
_uart_devdata[IMX6Q_UART], },
+   { .compatible = "fsl,imx53-uart", .data = 
_uart_devdata[IMX53_UART], },
+   { .compatible = "fsl,imx1-uart", .data = _uart_devdata[IMX1_UART], 
},
+   { .compatible = "fsl,imx21-uart", .data = 
_uart_devdata[IMX21_UART], },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rt_imx_uart_dt_ids);
+
 struct rt_imx_uart_ctx {
struct rtser_config config; /* current device configuration */
 
@@ -344,6 +423,7 @@ static int rt_imx_uart_rx_chars(struct rt_imx_uart_ctx *ctx,
 static void rt_imx_uart_tx_chars(struct rt_imx_uart_ctx *ctx)
 {
int ch, count;
+unsigned uts_reg = ctx->port->devdata->uts_reg;
 
for (count = ctx->port->tx_fifo;
 (count > 0) && (ctx->out_npend > 0);
@@ -352,7 +432,7 @@ static void rt_imx_uart_tx_chars(struct rt_imx_uart_ctx 
*ctx)
writel(ch, ctx->port->membase + URTX0);
ctx->out_head &= (OUT_BUFFER_SIZE - 1);
 
-   if (readl(ctx->port->membase + UTS) & UTS_TXFULL)
+   if 

[Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

From: Michael Welling <mwell...@ieee.org>

This patch is based on one that was submitted by Michael Welling back in Feb
2016 but a formal patch was never submitted.  The original thread that this
patch was derived from is located here 
https://xenomai.org/pipermail/xenomai/2016-February/035924.html


Fixed up kernel style errors and I added a couple small changes and tested on a 
imx7d board.  
One quick note, the IMX7D define may not really be needed since most imx7 uarts 
look to be 
compatible with imx6. 

Signed-off-by: Greg Gallagher <g...@embeddedgreg.com>
---
 kernel/drivers/serial/rt_imx_uart.c | 337 
 1 file changed, 229 insertions(+), 108 deletions(-)

diff --git a/kernel/drivers/serial/rt_imx_uart.c 
b/kernel/drivers/serial/rt_imx_uart.c
index 092cecc..2c93789 100644
--- a/kernel/drivers/serial/rt_imx_uart.c
+++ b/kernel/drivers/serial/rt_imx_uart.c
@@ -36,8 +36,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -65,7 +67,10 @@ MODULE_LICENSE("GPL");
 #define UBMR   0xa8 /* BRM Modulator Register */
 #define UBRC   0xac /* Baud Rate Count Register */
 #define MX2_ONEMS 0xb0 /* One Millisecond register */
-#define UTS (cpu_is_mx1() ? 0xd0 : 0xb4) /* UART Test Register */
+#define IMX1_UTS 0xd0 /* UART Test Register on i.mx1 */
+#define IMX21_UTS 0xb4 /* UART Test Register on all other i.mx*/
+
+
 
 /* UART Control Register Bit Fields.*/
 #define URXD_CHARRDY   (1<<15)
@@ -143,7 +148,7 @@ MODULE_LICENSE("GPL");
 #define USR1_DTRD  (1<<7)  /* DTR Delta */
 #define USR1_RXDS  (1<<6)  /* Receiver idle interrupt flag */
 #define USR1_AIRINT(1<<5)  /* Async IR wake interrupt flag */
-#define USR1_AWAKE (1<<4)  /* Aysnc wake interrupt flag */
+#define USR1_AWAKE (1<<4)  /* Async wake interrupt flag */
 #define USR2_ADET  (1<<15) /* Auto baud rate detect complete */
 #define USR2_TXFE  (1<<14) /* Transmit buffer FIFO empty */
 #define USR2_DTRF  (1<<13) /* DTR edge interrupt flag */
@@ -189,9 +194,25 @@ MODULE_LICENSE("GPL");
 #define RT_IMX_UART_MAX5
 
 static int tx_fifo[RT_IMX_UART_MAX];
-compat_module_param_array(tx_fifo, int, RT_IMX_UART_MAX, 0400);
+module_param_array(tx_fifo, int, NULL, 0400);
 MODULE_PARM_DESC(tx_fifo, "Transmitter FIFO size");
 
+/* i.MX21 type uart runs on all i.mx except i.MX1 and i.MX6q */
+enum imx_uart_type {
+   IMX1_UART,
+   IMX21_UART,
+   IMX53_UART,
+   IMX6Q_UART,
+   IMX7D_UART,
+};
+
+/* device type dependent stuff */
+struct imx_uart_data {
+   unsigned int uts_reg;
+   enum imx_uart_type devtype;
+};
+
+
 struct rt_imx_uart_port {
unsigned char __iomem *membase; /* read/write[bwl] */
resource_size_t mapbase;/* for ioremap */
@@ -200,11 +221,79 @@ struct rt_imx_uart_port {
unsigned int have_rtscts;
unsigned int use_dcedte;
unsigned int use_hwflow;
-   struct clk *clk;/* clock id for UART clock */
+   struct clk *clk_ipg;/* clock id for UART clock */
+   struct clk *clk_per;/* clock id for UART clock */
+   const struct imx_uart_data *devdata;
unsigned int uartclk;   /* base uart clock */
struct rtdm_device rtdm_dev;/* RTDM device structure */
 };
 
+
+static struct imx_uart_data imx_uart_devdata[] = {
+   [IMX1_UART] = {
+   .uts_reg = IMX1_UTS,
+   .devtype = IMX1_UART,
+   },
+   [IMX21_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX21_UART,
+   },
+   [IMX53_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX53_UART,
+   },
+   [IMX6Q_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX6Q_UART,
+   },
+   [IMX7D_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX7D_UART,
+   },
+};
+
+static const struct platform_device_id rt_imx_uart_id_table[] = {
+   {
+   .name = "imx1-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX1_UART],
+   }, {
+   .name = "imx21-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX21_UART],
+   }, {
+   .name = "imx53-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX53_UART],
+   }, {
+   .name = "imx6q-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX6Q_UART],
+   }, {
+   .name = "imx-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX7D_UART],
+   }, {
+   /* sentinel */
+   }
+};
+MODULE_DEVICE_TABLE(platform, rt_imx_uart_id_table);
+
+static c

Re: [Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

Had it correct the first time, I'll fix that up.

Thanks

Greg

  Original Message  
From: mwell...@ieee.org
Sent: January 8, 2018 4:16 PM
To: g...@embeddedgreg.com
Cc: xenomai@xenomai.org
Subject: Re: [PATCH] Fix up the imx uart driver so it now compiles with new 
kernels.

On Mon, Jan 8, 2018 at 3:09 PM, Greg Gallagher <g...@embeddedgreg.com> wrote:
>
> From: Michael Welling <mwell...@ieee.org>
>
> This patch is based on one that was submitted by Michael Welling back in Feb
> 2016 but a formal patch was never submitted.  The original thread that this
> patch was derived from is located here 
> https://xenomai.org/pipermail/xenomai/2016-February/035924.html


If you look closely it was a patch from Wolfgang Netbal.

>
>
>
>
> Fixed up kernel style errors and I added a couple small changes and tested on 
> a imx7d board.
> One quick note, the IMX7D define may not really be needed since most imx7 
> uarts look to be
> compatible with imx6.
>
> Signed-off-by: Greg Gallagher <g...@embeddedgreg.com>
> ---
>  kernel/drivers/serial/rt_imx_uart.c | 337 
>
>  1 file changed, 229 insertions(+), 108 deletions(-)
>
> diff --git a/kernel/drivers/serial/rt_imx_uart.c 
> b/kernel/drivers/serial/rt_imx_uart.c
> index 092cecc..2c93789 100644
> --- a/kernel/drivers/serial/rt_imx_uart.c
> +++ b/kernel/drivers/serial/rt_imx_uart.c
> @@ -36,8 +36,10 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
> +#include 
> +#include 
>
>  #include 
>  #include 
> @@ -65,7 +67,10 @@ MODULE_LICENSE("GPL");
>  #define UBMR   0xa8 /* BRM Modulator Register */
>  #define UBRC   0xac /* Baud Rate Count Register */
>  #define MX2_ONEMS 0xb0 /* One Millisecond register */
> -#define UTS (cpu_is_mx1() ? 0xd0 : 0xb4) /* UART Test Register */
> +#define IMX1_UTS 0xd0 /* UART Test Register on i.mx1 */
> +#define IMX21_UTS 0xb4 /* UART Test Register on all other i.mx*/
> +
> +
>
>  /* UART Control Register Bit Fields.*/
>  #define URXD_CHARRDY   (1<<15)
> @@ -143,7 +148,7 @@ MODULE_LICENSE("GPL");
>  #define USR1_DTRD  (1<<7)  /* DTR Delta */
>  #define USR1_RXDS  (1<<6)  /* Receiver idle interrupt flag */
>  #define USR1_AIRINT    (1<<5)  /* Async IR wake interrupt flag */
> -#define USR1_AWAKE (1<<4)  /* Aysnc wake interrupt flag */
> +#define USR1_AWAKE (1<<4)  /* Async wake interrupt flag */
>  #define USR2_ADET  (1<<15) /* Auto baud rate detect complete */
>  #define USR2_TXFE  (1<<14) /* Transmit buffer FIFO empty */
>  #define USR2_DTRF  (1<<13) /* DTR edge interrupt flag */
> @@ -189,9 +194,25 @@ MODULE_LICENSE("GPL");
>  #define RT_IMX_UART_MAX    5
>
>  static int tx_fifo[RT_IMX_UART_MAX];
> -compat_module_param_array(tx_fifo, int, RT_IMX_UART_MAX, 0400);
> +module_param_array(tx_fifo, int, NULL, 0400);
>  MODULE_PARM_DESC(tx_fifo, "Transmitter FIFO size");
>
> +/* i.MX21 type uart runs on all i.mx except i.MX1 and i.MX6q */
> +enum imx_uart_type {
> +   IMX1_UART,
> +   IMX21_UART,
> +   IMX53_UART,
> +   IMX6Q_UART,
> +   IMX7D_UART,
> +};
> +
> +/* device type dependent stuff */
> +struct imx_uart_data {
> +   unsigned int uts_reg;
> +   enum imx_uart_type devtype;
> +};
> +
> +
>  struct rt_imx_uart_port {
> unsigned char __iomem *membase; /* read/write[bwl] */
> resource_size_t mapbase;    /* for ioremap */
> @@ -200,11 +221,79 @@ struct rt_imx_uart_port {
> unsigned int have_rtscts;
> unsigned int use_dcedte;
> unsigned int use_hwflow;
> -   struct clk *clk;    /* clock id for UART clock */
> +   struct clk *clk_ipg;    /* clock id for UART clock */
> +   struct clk *clk_per;    /* clock id for UART clock */
> +   const struct imx_uart_data *devdata;
> unsigned int uartclk;   /* base uart clock */
> struct rtdm_device rtdm_dev;    /* RTDM device structure */
>  };
>
> +
> +static struct imx_uart_data imx_uart_devdata[] = {
> +   [IMX1_UART] = {
> +   .uts_reg = IMX1_UTS,
> +   .devtype = IMX1_UART,
> +   },
> +   [IMX21_UART] = {
> +   .uts_reg = IMX21_UTS,
> +   .devtype = IMX21_UART,
> +   },
> +   [IMX53_UART] = {
> +   .uts_reg = IMX21_UTS,
> +   .devtype = IMX53_UART,
> +   },
> +   [IMX6Q_UART] = {
> +   .uts_reg = IMX21_UTS,
> +   .devtype = IMX6Q_UART,
>

Re: [Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

Sounds good, I fixed up the patch and will submit it again.  There are
a couple of warnings from checkpath.pl still but I don't
think they need to be fixed up.  I can post the output if anyone would
like to see it.  I also had the original publisher wrong,
I fixed that up and added the sign off at the bottom.

Let me know if I missed anything.

Thanks

Greg

On Mon, Jan 8, 2018 at 1:03 PM, Jan Kiszka <jan.kis...@siemens.com> wrote:
> On 2018-01-08 18:52, Greg Gallagher wrote:
>> Hi,
>>  The patch I submitted was based on one that was submitted by Wolfgang
>> Netbal back in Feb
>>  2016.  The original thread that this patch was derived from is located here
>> https://xenomai.org/pipermail/xenomai/2016-February/035924.html
>>
>> Just wanted to make sure proper credit was given, I think I put this
>> info in the patch as well.
>
> Just write a commit message (which is desirable anyway) and mention the
> origin there. In case you barely changed the original version, you could
> also leave the original author in place by starting the body with "From:
> Author " and then just mention your changes at the end of the log
> message (usually before your signed-off-by, but Xenomai does not enforce
> that protocol yet).
>
> Could you sort out the unrelated style changes? Preferred style is that
> of the kernel. The kernel has a checker (scripts/checkpatch.pl), which
> does not mean there can be sometimes exceptions, but it should not a
> guideline still.
>
> Thanks for picking this up!
> Jan
>
>>
>> -Greg
>>
>> On Mon, Jan 8, 2018 at 12:49 PM, Greg Gallagher <g...@embeddedgreg.com> 
>> wrote:
>>> ---
>>>  kernel/drivers/serial/rt_imx_uart.c | 299 
>>> 
>>>  1 file changed, 204 insertions(+), 95 deletions(-)
>>>
>>> diff --git a/kernel/drivers/serial/rt_imx_uart.c 
>>> b/kernel/drivers/serial/rt_imx_uart.c
>>> index 092cecc..db63df6 100644
>>> --- a/kernel/drivers/serial/rt_imx_uart.c
>>> +++ b/kernel/drivers/serial/rt_imx_uart.c
>>> @@ -36,8 +36,10 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> -#include 
>>> -#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>>
>>>  #include 
>>>  #include 
>>> @@ -65,7 +67,10 @@ MODULE_LICENSE("GPL");
>>>  #define UBMR   0xa8 /* BRM Modulator Register */
>>>  #define UBRC   0xac /* Baud Rate Count Register */
>>>  #define MX2_ONEMS 0xb0 /* One Millisecond register */
>>> -#define UTS (cpu_is_mx1() ? 0xd0 : 0xb4) /* UART Test Register */
>>> +#define IMX1_UTS 0xd0 /* UART Test Register on i.mx1 */
>>> +#define IMX21_UTS 0xb4 /* UART Test Register on all other i.mx*/
>>> +
>>> +
>>>
>>>  /* UART Control Register Bit Fields.*/
>>>  #define URXD_CHARRDY   (1<<15)
>>> @@ -189,9 +194,25 @@ MODULE_LICENSE("GPL");
>>>  #define RT_IMX_UART_MAX5
>>>
>>>  static int tx_fifo[RT_IMX_UART_MAX];
>>> -compat_module_param_array(tx_fifo, int, RT_IMX_UART_MAX, 0400);
>>> +module_param_array(tx_fifo, int, NULL, 0400);
>>>  MODULE_PARM_DESC(tx_fifo, "Transmitter FIFO size");
>>>
>>> +/* i.MX21 type uart runs on all i.mx except i.MX1 and i.MX6q */
>>> +enum imx_uart_type {
>>> +   IMX1_UART,
>>> +   IMX21_UART,
>>> +   IMX53_UART,
>>> +   IMX6Q_UART,
>>> +IMX7D_UART,
>>> +};
>>> +
>>> +/* device type dependent stuff */
>>> +struct imx_uart_data {
>>> +   unsigned uts_reg;
>>> +   enum imx_uart_type devtype;
>>> +};
>>> +
>>> +
>>>  struct rt_imx_uart_port {
>>> unsigned char __iomem *membase; /* read/write[bwl] */
>>> resource_size_t mapbase;/* for ioremap */
>>> @@ -200,11 +221,69 @@ struct rt_imx_uart_port {
>>> unsigned int have_rtscts;
>>> unsigned int use_dcedte;
>>> unsigned int use_hwflow;
>>> -   struct clk *clk;/* clock id for UART clock */
>>> -   unsigned int uartclk;   /* base uart clock */
>>> +   struct clk *clk_ipg;/* clock id for UART clock */
>>> +   struct clk *clk_per;/* clock id for UART clock */
>>> +const struct imx_uart_data *devdata;
>>> +unsigned int uartclk;  /* base uart clock */
>>> struct rtdm_de

Re: [Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

Hi,
 The patch I submitted was based on one that was submitted by Wolfgang
Netbal back in Feb
 2016.  The original thread that this patch was derived from is located here
https://xenomai.org/pipermail/xenomai/2016-February/035924.html

Just wanted to make sure proper credit was given, I think I put this
info in the patch as well.

-Greg

On Mon, Jan 8, 2018 at 12:49 PM, Greg Gallagher <g...@embeddedgreg.com> wrote:
> ---
>  kernel/drivers/serial/rt_imx_uart.c | 299 
> 
>  1 file changed, 204 insertions(+), 95 deletions(-)
>
> diff --git a/kernel/drivers/serial/rt_imx_uart.c 
> b/kernel/drivers/serial/rt_imx_uart.c
> index 092cecc..db63df6 100644
> --- a/kernel/drivers/serial/rt_imx_uart.c
> +++ b/kernel/drivers/serial/rt_imx_uart.c
> @@ -36,8 +36,10 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
> +#include 
> +#include 
>
>  #include 
>  #include 
> @@ -65,7 +67,10 @@ MODULE_LICENSE("GPL");
>  #define UBMR   0xa8 /* BRM Modulator Register */
>  #define UBRC   0xac /* Baud Rate Count Register */
>  #define MX2_ONEMS 0xb0 /* One Millisecond register */
> -#define UTS (cpu_is_mx1() ? 0xd0 : 0xb4) /* UART Test Register */
> +#define IMX1_UTS 0xd0 /* UART Test Register on i.mx1 */
> +#define IMX21_UTS 0xb4 /* UART Test Register on all other i.mx*/
> +
> +
>
>  /* UART Control Register Bit Fields.*/
>  #define URXD_CHARRDY   (1<<15)
> @@ -189,9 +194,25 @@ MODULE_LICENSE("GPL");
>  #define RT_IMX_UART_MAX5
>
>  static int tx_fifo[RT_IMX_UART_MAX];
> -compat_module_param_array(tx_fifo, int, RT_IMX_UART_MAX, 0400);
> +module_param_array(tx_fifo, int, NULL, 0400);
>  MODULE_PARM_DESC(tx_fifo, "Transmitter FIFO size");
>
> +/* i.MX21 type uart runs on all i.mx except i.MX1 and i.MX6q */
> +enum imx_uart_type {
> +   IMX1_UART,
> +   IMX21_UART,
> +   IMX53_UART,
> +   IMX6Q_UART,
> +IMX7D_UART,
> +};
> +
> +/* device type dependent stuff */
> +struct imx_uart_data {
> +   unsigned uts_reg;
> +   enum imx_uart_type devtype;
> +};
> +
> +
>  struct rt_imx_uart_port {
> unsigned char __iomem *membase; /* read/write[bwl] */
> resource_size_t mapbase;/* for ioremap */
> @@ -200,11 +221,69 @@ struct rt_imx_uart_port {
> unsigned int have_rtscts;
> unsigned int use_dcedte;
> unsigned int use_hwflow;
> -   struct clk *clk;/* clock id for UART clock */
> -   unsigned int uartclk;   /* base uart clock */
> +   struct clk *clk_ipg;/* clock id for UART clock */
> +   struct clk *clk_per;/* clock id for UART clock */
> +const struct imx_uart_data *devdata;
> +unsigned int uartclk;  /* base uart clock */
> struct rtdm_device rtdm_dev;/* RTDM device structure */
>  };
>
> +
> +static struct imx_uart_data imx_uart_devdata[] = {
> +   [IMX1_UART] = {
> +   .uts_reg = IMX1_UTS,
> +   .devtype = IMX1_UART,
> +   },
> +   [IMX21_UART] = {
> +   .uts_reg = IMX21_UTS,
> +   .devtype = IMX21_UART,
> +   },
> +   [IMX53_UART] = {
> +   .uts_reg = IMX21_UTS,
> +   .devtype = IMX53_UART,
> +   },
> +   [IMX6Q_UART] = {
> +   .uts_reg = IMX21_UTS,
> +   .devtype = IMX6Q_UART,
> +   },
> +[IMX7D_UART] = {
> +.uts_reg = IMX21_UTS,
> +.devtype = IMX7D_UART,
> +},
> +};
> +
> +static const struct platform_device_id rt_imx_uart_id_table[] = {
> +{
> +   .name = "imx1-uart",
> +   .driver_data = (kernel_ulong_t) _uart_devdata[IMX1_UART],
> +   }, {
> +   .name = "imx21-uart",
> +   .driver_data = (kernel_ulong_t) _uart_devdata[IMX21_UART],
> +   }, {
> +   .name = "imx53-uart",
> +   .driver_data = (kernel_ulong_t) _uart_devdata[IMX53_UART],
> +   }, {
> +   .name = "imx6q-uart",
> +   .driver_data = (kernel_ulong_t) _uart_devdata[IMX6Q_UART],
> +   }, {
> +.name = "imx-uart",
> +.driver_data = (kernel_ulong_t) 
> _uart_devdata[IMX7D_UART],
> +}, {
> +   /* sentinel */
> +   }
> +};
> +MODULE_DEVICE_TABLE(platform, rt_imx_uart_id_table);
> +
> +static const struct of_device_id rt_imx_uart_dt_ids[] = {
> +   { .compatible = "fsl,imx7d-uart", .data = 
> _uar

Re: [Xenomai] heap allocation working for some memory sizes but not others

[Greg Gallagher]

Hi,
   So there could be a couple things going on.  First, I'm not sure
why from 2.6.4 to 3.0.x you are seeing the behavior change, but
Xenomai 3 is fairly different from 2.6.x.  It could be Xenomai 3 is
more strict when it comes to heap allocation or the heap code is
different in Xenomai 3. You are getting EWOULDBLOCK returned from the
rt_heap_alloc which means that there isn't a block available of
suitable size.  Instead of allocating the entire heap size try smaller
sizes in the rt_heap_alloc function and see if you get the same
result.  The test code uses a 16k heap with 8k allocations. I've only
briefly looked at the heap code (digging in more now) so I'm not sure
if it's valid to allocate the entire heap.  Try changing your test to
allocate less the the actual heap size and see if there is a change.

Thanks

Greg


On Thu, Jan 11, 2018 at 9:13 AM, Vincent Berenz
<vber...@tuebingen.mpg.de> wrote:
> Hi Greg,
>
> Thanks a lot for your help.
>
> Indeed, reading the doc it makes sense to call rt_heap_bind after
> rt_heap_create. I updated my test code, but our legacy code have been
> working fine the other way around, though.
> I also changed the error management to consider 0 as success.
> But the problem remains, with the output remaining the same.
>
> Some more info:
>
> - I ran the same code on ubuntu 14.04  / xenomai 2.6.4 and all was fine
> (prints "OK" for any memory size passed as argument)
> - indeed when using TM_INFINITE the program hang
> - code 11 indeed corresponds to EWOULDBLOCK / EAGAIN
> - if I replace H_SHARE with H_FIFO and H_PRIO, output remains the same
> - if I replace H_SHARE with H_SINGLE, error code becomes 12 (cannot allocate
> memory) (but also program still produces "OK" for some memory size, same
> values as when using H_SHARE)
> - I compiled the tests, and heap-1 / heap-2 run ok
>
> Best
>
> Vincent
>
>
>
> On 10.01.2018 23:38, Greg Gallagher wrote:
>>
>> Hi,
>>
>> You may want to look at this test for help:
>>
>> https://git.xenomai.org/xenomai-3.git/tree/lib/alchemy/testsuite/heap-1.c
>>
>> I think you should have rt_heap_bind after your call to
>> rt_heap_create, if you switch the timeout flag in rt_heap_bind to
>> TM_INFINITE I think you should see your program hang.  From the docs
>>
>> (https://xenomai.org/documentation/xenomai-3/html/xeno3prm/group__alchemy__heap.html#gae17a8784a83d2eec94089a86a831a833)
>>   on rt_heap_bind it returns 0 on success, and your program treats 0 as
>> an error.   Print the value of rc after rt_heap_bind returns, it will
>> probable be -EWOULDBLOCK .
>>
>> Thanks
>>
>> Greg
>>
>> On Wed, Jan 10, 2018 at 4:31 AM, Vincent Berenz
>> <vber...@tuebingen.mpg.de> wrote:
>>>
>>> Hi,
>>>
>>> We are currently moving from xenomai 2 to xenomai 3. I installed xenomai
>>> 3.0.5, and all seems to be working, with low latency.
>>> I am now trying to get our legacy code to work on xenomai 3 using the
>>> transition kit.
>>>
>>> Our program crashes on heap allocation (rt_heap_alloc function) with
>>> error
>>> code -11 (resource temporarily unavailable).
>>>
>>> The rt_heap_alloc function was called successfully a few times before the
>>> crash, so I first assumed not enough heap was reserved, so I recompiled
>>> the
>>> kernel with more and more heap:
>>>
>>> CONFIG_XENO_OPT_SYS_HEAPSZ=524288
>>>
>>> This does not solve the issue. We also tried tooling with the
>>> '--mem-pool-size' argument, with no success.
>>>
>>> To check things I created a toy executable which just allocate memory:
>>>
>>> --
>>>
>>>  void alloc (char *name, int elemSize) {
>>>
>>>rt_printf("allocating for %d | ",elemSize);
>>>
>>>int  rc;
>>>RT_HEAP  heap;
>>>void*ptr;
>>>
>>>rc = rt_heap_bind(,name,TM_NONBLOCK);
>>>if(!rc) return;
>>>
>>>rc = rt_heap_create(,name,(size_t)(elemSize),H_SHARED);
>>>if(rc) return;
>>>
>>>rc = rt_heap_alloc(,(size_t)(elemSize),TM_NONBLOCK,);
>>>if (rc) {
>>>  printf("%d %s\n",rc,strerror(-rc));
>>>  return;
>>>}
>>>
>>>printf("OK\n");
>>>return;
>>>  }
>>>
>>>  int main(int, char** argv){
>>>
>>>int nb_ints = atoi(argv[1]);
>>>char *name = &quo

Re: [Xenomai] Xenomai 3.0.6 - ipipe-3.18.20 - kernel build error

[Greg Gallagher]

Hi,
  Can you post more information on how you are building the patched
kernel?  I'm assuming you are building for x86_64?

Thanks

Greg

On Wed, Jan 10, 2018 at 11:16 AM, Fazio Maurizio
 wrote:
> Hello,
> I have some problems in building the 3.18.20 stable kernel patched with 
> Xenomai 3.0.6 - Cobalt - ipipe-core-3.18.20-x86-9.patch
> The installed operating system is Centos 7. The same kernel patched using 
> Xenomai 3.0.5 and the same ipipe patch works without any problems.
>
> The following lines are the errors during the kernel building
>
> In file included from kernel/xenomai/bufd.c:23:0:
> arch/x86/xenomai/include/asm/xenomai/syscall.h: In function 
> ‘__xn_get_syscall_n’:
> arch/x86/xenomai/include/asm/xenomai/syscall.h:60:2: error: implicit 
> declaration of function ‘__COBALT_CALL32_SYSNR’ 
> [-Werror=implicit-function-declaration]
>  return __xn_syscall_p(regs) ? __xn_syscall(regs)
>
> In file included from arch/x86/xenomai/machine.c:22:0:
> arch/x86/xenomai/include/asm/xenomai/syscall.h: In function 
> ‘__xn_get_syscall_n’:
> arch/x86/xenomai/include/asm/xenomai/syscall.h:60:2: error: implicit 
> declaration of function ‘__COBALT_CALL32_SYSNR’ 
> [-Werror=implicit-function-declaration]
>  return __xn_syscall_p(regs) ? __xn_syscall(regs)
>
> The only difference is the new release of Xenomai 3.0.6 instead of the older 
> 3.0.5 version...
>
> Thanks in advance
>
> Maurizio Fazio
>
> Chief Technical Office / Aircraft Systems
> Software Engineer
>
>
>
> Leonardo S.p.A.
> C.so Francia, 426 - Torino - 10146 - Italy
> Tel. +39 011 756 3308 / 3761
>
> maurizio.fa...@leonardocompany.com
> www.leonardocompany.com
>
> –——
> HELICOPTERS/AERONAUTICS/ELECTRONICS, DEFENCE & SECURITY SYSTEMS/SPACE
> –——
>
>
>
> Il presente messaggio e-mail e ogni suo allegato devono intendersi 
> indirizzati esclusivamente al destinatario indicato e considerarsi dal 
> contenuto strettamente riservato e confidenziale. Se non siete l'effettivo 
> destinatario o avete ricevuto il messaggio e-mail per errore, siete pregati 
> di avvertire immediatamente il mittente e di cancellare il suddetto messaggio 
> e ogni suo allegato dal vostro sistema informatico. Qualsiasi utilizzo, 
> diffusione, copia o archiviazione del presente messaggio da parte di chi non 
> ne è il destinatario è strettamente proibito e può dar luogo a responsabilità 
> di carattere civile e penale punibili ai sensi di legge.
> Questa e-mail ha valore legale solo se firmata digitalmente ai sensi della 
> normativa vigente.
>
> The contents of this email message and any attachments are intended solely 
> for the addressee(s) and contain confidential and/or privileged information.
> If you are not the intended recipient of this message, or if this message has 
> been addressed to you in error, please immediately notify the sender and then 
> delete this message and any attachments from your system. If you are not the 
> intended recipient, you are hereby notified that any use, dissemination, 
> copying, or storage of this message or its attachments is strictly 
> prohibited. Unauthorized disclosure and/or use of information contained in 
> this email message may result in civil and criminal liability. “
> This e-mail has legal value according to the applicable laws only if it is 
> digitally signed by the sender
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] heap allocation working for some memory sizes but not others

[Greg Gallagher]

Hi,

You may want to look at this test for help:

https://git.xenomai.org/xenomai-3.git/tree/lib/alchemy/testsuite/heap-1.c

I think you should have rt_heap_bind after your call to
rt_heap_create, if you switch the timeout flag in rt_heap_bind to
TM_INFINITE I think you should see your program hang.  From the docs
(https://xenomai.org/documentation/xenomai-3/html/xeno3prm/group__alchemy__heap.html#gae17a8784a83d2eec94089a86a831a833)
 on rt_heap_bind it returns 0 on success, and your program treats 0 as
an error.   Print the value of rc after rt_heap_bind returns, it will
probable be -EWOULDBLOCK .

Thanks

Greg

On Wed, Jan 10, 2018 at 4:31 AM, Vincent Berenz
 wrote:
> Hi,
>
> We are currently moving from xenomai 2 to xenomai 3. I installed xenomai
> 3.0.5, and all seems to be working, with low latency.
> I am now trying to get our legacy code to work on xenomai 3 using the
> transition kit.
>
> Our program crashes on heap allocation (rt_heap_alloc function) with error
> code -11 (resource temporarily unavailable).
>
> The rt_heap_alloc function was called successfully a few times before the
> crash, so I first assumed not enough heap was reserved, so I recompiled the
> kernel with more and more heap:
>
> CONFIG_XENO_OPT_SYS_HEAPSZ=524288
>
> This does not solve the issue. We also tried tooling with the
> '--mem-pool-size' argument, with no success.
>
> To check things I created a toy executable which just allocate memory:
>
> --
>
> void alloc (char *name, int elemSize) {
>
>   rt_printf("allocating for %d | ",elemSize);
>
>   int  rc;
>   RT_HEAP  heap;
>   void*ptr;
>
>   rc = rt_heap_bind(,name,TM_NONBLOCK);
>   if(!rc) return;
>
>   rc = rt_heap_create(,name,(size_t)(elemSize),H_SHARED);
>   if(rc) return;
>
>   rc = rt_heap_alloc(,(size_t)(elemSize),TM_NONBLOCK,);
>   if (rc) {
> printf("%d %s\n",rc,strerror(-rc));
> return;
>   }
>
>   printf("OK\n");
>   return;
> }
>
> int main(int, char** argv){
>
>   int nb_ints = atoi(argv[1]);
>   char *name = "test";
>   alloc(name,nb_ints*sizeof(int));
>
> }
>
> --
>
>
> The output surprised me: allocation works for some values but not for
> others.
>
> for((nb_ints=2000;nb_ints<=132000;nb_ints+=2000)); do xenomai_heap_test
> $nb_ints; done
>
> results in:
>
> allocating for 8000 | OK
> allocating for 16000 | OK
> [...]
> allocating for 64000 | OK
> allocating for 72000 | -11 Resource temporarily unavailable
> allocating for 8 | -11 Resource temporarily unavailable
> allocating for 88000 | OK
> allocating for 96000 | OK
> [...]
> allocating for 128000 | OK
> allocating for 136000 | -11 Resource temporarily unavailable
> allocating for 144000 | -11 Resource temporarily unavailable
> [...]
> allocating for 168000 | -11 Resource temporarily unavailable
> allocating for 176000 | OK
> allocating for 184000 | OK
> allocating for 192000 | OK
> allocating for 20 | OK
> allocating for 208000 | OK
> allocating for 216000 | -11 Resource temporarily unavailable
> allocating for 224000 | -11 Resource temporarily unavailable
> [...]
> allocating for 328000 | -11 Resource temporarily unavailable
> allocating for 336000 | -11 Resource temporarily unavailable
> allocating for 344000 | OK
> allocating for 352000 | OK
> [...]
> allocating for 384000 | OK
> allocating for 392000 | -11 Resource temporarily unavailable
> [...]
> allocating for 52 | -11 Resource temporarily unavailable
> allocating for 528000 | -11 Resource temporarily unavailable
>
> Anything we are doing very wrong ?
>
> Vincent
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Xenomai community meeting 02.02.18

[Greg Gallagher]

I'll definitely attend via TelCo.

  Original Message  
From: henning.sch...@siemens.com
Sent: January 9, 2018 6:22 AM
To: r...@xenomai.org; jan.kis...@siemens.com; sance...@numalliance.com; 
j...@xenomai.org; s...@hilscher.com; g.m...@qmul.ac.uk; steven.see...@nasa.gov; 
l...@alaxarxa.net; g...@embeddedgreg.com; nolang...@gmail.com; 
dmit...@oss-tech.org; kendall.a...@3dsystems.com; w...@denx.de; 
lsore...@csclub.uwaterloo.ca; ggallaghe...@gmail.com; Xenomai@xenomai.org
Subject: Xenomai community meeting 02.02.18

Hi,

we have already talked about the "elephant in the room" and in that
thread we also talked about a face-to-face meeting of current and
future maintainers, contributers and users.

We have now agreed on a time and place for this meeting, and i want to
announce it and invite the whole community to it.

Where: somewhere in Brussels (details will follow)
   and remotely, TelCo link will be published
When: 02.02.18 13:00-18:00 (CET)
What: we do not have a clear agenda yet, but there is probably enough
  material to fill the timeslot
Attendees: Philippe Gerum, Jan Kiszka and myself will be there, you as
   well?

That meeting is colocated with https://fosdem.org/2018/ if you are
planning to attend in person, keep that in mind and maybe stay the
weekend. Jan and me will be around until Sunday afternoon, Phillippe
will leave Brussels on Saturday.

Sorry for the short notice, i still hope more people will attend in
person or at least in the TelCo. We will rent a coworking space for the
meeting, so the location depends on the number of participants.
If you want to participate please answer this mail before 01/24/18.

Looking forward to the meeting!
Henning
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Greg Gallagher]

We can add an ELC meeting ;)

On Fri, Jan 26, 2018 at 1:49 PM, Jan Kiszka  wrote:
> On 2018-01-25 18:40, Philippe Gerum wrote:
>>
>> Here are some points I would like to discuss during this meeting. Please
>> feel free to comment:
>>
>> 1. Release management
>>
>>   * Currently, the person who contributes most of the code is also the
>> release manager, which is clearly not optimal. Both activities should be
>> decoupled for efficiency (esp. hindsight) and practical reasons. At some
>> point, I will stop acting as the release manager, so the project will
>> need a different organization in this respect. Which one?
>>
>>   * As a corollary, the current release process is broken: no explicit
>> release plan or schedule, limited testing, barely any user feedback
>> about the development version in general. Practical steps to improve
>> this should be discussed.
>>
>>   * My understanding is that v3.1 is almost there feature-wise, with a
>> working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually
>> enabling RTnet with SMAP/x86 (which still need some feedback btw), and
>> support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is
>> still lagging behind with kernel 4.9 though. I'm about to queue a couple
>> of ABI changes more, with the implementation of sendmmsg() and
>> recvmmsg() for RTDM sockets.
>>
>> This raises the following questions: 1) may we freeze the v3.1 ABI, 2)
>> should we wait for supporting 4.14/x86 before releasing v3.1, 3) how
>> much use/testing do we currently have of the -next branch, on which CPU
>> architecture(s)?
>>
>> 2. Documentation
>>
>>   * The existing documentation has several weaknesses; from the traffic
>> on the mailing list, the main one may be that it leaves newcomers with a
>> steep learning curve, in some occasions, even when the information is
>> published on the website and/or present in the inline documentation. How
>> to improve the situation, how to better organize the existing doc so
>> that people do find what they are looking for?
>>
>>   * Doxygen may not be the best option anymore for inline documentation;
>> Chasing glitches with using the markup has been a real pain over the
>> years, getting properly structured output has never been obvious. Could
>> we do better with Doxygen in a reasonably simple fashion, or should
>> reStructuredText and Sphinx be considered as a replacement, so that we
>> can converge toward the kernel documentation system?
>>
>> 3. Pipeline maintenance
>>
>>   * We now have a dedicated I-pipe maintainer per CPU architecture, which
>> is a great relief to me. Now I'd like we discuss the maintenance
>> process, 1) how to organize the upstream/downstream flow of the generic
>> pipeline bits I still maintain currently, between other maintainers and
>> me? 2) how to best disseminate knowledge about the I-pipe implementation?
>>
>>   * mainline vs CIP kernel, LTS maintenance policy
>>
>> 4. Misc
>>
>>   * formalizing the decision about dropping the blackfin and powerpc64
>> port, since we had zero feedback from users so far, so everyone must be
>> fine with this.
>>
>> Thanks,
>>
>
> Thanks for preparing this. Sounds good to me.
>
> Adding from Greg's points as well, we probably need to bring up bug
> tracking together with the bigger topic workflow and related tooling.
> This may easily make us run out of time, but a survey of opinions and
> ideas in that round would be good to follow up on the list afterwards.
>
> Then testing. I would also not go into too much details, but it would be
> good to understand what exist(ed) and what could be done easily to
> improve it. Overlaps also with release management and with the good
> proposal to define reference boards.
>
> How many days will our meeting have? ;)
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Greg Gallagher]

That would be great,  I booked my flights and hotel this morning.
Definitely attending the Xenomai talk and there was another talk on a
3D printer that is using Xenomai
(https://elciotna18.sched.com/event/DXmw/3d-printing-with-linux-and-xenomai-kendall-auel-3d-systems-corp)
that sounds like it will be interesting.  I'm up for anything Xenomai,
I'll be getting there late Sunday and leaving around 6pm Wednesday.

-Greg

On Fri, Jan 26, 2018 at 1:57 PM, Jan Kiszka <jan.kis...@siemens.com> wrote:
> On 2018-01-26 19:51, Greg Gallagher wrote:
>> We can add an ELC meeting ;)
>>
>
> Sure! Will you attend?
>
> Our Xenomai talk was accepted [1], and I'll hang around in Portland for
> the whole ELC. We can do some hallway tracks or more if there is interest.
>
> Jan
>
> [1]
> https://elciotna18.sched.com/event/DXnN/steering-xenomai-into-the-real-time-linux-future-jan-kiszka-siemens-ag
>
>> On Fri, Jan 26, 2018 at 1:49 PM, Jan Kiszka <jan.kis...@siemens.com> wrote:
>>> On 2018-01-25 18:40, Philippe Gerum wrote:
>>>>
>>>> Here are some points I would like to discuss during this meeting. Please
>>>> feel free to comment:
>>>>
>>>> 1. Release management
>>>>
>>>>   * Currently, the person who contributes most of the code is also the
>>>> release manager, which is clearly not optimal. Both activities should be
>>>> decoupled for efficiency (esp. hindsight) and practical reasons. At some
>>>> point, I will stop acting as the release manager, so the project will
>>>> need a different organization in this respect. Which one?
>>>>
>>>>   * As a corollary, the current release process is broken: no explicit
>>>> release plan or schedule, limited testing, barely any user feedback
>>>> about the development version in general. Practical steps to improve
>>>> this should be discussed.
>>>>
>>>>   * My understanding is that v3.1 is almost there feature-wise, with a
>>>> working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually
>>>> enabling RTnet with SMAP/x86 (which still need some feedback btw), and
>>>> support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is
>>>> still lagging behind with kernel 4.9 though. I'm about to queue a couple
>>>> of ABI changes more, with the implementation of sendmmsg() and
>>>> recvmmsg() for RTDM sockets.
>>>>
>>>> This raises the following questions: 1) may we freeze the v3.1 ABI, 2)
>>>> should we wait for supporting 4.14/x86 before releasing v3.1, 3) how
>>>> much use/testing do we currently have of the -next branch, on which CPU
>>>> architecture(s)?
>>>>
>>>> 2. Documentation
>>>>
>>>>   * The existing documentation has several weaknesses; from the traffic
>>>> on the mailing list, the main one may be that it leaves newcomers with a
>>>> steep learning curve, in some occasions, even when the information is
>>>> published on the website and/or present in the inline documentation. How
>>>> to improve the situation, how to better organize the existing doc so
>>>> that people do find what they are looking for?
>>>>
>>>>   * Doxygen may not be the best option anymore for inline 
>>>> documentation;
>>>> Chasing glitches with using the markup has been a real pain over the
>>>> years, getting properly structured output has never been obvious. Could
>>>> we do better with Doxygen in a reasonably simple fashion, or should
>>>> reStructuredText and Sphinx be considered as a replacement, so that we
>>>> can converge toward the kernel documentation system?
>>>>
>>>> 3. Pipeline maintenance
>>>>
>>>>   * We now have a dedicated I-pipe maintainer per CPU architecture, 
>>>> which
>>>> is a great relief to me. Now I'd like we discuss the maintenance
>>>> process, 1) how to organize the upstream/downstream flow of the generic
>>>> pipeline bits I still maintain currently, between other maintainers and
>>>> me? 2) how to best disseminate knowledge about the I-pipe implementation?
>>>>
>>>>   * mainline vs CIP kernel, LTS maintenance policy
>>>>
>>>> 4. Misc
>>>>
>>>>   * formalizing the decision about dropping the blackfin and powerpc64
>>>> port, since we had zero feedback from users so far, so everyone must be
>>>>

Re: [Xenomai] [RFC] FOSDEM meeting agenda

[Greg Gallagher]

Sounds good to me, I can send out a reminder to the list the week
before the conference.

On Fri, Jan 26, 2018 at 2:34 PM, Jan Kiszka <jan.kis...@siemens.com> wrote:
> On 2018-01-26 20:02, Greg Gallagher wrote:
>> That would be great,  I booked my flights and hotel this morning.
>> Definitely attending the Xenomai talk and there was another talk on a
>> 3D printer that is using Xenomai
>> (https://elciotna18.sched.com/event/DXmw/3d-printing-with-linux-and-xenomai-kendall-auel-3d-systems-corp)
>
> Cool! Didn't check the agenda yet.
>
>> that sounds like it will be interesting.  I'm up for anything Xenomai,
>> I'll be getting there late Sunday and leaving around 6pm Wednesday.
>
> I'll have a couple of appointments, I suppose, but we could do a Xenomai
> lunch. Maybe right away on Monday (Tuesdays would be before my talk, I
> will likely need that time ;)).
>
> Jan
>
>>
>> -Greg
>>
>> On Fri, Jan 26, 2018 at 1:57 PM, Jan Kiszka <jan.kis...@siemens.com> wrote:
>>> On 2018-01-26 19:51, Greg Gallagher wrote:
>>>> We can add an ELC meeting ;)
>>>>
>>>
>>> Sure! Will you attend?
>>>
>>> Our Xenomai talk was accepted [1], and I'll hang around in Portland for
>>> the whole ELC. We can do some hallway tracks or more if there is interest.
>>>
>>> Jan
>>>
>>> [1]
>>> https://elciotna18.sched.com/event/DXnN/steering-xenomai-into-the-real-time-linux-future-jan-kiszka-siemens-ag
>>>
>>>> On Fri, Jan 26, 2018 at 1:49 PM, Jan Kiszka <jan.kis...@siemens.com> wrote:
>>>>> On 2018-01-25 18:40, Philippe Gerum wrote:
>>>>>>
>>>>>> Here are some points I would like to discuss during this meeting. Please
>>>>>> feel free to comment:
>>>>>>
>>>>>> 1. Release management
>>>>>>
>>>>>>   * Currently, the person who contributes most of the code is also 
>>>>>> the
>>>>>> release manager, which is clearly not optimal. Both activities should be
>>>>>> decoupled for efficiency (esp. hindsight) and practical reasons. At some
>>>>>> point, I will stop acting as the release manager, so the project will
>>>>>> need a different organization in this respect. Which one?
>>>>>>
>>>>>>   * As a corollary, the current release process is broken: no 
>>>>>> explicit
>>>>>> release plan or schedule, limited testing, barely any user feedback
>>>>>> about the development version in general. Practical steps to improve
>>>>>> this should be discussed.
>>>>>>
>>>>>>   * My understanding is that v3.1 is almost there feature-wise, with 
>>>>>> a
>>>>>> working arm64 port Dmitriy is polishing, a bunch of rtnet fixes actually
>>>>>> enabling RTnet with SMAP/x86 (which still need some feedback btw), and
>>>>>> support for recent kernels up to 4.14 (arm, arm64, powerpc). x86 is
>>>>>> still lagging behind with kernel 4.9 though. I'm about to queue a couple
>>>>>> of ABI changes more, with the implementation of sendmmsg() and
>>>>>> recvmmsg() for RTDM sockets.
>>>>>>
>>>>>> This raises the following questions: 1) may we freeze the v3.1 ABI, 2)
>>>>>> should we wait for supporting 4.14/x86 before releasing v3.1, 3) how
>>>>>> much use/testing do we currently have of the -next branch, on which CPU
>>>>>> architecture(s)?
>>>>>>
>>>>>> 2. Documentation
>>>>>>
>>>>>>   * The existing documentation has several weaknesses; from the 
>>>>>> traffic
>>>>>> on the mailing list, the main one may be that it leaves newcomers with a
>>>>>> steep learning curve, in some occasions, even when the information is
>>>>>> published on the website and/or present in the inline documentation. How
>>>>>> to improve the situation, how to better organize the existing doc so
>>>>>> that people do find what they are looking for?
>>>>>>
>>>>>>   * Doxygen may not be the best option anymore for inline 
>>>>>> documentation;
>>>>>> Chasing glitches with using the markup has been a real pain over the
>>>>>> years, getting properly structured output has never been obvious. Coul

[Xenomai] meeting agenda suggestions

[Greg Gallagher]

Adding some points that I think need some attention at the meeting.

Drivers:
Currently we have support for certain boards, SOC families and
devices.   Do we want to expand on that?  Are there commonly used
pieces of hardware that we want to add support for?  For most devices
it may be a port from Linux to Xenomai, which could be low effort.
What drives improvements to our current  frameworks like gpio and spi
?  Adding i2c, pwm and pci devices (etc) may be helpful.  Are users
looking for full BSPs?

Reference Boards:
Projects like AGL (Automotive Grade Linux) use low cost boards as
reference platforms so potential customers can get up and running
quickly.  I really think this helps for prototyping.  There's already
some support for Raspberry Pi, we could expand on that.  We could look
at the beaglebone family of boards and potentially Zynq boards.

Quick Start Guide:
This would probably fall under documentation but putting together
a quick start guide for new users may be worthwhile.  It could be tied
into the above comment of using low cost boards and we focus on a
quick start guide for one or two community (low cost) boards.

"How to" Articles:
   This may go with the above point, but adding some type of doc that
shows how to properly use the gpio, udd, ipc and other sub systems
would help new users and people possibly evaluating Xenomai.  Having
these on the homepage I think would show potential users that there
are resources to help get them started.  It would give prospective
users a general idea of what features Xenomai supports so far.  They
could also serve as reference/example code.

Testing:
   How do we test Xenomai?  There's some documentation on smokey the
smoke test framework, when are those tests run and how often?  Do we
run those tests across all architectures? Is a regression test suite
something we want to build?  Any reported bugs can be made into a test
case and added to the regression tests.

Bug reporting:
   When a user reports a bug on the mailing list they usually don't
include all the information needed.  There has been discussion on
using a bug tracking system.  Is this part of the gitlab effort? it
would be nice to ask the users for example code to reproduce their
bugs.  The udd issue on the todo list is hard to reproduce since there
is only snippets of code in the email thread and not a lot of
information on what the kernel side of the udd driver does.  We can
also see if anyone is watching or currently working on the bug.

Xenomai's successes:
We could give community members and companies the opportunity to
post their product or creation somewhere on the Xenomai home page.  It
would give potential users the ability to see Xenomai's successes.

Thanks,

Greg

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] ipipe: kernel updates in the light of recent fixes (meltdown...)

[Greg Gallagher]

I think using the CIP kernel would be a great idea.  I can see this
being popular with product developers.

-Greg

On Tue, Jan 23, 2018 at 12:52 PM, Jan Kiszka  wrote:
> Hi Philippe,
>
> as the number of question increase here, but I bet elsewhere as well,
> and I'm planning to work on some parts soonish, I'd like to coordinate:
>
> Where are we standing with 4.14 right now? There is nothing for x86 yet,
> right?
>
> What are the update plans for 4.9? We currently have one x86 user on
> that kernel, but I suppose we could also move on to 4.14 once it's
> ready. For me the question is right now where to invest x86-wise, 4.9
> update or 4.14 completion + update?
>
> For 4.4, which we will need for product use for sure, I'm considering to
> lift the support from 4.4 LTS to the CIP [1][2] kernel. That one will be
> longer maintained and basically differs from LTS only in mainline
> backports of certain hardware support and critical features. Plus some
> reverts of broken LTS commits that will later on be reverted there as
> well. The fuss that meltdown brings in would be a good point to do the
> jump IMHO (there is no CIP kernel with meltdown fixes yet, due to issues
> in LTS, but that will change soon).
>
> Regarding spectre, I'm not expected that much impact on ipipe, but that
> situation is still too much in flux, even in upstream.
>
> What do you think?
>
> @all: What are requirements of other users here?
>
> Jan
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-cip.git
> [2]
> https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Writing to UDD driver through mapped memory cause secondary mode switch

[Greg Gallagher]

Sorry to bring back an old thread but I just noticed this.  Did you
solve your issue?  Did you use the documentation in this file for
help? 
https://git.xenomai.org/xenomai-3.git/tree/include/cobalt/kernel/rtdm/udd.h?id=f4a54b173db71a182d9826852a94b20f6095b411

-Greg

On Thu, Dec 14, 2017 at 6:23 AM, MINIER Bertrand
 wrote:
> Hi,
>
> I implemented an UDD driver for a SOC IP on my Xilinx Ultrascale ZCU102 board.
> The arch is arm64 so I'm using Xenomai from the next branch.
>
> When I try to write to the memory mapped from the user space side, Xenomai 
> switches to secondary mode.
>
> I activated the SIGDEBUG and attached an handler to point the origin and the 
> reason of this secondary mode switch.
> The result of sigdebug_reason(siginfo) is SIGDEBUG_MIGRATE_FAULT.
>
> I'm using mmap with the following attributes:
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fpgaMemfd, 0);
>
> The file descriptor is opened with O_RDWR flag.
>
> What is strange is that memory write effectively works but the 
> SIGDEBUG_MIGRATE_FAULT is triggered. Reading the physical driver memory with 
> devmem returns the written value.
>
> Does anyone would have any idea about the origin of the issue ?
>
> Thanks,
>
> Bertrand Minier
>
>
> This e-mail and any accompanying attachments are confidential. If you are not 
> the intended recipient, you must not review, disclose, copy, distribute or 
> use this e-mail; please delete it from your system and notify the sender 
> immediately.
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] R: R: Xenomai 3.0.6 high latency

[Greg Gallagher]

Hi,
  I configured a xenomai 3 system on a x86 i7 not too long ago, I got
really got latency results. Here is what I did when I configured my
system:
Menu config options:

* Power management and ACPI options
  --> CPU Frequency scaling
  --> CPU Frequency scaling (Disable)
  --> ACPI (Advanced Configuration and Power Interface) Support
  --> Processor (Disable)
  --> CPU Idle
  --> CPU idle PM support (Disable)
* Pocessor type and features
  --> Enable maximum number of SMP processors and NUMA nodes (Disable)
  // Ref : http://xenomai.org/pipermail/xenomai/2017-September/037718.html
  --> Processor family
  --> Core 2/newer Xeon (if "cat /proc/cpuinfo | grep family"
returns 6, set as Generic otherwise)
  // Xenomai will issue a warning about CONFIG_MIGRATION, disable
those in this order
  --> Transparent Hugepage Support (Disable)
  --> Allow for memory compaction (Disable)
  --> Contiguous Memory Allocation (Disable)
  --> Allow for memory compaction
--> Page Migration (Disable)

I also followed the steps here:
https://xenomai.org/2014/06/dealing-with-x86-smi-troubles/

There was a print in the dmesg for my system telling me I didn't have
the SMI work around applied.

Hope this helps, take a look at the Xenomai website for help with
getting started using the ipipe tracer if you want to start debugging
software latency.

-Greg

On Fri, Jan 12, 2018 at 8:58 AM, Fazio Maurizio
 wrote:
> Hello,
> Following are the system informations:
> - OS: Centos 7 64 bit with Gnome 3.14.2 Version
> - Processor:   Intel® Xeon(R) CPU E5-2630 v3 @ 2.40GHz × 32
> - Graphics: Gallium 0.4 on llvmpipe (LLVM 3.8, 256 bits) I patched 3.18.20 
> kernel with Xenomai 3.0.6...
> For more details I attach the kernel configuration file...
>
> I built Xenomai with the following configure option:
> configure --enable-smp --enable-dlopen-libs --enable-pshared
>
> I disabled the following system services:
> upower.service - Daemon for power management tuned.service - Dynamic System 
> Tuning Daemon smartd.service - Self Monitoring and Reporting Technology 
> (SMART) Daemon firewalld.service - firewalld - dynamic firewall daemon
>
> As Simone Zucchi wrote before... I disabled the gnome power management 
> dconf-editor => gnome.settings-daemon.plugins.power => active false
>
> in grub2 I configured the following kernel parameters:
> apm=off xenomai.msi=disabled xenomai.sysheap_size=2048
>
> Latency grows when I launch applications like kdevelop or similar, or when 
> the I return from the lock screen...
> I simply launch the [XENOMAI FOLDER]/bin/latency application... can I trace 
> this built in application?
>
> Thanks in advance
> Maurizio Fazio
>
> Chief Technical Office / Aircraft Systems Software Engineer
>
>
>
> Leonardo S.p.A.
> C.so Francia, 426 - Torino - 10146 - Italy Tel. +39 011 756 3308 / 3761
>
> maurizio.fa...@leonardocompany.com
> www.leonardocompany.com
>
> –——
> HELICOPTERS/AERONAUTICS/ELECTRONICS, DEFENCE & SECURITY SYSTEMS/SPACE 
> –——
>
>
>
> Company General Use
>
>
> Il presente messaggio e-mail e ogni suo allegato devono intendersi 
> indirizzati esclusivamente al destinatario indicato e considerarsi dal 
> contenuto strettamente riservato e confidenziale. Se non siete l'effettivo 
> destinatario o avete ricevuto il messaggio e-mail per errore, siete pregati 
> di avvertire immediatamente il mittente e di cancellare il suddetto messaggio 
> e ogni suo allegato dal vostro sistema informatico. Qualsiasi utilizzo, 
> diffusione, copia o archiviazione del presente messaggio da parte di chi non 
> ne è il destinatario è strettamente proibito e può dar luogo a responsabilità 
> di carattere civile e penale punibili ai sensi di legge.
> Questa e-mail ha valore legale solo se firmata digitalmente ai sensi della 
> normativa vigente.
>
> The contents of this email message and any attachments are intended solely 
> for the addressee(s) and contain confidential and/or privileged information.
> If you are not the intended recipient of this message, or if this message has 
> been addressed to you in error, please immediately notify the sender and then 
> delete this message and any attachments from your system. If you are not the 
> intended recipient, you are hereby notified that any use, dissemination, 
> copying, or storage of this message or its attachments is strictly 
> prohibited. Unauthorized disclosure and/or use of information contained in 
> this email message may result in civil and criminal liability. “
> This e-mail has legal value according to the applicable laws only if it is 
> digitally signed by the sender
> -Messaggio originale-
> Da: Jan Kiszka [mailto:jan.kis...@siemens.com]
> Inviato: venerdì 12 gennaio 2018 14:37
> A: Fazio Maurizio; Simone M. Zucchi; xenomai@xenomai.org
> Oggetto: Re: R: Xenomai 3.0.6 high latency
>
> On 2018-01-12 10:51, Fazio Maurizio wrote:
>> Hello,
>> 

[Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

This patch is based on one that was submitted by Wolfgang Netbal back in Feb
2016 but a formal patch was never submitted.
I added a couple small changes (style errors and imx7 define) and tested on a
imx7d board. One quick note, the IMX7D define may not really be needed since
most imx7 uarts look to be compatible with imx6. The original thread that this
patch was derived from is located here:

https://xenomai.org/pipermail/xenomai/2016-February/035924.html

Signed-off-by: Greg Gallagher <g...@embeddedgreg.com>
---
 kernel/drivers/serial/rt_imx_uart.c | 337 
 1 file changed, 229 insertions(+), 108 deletions(-)

diff --git a/kernel/drivers/serial/rt_imx_uart.c 
b/kernel/drivers/serial/rt_imx_uart.c
index 092cecc..2c93789 100644
--- a/kernel/drivers/serial/rt_imx_uart.c
+++ b/kernel/drivers/serial/rt_imx_uart.c
@@ -36,8 +36,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -65,7 +67,10 @@ MODULE_LICENSE("GPL");
 #define UBMR   0xa8 /* BRM Modulator Register */
 #define UBRC   0xac /* Baud Rate Count Register */
 #define MX2_ONEMS 0xb0 /* One Millisecond register */
-#define UTS (cpu_is_mx1() ? 0xd0 : 0xb4) /* UART Test Register */
+#define IMX1_UTS 0xd0 /* UART Test Register on i.mx1 */
+#define IMX21_UTS 0xb4 /* UART Test Register on all other i.mx*/
+
+
 
 /* UART Control Register Bit Fields.*/
 #define URXD_CHARRDY   (1<<15)
@@ -143,7 +148,7 @@ MODULE_LICENSE("GPL");
 #define USR1_DTRD  (1<<7)  /* DTR Delta */
 #define USR1_RXDS  (1<<6)  /* Receiver idle interrupt flag */
 #define USR1_AIRINT(1<<5)  /* Async IR wake interrupt flag */
-#define USR1_AWAKE (1<<4)  /* Aysnc wake interrupt flag */
+#define USR1_AWAKE (1<<4)  /* Async wake interrupt flag */
 #define USR2_ADET  (1<<15) /* Auto baud rate detect complete */
 #define USR2_TXFE  (1<<14) /* Transmit buffer FIFO empty */
 #define USR2_DTRF  (1<<13) /* DTR edge interrupt flag */
@@ -189,9 +194,25 @@ MODULE_LICENSE("GPL");
 #define RT_IMX_UART_MAX5
 
 static int tx_fifo[RT_IMX_UART_MAX];
-compat_module_param_array(tx_fifo, int, RT_IMX_UART_MAX, 0400);
+module_param_array(tx_fifo, int, NULL, 0400);
 MODULE_PARM_DESC(tx_fifo, "Transmitter FIFO size");
 
+/* i.MX21 type uart runs on all i.mx except i.MX1 and i.MX6q */
+enum imx_uart_type {
+   IMX1_UART,
+   IMX21_UART,
+   IMX53_UART,
+   IMX6Q_UART,
+   IMX7D_UART,
+};
+
+/* device type dependent stuff */
+struct imx_uart_data {
+   unsigned int uts_reg;
+   enum imx_uart_type devtype;
+};
+
+
 struct rt_imx_uart_port {
unsigned char __iomem *membase; /* read/write[bwl] */
resource_size_t mapbase;/* for ioremap */
@@ -200,11 +221,79 @@ struct rt_imx_uart_port {
unsigned int have_rtscts;
unsigned int use_dcedte;
unsigned int use_hwflow;
-   struct clk *clk;/* clock id for UART clock */
+   struct clk *clk_ipg;/* clock id for UART clock */
+   struct clk *clk_per;/* clock id for UART clock */
+   const struct imx_uart_data *devdata;
unsigned int uartclk;   /* base uart clock */
struct rtdm_device rtdm_dev;/* RTDM device structure */
 };
 
+
+static struct imx_uart_data imx_uart_devdata[] = {
+   [IMX1_UART] = {
+   .uts_reg = IMX1_UTS,
+   .devtype = IMX1_UART,
+   },
+   [IMX21_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX21_UART,
+   },
+   [IMX53_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX53_UART,
+   },
+   [IMX6Q_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX6Q_UART,
+   },
+   [IMX7D_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX7D_UART,
+   },
+};
+
+static const struct platform_device_id rt_imx_uart_id_table[] = {
+   {
+   .name = "imx1-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX1_UART],
+   }, {
+   .name = "imx21-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX21_UART],
+   }, {
+   .name = "imx53-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX53_UART],
+   }, {
+   .name = "imx6q-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX6Q_UART],
+   }, {
+   .name = "imx-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX7D_UART],
+   }, {
+   /* sentinel */
+   }
+};
+MODULE_DEVICE_TABLE(platform, rt_imx_uart_id_table);
+
+static const struct of_device_id rt_imx_uart_dt_ids[] = {
+   {
+   .compatible = &

[Xenomai] [PATCH 1/3] Add Xilinx AXI gpio driver

[Greg Gallagher]

---
 kernel/drivers/gpio/Kconfig   | 10 +-
 kernel/drivers/gpio/Makefile  |  3 ++-
 kernel/drivers/gpio/gpio-xilinx.c | 40 +++
 3 files changed, 51 insertions(+), 2 deletions(-)
 create mode 100644 kernel/drivers/gpio/gpio-xilinx.c

diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
index 81fc442..b7efa54 100644
--- a/kernel/drivers/gpio/Kconfig
+++ b/kernel/drivers/gpio/Kconfig
@@ -6,7 +6,7 @@ config XENO_DRIVERS_GPIO
help
 
Real-time capable GPIO module.
-  
+
 if XENO_DRIVERS_GPIO
 
 config XENO_DRIVERS_GPIO_BCM2835
@@ -41,6 +41,14 @@ config XENO_DRIVERS_GPIO_ZYNQ7000
Enables support for the GPIO controller available from
Xilinx's Zynq7000 SoC.
 
+config XENO_DRIVERS_GPIO_XILINX
+   depends on ARCH_ZYNQ
+   bool "Support for Xilinx GPIOs"
+   help
+
+   Enables support for the GPIO controller available from
+   Xilinx's softcore IP.
+
 config XENO_DRIVERS_GPIO_DEBUG
bool "Enable GPIO core debugging features"
 
diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
index 7f28403..3737330 100644
--- a/kernel/drivers/gpio/Makefile
+++ b/kernel/drivers/gpio/Makefile
@@ -1,4 +1,3 @@
-
 ccflags-$(CONFIG_XENO_DRIVERS_GPIO_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_XENO_DRIVERS_GPIO) += xeno_gpio.o
@@ -9,3 +8,5 @@ xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += gpio-bcm2835.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += gpio-mxc.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += gpio-sun8i-h3.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += gpio-zynq7000.o
+xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += gpio-xilinx.o
+
diff --git a/kernel/drivers/gpio/gpio-xilinx.c 
b/kernel/drivers/gpio/gpio-xilinx.c
new file mode 100644
index 000..72d4364
--- /dev/null
+++ b/kernel/drivers/gpio/gpio-xilinx.c
@@ -0,0 +1,40 @@
+/**
+ * @note Copyright (C) 2017 Greg Gallagher <g...@embeddedgreg.com>
+ *
+ * This driver controls the gpio that can be located on the PL
+ * of the Zynq SOC
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+#include 
+#include "gpio-core.h"
+
+#define RTDM_SUBCLASS_XILINX  5
+
+static int __init xilinx_gpio_init(void)
+{
+   return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
+ RTDM_SUBCLASS_XILINX);
+}
+module_init(xilinx_gpio_init);
+
+static void __exit xilinx_gpio_exit(void)
+{
+   rtdm_gpiochip_remove_of(RTDM_SUBCLASS_XILINX);
+}
+module_exit(xilinx_gpio_exit);
+
+MODULE_LICENSE("GPL");
+
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH 3/3] Allow for more then one rt gpio driver to be built and loaded at the same build

[Greg Gallagher]

Some SOCs will have two GPIO chips that require two independent drivers.  In my
case I was working with the Zynq SOC and needed a driver for the gpios on the
FPGA and a driver for the gpios available on the ARM core. This change allows
for two rt gpio drivers to be built and loaded at the same time.
The rt gpio driver will be renamed from xeno-gpio to the following:

xeno-gpio-bcm2835.ko
xeno-gpio-mxc.ko
xeno-gpio-sun8i-h3.ko
xeno-gpio-zynq7000.ko

This also moves the gpio-core logic into the kernel image.
---
 kernel/drivers/gpio/Kconfig   | 12 ++--
 kernel/drivers/gpio/Makefile  | 22 --
 kernel/drivers/gpio/gpio-xilinx.c |  4 ++--
 3 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
index b7efa54..48475f2 100644
--- a/kernel/drivers/gpio/Kconfig
+++ b/kernel/drivers/gpio/Kconfig
@@ -1,7 +1,7 @@
 menu "Real-time GPIO drivers"
 
 config XENO_DRIVERS_GPIO
-   tristate "GPIO controller"
+   bool "GPIO controller"
depends on GPIOLIB
help
 
@@ -11,7 +11,7 @@ if XENO_DRIVERS_GPIO
 
 config XENO_DRIVERS_GPIO_BCM2835
depends on MACH_BCM2708 || ARCH_BCM2835
-   bool "Support for BCM2835 GPIOs"
+   tristate "Support for BCM2835 GPIOs"
help
 
Enables support for the GPIO controller available from
@@ -19,7 +19,7 @@ config XENO_DRIVERS_GPIO_BCM2835
 
 config XENO_DRIVERS_GPIO_MXC
depends on GPIO_MXC
-   bool "Support for MXC GPIOs"
+   tristate "Support for MXC GPIOs"
help
 
Suitable for the GPIO controller available from
@@ -27,7 +27,7 @@ config XENO_DRIVERS_GPIO_MXC
 
 config XENO_DRIVERS_GPIO_SUN8I_H3
depends on MACH_SUN8I && PINCTRL_SUN8I_H3
-   bool "Support for SUN8I H3 GPIOs"
+   tristate "Support for SUN8I H3 GPIOs"
help
 
Suitable for the GPIO controller available from Allwinner's H3
@@ -35,7 +35,7 @@ config XENO_DRIVERS_GPIO_SUN8I_H3
 
 config XENO_DRIVERS_GPIO_ZYNQ7000
depends on ARCH_ZYNQ
-   bool "Support for Zynq7000 GPIOs"
+   tristate "Support for Zynq7000 GPIOs"
help
 
Enables support for the GPIO controller available from
@@ -43,7 +43,7 @@ config XENO_DRIVERS_GPIO_ZYNQ7000
 
 config XENO_DRIVERS_GPIO_XILINX
depends on ARCH_ZYNQ
-   bool "Support for Xilinx GPIOs"
+   tristate "Support for Xilinx GPIOs"
help
 
Enables support for the GPIO controller available from
diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
index 3737330..8648fcc 100644
--- a/kernel/drivers/gpio/Makefile
+++ b/kernel/drivers/gpio/Makefile
@@ -1,12 +1,14 @@
 ccflags-$(CONFIG_XENO_DRIVERS_GPIO_DEBUG) := -DDEBUG
 
-obj-$(CONFIG_XENO_DRIVERS_GPIO) += xeno_gpio.o
-
-xeno_gpio-y := gpio-core.o
-
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += gpio-bcm2835.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += gpio-mxc.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += gpio-sun8i-h3.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += gpio-zynq7000.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += gpio-xilinx.o
-
+obj-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += xeno-gpio-bcm2835.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += xeno-gpio-mxc.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += xeno-gpio-sun8i-h3.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += xeno-gpio-zynq7000.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += xeno-gpio-xilinx.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO) += gpio-core.o
+
+xeno-gpio-bcm2835-y := gpio-bcm2835.o
+xeno-gpio-mxc-y := gpio-mxc.o
+xeno-gpio-sun8i-h3-y := gpio-sun8i-h3.o
+xeno-gpio-zynq7000-y := gpio-zynq7000.o
+xeno-gpio-xilinx-y := gpio-xilinx.o
diff --git a/kernel/drivers/gpio/gpio-xilinx.c 
b/kernel/drivers/gpio/gpio-xilinx.c
index 72d4364..e982f5f 100644
--- a/kernel/drivers/gpio/gpio-xilinx.c
+++ b/kernel/drivers/gpio/gpio-xilinx.c
@@ -19,13 +19,13 @@
  * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */
 #include 
-#include "gpio-core.h"
+#include 
 
 #define RTDM_SUBCLASS_XILINX  5
 
 static int __init xilinx_gpio_init(void)
 {
-   return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
+   return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
  RTDM_SUBCLASS_XILINX);
 }
 module_init(xilinx_gpio_init);
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH 2/3] Handle device paths from the device tree that start with a forward slash

[Greg Gallagher]

If the device name from the device tree starts with a forward slash (/) the
rtdm device stores it in the registry including the forward slash.  When we
go to use that device and do the registry lookup we use a relative path from
/dev/rtdm which doesn't contain the forward slash and fails to find a match.
Open won't return an error but IO calls will fail.  To fix this when we
register an RTDM device skip the first character if it's a forward slash.

In my case the path from the device tree is
/amba_pl/gpio@4120/gpio905
which gets stored in the registry. When we want to use the device and look up
the device path in the registry we use
amba_pl/gpio@4120/gpio905
which won't find a match in the registry.

Tested on Zynq7000 gpio drivers
---
 kernel/cobalt/rtdm/device.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/kernel/cobalt/rtdm/device.c b/kernel/cobalt/rtdm/device.c
index 4533dfb..89e0815 100644
--- a/kernel/cobalt/rtdm/device.c
+++ b/kernel/cobalt/rtdm/device.c
@@ -91,9 +91,12 @@ struct rtdm_device *__rtdm_get_namedev(const char *path)
if (strncmp(path, "rtdm/", 5) == 0)
path += 5;
 
+   printk(KERN_ERR "path to bind %s\n", path);
ret = xnregistry_bind(path, XN_NONBLOCK, XN_RELATIVE, );
-   if (ret)
+   if (ret) {
+   printk(KERN_ERR "xnreg bind fail %d\n", ret);
return NULL;
+   }
 
mutex_lock(_lock);
 
@@ -394,6 +397,7 @@ int rtdm_dev_register(struct rtdm_device *dev)
int ret, major, minor;
xnkey_t id;
dev_t rdev;
+   const char *dev_name;
 
secondary_mode_only();
 
@@ -446,8 +450,12 @@ int rtdm_dev_register(struct rtdm_device *dev)
ret = -ENOMEM;
goto fail;
}
-
-   ret = xnregistry_enter(dev->name, dev,
+   if (dev->name[0] == '/') {
+   dev_name = dev->name+1;
+   } else {
+   dev_name = dev->name;
+   }
+   ret = xnregistry_enter(dev_name, dev,
   >named.handle, NULL);
if (ret)
goto fail;
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Uninstall xenomai

[Greg Gallagher]

How did you install it?

  Original Message  
From: samiraelmada...@gmail.com
Sent: February 2, 2018 4:08 PM
To: xenomai@xenomai.org
Subject: [Xenomai] Uninstall xenomai

Please How to uninstall xenomai-2.4.6 (remove all the partition)
from the computer
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] ipipe 4.14 arm 32-bit

[Greg Gallagher]

Hi,
  Which ipipe branch should I be using to test out 4.14 ipipe?  I
tried rebase/4.14-arm, which worked after a couple of very small fix
ups.  If this is the branch we should be testing against I'll submit
the patches to fix the raspberry pi build.

-Greg

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH 2/3] Handle device paths from the device tree that start with a forward slash

[Greg Gallagher]

Yep, sorry I thought I removed that. Will update

On Thu, Feb 1, 2018 at 5:29 AM, Philippe Gerum <r...@xenomai.org> wrote:
> On 01/31/2018 03:36 AM, Greg Gallagher wrote:
>> If the device name from the device tree starts with a forward slash (/) the
>> rtdm device stores it in the registry including the forward slash.  When we
>> go to use that device and do the registry lookup we use a relative path from
>> /dev/rtdm which doesn't contain the forward slash and fails to find a match.
>> Open won't return an error but IO calls will fail.  To fix this when we
>> register an RTDM device skip the first character if it's a forward slash.
>>
>> In my case the path from the device tree is
>> /amba_pl/gpio@4120/gpio905
>> which gets stored in the registry. When we want to use the device and look up
>> the device path in the registry we use
>> amba_pl/gpio@4120/gpio905
>> which won't find a match in the registry.
>>
>
> Good catch, thanks.
>
>> Tested on Zynq7000 gpio drivers
>> ---
>>  kernel/cobalt/rtdm/device.c | 14 +++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/cobalt/rtdm/device.c b/kernel/cobalt/rtdm/device.c
>> index 4533dfb..89e0815 100644
>> --- a/kernel/cobalt/rtdm/device.c
>> +++ b/kernel/cobalt/rtdm/device.c
>> @@ -91,9 +91,12 @@ struct rtdm_device *__rtdm_get_namedev(const char *path)
>>   if (strncmp(path, "rtdm/", 5) == 0)
>>   path += 5;
>>
>> + printk(KERN_ERR "path to bind %s\n", path);
>
> Debug stuff to remove before merging.
>
> --
> Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH 3/3] Allow for more then one rt gpio driver to be built and loaded at the same build

[Greg Gallagher]

Yes, will fix that

On Thu, Feb 1, 2018 at 5:30 AM, Philippe Gerum <r...@xenomai.org> wrote:
> On 01/31/2018 03:36 AM, Greg Gallagher wrote:
>> Some SOCs will have two GPIO chips that require two independent drivers.  In 
>> my
>> case I was working with the Zynq SOC and needed a driver for the gpios on the
>> FPGA and a driver for the gpios available on the ARM core. This change allows
>> for two rt gpio drivers to be built and loaded at the same time.
>> The rt gpio driver will be renamed from xeno-gpio to the following:
>>
>> xeno-gpio-bcm2835.ko
>> xeno-gpio-mxc.ko
>> xeno-gpio-sun8i-h3.ko
>> xeno-gpio-zynq7000.ko
>>
>> This also moves the gpio-core logic into the kernel image.
>> ---
>>  kernel/drivers/gpio/Kconfig   | 12 ++--
>>  kernel/drivers/gpio/Makefile  | 22 --
>>  kernel/drivers/gpio/gpio-xilinx.c |  4 ++--
>>  3 files changed, 20 insertions(+), 18 deletions(-)
>>
>> diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
>> index b7efa54..48475f2 100644
>> --- a/kernel/drivers/gpio/Kconfig
>> +++ b/kernel/drivers/gpio/Kconfig
>> @@ -1,7 +1,7 @@
>>  menu "Real-time GPIO drivers"
>>
>>  config XENO_DRIVERS_GPIO
>> -   tristate "GPIO controller"
>> +   bool "GPIO controller"
>> depends on GPIOLIB
>> help
>>
>> @@ -11,7 +11,7 @@ if XENO_DRIVERS_GPIO
>>
>>  config XENO_DRIVERS_GPIO_BCM2835
>>   depends on MACH_BCM2708 || ARCH_BCM2835
>> - bool "Support for BCM2835 GPIOs"
>> + tristate "Support for BCM2835 GPIOs"
>>   help
>>
>>   Enables support for the GPIO controller available from
>> @@ -19,7 +19,7 @@ config XENO_DRIVERS_GPIO_BCM2835
>>
>>  config XENO_DRIVERS_GPIO_MXC
>>   depends on GPIO_MXC
>> - bool "Support for MXC GPIOs"
>> + tristate "Support for MXC GPIOs"
>>   help
>>
>>   Suitable for the GPIO controller available from
>> @@ -27,7 +27,7 @@ config XENO_DRIVERS_GPIO_MXC
>>
>>  config XENO_DRIVERS_GPIO_SUN8I_H3
>>   depends on MACH_SUN8I && PINCTRL_SUN8I_H3
>> - bool "Support for SUN8I H3 GPIOs"
>> + tristate "Support for SUN8I H3 GPIOs"
>>   help
>>
>>   Suitable for the GPIO controller available from Allwinner's H3
>> @@ -35,7 +35,7 @@ config XENO_DRIVERS_GPIO_SUN8I_H3
>>
>>  config XENO_DRIVERS_GPIO_ZYNQ7000
>>   depends on ARCH_ZYNQ
>> - bool "Support for Zynq7000 GPIOs"
>> + tristate "Support for Zynq7000 GPIOs"
>>   help
>>
>>   Enables support for the GPIO controller available from
>> @@ -43,7 +43,7 @@ config XENO_DRIVERS_GPIO_ZYNQ7000
>>
>>  config XENO_DRIVERS_GPIO_XILINX
>>   depends on ARCH_ZYNQ
>> - bool "Support for Xilinx GPIOs"
>> + tristate "Support for Xilinx GPIOs"
>>   help
>>
>>   Enables support for the GPIO controller available from
>> diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
>> index 3737330..8648fcc 100644
>> --- a/kernel/drivers/gpio/Makefile
>> +++ b/kernel/drivers/gpio/Makefile
>> @@ -1,12 +1,14 @@
>>  ccflags-$(CONFIG_XENO_DRIVERS_GPIO_DEBUG) := -DDEBUG
>>
>> -obj-$(CONFIG_XENO_DRIVERS_GPIO) += xeno_gpio.o
>> -
>> -xeno_gpio-y := gpio-core.o
>> -
>> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += gpio-bcm2835.o
>> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += gpio-mxc.o
>> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += gpio-sun8i-h3.o
>> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += gpio-zynq7000.o
>> -xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += gpio-xilinx.o
>> -
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += xeno-gpio-bcm2835.o
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += xeno-gpio-mxc.o
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += xeno-gpio-sun8i-h3.o
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += xeno-gpio-zynq7000.o
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += xeno-gpio-xilinx.o
>> +obj-$(CONFIG_XENO_DRIVERS_GPIO) += gpio-core.o
>> +
>> +xeno-gpio-bcm2835-y := gpio-bcm2835.o
>> +xeno-gpio-mxc-y := gpio-mxc.o
>> +xeno-gpio-sun8i-h3-y := gpio-sun8i-h3.o
>> +xeno-gpio-zynq7000-y := gpio-zynq7000.o
>> +xeno-gpio-xilinx-y := gpio-xilinx.o
>
> Ok.
>
>> diff --git a/kernel/drivers/gpio/gpio-xilinx.c 
>> b/kernel/drivers/gpio/gpio-xilinx.c
>> index 72d4364..e982f5f 100644
>> --- a/kernel/drivers/gpio/gpio-xilinx.c
>> +++ b/kernel/drivers/gpio/gpio-xilinx.c
>> @@ -19,13 +19,13 @@
>>   * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, 
>> USA.
>>   */
>>  #include 
>> -#include "gpio-core.h"
>> +#include 
>>
>>  #define RTDM_SUBCLASS_XILINX  5
>>
>>  static int __init xilinx_gpio_init(void)
>>  {
>> - return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
>> + return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
>>   RTDM_SUBCLASS_XILINX);
>>  }
>>  module_init(xilinx_gpio_init);
>>
>
> Left over from patch #1?
>
> --
> Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

Makes sense, after the fact I realized this would diverge from the
mainline structs.  Will fix up and update.

On Thu, Feb 1, 2018 at 5:02 AM, Philippe Gerum <r...@xenomai.org> wrote:
> On 01/31/2018 03:28 AM, Greg Gallagher wrote:
>> This patch is based on one that was submitted by Wolfgang Netbal back in Feb
>> 2016 but a formal patch was never submitted.
>> I added a couple small changes (style errors and imx7 define) and tested on a
>> imx7d board. One quick note, the IMX7D define may not really be needed since
>> most imx7 uarts look to be compatible with imx6.
>
> I would drop this additional definition. DT indeed says that imx7d uarts
> can be handled by the i.MX serial driver as imx6q devices, and
> fsl,imx7d-uart is a mere alias to fsl,imx6q-uart AFAICS in the mainline
> tree up to 4.15.
>
> --
> Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH 3/3] Allow for more then one rt gpio driver to be built and loaded at the same build

[Greg Gallagher]

Some SOCs will have two GPIO chips that require two independent drivers.  In my
case I was working with the Zynq SOC and needed a driver for the gpios on the
FPGA and a driver for the gpios available on the ARM core. This change allows
for two rt gpio drivers to be built and loaded at the same time.
The rt gpio driver will be renamed from xeno-gpio to the following:

xeno-gpio-bcm2835.ko
xeno-gpio-mxc.ko
xeno-gpio-sun8i-h3.ko
xeno-gpio-zynq7000.ko

This also moves the gpio-core logic into the kernel image.
---
 kernel/drivers/gpio/Kconfig  | 12 ++--
 kernel/drivers/gpio/Makefile | 22 --
 2 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
index b7efa54..48475f2 100644
--- a/kernel/drivers/gpio/Kconfig
+++ b/kernel/drivers/gpio/Kconfig
@@ -1,7 +1,7 @@
 menu "Real-time GPIO drivers"
 
 config XENO_DRIVERS_GPIO
-   tristate "GPIO controller"
+   bool "GPIO controller"
depends on GPIOLIB
help
 
@@ -11,7 +11,7 @@ if XENO_DRIVERS_GPIO
 
 config XENO_DRIVERS_GPIO_BCM2835
depends on MACH_BCM2708 || ARCH_BCM2835
-   bool "Support for BCM2835 GPIOs"
+   tristate "Support for BCM2835 GPIOs"
help
 
Enables support for the GPIO controller available from
@@ -19,7 +19,7 @@ config XENO_DRIVERS_GPIO_BCM2835
 
 config XENO_DRIVERS_GPIO_MXC
depends on GPIO_MXC
-   bool "Support for MXC GPIOs"
+   tristate "Support for MXC GPIOs"
help
 
Suitable for the GPIO controller available from
@@ -27,7 +27,7 @@ config XENO_DRIVERS_GPIO_MXC
 
 config XENO_DRIVERS_GPIO_SUN8I_H3
depends on MACH_SUN8I && PINCTRL_SUN8I_H3
-   bool "Support for SUN8I H3 GPIOs"
+   tristate "Support for SUN8I H3 GPIOs"
help
 
Suitable for the GPIO controller available from Allwinner's H3
@@ -35,7 +35,7 @@ config XENO_DRIVERS_GPIO_SUN8I_H3
 
 config XENO_DRIVERS_GPIO_ZYNQ7000
depends on ARCH_ZYNQ
-   bool "Support for Zynq7000 GPIOs"
+   tristate "Support for Zynq7000 GPIOs"
help
 
Enables support for the GPIO controller available from
@@ -43,7 +43,7 @@ config XENO_DRIVERS_GPIO_ZYNQ7000
 
 config XENO_DRIVERS_GPIO_XILINX
depends on ARCH_ZYNQ
-   bool "Support for Xilinx GPIOs"
+   tristate "Support for Xilinx GPIOs"
help
 
Enables support for the GPIO controller available from
diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
index 3737330..8648fcc 100644
--- a/kernel/drivers/gpio/Makefile
+++ b/kernel/drivers/gpio/Makefile
@@ -1,12 +1,14 @@
 ccflags-$(CONFIG_XENO_DRIVERS_GPIO_DEBUG) := -DDEBUG
 
-obj-$(CONFIG_XENO_DRIVERS_GPIO) += xeno_gpio.o
-
-xeno_gpio-y := gpio-core.o
-
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += gpio-bcm2835.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += gpio-mxc.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += gpio-sun8i-h3.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += gpio-zynq7000.o
-xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += gpio-xilinx.o
-
+obj-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += xeno-gpio-bcm2835.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += xeno-gpio-mxc.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += xeno-gpio-sun8i-h3.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += xeno-gpio-zynq7000.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += xeno-gpio-xilinx.o
+obj-$(CONFIG_XENO_DRIVERS_GPIO) += gpio-core.o
+
+xeno-gpio-bcm2835-y := gpio-bcm2835.o
+xeno-gpio-mxc-y := gpio-mxc.o
+xeno-gpio-sun8i-h3-y := gpio-sun8i-h3.o
+xeno-gpio-zynq7000-y := gpio-zynq7000.o
+xeno-gpio-xilinx-y := gpio-xilinx.o
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH 1/3] Add Xilinx AXI gpio driver

[Greg Gallagher]

---
 kernel/drivers/gpio/Kconfig   | 10 +-
 kernel/drivers/gpio/Makefile  |  3 ++-
 kernel/drivers/gpio/gpio-xilinx.c | 40 +++
 3 files changed, 51 insertions(+), 2 deletions(-)
 create mode 100644 kernel/drivers/gpio/gpio-xilinx.c

diff --git a/kernel/drivers/gpio/Kconfig b/kernel/drivers/gpio/Kconfig
index 81fc442..b7efa54 100644
--- a/kernel/drivers/gpio/Kconfig
+++ b/kernel/drivers/gpio/Kconfig
@@ -6,7 +6,7 @@ config XENO_DRIVERS_GPIO
help
 
Real-time capable GPIO module.
-  
+
 if XENO_DRIVERS_GPIO
 
 config XENO_DRIVERS_GPIO_BCM2835
@@ -41,6 +41,14 @@ config XENO_DRIVERS_GPIO_ZYNQ7000
Enables support for the GPIO controller available from
Xilinx's Zynq7000 SoC.
 
+config XENO_DRIVERS_GPIO_XILINX
+   depends on ARCH_ZYNQ
+   bool "Support for Xilinx GPIOs"
+   help
+
+   Enables support for the GPIO controller available from
+   Xilinx's softcore IP.
+
 config XENO_DRIVERS_GPIO_DEBUG
bool "Enable GPIO core debugging features"
 
diff --git a/kernel/drivers/gpio/Makefile b/kernel/drivers/gpio/Makefile
index 7f28403..3737330 100644
--- a/kernel/drivers/gpio/Makefile
+++ b/kernel/drivers/gpio/Makefile
@@ -1,4 +1,3 @@
-
 ccflags-$(CONFIG_XENO_DRIVERS_GPIO_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_XENO_DRIVERS_GPIO) += xeno_gpio.o
@@ -9,3 +8,5 @@ xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_BCM2835) += gpio-bcm2835.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_MXC) += gpio-mxc.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_SUN8I_H3) += gpio-sun8i-h3.o
 xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_ZYNQ7000) += gpio-zynq7000.o
+xeno_gpio-$(CONFIG_XENO_DRIVERS_GPIO_XILINX) += gpio-xilinx.o
+
diff --git a/kernel/drivers/gpio/gpio-xilinx.c 
b/kernel/drivers/gpio/gpio-xilinx.c
new file mode 100644
index 000..e982f5f
--- /dev/null
+++ b/kernel/drivers/gpio/gpio-xilinx.c
@@ -0,0 +1,40 @@
+/**
+ * @note Copyright (C) 2017 Greg Gallagher <g...@embeddedgreg.com>
+ *
+ * This driver controls the gpio that can be located on the PL
+ * of the Zynq SOC
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+#include 
+#include 
+
+#define RTDM_SUBCLASS_XILINX  5
+
+static int __init xilinx_gpio_init(void)
+{
+   return rtdm_gpiochip_scan_of(NULL, "xlnx,xps-gpio-1.00.a",
+ RTDM_SUBCLASS_XILINX);
+}
+module_init(xilinx_gpio_init);
+
+static void __exit xilinx_gpio_exit(void)
+{
+   rtdm_gpiochip_remove_of(RTDM_SUBCLASS_XILINX);
+}
+module_exit(xilinx_gpio_exit);
+
+MODULE_LICENSE("GPL");
+
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH 2/3] Handle device paths from the device tree that start with a forward slash

[Greg Gallagher]

If the device name from the device tree starts with a forward slash (/) the
rtdm device stores it in the registry including the forward slash.  When we
go to use that device and do the registry lookup we use a relative path from
/dev/rtdm which doesn't contain the forward slash and fails to find a match.
Open won't return an error but IO calls will fail.  To fix this when we
register an RTDM device skip the first character if it's a forward slash.

In my case the path from the device tree is
/amba_pl/gpio@4120/gpio905
which gets stored in the registry. When we want to use the device and look up
the device path in the registry we use
amba_pl/gpio@4120/gpio905
which won't find a match in the registry.

Tested on Zynq7000 gpio drivers
---
 kernel/cobalt/rtdm/device.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/cobalt/rtdm/device.c b/kernel/cobalt/rtdm/device.c
index 4533dfb..4cfdb1c 100644
--- a/kernel/cobalt/rtdm/device.c
+++ b/kernel/cobalt/rtdm/device.c
@@ -394,6 +394,7 @@ int rtdm_dev_register(struct rtdm_device *dev)
int ret, major, minor;
xnkey_t id;
dev_t rdev;
+   const char *dev_name;
 
secondary_mode_only();
 
@@ -446,8 +447,12 @@ int rtdm_dev_register(struct rtdm_device *dev)
ret = -ENOMEM;
goto fail;
}
-
-   ret = xnregistry_enter(dev->name, dev,
+   if (dev->name[0] == '/') {
+   dev_name = dev->name+1;
+   } else {
+   dev_name = dev->name;
+   }
+   ret = xnregistry_enter(dev_name, dev,
   >named.handle, NULL);
if (ret)
goto fail;
-- 
2.7.4


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH] Fix up the imx uart driver so it now compiles with new kernels.

[Greg Gallagher]

This patch is based on one that was submitted by Wolfgang Netbal back in Feb
2016 but a formal patch was never submitted.
I added a couple small changes (style errors and imx7 define) and tested on a
imx7d board. One quick note, the IMX7D define may not really be needed since
most imx7 uarts look to be compatible with imx6. The original thread that this
patch was derived from is located here:

https://xenomai.org/pipermail/xenomai/2016-February/035924.html

Signed-off-by: Greg Gallagher <g...@embeddedgreg.com>
---
 kernel/drivers/serial/rt_imx_uart.c | 326 
 1 file changed, 218 insertions(+), 108 deletions(-)

diff --git a/kernel/drivers/serial/rt_imx_uart.c 
b/kernel/drivers/serial/rt_imx_uart.c
index 092cecc..61836ae 100644
--- a/kernel/drivers/serial/rt_imx_uart.c
+++ b/kernel/drivers/serial/rt_imx_uart.c
@@ -36,8 +36,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -65,7 +67,10 @@ MODULE_LICENSE("GPL");
 #define UBMR   0xa8 /* BRM Modulator Register */
 #define UBRC   0xac /* Baud Rate Count Register */
 #define MX2_ONEMS 0xb0 /* One Millisecond register */
-#define UTS (cpu_is_mx1() ? 0xd0 : 0xb4) /* UART Test Register */
+#define IMX1_UTS 0xd0 /* UART Test Register on i.mx1 */
+#define IMX21_UTS 0xb4 /* UART Test Register on all other i.mx*/
+
+
 
 /* UART Control Register Bit Fields.*/
 #define URXD_CHARRDY   (1<<15)
@@ -143,7 +148,7 @@ MODULE_LICENSE("GPL");
 #define USR1_DTRD  (1<<7)  /* DTR Delta */
 #define USR1_RXDS  (1<<6)  /* Receiver idle interrupt flag */
 #define USR1_AIRINT(1<<5)  /* Async IR wake interrupt flag */
-#define USR1_AWAKE (1<<4)  /* Aysnc wake interrupt flag */
+#define USR1_AWAKE (1<<4)  /* Async wake interrupt flag */
 #define USR2_ADET  (1<<15) /* Auto baud rate detect complete */
 #define USR2_TXFE  (1<<14) /* Transmit buffer FIFO empty */
 #define USR2_DTRF  (1<<13) /* DTR edge interrupt flag */
@@ -189,9 +194,24 @@ MODULE_LICENSE("GPL");
 #define RT_IMX_UART_MAX5
 
 static int tx_fifo[RT_IMX_UART_MAX];
-compat_module_param_array(tx_fifo, int, RT_IMX_UART_MAX, 0400);
+module_param_array(tx_fifo, int, NULL, 0400);
 MODULE_PARM_DESC(tx_fifo, "Transmitter FIFO size");
 
+/* i.MX21 type uart runs on all i.mx except i.MX1 and i.MX6q */
+enum imx_uart_type {
+   IMX1_UART,
+   IMX21_UART,
+   IMX53_UART,
+   IMX6Q_UART,
+};
+
+/* device type dependent stuff */
+struct imx_uart_data {
+   unsigned int uts_reg;
+   enum imx_uart_type devtype;
+};
+
+
 struct rt_imx_uart_port {
unsigned char __iomem *membase; /* read/write[bwl] */
resource_size_t mapbase;/* for ioremap */
@@ -200,11 +220,69 @@ struct rt_imx_uart_port {
unsigned int have_rtscts;
unsigned int use_dcedte;
unsigned int use_hwflow;
-   struct clk *clk;/* clock id for UART clock */
+   struct clk *clk_ipg;/* clock id for UART clock */
+   struct clk *clk_per;/* clock id for UART clock */
+   const struct imx_uart_data *devdata;
unsigned int uartclk;   /* base uart clock */
struct rtdm_device rtdm_dev;/* RTDM device structure */
 };
 
+
+static struct imx_uart_data imx_uart_devdata[] = {
+   [IMX1_UART] = {
+   .uts_reg = IMX1_UTS,
+   .devtype = IMX1_UART,
+   },
+   [IMX21_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX21_UART,
+   },
+   [IMX53_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX53_UART,
+   },
+   [IMX6Q_UART] = {
+   .uts_reg = IMX21_UTS,
+   .devtype = IMX6Q_UART,
+   },
+};
+
+static const struct platform_device_id rt_imx_uart_id_table[] = {
+   {
+   .name = "imx1-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX1_UART],
+   }, {
+   .name = "imx21-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX21_UART],
+   }, {
+   .name = "imx53-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX53_UART],
+   }, {
+   .name = "imx6q-uart",
+   .driver_data = (kernel_ulong_t) _uart_devdata[IMX6Q_UART],
+   }, {
+   /* sentinel */
+   }
+};
+MODULE_DEVICE_TABLE(platform, rt_imx_uart_id_table);
+
+static const struct of_device_id rt_imx_uart_dt_ids[] = {
+   {
+   .compatible = "fsl,imx6q-uart",
+   .data = _uart_devdata[IMX6Q_UART], },
+   {
+   .compatible = "fsl,imx53-uart",
+   .data = _uart_devdata[IMX53_UART], },
+   {
+   .compatible = "fsl,imx1-u

[Xenomai] Reference Board

[Greg Gallagher]

Hi,
   After the recent meet up we had, I had an idea to help with a
couple of issues that we identified.  One issue that was brought up is
new users don't know how to get started with Xenomai, this impacts the
community of users and downstream feedback we get.  To help this
problem I'm proposing we choose one hardware board (maybe more later)
that we would ensure has proper Xenomai support.
   This would ensure that new users are able to try out Xenomai on
real hardware and we (the Xenomai community) can make sure that it
works well and gives new users a great experience as they get started
with Xenomai.  Based on popularity and availability I suggest we start
with the Raspberry PI family of boards.  They are pretty common and
most people of this list probably have one or two (because of an
office clean out at work, I now have almost one of each variant).  The
wide availability would make it easy to (eventually) distribute the
testing across interested contributors and new Xenomai users.
   The other nice benefit is the ability to test and maintain a good
set of example drivers for the raspberry PI platform.  We can ensure
that these RTDM drivers are using the most up to date interfaces and
best practices.  These could be examples that we point developers to
when they try to create RTDM drivers for their own platform.  I did a
quick audit of what we currently support today in Xenomai for
raspberry pi and we are only 3-4 drivers away from supporting most of
what's on the board.  Video drivers, GPU etc would be left to only the
Linux domain for now.
Creating and easy to use getting started wiki around the raspberry pi
would give us the ability to create interesting examples using Xenomai
that controls real hardware.  We could provide pre-built images based
on either buildroot or Ubuntu (I've done both of these for different
pi boards with good success).  This would give new users the ability
to get their hands dirty pretty quickly and with out having to build
everything from scratch.  Once they get comfortable with Xenomai then
they can move into building it from scratch and replacing bits and
pieces of the stock images.
   The cost of doing this may seem steep at first, but I'm willing to
take on a good chunk of the work and then hopefully the maintenance
and testing won't prove to be too bad.  As the idea becomes more clear
hopefully other users or developers will help out.  The benefit of
doing this I believe will help with the ability to build a community
around Xenomai and start to create a larger base of downstream users.

   If we think this is a good path to go down, I can post some more
information on what I've already started and what needs to be done.
Discussion and feedback would be appreciated :)

Thanks

Greg

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Reference Board

[Greg Gallagher]

Technically we should be able to hit them all.  The drivers don't
really differ, most of them target the bcm2835.  The larger work would
be testing, we would need to build and test for v6, v7 and v8.
Currently I've tested the Rpi2b and rpi zero w on Philippe's latest
I-ipipe branch.  I still need to verify RPI3 boots and works properly
with the newest ipipe for ARM64.  For the short term I'd like to start
with 4.14 since it's that latest LTS kernel and then we can look at
supporting older ones.  I'd like to support the SLTS kernel if we port
the ipipe to it.

-Greg

On Mon, Feb 5, 2018 at 11:52 AM, Lennart Sorensen
<lsore...@csclub.uwaterloo.ca> wrote:
> On Mon, Feb 05, 2018 at 11:22:46AM -0500, Greg Gallagher wrote:
>> Hi,
>>After the recent meet up we had, I had an idea to help with a
>> couple of issues that we identified.  One issue that was brought up is
>> new users don't know how to get started with Xenomai, this impacts the
>> community of users and downstream feedback we get.  To help this
>> problem I'm proposing we choose one hardware board (maybe more later)
>> that we would ensure has proper Xenomai support.
>>This would ensure that new users are able to try out Xenomai on
>> real hardware and we (the Xenomai community) can make sure that it
>> works well and gives new users a great experience as they get started
>> with Xenomai.  Based on popularity and availability I suggest we start
>> with the Raspberry PI family of boards.  They are pretty common and
>> most people of this list probably have one or two (because of an
>> office clean out at work, I now have almost one of each variant).  The
>> wide availability would make it easy to (eventually) distribute the
>> testing across interested contributors and new Xenomai users.
>>The other nice benefit is the ability to test and maintain a good
>> set of example drivers for the raspberry PI platform.  We can ensure
>> that these RTDM drivers are using the most up to date interfaces and
>> best practices.  These could be examples that we point developers to
>> when they try to create RTDM drivers for their own platform.  I did a
>> quick audit of what we currently support today in Xenomai for
>> raspberry pi and we are only 3-4 drivers away from supporting most of
>> what's on the board.  Video drivers, GPU etc would be left to only the
>> Linux domain for now.
>> Creating and easy to use getting started wiki around the raspberry pi
>> would give us the ability to create interesting examples using Xenomai
>> that controls real hardware.  We could provide pre-built images based
>> on either buildroot or Ubuntu (I've done both of these for different
>> pi boards with good success).  This would give new users the ability
>> to get their hands dirty pretty quickly and with out having to build
>> everything from scratch.  Once they get comfortable with Xenomai then
>> they can move into building it from scratch and replacing bits and
>> pieces of the stock images.
>>The cost of doing this may seem steep at first, but I'm willing to
>> take on a good chunk of the work and then hopefully the maintenance
>> and testing won't prove to be too bad.  As the idea becomes more clear
>> hopefully other users or developers will help out.  The benefit of
>> doing this I believe will help with the ability to build a community
>> around Xenomai and start to create a larger base of downstream users.
>>
>>If we think this is a good path to go down, I can post some more
>> information on what I've already started and what needs to be done.
>> Discussion and feedback would be appreciated :)
>
> So would that be the Pi, Pi 2 or Pi 3?  A, or B or Zero?
>
> --
> Len Sorensen

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RTnet] 3.0.6 xenomai/net/drivers 'debug' symbol redeclared

[Greg Gallagher]

This is fixed in stable-3.0.x

On Mon, Jan 29, 2018 at 1:15 PM, Philippe Gerum  wrote:
> On 01/29/2018 07:01 PM, alessio margan wrote:
>> Hi all,
>>
>> I was installing xenomai 3.0.6 (
>> https://xenomai.org/downloads/xenomai/stable/ ) on a 4.9.51 kernel, I
>> get the following errors
>>
>> drivers/xenomai/net/drivers/r8169.c:131:12: error: ‘debug’ redeclared as
>> different kind of symbol
>>
>>  static int debug = -1;
>> ^
>> In file included from arch/x86/xenomai/include/asm/xenomai/thread.h:25:0,
>>  from include/xenomai/cobalt/kernel/thread.h:35,
>>  from include/xenomai/cobalt/kernel/sched.h:24,
>>  from include/xenomai/rtdm/driver.h:37,
>>  from drivers/xenomai/net/stack/include/rtnet.h:99,
>>  from drivers/xenomai/net/stack/include/rtskb.h:32,
>>  from drivers/xenomai/net/stack/include/rtdev.h:37,
>>  from drivers/xenomai/net/stack/include/rtnet_port.h:32,
>>  from drivers/xenomai/net/drivers/r8169.c:82:
>> ./arch/x86/include/asm/traps.h:13:17: note: previous declaration of
>> ‘debug’ was here
>>  asmlinkage void debug(void);
>>
>> drivers/xenomai/net/drivers/igb/igb_main.c:280:12: error: ‘debug’
>> redeclared as different kind of symbol
>>  static int debug = -1;
>> ^
>> In file included from arch/x86/xenomai/include/asm/xenomai/thread.h:25:0,
>>  from include/xenomai/cobalt/kernel/thread.h:35,
>>  from include/xenomai/cobalt/kernel/sched.h:24,
>>  from include/xenomai/rtdm/driver.h:37,
>>  from drivers/xenomai/net/stack/include/rtnet.h:99,
>>  from drivers/xenomai/net/stack/include/rtskb.h:32,
>>  from drivers/xenomai/net/stack/include/rtdev.h:37,
>>  from drivers/xenomai/net/stack/include/rtnet_port.h:32,
>>  from drivers/xenomai/net/drivers/igb/e1000_hw.h:31,
>>  from drivers/xenomai/net/drivers/igb/e1000_mac.h:28,
>>  from drivers/xenomai/net/drivers/igb/igb.h:30,
>>  from drivers/xenomai/net/drivers/igb/igb_main.c:56:
>> ./arch/x86/include/asm/traps.h:13:17: note: previous declaration of
>> ‘debug’ was here
>>  asmlinkage void debug(void);
>>
>>
>> there is a workaround or I should try git://xenomai.org/xenomai-3.git
>> wip/rtnet-fixes and then wait for a 3.0.7 ?
>>
>
> The rule of thumb is to track and pull the latest code from the
> stable-3.0.x branch at git://git.xenomai.org/xenomai-3.git.
>
> --
> Philippe.
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH] fixes for rpi 2b build

[Greg Gallagher]

Small fix ups to enable building multi_v7_defconfig
---
 drivers/gpio/gpio-mvebu.c  |  1 +
 drivers/gpio/gpio-pl061.c  |  1 +
 drivers/gpio/gpio-zynq.c   |  2 +-
 drivers/irqchip/irq-atmel-aic5.c   |  6 --
 drivers/irqchip/irq-bcm7120-l2.c   | 15 +--
 drivers/irqchip/irq-brcmstb-l2.c   | 10 ++
 drivers/irqchip/irq-dw-apb-ictl.c  |  1 +
 drivers/pinctrl/pinctrl-rockchip.c |  8 
 drivers/soc/dove/pmu.c |  1 +
 9 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index 50242fa..058362c 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "gpiolib.h"
 
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 97b093e..5f9be96 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -261,6 +261,7 @@ static void pl061_irq_mask_ack(struct irq_data *d)
writeb(gpioie, pl061->base + GPIOIE);
raw_spin_unlock(>lock);
 }
+#endif
 
 static void pl061_irq_unmask(struct irq_data *d)
 {
diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index f961274..4dd3627 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -225,7 +225,6 @@ static int zynq_gpio_get_value(struct gpio_chip *chip, 
unsigned int pin)
u32 data;
unsigned int bank_num, bank_pin_num;
struct zynq_gpio *gpio = gpiochip_get_data(chip);
-   unsigned long flags;
 
zynq_gpio_get_bank_pin(pin, _num, _pin_num, gpio);
 
@@ -306,6 +305,7 @@ static int zynq_gpio_dir_in(struct gpio_chip *chip, 
unsigned int pin)
u32 reg;
unsigned int bank_num, bank_pin_num;
struct zynq_gpio *gpio = gpiochip_get_data(chip);
+   unsigned long flags;
 
zynq_gpio_get_bank_pin(pin, _num, _pin_num, gpio);
 
diff --git a/drivers/irqchip/irq-atmel-aic5.c b/drivers/irqchip/irq-atmel-aic5.c
index 699a7be..4bbdd31 100644
--- a/drivers/irqchip/irq-atmel-aic5.c
+++ b/drivers/irqchip/irq-atmel-aic5.c
@@ -194,6 +194,7 @@ static void aic5_suspend(struct irq_data *d)
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
int i;
u32 mask;
+   unsigned long flags;
 
if (smr_cache)
for (i = 0; i < domain->revmap_size; i++) {
@@ -201,7 +202,7 @@ static void aic5_suspend(struct irq_data *d)
smr_cache[i] = irq_reg_readl(bgc, AT91_AIC5_SMR);
}
 
-   irq_gc_lock(bgc);
+   flags = irq_gc_lock(bgc);
for (i = 0; i < dgc->irqs_per_chip; i++) {
mask = 1 << i;
if ((mask & gc->mask_cache) == (mask & gc->wake_active))
@@ -224,8 +225,9 @@ static void aic5_resume(struct irq_data *d)
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
int i;
u32 mask;
+   unsigned long flags;
 
-   irq_gc_lock(bgc);
+   flags = irq_gc_lock(bgc);
 
if (smr_cache) {
irq_reg_writel(bgc, 0x, AT91_AIC5_SPU);
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 983640e..1224980 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -61,6 +61,7 @@ static void bcm7120_l2_intc_irq_handle(struct irq_desc *desc)
struct bcm7120_l2_intc_data *b = data->b;
struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned int idx;
+   unsigned long flags;
 
chained_irq_enter(chip, desc);
 
@@ -71,11 +72,11 @@ static void bcm7120_l2_intc_irq_handle(struct irq_desc 
*desc)
unsigned long pending;
int hwirq;
 
-   irq_gc_lock(gc);
+   flags = irq_gc_lock(gc);
pending = irq_reg_readl(gc, b->stat_offset[idx]) &
gc->mask_cache &
data->irq_map_mask[idx];
-   irq_gc_unlock(gc);
+   irq_gc_unlock(gc, flags);
 
for_each_set_bit(hwirq, , IRQS_PER_WORD) {
generic_handle_irq(irq_find_mapping(b->domain,
@@ -90,22 +91,24 @@ static void bcm7120_l2_intc_suspend(struct irq_chip_generic 
*gc)
 {
struct bcm7120_l2_intc_data *b = gc->private;
struct irq_chip_type *ct = gc->chip_types;
+unsigned long flags;
 
-   irq_gc_lock(gc);
+   flags = irq_gc_lock(gc);
if (b->can_wake)
irq_reg_writel(gc, gc->mask_cache | gc->wake_active,
   ct->regs.mask);
-   irq_gc_unlock(gc);
+   irq_gc_unlock(gc, flags);
 }
 
 static void bcm7120_l2_intc_resume(struct irq_chip_generic *gc)
 {
struct irq_chip_type *ct = gc->chip_types;
+unsigned long flags;
 
/* Restore the saved mask */
-   irq_gc_lock(gc);
+   flags = irq_gc_lock(gc);
irq_reg_writel(gc,