Yocto: bitbake build/populate sysroot

Yocto stops building the global sysroot (both native and cross) from version 2.6. To build any package yocto copies the sysroot as “recipes-sysroot” and “recipes-sysroot-native” into each WORKDIR. This stops the external application builders from using “tmp/sysroots/<MACHINE>” for cross compilation. To do the same way building external application using common sysroot and toolchain one need to build or populate the sysroot explicitly using

bitbake build-sysroots

This bitbake command explicitly populates the sysroot in “tmp/sysroots/<MACHINE>”  and “tmp/sysroots/x86_64 or x86” accordingly. With this application developers can cross compile after exporting the toolchain path “tmp/sysroots/x86_64/usr/bin/<toolchain-name>”. All the dependent cross compiled binaries and libraries can be found under “tmp/sysroots/<MACHINE>”.

Use bitbake sysroot to find provider:

You can also use this sysroot to find the provider of a particular file. For example, if you want to use blkid functionality and you don’t know the yocto/bitbake provider for this libraries or binaries to include into your recipe, you can grep for the header/library/binary inside “tmp/sysroots/<MACHINE>” directory. For this case “libblkid.so/blkid.h” is provided by util-linux, which can be obtained from “manifest-armv7ahf-neon-util-linux.populate_sysroot” (machine type may vary according to your target configuration).

Reference: Build directory structure in Yocto Mega manual

Bluetooth: List available controllers

This is the fist post in the series of blogs for Bluetooth in Linux. In this series we are going to cover mostly about Bluez and it’s provisions for Bluetooth functionality over DBUS (API’s in bluez/doc/).

We will also cover few Bluetooth profiles like GAP, A2DP, AVRCP, PBAP in near future.
Assumption:

This series of post assumes that you have successfully installed Bluetooth and libbluetooth-dev package. And also enabled the Bluetooth controller. If not, please visit your distribution document and install the required packages.

For arch linux,

pacman -S bluez bluez-utils

systemctl start bluetooth

systemctl enable bluetooth # Enable automatic startup during bootup

In this post, we are going to find the available Bluetooth controller using the HCI interface. Note: We are not going to use HCI interface in our future post. The next blog will cover the same use case of finding the controllers using org.bluez interface provided by Bluez over DBUS.

HCI_MAX_DEV is the maximum number of controller devices which can be handled at a time. So here we are using the HCI interface “hci_devinfo” to find the device information. This API internally uses AF_BLUETOOTH socket to connect with Linux Kernel Bluetooth and uses IOCTL HCIGETDEVINFO to get device information.

hci_devinfo fills the “struct hci_dev_info“, which contains the information/details about the controller. flags element in hci_dev_info stores the current status of the controller. This example tests the status against HCI_UP to find the controller which is in UP state. Here only the Name and MAC address of the controller is printed.

As HCI interface interacts directly from userspace to kernel space using IOCTL, we don’t need have bluetoothd daemon running.