By default for the BeagleBoard-X15 debian image, we will be shipping a
v4.1.x lts based kernel with ti's patches (1), along with our
cape-manager patch-set for the BeagleBone (shared kernel).
Using the built-in kernel update tool, these can also just be
installed by "sudo apt-get install linux-image-xyz
linux-headers-xyz"..
cd /opt/scripts/tool/
git pull
sudo ./update_kernel.sh ${options}
Options:
v4.1.x-ti: deb package push-outs every Thursday:
v4.1.x-ti: (default)
--ti-channel --testing
v4.1.x-ti + Real-Time patchset:
--ti-rt-channel --testing
v4.1.x-ti + Xenomai patchset: (planned, not available yet)
v4.1.x-ti-omap2plus: (ti only, no external patch-set except for make
deb-pkg changes)
--ti-omap2plus-channel
Mainline: push out's every Sunday/Monday, (no external patch-set
except for make deb-pkg changes)
omap2plus: (2)
--omap2plus-channel
multiv7: (3)
--multiv7-channel
1: http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.1.y
2: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/configs/omap2plus_defconfig
3: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/configs/multi_v7_defconfig
Regards,
This is the PREEMPT_RT patch set, correct?
That may work well enough now it can be used to move motors with
Machinekit. And I'm positive it's good enough for initial testing if
Xenomai doesn't "play nice" with 4.1 yet.
Actually... CONFIG_PREEMPT_RT_FULL=y 
Along with overlays and cape-universal by default..
The only thing you might not like, for the PRU:
CONFIG_PRUSS_REMOTEPROC
vs what we used on v3.8.x:
CONFIG_UIO_PRUSS
But it's going mainline... and we just need a first user to figure out
what we need to port.
Regards,
v4.1.x-ti + Real-Time patchset:
--ti-rt-channel --testing
This is the PREEMPT_RT patch set, correct?
That may work well enough now it can be used to move motors with
Machinekit. And I'm positive it's good enough for initial testing if
Xenomai doesn't "play nice" with 4.1 yet.
Actually... CONFIG_PREEMPT_RT_FULL=y 
Excellent!
Along with overlays and cape-universal by default..
The only thing you might not like, for the PRU:
CONFIG_PRUSS_REMOTEPROC
vs what we used on v3.8.x:
CONFIG_UIO_PRUSS
But it's going mainline... and we just need a first user to figure out
what we need to port.
Yeah, I've needed to migrate to the remoteproc interface for a while,
but have had too much other stuff to deal with since 3.8 still works
great (well, except for some USB stuff, and GPU drivers, and ...).
I'll add remoteproc to the ToDo list for Machinekit on the X15, and it
should back-port to the BBB pretty easily.
Are the DSPs and M4 cores also available via remoteproc, or do they
use some other interface? We're working on getting the real-time HAL
layer to fully support multi-thread and multi-core, and I'd love to
see some of the fast number-crunching pushed onto those C66x cores,
and maybe some bit-twiddling by the M4s.
Correct, they are all under remoteproc, so they have that framework in common.
Regards,
I’ve been working on getting PRUSS_REMOTEPROC & RPMSG_PRU working on BBB, but all this should also work for the BeagleBoard-x15. I used /drivers/remoterpoc/* from git://git.ti.com/rpmsg/rpmsg.git and rpmsg-pru from
http://software-dl.ti.com/sitara_linux/esd/processor-sdk/PROCESSOR-SDK-LINUX-AM335X/latest/index_FDS.html
with the PRU addon package. My guess is you would probably use the git://git.ti.com/rpmsg/remoteproc for the x15.
Jason Reeder from TI says they are working on getting this working and will be releasing in with their next SDK release. Apparently they have some issues with the vring descriptor buffer address translation on the AM437x device.
Everything builds with Robert’s V4.1.6-bone15 kernel. I’m starting testing, but if you want me to send a patch, let me know.
Regards,
John
Just to clarify, when you say “default” you mean that those are the options you should use to update the x15 kernel. Running without any arguments “defaults” to an old stable 3.14.x kernel…
default=default kernel i'm shipping by default for x15...
Without any arguments, update_kernel.sh will default to the "stable"
tag, which is 3.14.x.. As "xenomai" doesn't have a v4.1.x-ipipe driver
yet, i can't move "4.1.x testing" -> "v4.1.x stable" just yet without
breaking other users...
So yeah, use the directions in the post i posted till i update it..
Regards,