howto install and use the sdk - victronenergy/venus GitHub Wiki

This page explains setting up a cross compiling environment for Venus. Cross compiling means that the software is built/compiled on a different system (your computer aka host) than the one on which it is executed (for example your CCGX).

Notes:

• rebuilding the whole rootfs and image from scratch is something entirely different, explained here.
• this page assumes your host pc/vm runs linux
• it is often faster to do most development and debugging of software on your pc first. So no cross-compiling required at first. See below.
• when looking for ordinary packages, such as git, gdb, or something else, as opposed to your own development, you do not need this SDK. Therefore, make sure to first have a look at all pre-compiled and available packages. To do that, login to the Venus device, then run /opt/victronenergy/swupdate-scripts/set-feed.sh and choose a feed that holds a similar style env as the one thats running on your device, then run opkg update, and then opkg list. For further details see the commandline development page on the wiki, and search for opkg.
• another alternative: compile on the target itself. Use opkg to install git, make and gcc, then checkout whatever source you want to compile. Easier than cross compiling, but can be a bit slower :)
• know that on some devices (for now Venus GX, more future devices also) you can easily increase available diskspace on the rootfs. More info in machines.

To cross compile, you need to setup an SDK, which contains the gcc compiler, as well as all header files and other setup of Venus OS.

The SDK you'll be installing is built with Open Embedded (OE). Their generic manual for it is here: https://www.yoctoproject.org/docs/3.1/sdk-manual/sdk-manual.html#sdk-installing-the-sdk. Note that that link points to the manual belonging to OE release 3.1 aka Dunfell. Which we'll switch to per Venus OS v2.80. More information about Open Embedded versions aka releases here: https://wiki.yoctoproject.org/wiki/Releases.

The SDK includes the gcc compiler for the ARM processor, as well as all the needed libraries and header files.

First, download the latest sdk here.

• Cortex A8 for the Venus GX and CCGX
• Cortex A7 for the Cerbo GX, Raspberrypi2 and Raspberrypi3. Note that you can also use the A8 SDK, instead of the A7. And after releasing v2.80, we'll stop building the A7.
• And on the machines page you can see which SDK for the other devices

The file needed is the large one, ending with .sh.

Note about SDK version vs Venus OS version - (relevant for Venus OS v2.80)

Usually, there is no need to worry about them not being from the same version.

That matters only in case we are making a major change in Venus OS, mostly when updating to a newer release of Open Embedded.

In such case, when developing for a device running a candidate image, then download and use the sdk from the candidate feed instead of the release feed linked above.

Then install it. It will ask where you want to have it installed, make sure to install the ccgx sdk in its default location! And, in these examples, make sure to replace v2.62 to the version you downloaded:

chmod u+x ./venus-rocko-x86_64-arm-cortexa7hf-neon-vfpv4-toolchain-qte-v2.62.sh
sudo ./venus-rocko-x86_64-arm-cortexa7hf-neon-vfpv4-toolchain-qte-v2.62.sh

Make a symlink /opt/venus/current

sudo ln -s /opt/venus/rocko-arm-cortexa7hf-neon-vfpv4en /opt/venus/current

Now to use this SDK, the following command is to be executed in the terminal where you also call make or start qtcreator. This has to be done every time, but you are free to automate it of course:

. /opt/venus/current/environment-setup-cortexa7hf-neon-vfpv4-ve-linux-gnueabi

Note: yes, you might be thinking about skipping this step, but its real easy to make a mistake somewhere with all this, and you wouldn't be the first spending days to make building and running one of the C/Cpp/Qt/Velib related Venus OS projects. Therefor our advice is to do take this little effort, to make sure you have the right SDK, understand sourcing and so forth.

Create a file helloworld.c with the following content:

#include <stdio.h>
    
int main()
{
    puts("hello world");
    return 0;
}

The following is needed to compile above for a ccgx

# first setup, aka source, the environment:
. /opt/venus/current/environment-setup-cortexa7hf-neon-vfpv4-ve-linux-gnueabi

$CC helloworld.c -o helloworld

Make sure you are using bash or dash as shell, as there are known issues when using zsh.
The resulting binary is now called helloworld.
This is an ARM executable, this can be checked with

file helloworld

This should report something like:

helloworld: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped

Copy the file over to your GX device, and run it there.

QT projects, which are projects using one or more QT libraries, rely on the qmake engine. Compiling such a project from the commandline works like this:

# first source the environment:
. /opt/venus/current/environment-setup-cortexa7hf-neon-vfpv4-ve-linux-gnueabi

# change directory to the location of the qmake file (.pro extension)
cd <path to project file>

# Run qmake to create a makefile. Use the qmake supplied with the SDK!
/opt/venus/current/sysroots/x86_64-ve-linux/usr/bin/qmake <project file>.pro

# Build the project
make

Such as for example dbus-gps, which as some examples in its readme.

Step by step procedure:

# 1. first source the environment:
. /opt/venus/current/environment-setup-cortexa7hf-neon-vfpv4-ve-linux-gnueabi
    
# 2. unset CROSS_COMPILE
# Needing to do this is related to http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=678e8798ebe0f4fd1bd347db136f1499b8fe00c9
# Reason: if CROSS_COMPILE exists, older versions of velib make rules will redefine CC. For more info
# on that, see README_make.txt in velib.
# And, to help the search engines: if you don't do this, --sysroot won't be set,
# which leads to a stdint.h missing error in the compiler.
#
# All projects that have a recent velib version no longer need unsetting CROSS_COMPILE, since
# there is a fix in velib since 2017:
# https://github.com/victronenergy/velib/commit/21f0d3a1094874883fedfa91523ae077495ba07b
#
# So, only on projects using an old velib, do:
export CROSS_COMPILE=

