Dear sirs,
I’ve done some work concerning porting ipipe patches to Robert Nelson 3.13-bone5 kernel.
The patches & short descriptions how to apply are stored here:
https://github.com/t-szczyrba/bbb-xenomai-patches
Please read Robert C Nelson kernel installation documentation as well as xenomai installation documentation before playing with it,
regards,
T.
Very exciting, thanks for sharing!
Keep us posted, I'm hoping at some point a Xenomai patched kernel with
SGX GPU support will be possible. You might also want to let the folks
on the Xenomai list know you're working on this, there may be someone
else trying to do something similar.
Is it possible to get a same instructions list for the official one ?
Until now I was using your machinekit Charles, but I’d like to use my own Xenomai that I could
change options (to add Traces, reduces latency, etc) .After getting the R. Nelson and checkout
to 3.8 repo I’m lost to the next things to do .
If it bothers you here, I can create a dedicated post however.
PS if it can helps after successfully found how to do it I could put it on a doc that way nobody would ask anymore.
For the MachineKit Xenomai kernels it's very easy, and identical to
working with Robert Nelson's kernels. You just work from my github
repository instead of his (I've added the Xenomai patches to the
laundry-list of BeagleBone patches his scripts apply):
https://github.com/cdsteinkuehler/linux-dev
You run the ./build_kernel.sh script, so the BeagleBone and Xenomai
patches will be applied. You can then edit the configuration as desired
and rebuild the kernel using tools/rebuild.sh
The latest configuration tweaks I have made at the suggestion of the
Xenomai folks may be found in the 3.8.13-bone39-xenomai branch. If you
find any configuration changes that help with latency or performance,
please let me know!
Thanks a lot Charles it helps me a lot.
What I am doing is trying indeed to experiment and benchmark Xenomai with Beablegone. Thus, I did some tests from your machinekit in SD Card
In “mesures 1” I’ve used a set_periodic_timer to toggle a gpio with a 2000 uS task as another process was doing : ping -f localhost -s 65000 >/dev/null
Dans mesures 2 I did the same + latency_test -p 100 -T 240.
As I was a bit wondering I did a latency test during 1 h but did before echo 0 > /proc/xenoami/latency (instead of 4999 ) :
lat min|—-lat avg|—-lat max|-overrun|—msw|—lat best|–lat worst
11.083| 13.874 | 24.416 | 0 | 0 | 6.374 | 32.791
As I m somewhat surprised by these results -even if they are in user space- I’d like to get more familiar with the build, and being able to put the Machinekit or Xenomai image directly in eMMC to avoid SD accesses , hoping to have better latency results.
David
You can use the Xenomai kernel with any of the Debian images from RCN,
just install to the eMMC then update the kernel.
The MachineKit images are on SD card to support LinuxCNC and it's (large
set of) build dependencies. You can get a much lighter-weight system
running Xenomai if that's all you are interested in.
You'll probably still want to compile and install the Xenomai user-space
tools (or copy the /home/linuxcnc/xenomai-2.6 folder from the MachineKit
install), but the build requirements are much lighter for Xenomai than
for LinuxCNC.
You can use the Xenomai kernel with any of the Debian images from RCN,
just install to the eMMC then update the kernel
Whereas I m quite ok with the use of Xenomai, I’m not really at ease with the way to build it, the Readme is clear but some steps are missings for me.
You can get a much lighter-weight system running Xenomai if that’s all you are interested in
Exactly my purpose, I’ll stay in user space (no RTDM driver)
You’ll probably still want to compile and install the Xenomai user-space
tools (or copy the /home/linuxcnc/xenomai-2.6 folder from the MachineKit
install), but the build requirements are much lighter for Xenomai than
for LinuxCNC
If I’ve understood what you said, I’d better have to copy from the built image /home/linuxcnc/xenomai-2.6, but
that won’t suffice to have eMMC working.
There's not much to building the user-space Xenomai tools from scratch,
either follow along with the Xenomai instructions, or you can refer to
the scripts that get run when I build my images:
The *.shu script is run as a normal user (linuxcnc), and the *.shr
script is run as root.
You can do this on your preferred version of Debian/Ubuntu running out
of the eMMC (just grab one of RCN's eMMC flasher images). That and
swapping out the kernel gets you a working Xenomai system. Anything
else you need you should be able to pull in with a simple "aptitude
install whatever".
I think I’ve misunderstood finally, you were explaining me how to build tools , so indeed : I’ve reproduced the operations manually as from the shu script
Besides, from the Readme :
first run (to setup baseline tree): ./build_kernel.sh
then modify files under KERNEL directory
then run (to rebuild with your changes): ./tools/rebuild.sh
seems what you were talking about, therefore my modifications will be in the 2nd part.
just grab one of RCN’s eMMC flasher images
That and swapping out the kernel gets you a working Xenomai system.
Then, I only copy the built xenomai linuxcnc kernel onto this RCN’s eMMC image ? no dependency (libs, …)
No dependencies are required for the kernel, and the kernel interface is
standard enough you can swap out versions without having to recompile
everything that sits above the kernel.
So yes, you can just swap out the kernel. Especially a 3.8.13 kernel
for a 3.8.13 kernel patched with Xenomai! They are virtually identical.
Thank you for this Charles.
Charles,
My tries didn’t succeeded, but I’m sure I’ve missed the good kernel :
I’ve flashed the http://rcn-ee.net/deb/testing/2014-02-05/BBB-eMMC-flasher-debian-7.3-2014-02-05-2gb.img.xz
which could boot and run.
It use currently : 3.8.13-bone36
I then build the linux-dev where /deploy/3.11.0-rc1-armv7-d1.zimage to overwrite the bbb /boot/uboot
which lead me to a wrong boot : 4 leds fixed.
Therefore, please where to get the correct kernel to swap from ?
If you built/installed "3.11.0-rc1-armv7-d1.zimage" then you didn't follow
the directions posted, as that would have been the "master" branch of
linux-dev..
Regards,
I’ve followed :
For the MachineKit Xenomai kernels it’s very easy, and identical to
working with Robert Nelson’s kernels. You just work from my github
repository instead of his (I’ve added the Xenomai patches to the
laundry-list of BeagleBone patches his scripts apply):
https://github.com/cdsteinkuehler/linux-dev
You run the ./build_kernel.sh script, so the BeagleBone and Xenomai
patches will be applied. You can then edit the configuration as desired
and rebuild the kernel using tools/rebuild.sh
which may be wrong, but :
git branch
within linux-dev is correctly pointing to master.
What did I’ve missed
If you're using my linux-dev repository, you need to check out the
appropriate branch, master is not intended for actual use.
Therefore, this would need to
is that right ?
if yes, I couldn’t retrieve where to set the branch to co.
If you're wanting a Xenomai kernel, you should:
git checkout --track 3.8.13-bone39-xenomai
...then run the build-kernel.sh script.
If you want a plain kernel, pull from Robert's repository and use one of
the 3.8.13-bone* tags. It's not a branch so when you checkout the tag
you'll get a "detatched head" warning. You can ignore this (until you
have changes you want to push back upstream) and just build the kernel
as usual.
If you're wanting a Xenomai kernel, you should:
git checkout --track 3.8.13-bone39-xenomai
...then run the build-kernel.sh script.
If you want a plain kernel, pull from Robert's repository and use one of
the 3.8.13-bone* tags. It's not a branch so when you checkout the tag
you'll get a "detatched head" warning. You can ignore this (until you
have changes you want to push back upstream) and just build the kernel
as usual.
Why not checkout the am33x-v3.8 branch? That way you can track the changes
Robert makes to his v3.8 branch. I find it easier to patch Robert¹s
linux-dev repo with your xenomai changes and then I¹m always up to date
with Robert¹s changes. It might be even easier to have Robert add a
Xenomai branch.
Regards,
John
I 200% agree : that’s why I was refering to it :
Is it possible to get a same instructions list for the official one ?
anyway with a checkout from any branch, I’m not sure that xenomai will be compiled as from docs, blog, forums, book
it’s clearly precise that not all kernel version accept xenomai patches. Therefore, from my understanding only 1 commit is currenlty guaranteed to work :
---- Beaglebone 1- Checkout the "am33x-v3.8" branch in the Robert Nelson repository [3], the patch has been tested with commit **3fc8a73d782231ab2750ff29793a760e8fa076bb** 2- apply beaglebone/ipipe-core-3.8.13-beaglebone-pre.patch 3- apply ipipe-core-3.8.13-arm-1.patch 4- apply beaglebone/ipipe-core-3.8.13-beaglebone-post.patch 5- you can resume to generic installation instructions.
John: until now I’ve been just compiled vanilla kernels, -ie no xenomai worked- could you please indicate what are these steps you have followed to compile it ?
I wrote those instructions, and the scripts I added to the linux-dev
kernel builder follow the official Xenomai instructions for how to build
a kernel.
The specific git commit referenced in the instructions above was known
to work when the instructions were written, and is listed because the
Xenomai folks wanted a specific commit and not just a branch. Once
everything got sorted out, I have been able to apply the Xenomai patches
to any of the 3.8.13 kernels without issue.