4.4.x kernel

AndyCap

Thats the one I already tried, maybe that is where I went wrong!

giuliomoro

Well, I tried the "IoT" with my hand-compiled kernel, you have tried the "LXQT" with both mine and your hand-compiled kernel ... So the last permutation would be the IoT with your kernel

AndyCap

I'll give it a go in the morning, I doubt my kernel is much different to yours though as it was built from the same source, the deb sizes were slightly different so there may be a sliver of a hope. The last update on git was 2 days ago which I guess is before you first built it?

I will try building a filesystem tomorrow and see if that helps, although I am not optimistic.

giuliomoro

Yes I already had the latest (well almost actually: the only changeset that was missing is this.

giuliomoro

I am rebuilding on a new VM and noticed that menuconfig shows a warning about CPU frequency scaling being enabled.
I am not sure if that used to be there before. Not easy to miss it! Fixed it now.

Anyhow, now I am left with a warning about CONFIG_MIGRATION increasing latency, but it seems I cannot disable it.

AndyCap

Ok got the ito going with the kernel I built here, seems stable so far!

Currently building xenomai on the BB the libs as the link above is no longer there.

Fingers crossed...

AndyCap

Ok all built and installed.

Back to the old problem with board dying:

root@beaglebone:/usr/xenomai/bin# ./latency
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...

LiamDonovan

AndyCap (or @giuliomoro) could you take a look at the logs after a rebooting from a crash and see if there are any error messages? I believe there are a number of log files in /var/logs, inlcuding the previous dmesg and the main syslog.

It may be that nothing gets written, but if there's an error we may at least get a hint of where to start looking, and we can file a bug report with RCN.

AndyCap

I did check before by tailing the logs {messages,kernel,dimes,syslog} as I ran the latency test and didn't see anything much, I will have a closer look at the logs...

AndyCap

Ok did another test and looked at the logs, nothing to see unfortunately.

It did mange to run a few iterations of latency before going bang:

root@beaglebone:/usr/xenomai/bin# date;./latency
Fri Dec  2 10:48:36 UTC 2016
== 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|     34.374|    317.362|    801.291|       0|     0|     34.374|    801.291
RTD|     29.291|    295.369|    481.624|       0|     0|     29.291|    801.291

Not very good figures!

LiamDonovan

AndyCap urgh, I get an average of 2.4 on the stable image, that's 100x worse. Though I've never actually been sure what those numbers represent exactly...

When you compiled your kernel, was CPU frequency scaling enabled? (it can be found in the menuconfig) Xenomai requires it to be disabled.

AndyCap

LiamDonovan

I used the default config from git, didn't check the cpu scaling. Although from Giulio's post it may well have been the issue with my build.

I guessed the numbers were us jitter timings for a 1000us timer driven task, need to look at the code I guess to see what they really are!

giuliomoro

new build without CPU frequency scaling, get this

root@beaglebone:~/# /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|      8.124|      9.767|     20.208|       0|     0|      8.124|     20.208
RTD|      8.166|     10.295|     57.499|       0|     0|      8.124|     57.499
RTD|      8.207|     10.240|     36.249|       0|     0|      8.124|     57.499
RTD|      8.124|      9.756|     40.874|       0|     0|      8.124|     57.499
RTD|      8.207|     10.482|     38.582|       0|     0|      8.124|     57.499
RTD|      8.040|      9.534|     35.998|       0|     0|      8.040|     57.499
RTD|      8.164|      9.715|     32.206|       0|     0|      8.040|     57.499
RTD|      8.081|      8.909|     39.498|       0|     0|      8.040|     57.499
RTD|      8.247|      9.657|     41.331|       0|     0|      8.040|     57.499

LiamDonovan

giuliomoro that's a bit better!

Any crashing or connectivity problems?

giuliomoro

not insofar, I will try to disable CONFIG_MIGRATION next.

AndyCap

Nice job!

giuliomoro

To get the PRU running:

edit the uncompiled dts file (either in the KERNEL source KERNEL/arch/arm/boot/dts/am335x-boneblack.dts or using dtb-rebuilder*)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts
index 73f3cfc..cbdef11 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -26,17 +26,17 @@
 /*
  * /etc/modprobe.d/pruss-blacklist.conf
  *
  * blacklist pruss
  * blacklist pruss_intc
  * blacklist pru-rproc
  */
 
-/* #include "am33xx-pruss-uio.dtsi" */
+#include "am33xx-pruss-uio.dtsi"

and add

blacklist pruss
blacklist pruss_intc
blacklist pru-rproc

to /etc/modprobe.d/pruss-blacklist.conf

This will enable the PRU and you will be able to run some Bela (though you will get no I/O until you set the appropriate pinmux pins!) !!!

* using dtb rebuilder:

* `git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder dtb-4.4-ti --depth=1 && cd dtb-4.4-ti`
* edit the file in src/arm/am335x-boneblack.dts
* `make install`

giuliomoro

Once you install the user-space library support you can have some fun.
First thing: "Calibrating the Cobalt core timer" (see relevant section here). Note that autotune will not be in /usr/xenomai/bin, but in $XENOMAI_BUILD_FOLDER/utils/autotune/autotune.

root@beaglebone ~$ ./build/xenomai/utils/autotune/autotune
== auto-tuning started, period=1000000 ns (may take a while)
irq gravity... 999 ns
kernel gravity... 5999 ns
user gravity... 5499 ns
== auto-tuning completed after 27s

Now take those values and send them to coreclk (Xenomai docs have a typo at this step):

root@beaglebone ~$ echo "999i 5999k 5499u" > /proc/xenomai/clock/coreclk

These values should be set via a startup script.

Now you can run latency:

root@beaglebone ~$ /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|      7.958|     11.133|     18.208|       0|     0|      7.958|     18.208
RTD|      8.000|     11.434|     41.541|       0|     0|      7.958|     41.541
...
^C---|-----------|-----------|-----------|--------|------|-------------------------
RTS|      7.872|     11.098|     54.957|       0|     0|    00:00:18/00:00:18

Still not as good as they should be. Maybe some playing around with the CONFIGs or the user-space library options would help?

Another thing is

root@beaglebone ~/xenomai_staging$ /usr/xenomai/bin/xeno-test -k
Started child 4989: /bin/bash /usr/xenomai/bin/xeno-test-run-wrapper /usr/xenomai/bin/xeno-test -k
...
FAILURE rt_thread_body:116: no SIGDEBUG_MIGRATE_PRIOINV received

which unfortunately fails (I am enquiring the Xenomai mailing list about this).

New kernel is up here, the config file is here.

AndyCap

Nice job Giulio.

I will give your kernel a go....

AndyCap

Ok got it going with int and your kernel then build xenomai on the BB.

One thing I have noticed is that the autotune can give pretty varying numbers:

root@beaglebone:~/xenomai/xenomai-3.0.3/utils/autotune# ./autotune
== auto-tuning started, period=1000000 ns (may take a while)
irq gravity... 1999 ns
kernel gravity... 6999 ns
user gravity... 5999 ns
== auto-tuning completed after 30s

root@beaglebone:~/xenomai/xenomai-3.0.3/utils/autotune# ./autotune
== auto-tuning started, period=1000000 ns (may take a while)
irq gravity... 999 ns
kernel gravity... 4999 ns
user gravity... 7499 ns
== auto-tuning completed after 24s

root@beaglebone:~/xenomai/xenomai-3.0.3/utils/autotune# ./autotune
== auto-tuning started, period=1000000 ns (may take a while)
irq gravity... 2999 ns
kernel gravity... 8499 ns
user gravity... 9999 ns
== auto-tuning completed after 33s

root@beaglebone:~/xenomai/xenomai-3.0.3/utils/autotune# ./autotune
== auto-tuning started, period=1000000 ns (may take a while)
irq gravity... 1999 ns
kernel gravity... 7999 ns
user gravity... 5999 ns
== auto-tuning completed after 32s

Seems a little strange!

« Previous Page Next Page »