# 3. Prepare the project.
./configure

# 4. Build the project.
make

# 5. Finished.

If there was an error, then as a minimum first do the hello world example above.

Note that some projects don't include a ./configure script. In which case, if its a velib project, you'll probably need to run ./ext/velib/mk/init_build.sh

sudo apt-get install qtcreator (or take latest from qt website)

To start QTCreator, start a new terminal, and source the environment

. /opt/venus/current/environment-setup-cortexa7hf-neon-vfpv4-ve-linux-gnueabi

And then start qtcreator: make sure to start it from the same terminal where you typed . /opt/venus/... !!

qtcreator

• Goto Tools->Options->Kits->Compilers
• press Add Select GCC->C as the type
• point it to:
  /opt/venus/current/sysroots/x86_64-ve-linux/usr/bin/arm-ve-linux-gnueabi/arm-ve-linux-gnueabi-gcc

Result will look like this:

Then do the same for the C++ compiler:
Select GCC->C++ as the type. And point it to .../arm-ve-linux-gnueabi-g++

Same screen, but one tab to the right: Debuggers.
Click add and point it to:

/opt/venus/current/sysroots/x86_64-ve-linux/usr/bin/arm-ve-linux-gnueabi/arm-ve-linux-gnueabi-gdb

Same screen, but then one tab to the left, Qt Versions.
Point it to

/opt/venus/current/sysroots/x86_64-ve-linux/usr/bin/qmake

• Arrange root access

It's no longer necessary to install gdbserver on the CCGX. It is already installed by default.

Add device, see screenshot.

Select Authentication type: Default to use the root password you've configured in the previous step or to use the system default (ssh-agent).

To prevent filling in the root password every time you start Qt Creator, you can use the following steps:

1. Make sure the Default authentication type is selected
2. Click Create New... to create a new SSH key. The default settings are ok, just click Generate an Save Key Pair
   
3. Click Deploy Public Key... to selected and copy the generated public (.pub) key to the device. Use the root password when prompted for a password.
4. Now select Specific key as authentication method

Next add a new kit:

• select the Compiler, Debugger and Qt Version which you have created in the previous steps.
• select a sysroot: /opt/venus/current/sysroots/cortexa8hf-neon-ve-linux-gnueabi

End result will look like this:

Note that you might have a different CMake location, which is fine. CMake is not used anyway, so you can also leave it empty, although this might show a warning (which you can ignore).

Now you are ready to start compiling. Open a QT project file (.pro extension) and chose the CCGX kit, and chose Build->Build Project. If you get an error message c: Command not found, you probably forgot to run the environment script before starting QT Creator.

After a successful build deploy the executable to the CCGX: Build->Deploy project. Note that it is not possible to overwrite an executable that is currently running. So, for this gui example, make sure to first stop the gui on the ccgx:

svc -d /service/gui

Cross-compile run:
Executable on device: /opt/victronenergy/gui

When working on a velib project, make sure to change these settings in the Kit:

• Remove qmake from build steps in the kit
• Disable shadow build
• Add ARCH=arm HOST_ABI=gnueabi to the Make arguments of the build steps
• Probably you need to unset the CROSS_COMPILE variable, see basic section above.
• For the debug build, also add BUILD=debug
• Add the same to the clean steps

And if you are going to build release builds with qtcreator, do more or less the same for that build config.

End result will look like this:

First of all, note that we work with QtCreator, so start with asking yourself the question "why am I not using QtCreator, instead of doing something else instead risking endless loss of time on setting up cross-compiling and remote debugging".

For Eclipse, there is a OE Yocto plug-in that works with the SDK.

First double check what OE version is used in the current builds of Venus. See here for what that means.

Then, find the right url. For OE/Yocto version Rocko, aka 2.4, it is this:

http://downloads.yoctoproject.org/releases/eclipse-plugin/2.4/

The subdirectories that you see there (Neon, Mars, Oxygen) pertain to different versions of Eclipse. So, now find out which one you need.

Thereafter follow instructions here: https://www.yoctoproject.org/docs/2.4/sdk-manual/sdk-manual.html#adt-eclipse.

Chapter 5.2.3.2.1.

Success! We never tried this at home.

To save yourself some time copying files back and forth between your PC and your CCGX, for example while editing Python code, use sshfs to mount the CCGX drive to your local machine:

mkdir ~/rem
sshfs root@ccgx:/opt/color-control ~/rem

Use fusermount -u PATH to unmount it again. or just reboot your machine.

Developing, running, debugging a module on your (Linux) PC is often much faster than first having it uploaded to the CCGX everytime you want to run it. And the good news is that it is perfectly possible.

Most of our modules will run perfectly on a pc: localsettings, dbus_gps, dbus_modbustcp, dbus_fronius, etcetera. Even the gui runs on a pc, but that is a bit more difficult since it needs some changes which we made to the qt libraries.

Most -perhaps even all- of our D-Bus implementations (C, Cpp, Python, etc) automatically choose the Session D-Bus instead of the System D-Bus which is used on the ccgx. This is done at either compile- or run-time. To see what is going on on the D-Bus, use the DBusCli command-line tool. Make sure to omit the -y commandline parameter. Tips and tricks for command line D-Bus access. For some modules you'll need to run localsettings on your pc. Github repo including explanation of what it is is here. Look for localsettings on this page for instructions on setting it up. Note that it shouldn't be necessary to change the dbus config files! Since it will be using the (open) session dbus, and not the system dbus which is usually locked down.