kstrize/embedded_ide

My Embedded Linux (Yocto) IDE setup

Embedded Linux (Yocto) IDE setup

Working on a Yocto project, I couldn't find any IDE type of solution that would make my job easier.
My main problem was lack of GUI editor code indexing for Linux, u-boot and arm-trusted-firmware source codes.
So in my spare time I tried to find some kind of solution for my inconvenience.
I wanted to build a fully open source IDE solution for working with Yocto projects.
Even though in this document I will be focused on VSCodium, this setup should be 100% compatible with Visual Studio Code.

Requirements when building this setup were:

1. Modern text editor with integrated debugging GUI that is open source
2. Have full indexing of a devtool workspace (Linux, u-boot, arm-trusted-firmware...)
3. Remote GDB application debugging on the embedded board
4. Development on the remote machine over SSH

The good thing was that I didn't have to build anything.
All the pieces were already available.
I just had to gather and configure them in one place.

GUI IDE base

The setup is based on VSCodium that is a fully MIT build of Visual Studio Code.
VSCodium project also disables telemetry and uses open-vsx.org as its extension market place.
open-vsx.org is an Eclipse foundation supported project and it only hosts open source Visual Studio Code extensions.

Extensions

To achieve all the desired functionality, these extensions need to be installed and configured:

1. clangd
2. Native Debug
3. Open Remote - SSH
4. (Optional) CMake
5. (Optional) CMake Tools
6. (Optional) Code Spell Checker
7. (Optional) GitLens
8. (Optional) Hex Editor
9. (Optional) Doxygen Documentation Generator

TL;DR

In this repository there is a .vscode directory that has settings.json, tasks.json and launch.json.
To reproduce this setup:

1. Install the necessary extensions
2. Install Bear 2.4.4 tool (next chapter is HOWTO)
3. Install gdb-multiarch
4. Copy .vscode directory from this repo to the root directory of your Yocto project.
5. Fill out the necessary variables in settings.json
6. Check commands in tasks.json
7. Check launch.json

To build the recipe just: Ctrl+Shift+B and in popup write recipe name
To execute any task just:
Ctrl+Shift+P
Tasks: Run Task
<select_task_name>

Bear tool

In this setup, clangd is used as a replacement for closed sourced C/C++ Extension.
That way the whole solution can remain fully open sourced.

To make clangd work (index code), compile_commands.json file needs to be generated.
If your project uses CMake, then this file can be generated by setting -DCMAKE_EXPORT_COMPILE_COMMANDS=1.
If you are only working on Linux kernel, you can use the gen_compile_commands.py (I haven't tried this, I just now it exists).

But to make it generic and to work with any project that can be build by devtool, I decide to use Bear.
With Bear you can pass any build command and it will generate compile_commands.json file that is needed by clangd.

Version warning!

You can probably install Bear with your distros package manager (example: sudo apt install bear), but most likely the package will be version 3.x.x.
Version 3.x.x doesn't work with bitbake. So to use Bear, I have build older version 2.4.4.
It's really simple and fast to build (no complicated dependencies).
To build and install Bear 2.4.4.:

git clone https://github.com/rizsotto/Bear.git
cd Bear/
git checkout 2.4.4
mkdir build
cd build
cmake ..
make all
sudo make install

devtool workspace indexing

After you have fetched all the necessary source codes needed by your Yocto image (using bitbake) and sourced the environment variables, you can open the desired folder in VSCodium.

In the terminal you can run:

devtool modify <recipe>
cd workspace/sources/<recipe>
bear devtool build <recipe>

For example:

devtool modify virtual/kernel
cd workspace/sources/linux-yocto
bear devtool build linux-yocto

or

devtool modify virtual/bootloader
cd workspace/sources/u-boot
bear devtool build u-boot

or

devtool modify arm-trusted-firmware
cd workspace/sources/arm-trusted-firmware
bear devtool build arm-trusted-firmware

This will enable clangd to index the entire source code of your build recipe.

VSCodium/VSCode task for devtool workspace indexing

In this repository I have created a task that builds and indexes any Yocto recipe using devtool.
All you need is to copy .vscode directory from this repo to your root Yocto project directory and fill out the variables in settings.json.
The exact build commands are defined in tasks.json so you can check them if they are valid for your Yocto project setup.
Using Ctrl+Shift+B the default build task will run and a popup box will appear that will ask you to write the recipe name that you want to build (using the devtool).
I tried to make it all generic, flexible and in one place (settings.json) so that it can work with many different project setups.

SDK cross compilation

In this repo there is a .vscode directory that has settings.json, tasks.json and launch.json.
In settings.json fill the appropriate variables and to build the application just run SDK cross compile task by:
Ctrl+Shift+P
Tasks: Run Task
SDK cross compile

Remote GDB application debugging on the embedded board

For remote GDB debugging you need to have:

• GDB server on your embedded board (include tools-debug image feature)
• application compiled in debug mode
• gdb-multiarch installed on you computer/laptop

Example of launch.json that is located in .vscode directory:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "gdb",
            "request": "attach",
            "name": "App remote GDB",
            "gdbpath": "/usr/bin/gdb-multiarch",
            "executable": "${workspaceFolder}/path/to/your/binary",
            "target": "<ip_address>:<port>",
            "cwd": "${workspaceRoot}",
            "remote": true
        }
    ]
}

