eltonlaw sundries

Building a Custom Raspberry Pi Image: Part 2

Updating buildroot to latest stable

Updating the buildroot submodule led to some issues with legacy options in my .config.

I had taken a patch that wasn't merged into master, adding missing dependencies host-libjpeg and host-freetype to QT5WEBENGINE_DEPENDENCIES in package/qt5/qt5webengine/qt5webengine.mk. That's in there now, so I can remove the git apply hotfix stuff I had.

The following is deprecated and was moved into a separate package

BR2_PACKAGE_RPI_WIFI_FIRMWARE=y

The Raspberry Pi 3B has a Broadcom BCM43438 chip (renamed to CYW43438) which has 2.4ghz WLAN and BT 5.1 The new entries should look like

BR2_PACKAGE_BRCMFMAC_SDIO_FIRMWARE_RPI=y
BR2_PACKAGE_BRCMFMAC_SDIO_FIRMWARE_RPI_BT=y
BR2_PACKAGE_BRCMFMAC_SDIO_FIRMWARE_RPI_WIFI=y

Split into development image and release image

release image will have everything required to run the QT UI and the systemd services

development image will be release image with some extra debug tooling. Currently,

BR2_CCACHE=y
BR2_ENABLE_DEBUG=y
BR2_ENABLE_RUNTIME_DEBUG=y
BR2_OPTIMIZE_G=y

Switching the init system to systemd

From the default of busybox, I decided to switch to systemd as the init system. Busybox was easy to work with but I'm planning to have a lot of services; polling of various sensors, cloud backup, real time data analysis, etc. Maybe 10 - 20 different processes running concurrently, with some sort of IPC between them. Bringing in systemd increases the image size and complexity of the codebase but will standardize alot of the integration I think. For IPC I was planning to use DBus too, so it would fit well.

For certain services, socket activation allows for very, very fast starts. Basically, all services can be started in parallel if the sockets they output data to are initialized first before any services that consume from them are started. Then any service can start and it'll just start queuing messages which sit there. The destination service will spin up in time and start processing the backlog. I'm planning to make all the sensor services point to a socket, it would be interesting to see how much lag time there is between pressing the power button and the first sensor measurement. Changing it involves just adding

BR2_INIT_SYSTEMD=y
BR2_PACKAGE_SYSTEMD=y

QT can't connect to the D-Bus session bus.

Added a connect to QT session bus in the UI. Got an error

"Cannot connect to the D-Bus session bus"

Which is because QT can't determine the unix path of the D-BUS session bus socket filepath. This is fixable by running

export $(dbus-launch)

and that just exports DBUS_SESSION_BUS_ADDRESS and DBUS_SESSION_BUS_PID.