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>
    <remote name="github" fetch="https://github.com/" />
    <project path="src/private-overlays/overlay-foo-private" name="chromiumos/foo" remote="github" revision="branchname"/>
</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 “<kernel_name>” 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-kernel2 cros-workon

DESCRIPTION="Chrome OS Kernel-<kernel_name>"
KEYWORDS="mips"

DEPEND="!sys-kernel/chromeos-kernel-next
    !sys-kernel/chromeos-kernel
"
RDEPEND="${DEPEND}"

  • Replace “<kernel_name>” 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 ‘<kernel_name>-<version>-r1.ebuild’ file is just a symbolic link to the ‘<kernel_name>-<version>.ebuild’ file.  Whenever changes are made to the ebuild file, the symlink should be revbumped/renamed, for instance incrementing ‘-r1’ to ‘-r2’.

  • <version> should be the version number, for instance “3.0.8”

  • <git_repo_path> is the git repository path, such as “git://github.com/MIPS”

  • <git_repo_name> is the git repository name, such as “CI20_linux”.  This field is prepended with <git_repo_path> when referring to a repository location.

  • <git_commit_hash> 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() { }

    • src_configure() { }

    • src_compile() { }

      • Compiling the source, i.e. calling make or emake.

    • src_test() { }

      • Run pre-install test scripts

    • src_install() { }

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 <name> 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-<name>-<version>-r1.ebuild’ file is just a symbolic link to the ‘chromeos-firmware-<name>-<version>.ebuild’ file.  Whenever changes are made to the ebuild file, the symlink should be revbumped/renamed, for instance incrementing ‘-r1’ to ‘-r2’.

  • <version> should be the version number, for instance “2015.03.05” for the revision date for repos that do not have branched versions

  • <git_repo_path> is the git repository path, such as “git://github.com/raspberrypi”

  • <git_repo_name> is the git repository name, such as “firmware”.  This field is prepended with <git_repo_path> when referring to a repository location.

  • <git_commit_hash> 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() { }

    • src_configure() { }

    • src_compile() { }

      • Compiling the source, i.e. calling make or emake.

    • src_test() { }

      • Run pre-install test scripts

    • src_install() { }


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 <name> 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 <name> with the name of your board

  • The ‘chromeos-bsp-<name>-0.0.1-r1.ebuild’ file is just a symbolic link to the ‘chromeos-bsp-<name>-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(), src_configure(), src_compile(), src_test(), and src_install() functions to do the respective work.

Comments