In embedded Linux board run:

gdbserver <port> --attach <pid> or gdbserver host:<port> <program>

For example:

gdbserver :24 /usr/bin/HelloWorld

Then in VSCodium you can just run the application in debug mode with F5.
You can debug multiple applications at once.

Development on the remote machine over SSH

With Open Remote - SSH you can have the entire project on a server (build machine) and use the VSCodium installed on your computer/laptop as if the whole project was located on your computer/laptop.
This way you can have your server to be Linux and your laptop to be Windows. Everything just works.
In Open Remote - SSH extension side panel, click on + and in the editor fill the information:

Host <server_name>
    HostName <ip_address>
    User <user_name>

Example:

Host bobs_build_machine
    HostName 192.168.100.30
    User bob

How this setup is tested

To make a testing environment:

git clone -b kirkstone https://git.yoctoproject.org/git/poky
source poky/oe-init-build-env
MACHINE="beaglebone-yocto" bitbake core-image-minimal

Why I insist on VSCodium instead of Visual Studio Code?

I wanted to have a 100% open source solution.
Inside Yocto we have such complex tools that are fully open sourced like Linux kernel, GCC, GLIBC, openSSL, u-boot, bitbake, QUEMU...
I guess for me, its kind of silly to have all this complex software and then have some editor or C/C++ extension or debugger frontend GUI close sourced.

With that said, I wan't to emphases how much of a big fan I am of all the work that Microsoft did with Visual Studio Code.
Making it open source under MIT license with Code - OSS project is just amazing!

My plan is to have full compatibility with Visual Studio Code.
If you don't want VSCodium or simply don't care, you can use everything in Visual Studio Code.

Collection of useful tips

clangd extension function arguments insertion

Inside the editor, clangd extension inserts the function arguments in the function calls.
This feature is called inlay hints and can be turned on or off with editor.inlayHints.enabled field in the settings.

Enable Command Center in VSCodium in Linux

Open Settings and type in search Window: Command Center
Set Window: Command Center to ON.
Then type in search Window: Title Bar Style
Set Window: Title Bar Style to custom

Install VSCodium in WSL2

In the WSL2 distro, you can setup the specific package manager. Instructions are in https://vscodium.com/

or

Manual download from the release package (for example codium_1.84.2.23319_amd64.deb) and then use

sudo apt install ~/Downloads/<package_name>.deb

In this case you don't have Check for updates... option inside the VSCodium.
To fix this:

cd ~/.config/VSCodium
touch product.json
vim product.json

{
    "updateUrl": "https://vscodium.now.sh",
    "downloadUrl": "https://github.com/VSCodium/vscodium/releases"
}

WSL2 VSCodium Windows shortcut

Create a new Windows Shortcut (right click on Desktop -> New -> Shortcut):
Type the location of the item:

C:\Windows\System32\wsl.exe bash -c "export GDK_SCALE=1 && export XCURSOR_SIZE=24 && DONT_PROMPT_WSL_INSTALL=1 codium"

Next

Type a name for this shortcut:

codium_wsl.exe

Finish

Command attributes explanation:

• GDK_SCALE is if you use scaling on your monitor. In this example, the scale is set to 1 (100%).
• XCURSOR_SIZE is the size of the mouse cursor in gWSL. The default cursor was enormous for me. Value examples: 16, 24, 32, 48, 64.
• DONT_PROMPT_WSL_INSTALL - this is to remove the warning message that you should install VSCode in Windows and then use proprietary Microsoft WSL extension.

TODO

• More setup testing
• Create a version compatibility issue in the Bear repository
• Add more tasks in tasks.json
• Incorporate the new vscode-bitbake extension
• Incorporate u-boot and Linux debugging with a debug adapter (maybe using Cortex-Debug and Black Magic Probe or some kind of openocd compatible debug adapter)