breadcrumbs:
You‘ve got a wonderful new platform that you’d like to run Chromium OS on, but have no idea how to get there from here? Fret not my fellow traveler, for this document shall be your guide. We promise it'll be a wondrous and enlightening journey.
An overlay is the set of configuration files that define how the build system will build a Chromium OS disk image. Configurations will be different depending on the board and architecture type, and what files a developer wants installed on a given disk image. Every command in the build process takes a required `--board` parameter, which developers should pass the overlay name to.
On your first run through this document for creating your first platform, you can skip the sections labeled (advanced). This will let you focus on the minimum bits to get running, and then you can revisit once you're more comfortable with things.
This guide covers doing a public build (one that will be released to the world). There is a separate guide (meant as an add-on to this one) for creating a private board. Setting up a private board is useful for when you want to keep your project details a secret before launch, or if your board contains proprietary drivers or firmware that can't be released publicly.
Possible board names follow a simple specification defined below. Note that this should generally be followed for any new project, as such this encompasses device and model names also, in general any new names that go into the Chromium OS code base.
`cbuildbot -l -a` to get a feel for the “group” namesSettled on a name? Hopefully it's nifty.
Often times you will have a base/reference board on which you will build other boards/devices, and you want to customize each in ways that are incompatible with the others. The board variant framework is designed to handle this setup. Note: at the moment, the variant framework is only one level deep. So you cannot do a variant of a variant. A need for this has not been found, so we haven't worried about it.
When it comes to naming, you will take the existing reference board name and add on the new project's name separated by an underscore. Both projects must follow the naming convention laid out in the above section.
As an example, Google has a reference board named daisy. Using that base, other board variations have been created such as the snow board. Thus the final board name is daisy_snow.
Let‘s start by laying the ground work for the board. We won’t worry about the fine details (like custom set of packages or flags or ...) at this point. We just want a board that the build system will recognize and be able to produce a generic set of artifacts. Once we have that, we'll start customizing things.
Be aware that we assume your board falls under one of the main (currently supported) architectures:
If you're using a different architecture, please see the Chromium OS Architecture Porting Guide first.
This is the main location for per-board customization. Let's start off with a simple overlay:
overlay-$BOARD/ |-- metadata/ | `-- layout.conf # Gentoo repo syntatic sugar |-- profiles/ | `-- base/ | |-- make.defaults # Board customizations (USE/LINUX_FIRMWARE/etc...) | `-- parent # Parent profile for this board (common arch/OS settings) `-- toolchain.conf # Toolchains needed to compile this board
Most of these files are one or two lines. Let's go through them one at a time.
For standard architectures, you only need one line here. Pick the one that matches the architecture for your board.
Example file for an x86_64 board:
$ cat toolchain.conf x86_64-cros-linux-gnu
Note that if you do need more than one toolchain, you can list as many as you like (one per line). But the first entry must be the default one for your board.
Don't worry about the content of this file. Simply copy & paste what you see below, and then update the repo-name field to match your $BOARD.
This is the “base” profile (aka the default) for your board. It allows you to customize a wide array of settings.
This is where the majority of board customization happens -- USE customizations across all packages in make.defaults, or USE and KEYWORDS on a per-package basis (via the package.use and package.keywords files respectively). See the portage(5) man page for all the gory details.
By using the profile, stacking behavior across other profiles is much easier to reason about (when talking about chipsets, baseboards, projects, etc...).
This file can be used to customize global settings for your board. In this first go, we'll use a standard form. New content later on should be appended to this.
$ cat profiles/base/make.defaults # Initial value just for style purposes. USE="" LINUX_FIRMWARE="" # Custom optimization settings for C/C++ code. BOARD_COMPILER_FLAGS=""
This will vary based on your architecture.
Example file for an x86_64 board:
$ cat profiles/base/parent chromiumos:default/linux/amd64/10.0/chromeos
Sometimes you will want to take an existing board and try out some tweaks on it. Perhaps you want to use a different kernel, or change one or two USE flags, or use a different compiler settings (like more debugging or technology like ASAN). You could create a board variant, but that is more for different boards, and is much more heavy handed.
To create a sub-profile, simply make a new directory under the profiles/ and name it whatever you like. Many Google based systems have one called kernel-next and we use this to easily test the new development kernel tree.
You should then create a parent file in there like so:
$ cat profiles/kernel-next/parent ../base
This says the sub-profile will start off using the existing base profile (so you don‘t have to duplicate all the settings you’ve already put into that directory). From here, you can add any files like you would any other profile directory.
Now to select this new profile, you use the --profile option when running setup_board. You can either blow away the existing build dir (if one exists), or tell the system to simply rewrite the configs to point to the new profile. You'll have to make the decision using your knowledge of the profile (whether it means a lot of changes or just swapping of one or two packages).
# Recreate from scratch. $ ./setup_board --profile=kernel-next --board=lumpy --force # Or just rewrite the configs to use the new profile. $ ./setup_board --profile=kernel-next --board=lumpy --regen_configs
This folder contains scripts used during build_image, to tweak the packages that are allowed on the final image. The scripts of interest here are
Note: No new boards should use the variant framework. Instead they should use the arbitrary overlay stacking system (where we have chipsets, baseboards, projects, etc...).
Rather than create an entire hardware board from scratch every time a new project comes along, companies will often take existing projects and make tweaks to fit the new one. It‘s a common industry practice which allows for rapid expansion into more areas. Since these boards are pretty close to each other, it’d be annoying to have to duplicate the entire board settings just to make a handful of changes. The variant framework was designed to address this.
Basically, refer to the sections above for creating a new board overlay. However, this time name it slightly different. If the base board is named daisy and the variant is named snow, we would create the directory overlay-variant-daisy-snow. Yes, the separator is now a dash rather than an underscore.
You will still need to create at least these files (see the previous section for what to put into them):
* metadata/layout.conf
repo-name fieldThe base board overlay will be set as the parent of this variant automatically. So settings/packages that exist in there will be the starting point for this variant.
Since your board should be all set up and ready to go, let's test it. All operations will be done inside the chroot (so run `cros_sdk` to get in first).
$ ./setup_board --board=$BOARD <random build output> $ ./build_packages --board=$BOARD <lots of build output>
Those should both have worked and produced a generic build for that architecture (using your $BOARD name). Let's set about customizing the build now.
Note: as you make changes below to your overlay, re-running build_packages again will rebuild packages that have changed based on your USE flags. But other changes (like compiler settings or kernel configs) will not trigger automatic rebuilds. Only new package builds will use the new settings. Once you're happy with all your settings though, you can re-run setup_board with the --force flag. Then running build_packages will build everything from scratch with the latest settings.
This file contains a few key variables you'll be interested in. Since each of these can be a large topic all by themselves, this is just an overview.
You can set variables like you would in a shell script (VAR="value"), as well as expand them (FOO="${VAR} foo"). But do not try to use shell commands like if [...]; then or sub-shells like $(...) or `...` as things will fail.
The kernel is automatically compiled & installed by the build system. In order to configure it, you have to start with a defconfig file as the base (it can later be refined by various USE flags). This value allows you to control exactly that.
You can specify the relative path (to the root of the kernel tree) to your defconfig. This is useful if you are using a custom kernel tree rather than the official Chromium OS Linux kernel tree.
$ grep CHROMEOS_KERNEL_CONFIG profiles/base/make.defaults CHROMEOS_KERNEL_CONFIG="arch/arm/configs/bcmrpi_defconfig"
Or you can specify a Chromium OS config base. We have one for each major platform/SoC that ships in an official Chrome OS device, and we have architecture generic configs. You can find the full list by browsing the chromeos/config/ directory in the kernel tree. Unlike a defconfig, splitconfigs are much smaller fragments which start with a common base and then enable/disable a few options relative to that.
$ grep CHROMEOS_KERNEL_SPLITCONFIG profiles/base/make.defaults CHROMEOS_KERNEL_SPLITCONFIG="chromeos-pinetrail-i386"
The kernel build system normally detects what architecture you're using based on your overall profile. For example, if you have an amd64 board overlay setup, the build knows it should use ARCH=x86_64.
However, there arises edge cases where you want to run a kernel architecture that is different from the userland. For example, say you wanted to run a 64-bit x86_64 kernel, but you wanted to use a 32-bit i386 userland. If your profile is normally setup for an x86 system, you can set this variable to x86_64 to get a 64-bit kernel.
$ grep CHROMEOS_KERNEL_ARCH profiles/base/make.defaults CHROMEOS_KERNEL_ARCH="x86_64"
One of the strengths of the Gentoo distribution is that you can easily control general feature availability in your builds by changing your USE settings. For example, if you don‘t want audio, you can disable alsa & oss. Or if you don’t want LDAP, you can disable that. All of the ebuild files (the package scripts used to build/install code) have logic to check each setting that is optional so you don't have to.
The downside, as you can imagine, is that with thousands and thousands of packages, the number of possible USE flags is vast. There are also some optional settings which only make sense with one or two packages (global vs local USE flags). So weeding through which USE flags exactly matter can be a bit of a monstrous task.
An extension to the USE flag system are so called USE-expanded variables. This helps reduce the global USE flag noise a bit by having specially named variables with specific meaning. In this case, we'll discuss device inputs (keyboards/mouse/etc...) and video outputs.
The exact driver availability (and naming convention) depends on what graphic system you intend to use. The X project tends to have the widest selection but is a larger overall install size, while DirectFB tends to have smaller selection of drivers but be much smaller. We'll focus on X here as that is the main system that Chromium supports.
TBD
TBD
Everyone likes optimizations. Faster is better, right? Here's the nuts and bolts of it.
While picking out flags to use, keep in mind that Chromium OS uses LLVM/Clang for its compiler suite. It also uses the gold linker. So see the respective documentation.
You should put compiler optimizations that target your specific cpu into this variable. Commonly, this means:
If you have flags that you want to use only when compiling C code, use this variable. Otherwise, things will default to -O2 -g -pipe.
$ grep CFLAGS profiles/base/make.defaults CFLAGS="-march=foo"
If you have flags that you want to use only when compiling C++ code, use this variable. Otherwise, things will default to -O2 -g -pipe.
$ grep CXXFLAGS profiles/base/make.defaults CXXFLAGS="-march=foo"
If you have flags that you want to send directly to the linker for all links, use this variable.
These should take the form as given to the compiler driver. i.e. use -Wl,-z,relro rather than -z relro.
You can find common settings in the GNU Linker manual.
Presumably you‘d like to be able to easily (and cleanly) produce artifacts for your board. In our chromite repo, we have a tool called cbuildbot that takes care of all that for us. Normally it’s run by buildbot on a waterfall to produce all the goodness, but there's no requirement that buildbot be the tool you use. You can even run it locally.
At any rate, you'll need to update this master file to add your new board configs. There are a few classes of configs to be familiar with:
The file should be largely self-documenting.
Sometimes you‘ll want to host large files or prebuilt binary packages for your repo, but you don’t want to give out access to everyone in the world. You can great some boto config files, and the build scripts will automatically use them when they're found.
Create this file in the root of the overlay. This file stores the access credential (in cleartext) for the role account.
These are the ACL files used by gsutil to apply access for people. Used whenever you want to upload files and grant access to people who have the boto file.
The TXT format is documented in the gsutil FAQ. The JSON format is not yet used. Support for the XML format has been dropped.