the Chromium logo

The Chromium Projects

1. Overview of the Porting Process

Basic Tasks

U-Boot is a highly portable boot loader, supporting many high-end ARM SoCs. It contains a vast array of features and drivers to help speed up the porting process. When porting U-Boot to a new board, follow these basic steps:

  1. Add support for your SoC. U-Boot supports many common SoCs, and in many cases, a new SoC is a variant of an existing one that can serve as a starting point for the port.
  2. Add a board configuration file and a board implementation file containing code specific to your board.
  3. Add or modify any drivers you need for your platform.
  4. Bring in the kernel device tree file if available (or write a new device tree).

This guide describes these steps in some detail, with a focus on Chrome OS-specific implementations.

Note: The following information was written for Tegra in 2011 and is somewhat out of date.

Development Flow

Chromium OS uses U-Boot as its boot loader on ARM and x86. This page describes the development flow, requirements for commits submitted to the project, upstreaming responsibilities and Chromium OS-specific features.

Before reading this document, please see http://www.denx.de/wiki/U-Boot and at the very least, read:

Except during a rebase period, Chromium OS has a single U-Boot repository, called ‘u-boot.git’, containing all U-Boot source code. There is no split between different SOCs, no split for Chromium OS-specific code, no split at all. We deal with the different types of commits using commit tags.

Commits

Upstreaming

We plan to upstream most or all of our code. Any code that you write will likely either be dropped or sent upstream. Please consider when writing code that it should fit with U-Boot conventions Let’s call the person who is upstreaming a particular feature the ‘canoe captain’.

Code Review

Code Refactors

Testing

Most testing is currently manual. It is important that people can repeat your test steps later without a deep knowledge of your environment, board, commit and mind.

You may find the crosfw script useful for building and testing U-Boot.

Mandatory testing:

Suggested testing:

Commit Tags

All commits should have exactly one tag from the following table at the start of the subject line. The tag indicates the intended destination for the commit. Note that standard upstream commit tags are encouraged also (i2c, usb, net, lcd, spi) and these follow the primary tag. Tags are always lower case.

Commits cannot normally span more than one of the paths below, so commits in multiple areas must be split into different commits. The idea to keep in mind is that this is like having separate repositories, but with less admin/productivity overhead.

Where a change requires that (say) Chromium, Tegra and Samsung code must change at the same time to avoid a build breakage, the ‘split’ tag should be used first, and the rest in alphabetical order as in ‘split: chromium: exynos: tegra: fiddle with something’.

Tag: Meaning Canoe Captain Path
cros: Local patches, will not conceivably go upstream. Use for verified boot mainly - cros/
tegra: Tegra SOC, board and driver code Nvidia arch/arm/cpu/armv7/tegra\*/ board/nvidia/ drivers/
exynos: Samsung SOC, board and driver code Samsung arch/arm/cpu/armv7/exynos\*/ board/samsung/ drivers/
arm: ARM-generic patches, committer mans the canoe Committer arch/arm (but not in an soc subdir)
x86: x86-generic patches, committer mans the canoe Committer
upstream: Pulled in from upstream - any
drop: Urgent / unclean / factory patches which we will drop on next rebase - any
split: Indicates a commit which must be split to send upstream
gen: Generic (not architecture-specific) commit which should go upstream Committer any. Note that when sending upstream this tag is dropped
config: Change to a board configuration file - include/configs/

Pre-upload Checks

Before uploading a commit for review, please do the following checks:

BUG=

TEST=

This should be detailed enough that another person without particular knowledge of your code can run the procedure you detail, and verify your commit. The information should specific. Examples are:

Some bad examples of test information are:

Chromium Source Subdirectory

Our local code commits can be broken into several areas, but almost all code is in a ‘cros/’ subdirectory. Here is the current split:

Directory Used for Previously
cros/ All Chromium OS commits Various
cros/tegra Implementation of Chrome OS low-level API on Tegra SOCs board/nvidia/chromeos
cros/exynos Implementation of Chrome OS low-level API on Exynos SOCs -
cros/coreboot Implementation of Chrome OS low-level API on Coreboot board/chromebook-x86/chromeos
cros/lib Chrome OS library functions lib/chromeos
cros/vboot Verified boot exported functions lib/vbexport
cros/cmd Chrome OS commands common/cmd_....c
cros/include Chrome OS headers include/chromeos

Other sections in the U-Boot Porting Guide

  1. Overview of the Porting Process (this page)

  2. Concepts

  3. U-Boot Drivers