Buildroot

We use the latest available version of Buildroot with slight modifications allowing us to create a truely relocatable building environment.

Cameras, Modules and Fragments

Camera hardware is primarily based on the SoC model, image sensor, and sometimes a wireless module. Different cameras may use the same SoC, sensor, and Wi-Fi module, thus requiring similarly built firmware, but still have different GPIO mapping and peripheral configuration. To avoid repeating settings in configs, we have decoupled camera-specific configs from the underlying hardware configs (we call them modules). We just tell the camera config stored in config/cameras/' which hardware module stored in config/modules/' to use:

# MODULE: t31x_gc2053_rtl8189ftv_defconfig

Then in the module config file we have everything configured for the Triade: SoC, sensor and the Wi-Fi module, if there is one.

But these hardware configs have a lot of common, repetitive information related to processor architecture and firmware in general. We use configuration fragments, stored in `config/fragments/*.fragment' files, to avoid repeating these settings. You can see how these fragments are included in the module config:

# FRAG: soc toolchain ccache brand rootfs kernel system target

This allows us to minimize the configuration steps required to add new hardware. And, if necessary, we can easily propagate changes to all dependent hardware.

Config for compilation

When make is run, the final configuration for a given camera is assembled from the pieces and saved as a ~/output/<camera_config_name>/.config file. It then runs make olddefconfig, which parses the file, resolves any conflicts and redundancies, and creates a new fully populated .config' file, saving the previous version as .config.old, which gets overwritten with any new changes, so we also save the initial version of the .config' file as .config_original for easier debugging.

To recreate the .config' file from the original camera configuration file and its includes, run make defconfig'.