the Chromium logo

The Chromium Projects
Chromium OS >

External BSP Hosting

Introduction

When any BSP developer wants to build their code with Chromium OS and have it easily shared with other developers, they currently typically have to commit their BSPs to either the public or private Chromium OS repositories and update the respective repo manifest files if necessary. In hosting their ebuilds in the Chromium OS repositories, however, they get tied into the Chromium OS Commit Queue and code review process, which is not always ideal for them.

Local Manifests

In order to pull in code hosted on an external git repository, developers can make use of local manifest files. Local manifest files allow more remotes and repositories to be specified for download in additional xml files without direct dependencies being specified in the main Chromium OS manifest files. Any number of local manifest files may be supplied, allowing developers to name and distribute their local manifest files for each project.

After following the instructions for getting the source, create a “local_manifests” folder inside the .repo folder. Assuming like in the setup instructions that your source code is in ${HOME}/chromiumos, run the following commands:

cd ${HOME}/chromiumos/.repo

mkdir local_manifests

Then, create or download any additional XML manifest files into the created folder and run `repo sync` to pull down the new code.

Manifest Format

Local manifest files can have any name as long as they are of the .xml extension. Their format is the same as normal manifest files, and can be viewed here. A simple example manifest file for pulling http://github.com/chromiumos/foo.git on branch “branchname” into src/private-overlays/overlay-foo-private:

File: ${HOME}/chromiumos/.repo/local_manifests/foo.xml

<?xml version="1.0" encoding="UTF-8"?>

<manifest>

`

`

</manifest>

BSP Overlays

This section is meant as a quick-start guide for the basics of setting up a BSP within an overlay, but doesn't fully cover creating the overlay itself. The basics of setting up an overlay can be found in the Board Porting guide. Even with board and BSP code hosted in an external repository, the board name still has to be added to the cros-board.eclass file. Also, for brevity, copyright headers have been left out of these sample templates, but should be added in all ebuild files in whatever format is correct for your organization.

make.conf

This file contains several key settings for kernel configurations, such as the architecture, config, and tune. The key fields are:

  • CHROMEOS_KERNEL_CONFIG - the kernel configuration file to use. The path is relative to the kernel source checkout. Setting this overrides any use of CHROMEOS_KERNEL_SPLITCONFIG.
  • CHROMEOS_KERNEL_SPLITCONFIG - the kernel splitconfig to use. Splitconfigs can be used instead of a full config. For details on splitconfigs, see here.
  • MARCH_TUNE - The common set of compiler flags used to optimize for your processor.
  • CFLAGS, CXXFLAGS - The compiler flags to use when building the code.
  • USE - use flags to set. When using splitconfigs, for example, providing the ‘nowerror’ flag disables treating warnings as errors.

For an example MIPS board, the make.conf would look something like:

CHROMEOS_KERNEL_CONFIG="arch/mips/configs/ci20_defconfig"

CHROMEOS_KERNEL_ARCH="mips"

# We assume that we are running a little endian 32bit MIPS CPU. If you have

# a MIPS64 CPU, then you really should be using the n32 overlay instead.

MARCH_TUNE="-march=mips32"

CFLAGS="${CFLAGS} ${MARCH_TUNE}"

CXXFLAGS="${CXXFLAGS} ${MARCH_TUNE}"

# Kernel doesn't yet build cleanly.

USE="${USE} nowerror"

Kernel

The following files are required for customizing the kernel source, build, or install.

virtual/linux-sources/linux-sources-2.ebuild

EAPI="6" DESCRIPTION="Chrome OS Kernel virtual package" HOMEPAGE="http://src.chromium.org" LICENSE="GPL-2" SLOT="0" KEYWORDS="mips" IUSE="-kernel_sources" RDEPEND=" sys-kernel/<kernel_name>[kernel_sources=] "`

Replace the KEYWORDS value with the correct platform

Replace the LICENSE value with your license

Replace “&lt;kernel_name&gt;” in the RDEPEND field with the name of your
kernel package, such as “ci20-kernel”

sys-kernel/<kernel_name>/<kernel_name>-<version>.ebuild

sys-kernel/<kernel_name>/<kernel_name>-<version>-r1.ebuild

EAPI="6" CROS_WORKON_REPO="<git_repo_path>" CROS_WORKON_PROJECT="<git_repo_name>" CROS_WORKON_BLACKLIST="1" CROS_WORKON_COMMIT="<git_commit_hash>" # This must be inherited *after* EGIT/CROS_WORKON variables defined inherit git-2 cros-kernel cros-workon DESCRIPTION="Chrome OS Kernel-<kernel_name>" KEYWORDS="mips" DEPEND="!sys-kernel/chromeos-kernel-next !sys-kernel/chromeos-kernel " RDEPEND="${DEPEND}"`

