Install Xenomai on Dragonboard 410c

[NewZephyr]

Hi, I am trying to install Xenomai on DB410c,
followed this 2 tutorials:
https://builds.96boards.org/releases/dragonboard410c/linaro/ubuntu/15.07/

Servo Motor Control: generating a stable PWM signal with Xenomai

at http://www.96boards.org/blog/servo-motor-control/ we did:

1. Downloaded Xenomai and Ipipe
2. git checkout do I need something for DB410c ? (the tutorial is written on Hikey)
3. run prepare-kernel.sh
   then we moved to the other tutorial and started from here:
   
   
   
   (because we want Xenomai instead of ubuntu.)
   then we got an image file
   but trying to fastboot the device with it
   the pc is detecting the device, we wrote successfully
   sudo fastboot flash boot boot-db410c.img

and then the image file was not loaded when the device is started.

Please let me know what we did wrong and how do I figure out it.
Thanks.

(btw, I saw this topic too before the steps I did
Installing xemomai on 410c - #2 by ldts
)

[ldts]

I would like to help but I am a little bit confused with the sequence of steps that you are taking.

Maybe you could collect them all in a script-like form and share them?

The basic idea is to boot your db410c with a not too recent ubuntu/Debian release and then replace the kernel and install the Xenomai libraries.

Do you know how to replace a kernel in a ubuntu/Debian release for a vanilla kernel? That should be your first step, ie, making sure you know how to do this standard operation.

Now back to installing Xenomai: when replacing the kernel you can either use the same kernel sources that you are booting patched with I-pipe OR use an I-pipe enabled tree (which is what I do in the document for simplicity). An I-pipe enable tree is basically a vanilla kernel patched with I-pipe (so not a Landing Team or a silicon vendor tree features there)

