4.4.x kernel

AndyCap

Ok, booted up, well done Gioliomoro.

root@beaglebone:~/4.4.35_kernel_deb_files# uname -a
Linux beaglebone 4.4.35-ti-xenomai-r69.1 #2 SMP Wed Nov 30 01:43:33 GMT 2016 armv7l GNU/Linux

root@beaglebone:~/4.4.35_kernel_deb_files# cat /proc/xenomai/latency 
6416

So what version of Xenomai should I putting on this?

giuliomoro

according to dmesg | grep -i cobalt, it is 3.0.3, so I just compiled the user-space libraries from 3.0.3

AndyCap

Nice, thanks for the info....

LiamDonovan

Good work!

I guess an important question now is what are the differences between this kernel and a 'standard' BeagleBone kernel. I know on our current kernel we have the cape manager installed, which allows you to use device tree overlays, but from a little googling it looks like it is only supported up to 4.1, so I wonder how much of a problem that is.

We also need to work out whether the prussdrv (pru uio driver, NOT rproc) stuff works on 4.4, this would seem to suggest so.

I'm so glad Robert Nelson did this so that we do not have to do it ourselves 😃

giuliomoro

if/as the capemanager is not there, does it not just mean that everything has to go in the dtb file?

giuliomoro

Anyhow, this thing is acting up on me, not showing up on boot or dropping the tethered connection multiple times.
It was also VEEERY unstable when I installed the wifi driver ...

Edit:

fixed the wireless instability

in order to get the board to show up I often have to do the trick:

sudo kextunload /Library/Extensions/HoRNDIS.kext/
sudo kextload /Library/Extensions/HoRNDIS.kext/
ifconfig up <interfaceName> 192.168.7.1

giuliomoro

Here's the xenomai libs I compiled, configured with

./configure CFLAGS="-march=armv7-a" LDFLAGS="-march=armv7-a" --with-core=cobalt --enable-smp

untar it, so that what is in dev/ goes to /dev/ and what is in usr/ goes in /usr/

once done, run

ldconfig /usr/xenomai/lib

AndyCap

giuliomoro

Hi Guilio,

That tar file seems to be damaged, tried downloading twice.

Cheers

Andy

giuliomoro

Pushed a branch which compiles (!) with xenomai 3 in backwards compatibility mode. It fails when loading the PRU driver.

Here it is: https://github.com/BelaPlatform/Bela/tree/dev-kernel-4.4.y-xenomai-3-support
you will need to

apt-get install libasound2-dev

beforehand, or exclude core/Midi.cpp and core/default_libpd_render.cpp from the build

@LiamDonovan you may have an idea about this

root@beaglebone:~# ./Bela/projects/minimal/minimal
Error: unable to initialise PRU
Error: unable to initialise audio
Failed to open PRU driver

This is due to prussdrv_open(PRU_EVTOUT_0) failing in core/PRU.cpp:270

https://github.com/beagleboard/am335x_pru_package/issues/16

LiamDonovan

Hmm, things I would check first:

Is the PRU uio kernel module installed
Is the PRU correctly registered in the device tree

giuliomoro

the module is there

root@beaglebone:~/Bela# lsmod | grep pruss
uio_pruss               5613  0
uio                    10581  2 uio_pruss,uio_pdrv_genirq

, how do I check the device tree?

I also tried to recompile libprussdrv, but with no success.

giuliomoro

Ok, updated the dtb file (which now lives in /boot/dtbs/4.4.35-ti-xenomai-r69.1/am335x-boneblack.dtb ) so to change PRU from "disabled" to "okay" (see e.g. here).
Still no luck. Is there a way I can test if it is enabled at run time

I also tried to run some of the examples that come with am335x_pru_package and none of them works, just to confim it is not only a Bela problem.

LiamDonovan

giuliomoro does the dtb contain this?


/* pruss: pick one: */
/*
 * /etc/modprobe.d/pruss-blacklist.conf
 *
 * blacklist uio_pruss
 */
/* #include "am33xx-pruss-rproc.dtsi" */
/*
 * /etc/modprobe.d/pruss-blacklist.conf
 *
 * blacklist pruss
 * blacklist pruss_intc
 * blacklist pru-rproc
 */
/* #include "am33xx-pruss-uio.dtsi" */

If so I think you have to uncomment the uio bit.

giuliomoro

I reuploaded, anyhow make sure you untar it on the beaglebone, it contains some files in dev/ that MacOS does not really like.

tar -xvf xenomai-3.0.3-for-4.4.35-ti-xenomai-r69.1.tar

giuliomoro

I am going to put this on hold for a couple of days.

One more useful insight is that the capemanager now goes through a thing called config-pin. You can, e.g.: load the BB-BONE-PRU-BELA-00A0.dtbo file in the /lib/firmware/ folder with config-pin overlay BB-BONE-PRU-BELA.
Check dmesg for errors after failed loads. Note that you will have to recompile the .dtb files from the corresponding .dts. For instance:
dtc BB-BONE-PRU-BELA-00A0.dts > BB-BONE-PRU-BELA-00A0.dtbo

We tried loading this, or the existing uio_pruss_enable-00A0.dtbo dtbo file, but none of them helped. The post Liam linked to earlier may contain some useful insights, although he suggests it may simply be a matter of applying this change to the kernel source tree.

Also, after loading the dtbo, you have to modprobe pruss manually .

This post may very well be the solution.
This one uses rproc instead "Using pru_rproc on the BeagleBone with Linux 4.4
Raw" ?

Here is a snapshot of my image to put it online for anyone willing to keep playing.

AndyCap

I will give you image a go because what I have ended up with here is extremely flaky!

giuliomoro

funny thing is that pre-compiled xenomai kernels are also available through apt-get:

apt-cache search linux | grep xenomai

you get the latest 4.4.x xenomai!

AndyCap

I gave the img file a go, I'm still getting the same problem that I got with the version I put together, for instance if I run the xenomai latency application the BBB dies.

Also getting quite a few broken pipes using usb and network port and general slow network access.

I'm going to put the standard 4.4 pre-built image on and try the apt-get approach to see if that is stable.

AndyCap

Ok I I tried the 4.4 and apt-get approach.

Good news is that it is stable.

Bad news is that it doesn't work:

root@beaglebone:/usr/lib/xenomai/testsuite# uname -a
Linux beaglebone 4.4.35-ti-xenomai-r70 #1 SMP Wed Nov 30 03:58:58 UTC 2016 armv7l GNU/Linux

root@beaglebone:/usr/lib/xenomai/testsuite# ./latency
Xenomai: native skin or CONFIG_XENO_OPT_PERVASIVE disabled.
(modprobe xeno_native?)

giuliomoro

That's strange, these should be RCN images, so I would expect them to use the default .config file, which is the one I used to compile this kernel

have you tried modprobe xeno_native ?