Replace “&lt;kernel_name&gt;” with the name of your kernel package, as
specified in the RDEPEND field of the linux-sources-2.ebuild file

Replace the KEYWORDS value with the correct platform

The ‘&lt;kernel_name&gt;-&lt;version&gt;-r1.ebuild’ file is just a symbolic
link to the ‘&lt;kernel_name&gt;-&lt;version&gt;.ebuild’ file. Whenever
changes are made to the ebuild file, the symlink should be
revbumped/renamed, for instance incrementing ‘-r1’ to ‘-r2’.

&lt;version&gt; should be the version number, for instance “3.0.8”

&lt;git_repo_path&gt; is the git repository path, such as
“git://github.com/MIPS”

&lt;git_repo_name&gt; is the git repository name, such as “CI20_linux”. This
field is prepended with &lt;git_repo_path&gt; when referring to a repository
location.

&lt;git_commit_hash&gt; is the hash of the git commit to use. For instance,
on the CI20_linux repo, “2e5af7d6650ce6435f2894bdd7ee7f0333950942” would
refer to the head of the 3.0.8 branch
(<https://github.com/MIPS/CI20_linux/tree/ci20-v3.0.8>)

By default, this builds the Makefile’s “vmlinuz.bin” target for mips, uImage
for arm, and uses the default target for everything else

For customizing the build process, the following functions can be added to
the ebuild:

    src_prepare() { }

        [Preparation](https://devmanual.gentoo.org/ebuild-writing/functions/src_prepare/index.html)
        of the source, such as applying patches

    src_configure() { }

        [Configuring](https://devmanual.gentoo.org/ebuild-writing/functions/src_configure/index.html)
        the source

    src_compile() { }

        [Compiling](https://devmanual.gentoo.org/ebuild-writing/functions/src_compile/index.html)
        the source, i.e. calling make or emake.

    src_test() { }

        [Run](https://devmanual.gentoo.org/ebuild-writing/functions/src_test/index.html)
        pre-install test scripts

    src_install() { }

        [Install](https://devmanual.gentoo.org/ebuild-writing/functions/src_install/index.html)
        the package

Firmware

The following files are required for customizing the firmware to install.

virtual/chromeos-firmware/chromeos-firmware-2.ebuild

EAPI="6" DESCRIPTION="Chrome OS Firmware virtual package" HOMEPAGE="http://src.chromium.org" LICENSE="BSD" SLOT="0" KEYWORDS="arm" IUSE="" RDEPEND="chromeos-base/chromeos-firmware-<name>"

Replace the LICENSE value with your correct license

Replace the KEYWORDS field with your board’s architecture (arm, mips, ppc,
x86, etc)

Replace &lt;name&gt; with the name of your board

chromeos-base/chromeos-firmware-<name>/chromeos-firmware-<name>-<version>.ebuild

chromeos-base/chromeos-firmware-<name>/chromeos-firmware-<name>-<version>-r1.ebuild

EAPI="6" CROS_WORKON_REPO="<git_repo_path>" CROS_WORKON_PROJECT="<git_repo_name>" CROS_WORKON_BLACKLIST="1" CROS_WORKON_COMMIT="<git_commit_hash>" inherit git-2 cros-workon DESCRIPTION="Chrome OS Firmware" KEYWORDS="mips"

Replace the KEYWORDS value with the correct platform

The ‘chromeos-firmware-&lt;name&gt;-&lt;version&gt;-r1.ebuild’ file is just
a symbolic link to the
‘chromeos-firmware-&lt;name&gt;-&lt;version&gt;.ebuild’ file. Whenever
changes are made to the ebuild file, the symlink should be
revbumped/renamed, for instance incrementing ‘-r1’ to ‘-r2’.

&lt;version&gt; should be the version number, for instance “2015.03.05” for
the revision date for repos that do not have branched versions

&lt;git_repo_path&gt; is the git repository path, such as
“git://github.com/raspberrypi”

&lt;git_repo_name&gt; is the git repository name, such as “firmware”. This
field is prepended with &lt;git_repo_path&gt; when referring to a repository
location.

&lt;git_commit_hash&gt; is the hash of the git commit to use. For instance,
on the raspberrypi/firmware repo, “cdcb50646bc035e9f3e74b99d764023c4b98d7d5”
would refer to the current head of the master branch
(https://github.com/raspberrypi/firmware/tree/master)

By default, this builds and installs the Makefile’s default target

For customizing the build process, the following functions can be added to
the ebuild:

    src_prepare() { }

        [Preparation](https://devmanual.gentoo.org/ebuild-writing/functions/src_prepare/index.html)
        of the source, such as applying patches

    src_configure() { }

        [Configuring](https://devmanual.gentoo.org/ebuild-writing/functions/src_configure/index.html)
        the source

    src_compile() { }

        [Compiling](https://devmanual.gentoo.org/ebuild-writing/functions/src_compile/index.html)
        the source, i.e. calling make or emake.

    src_test() { }

        [Run](https://devmanual.gentoo.org/ebuild-writing/functions/src_test/index.html)
        pre-install test scripts

    src_install() { }

        [Install](https://devmanual.gentoo.org/ebuild-writing/functions/src_install/index.html)
        the package

Board Specific Packages

The following files are required for adding any specific drivers and tools to a board.

virtual/chromeos-bsp/chromeos-bsp-2.ebuild

EAPI="6" DESCRIPTION="Chrome OS BSP virtual package" HOMEPAGE="http://src.chromium.org" LICENSE="BSD" SLOT="0" KEYWORDS="arm" RDEPEND="chromeos-base/chromeos-bsp-<name>"

Replace the LICENSE value with your correct license

Replace the KEYWORDS field with your board’s architecture (arm, mips, ppc,
x86, etc)

Replace &lt;name&gt; with the name of your board

chromeos-base/chromeos-bsp-<name>/chromeos-bsp-<name>-0.0.1.ebuild

chromeos-base/chromeos-bsp-<name>/chromeos-bsp-<name>-0.0.1-r1.ebuild

EAPI="6" DESCRIPTION="<name> bsp (meta package to pull in driver/tool dependencies)" LICENSE="BSD-Google" SLOT="0" KEYWORDS="arm" IUSE="" DEPEND="" RDEPEND=""

Replace the LICENSE value with your correct license

Replace the KEYWORDS field with your board’s architecture (arm, mips, ppc,
x86, etc)

Replace &lt;name&gt; with the name of your board

The ‘chromeos-bsp-&lt;name&gt;-0.0.1-r1.ebuild’ file is just a symbolic link
to the ‘chromeos-bsp-&lt;name&gt;-0.0.1.ebuild’ file. Whenever changes are
made to the ebuild file, the symlink should be revbumped/renamed, for
instance incrementing ‘-r1’ to ‘-r2’.

Adding any packages that currently have ebuilds in the source tree should be
added to the DEPEND and RDEPEND fields. The DEPEND field specifies
build-time dependencies that will not be installed into the build image. The
RDEPEND field specifies run-time dependencies that will be installed into
the build image.

Other source can be built and installed by adding
[src_prepare](https://devmanual.gentoo.org/ebuild-writing/functions/src_prepare/index.html)(),
[src_configure](https://devmanual.gentoo.org/ebuild-writing/functions/src_configure/index.html)(),
[src_compile](https://devmanual.gentoo.org/ebuild-writing/functions/src_compile/index.html)(),
[src_test](https://devmanual.gentoo.org/ebuild-writing/functions/src_test/index.html)(),
and
[src_install](https://devmanual.gentoo.org/ebuild-writing/functions/src_install/index.html)()
functions to do the respective work.