Once you have the I-pipe enabled kernel you should boot it to make sure I-pipe is not introducing a regression. If it is all good - the system boots- then you have to patch the kernel again this time with Xenomai (ie prepare-kernel.sh script_

==> So to be very clear: the I-pipe enabled tree MUST be patched with the Xenomai domain (hence the prepare-kernel.sh).

After that you would just boot it and install the Xenomai libaries as per the documentation.

So if you could help me understand where are you getting stuck I should be able to help.

[davidIoT]

Hi Idts.
First of all thanks for the detailed response. I’m a friend of NewZephyr and we are working together on some project that involves the Xenomai and Dragonboard 410c.
Actually we’ve managed right now to replace the previous kernel that was delviered with debian installation (4.4.23) with the i-pipe patched one after following your steps and the stpes mentioned here for customizing a kernel: https://builds.96boards.org/releases/dragonboard410c/linaro/debian/latest/

What we did was:

1. Download ipipe-jro-410c.linaro-15.07 (latest version was ipipe-jro-e712dead060629b2c7307216c2e6887d0fd16f5a )
2. Download xenomai-jro-410c.linaro-15.07
3. Patch Xenomai into the download kernel (the one with ipipe we donloaded in section 1):
   cd xenomai-jro-410c.linaro-15.07/scripts
   /prepare-kernel.sh –arch=arm64 –linux=$kernel
4. Customizing the kernel as I mentioned above exactly step by step as was writen there.

The result we’ve got is a 4.0.0 i-pipe kernel on the board. Now we try to understand a few things:

1. How we move on from here? As in the official installation manual on Xenomai page part of the progress was patching the cobalt kernel and a few more things. As arm64 was not supported there from our understanding what we did is some kind of bypassing the standard Xenomai installation by following your manual. How we proceed from here? How can we check if xenomai is actually installed and check some of its features?
2. Is there a way to use a newer kernel? From what we saw, last ipipe patch for arm64 is 4.1.18. Does it mean that there is no way to use it over a newer version kernel?

Thanks.

[NewZephyr]

can you please help us ?

[ldts]

If you are booting the kernel - which I dont know since you didnt send traces- and installed the libraries - I didn’t see that part in the summary that you posted either- then you have a Xenomai enabled (Cobalt) system.

You should then run the latency tests, check current benchmarks and if necessary do some troubleshooting.
The documentation in Xenomai.org is quite detailed so please have a look there as well as on the xenomai mailing list.

Xenomai now can run a 4.4 kernel and there is work in the process of a new and simpler co-kernel architecture which will be able to follow upstream. But in the meantime, ff you need a newer kernels l I am afraid you will have to do the work

[davidIoT]

I don’t sure what do you mean by saying “booting the kernel”, but I’ll try to clarify where do we stand right now.
We’ve patched the downloaded kernel that already includes ipipe (step 1 above) with Xenomai, and managed to customize the kernel on the dragonboard, so when I run “uname -r” from the board I get something like “kernel 4.0.0 i-pipe” (don’t sure if that’s the exact message but pretty close to it), so I guess we are booting the right kernel.
Maybe I miss something, but what libraries exactly are you talking about?
Relying on Xenomai.org is a little bit hard as the whole process of installation on dragonboard is different and not documented out there.

About the kernel version, I see that the last kernel that supports ipipe on arm64 architecture is 4.1.18 and not 4.4. Am I looking at the wrong place?

[davidIoT]

Looked again here http://www.96boards.org/blog/servo-motor-control/
I saw the “Installing the Xenomai libraries and demos” . It looks compatible with the HiKey but not with DB410c.
Does commands like “$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8” gonna work? As for example building kernel for the DB is done with a flag -j4 and not -j8, so I guess running those command straight forward is not gonna suit the DB. Can you tell me what changes should I do?
And as I see it we should rebuild the kernel again in order to add those libraries, right?

[NewZephyr]

we didn’t success to install libraries
We know how to boot the patched kernel
(Dragonboard’s kernel includes xenomai, but we don’t success to install its libraries)
Let us know what we did wrong

[ldts]

As I said, I’d like to help but I dont know what you are doing (you are not providing traces). After compiling Xenomai and installing them to some directory on the build server (or are you compiling it natively?) all you have to do is tar them and untar them in the target rootfs (easier if your rootfs is nfs mounted). then you can just run /user/xenomai/bin/latency

[davidIoT]

At the step where you execute:
cp arch/arm64/boot/dts/hi6220-hikey.dtb $share/

What should I do on the dragonboard? I don’t have any dtb files created in this path.
Though in arch/arm64/boot/dts/qcom I see msm8916-mtp.dtb and apq8016-sbc.dtb . Should I use one of them instead?

Thanks.

[davidIoT]

OK I tried to add those 2 dtb files.
Now I’m stuck trying to execute this:

~/xenomai3.git/configure --with-core=cobalt --enable-smp --disable-tls --enable-fortify --enable-maintainer-mode --disable-registry --disable-pshared --disable-lorew-clock --enable-assert --disable-doc-install --build=x86_64 --host=aarch64-linux-gnu CFLAGS=”-march=armv8-a” --prefix=/usr/xenomai

I get this:
configure: WARNING: unrecognized options: --disable-lorew-clock
checking whether we build for Cobalt or Mercury core… cobalt
checking build system type… x86_64-pc-none
checking host system type… aarch64-unknown-linux-gnu
checking for a BSD-compatible install… /usr/bin/install -c
checking for aarch64-linux-gnu-gcc… no
checking for gcc… gcc
configure: WARNING: using cross tools not prefixed with host triplet
checking whether the C compiler works… no
configure: error: in /home/david/build': configure: error: C compiler cannot create executables See config.log’ for more details

I saw in forums that this may help:
export CC=~/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc

but then I get this:
configure: WARNING: unrecognized options: --disable-lorew-clock
checking whether we build for Cobalt or Mercury core… cobalt
checking build system type… x86_64-pc-none
checking host system type… aarch64-unknown-linux-gnu
checking for a BSD-compatible install… /usr/bin/install -c
checking for aarch64-linux-gnu-gcc… /home/david/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
checking whether the C compiler works… no
configure: error: in /home/david/build': configure: error: C compiler cannot create executables See config.log’ for more details

For some reason it doesn’t reconize the compiler, although I made sure it’s there (and of course used it for other steps whick worked well).
Please help, I think we are just about to succeed

[ldts]

I assume you know you are cross-compiling: in some other thread you had decided to compile natively so just making sure.

I think you just need to add your aarch64 compiler to your path:

PATH=$PATH:~/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/

I also assume that you noticed that the compiler you are using is nearly three years old; not related to the problem you are having at the moment but maybe it would be a good idea to upgrade it to a more recent one.

check here:
https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-linux-gnu/

[davidIoT]

Yeah I used this cross compiler through all of the process.
I’ve downloaded a 2017 version of it as well at first but there was a step (don’t remember which one exactly) that required a lower version so somehow I ended up with this one (I think there was a recommendation for this one specifically).
I’ll try what you suggested and will let you know.

Thanks a lot for your help.

[davidIoT]

Unfortunately that didn’t work.
By looking at the config.log we have ecountered a few problems:

After running:
~/xenomai3.git/configure --with-core=cobalt --enable-smp --disable-tls --enable-fortify --enable-maintainer-mode --disable-registry --disable-pshared --disable-lorew-clock --enable-assert --disable-doc-install --build=x86_64 --host=aarch64-linux-gnu CFLAGS=”-march=armv8-a” --prefix=/usr/xenomai

the problem was this (part of the config.log):
configure:2980: aarch64-linux-gnu-gcc -V >&5
aarch64-linux-gnu-gcc: error: unrecognized command line option '-V’
aarch64-linux-gnu-gcc: fatal error: no input files

Tried to change -V to lower case v in the configure file and got this:
configure:2980: aarch64-linux-gnu-gcc -qversion >&5
aarch64-linux-gnu-gcc: error: unrecognized command line option '-qversion’
aarch64-linux-gnu-gcc: fatal error: no input files

Tried to delete the flag -qversion and got this:
configure:3011: checking whether the C compiler works
configure:3033: aarch64-linux-gnu-gcc ”-march=armv8-a” conftest.c >&5
aarch64-linux-gnu-gcc: error: ”-march=armv8-a”: No such file or directory

Do you have some ideas how can I get through this?

[ldts]

Please install this compiler:

aarch64-linux-gnu-gcc (Linaro GCC 5.1-2015.08) 5.1.1 20150608
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

And execute this script:

#!/bin/bash
set -e

install=your_install_directory
build=your_build_directory
xenomai=your_xenomai_sources_directory

read -p "Boostrap [y/N]: " strap
if [ “${strap}” = “y” ]; then
cd $xenomai
./scripts/bootstrap
fi

read -p "reconfigure [N/y]: " reconfig
if [ “${reconfig}” = y ]; then
cd $build
if [ “$PWD” = “${build}” ]; then
rm -rf *
else
echo “build directory does not exist”
exit
fi

$xenomai/configure --with-core=cobalt --enable-smp --enable-pshared --enable-assert --prefix=/usr/xenomai --host=aarch64-linux-gnu

fi

cd $build
make -j4

sudo PATH=$PATH:/path/to/your/compiler/bin make -j8 install DESTDIR=$install
cd $install
tar jcvf xenomai.tar.bz2 *
sync

Any problems, please just sent me config.log (no need to explain anything else).

[NewZephyr]

I tried to run the command:
…/xenomai3.git/configure --with-core=cobalt --enable-smp --enable-pshared --enable-assert --prefix=/usr/xenomai
(as you guided me)
on dragonboard
Got the following error:
Still unsupported target: aarch64-unknown-linux-gnu – Sorry.

the whole log:
checking whether we build for Cobalt or Mercury core… cobalt
checking build system type… aarch64-unknown-linux-gnu
checking host system type… aarch64-unknown-linux-gnu
checking for a BSD-compatible install… /usr/bin/install -c
checking for gcc… gcc
checking whether the C compiler works… yes
checking for C compiler default output file name… a.out
checking for suffix of executables…
checking whether we are cross compiling… no
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… none needed
checking whether gcc understands -c and -o together… yes
checking how to run the C preprocessor… gcc -E
checking target system type… aarch64-unknown-linux-gnu
checking for gcc… gcc
checking whether we are using the GNU C compiler… (cached) yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… (cached) none needed
checking whether gcc understands -c and -o together… (cached) yes
checking how to run the C preprocessor… gcc -E
checking for grep that handles long lines and -e… /bin/grep
checking for BSD- or MS-compatible name lister (nm)… /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface… BSD nm
checking for gawk… no
checking for mawk… mawk
checking for a sed that does not truncate output… /bin/sed
checking for egrep… /bin/grep -E
checking for fgrep… /bin/grep -F
checking how to print strings… printf
checking for ld used by gcc… /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld… yes
checking command to parse /usr/bin/nm -B output from gcc object… ok
checking for _ prefix in compiled symbols… no
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking whether make sets $(MAKE)… yes
checking for style of include used by make… GNU
checking whether make supports nested variables… yes
checking whether UID ‘1000’ is supported by ustar format… yes
checking whether GID ‘1000’ is supported by ustar format… yes
checking how to create a ustar tar archive… gnutar
checking dependency style of gcc… gcc3
checking whether make supports nested variables… (cached) yes
checking whether to enable maintainer-specific portions of Makefiles… no
checking dependency style of gcc… gcc3
checking for flex… no
checking for lex… no
checking for target architecture…

---

Still unsupported target: aarch64-unknown-linux-gnu – Sorry.

---

and we tried to add
–host=aarch64-linux-gnu
to the command.

command:
…/xenomai3.git/configure --with-core=cobalt --enable-smp --enable-pshared --enable-assert --prefix=/usr/xenomai --host=aarch64-linux-gnu
and we got the following log:

checking whether we build for Cobalt or Mercury core… cobalt
checking build system type… aarch64-unknown-linux-gnu
checking host system type… aarch64-unknown-linux-gnu
checking for a BSD-compatible install… /usr/bin/install -c
checking for aarch64-linux-gnu-gcc… aarch64-linux-gnu-gcc
checking whether the C compiler works… yes
checking for C compiler default output file name… a.out
checking for suffix of executables…
checking whether we are cross compiling… no
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether aarch64-linux-gnu-gcc accepts -g… yes
checking for aarch64-linux-gnu-gcc option to accept ISO C89… none needed
checking whether aarch64-linux-gnu-gcc understands -c and -o together… yes
checking how to run the C preprocessor… aarch64-linux-gnu-gcc -E
checking target system type… aarch64-unknown-linux-gnu
checking for aarch64-linux-gnu-gcc… aarch64-linux-gnu-gcc
checking whether we are using the GNU C compiler… (cached) yes
checking whether aarch64-linux-gnu-gcc accepts -g… yes
checking for aarch64-linux-gnu-gcc option to accept ISO C89… (cached) none needed
checking whether aarch64-linux-gnu-gcc understands -c and -o together… (cached) yes
checking how to run the C preprocessor… aarch64-linux-gnu-gcc -E
checking for grep that handles long lines and -e… /bin/grep
checking for BSD- or MS-compatible name lister (nm)… /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface… BSD nm
checking for gawk… no
checking for mawk… mawk
checking for a sed that does not truncate output… /bin/sed
checking for egrep… /bin/grep -E
checking for fgrep… /bin/grep -F
checking how to print strings… printf
checking for ld used by aarch64-linux-gnu-gcc… /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld… yes
checking command to parse /usr/bin/nm -B output from aarch64-linux-gnu-gcc object… ok
checking for _ prefix in compiled symbols… no
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking whether make sets $(MAKE)… yes
checking for style of include used by make… GNU
checking whether make supports nested variables… yes
checking whether UID ‘1000’ is supported by ustar format… yes
checking whether GID ‘1000’ is supported by ustar format… yes
checking how to create a ustar tar archive… gnutar
checking dependency style of aarch64-linux-gnu-gcc… gcc3
checking whether make supports nested variables… (cached) yes
checking whether to enable maintainer-specific portions of Makefiles… no
checking dependency style of aarch64-linux-gnu-gcc… gcc3
checking for flex… no
checking for lex… no
checking for target architecture…

---

Still unsupported target: aarch64-linux-gnu – Sorry.

---

can you please help us ?

[ldts]

send me the output of

$ echo $PATH
$ uname -a
$ aarch64-linux-gnu-gcc --version

[davidIoT]

linaro@linaro-alip:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
linaro@linaro-alip:~$ uname -a
Linux linaro-alip 4.0.0-ipipe #1 SMP PREEMPT Fri May 26 13:32:23 IDT 2017 aarch64 aarch64 aarch64 GNU/Linux
linaro@linaro-alip:~$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[ldts]

ok so you are building natively (this is getting confusing since DavidIOT is now cross compiling? are you guys working together?)

I am not really sure what you are doing with your system because things do work for me as per the instructions. Where did you get your Xenomai from?

You should try to follow the instructions:

1. download (you could use the tip of xenomai but let’s keep it simple) http://git.xenomai.org/xenomai-jro.git/ xenomai-jro-410c.linaro-15.07.tar.bz2 and execute natively

2. execute “scripts/bootstrap” (for with you had to install automake/libtool/libltdl-dev).

configure --with-core=cobalt --enable-smp --enable-pshared --enable-assert --prefix=/usr/xenomai

Then attach config.log or any error messages that pop up.

Also do not setup environment variables blindly. why is your target architecture aarch64-unknown-linux-gnu?? it should be arm64.

[NewZephyr]

Hi ldts,
we are working together, trying with the native compiling (on the dragonboard) method.
config.log file done with “exit 0” - it is above 3000 lines and the format is not supported for uploading here. Do you want us to send you it somehow?

we tried the next step according to xenomai manuals:
$ dmesg | grep -i xenomai
and we got the following:
[ 0.700352] [Xenomai] scheduling class idle registered.
[ 0.700362] [Xenomai] scheduling class rt registered.
[ 0.700585] I-pipe: head domain Xenomai registered.
[ 0.703817] [Xenomai] Cobalt v3.0 (Exact Zero)

We saw it should be written enabled at the end instead of Exact Zero. Maybe this affects somehow?

Also we tried to execute latency check and we get this error:
$ /usr/xenomai/bin/latency
0"000.000| BUG in low_init(): [main] Cobalt core not enabled in kernel

Of course before that we’ve executed:
$ sudo echo “/usr/xenomai/lib” > /etc/ld.so.conf.d/xenomai.conf
and added /usr/xenomai/bin to our $PATH.

Can you please help us?