Home
This layer is mainly a combination of BSP enhancements and some useful/custom recipes for the supported machines. Some machine bits are pulled in and others are overridden in local.conf (see the examples in the conf directory). The main point of all this is to provide FOSS recipes and configuration data to replace (or override) the proprietary bits in vendor layers, most recently a fully FOSS imx6 build with accelerated mesa GL and Xorg video drivers and mainline kernel. Although the config for this recent proof-of-concept uses nitrogen6x, it has also been applied and tested on other imx6 devices (eg, cubox-i4-pro) as well as replicated in Gentoo (see the Gentoo arm overlay).
The easiest way to use this layer is via one of the manifest repos:
- vct-boundary-bsp-platform - repo manifest for boundary devices and other imx6q/dl devices
- vct-beagleboard-bsp-platform - repo manifest for beaglebones of various colors
- vct-socfpga-bsp-platform - repo manifest for Altera hybrid ARM/FPGA SoCs
- vct-edgerouter-bsp-platform - repo manifest for Edgerouter Lite (yes, a MIPS machine)
Each of the above manifests supports multiple OE releases on different branches (typically jethro, krogoth, morty, master, depending on which one). If you don't find the branch you need, feel free to file a github issue. Most also provide both a poky layout and an oe-core layout; if you use oe-core it may require DISTRO = "vctlabs" in local.conf. Also note there are no special image recipes, rather, the example local.conf sets all of the custom build parameters as well as which packages get installed. The example configs should use the core-image-minimal target; use the variables in local.conf to enable/disable different package groups.
As mentioned, there are several ways to try the open source/mainline approach without any vendor forks of kernels or proprietary graphics dependencies. The first/original way for etnaviv that I ran across by Robert Nelson is documented in the LinuxOnArm wiki and the packages are available from the repos configured in his debian and ubuntu rootfs'.
There are both FOSS and more vendor-ish boards documented there, each on their own page, and there is some level of mainline support for both types of board; the primary difference between the two approaches being SPI flash for u-boot on the vendor-ish boards (the nitrogen6 boards from Boundary Devices have one boot-script for booting and one for flashing u-boot). There are wiki pages for the Wandboard and Udoo open source boards, as well as pages for a couple of SABRE Lite vendor-ish boards.
But wait, there's more! There are even more examples of each type of board in the mainline kernel and u-boot, so just follow the process for that type, eg, use the Wandboard page for Cubox-i4-pro or the SABRE Lite page for a nitrogen6x board. Using the recommended u-boot version/repo from the wiki should be the safest route.
The other two ways are the build-it-yourself approach; the easy/quick-ish way to build it uses the Yocto Project tools and metadata (based on either poky or oe-core) and the vct-boundary-bsp-platform mentioned above. Follow the README file and use the example config on the branch you select.
Finally, there is the Gentoo way to build it, meaning on the device itself, which is completely doable (including a mostly-hardened profile). The core support for etnaviv has already been mainlined in the kernel, mesa, and libdrm; as mentioned above, there are ebuilds for the Xorg armada video drivers and headers in the Gentoo arm overlay and bitbake nitrogen6x recipes for both graphics and kernel/bootloader in this layer.
Note
A mostly-hardened profile means you can start from the latest hardened stage3, add a current mainline kernel, and enable all of the core hardening features in mainline (new ones appear periodically). Feel free to try the latest available PAX patches for ARM, however, they appear to be mostly untested/unmaintained at this point.
Feel free to use ccache and/or distcc, however, you may see the odd/random compile failure with a "large" number of jobs, which is sometimes anything equal to or greater than the number of cores. If you lower the number of jobs so that one core is essentially "free" from compile jobs then it should build normally. For some of the biggest jobs (eg, webkit, qt5, firefox, etc) you might need to lower it to -j2 or even -j1, especially if you're using gold linker and -flto.