breadcrumbs: For Developers > page_name: u-boot title: U-Boot
Das U-Boot is the boot loader used by Chromium OS on ARM. This page provide some basic information about our use of it. See the official U-Boot page for more information.
Chrome OS uses a single variant of U-Boot for all Tegra2 boards and all purposes. The same applies for Exynos, although this is a different image from Tegra2. This is a departure from the previous approach of having different variants for each purpose (stub, developer, recovery, normal, flasher) and each board (Seaboard, Aebl, Kaen). Both of these changes are enabled by run-time configuration in U-Boot. Traditionally, U-Boot's configuration has been set by CONFIG_ options. We still use CONFIG_ options to select which functionality / drivers is included in an image. However, we avoid using CONFIG_ options that simply configure that functionality. For example, CONFIG_USB_EHCI is used to include the EHCI functionality for USB, but we do not use CONFIG_TEGRA2_USB0to specify the physical address of the first USB port. We use flattened device tree (FDT) to hold this run-time configuration. FDT consists of a number of nodes each with a list of properties. It is easy to add new nodes and properties, and a libfdt library exists for reading and writing them. For more information about FDT, see the specification document before you continue reading here. You might also find the U-Boot doc/README.fdt-control file useful. Note: as of March 2012 we still use ‘seaboard’ (rather than ‘generic’) as the name of our generic Tegra2 board. This may change in the future.
We have various types of nodes in the FDT and they can be categorized as follows:
FDT-based configuration is enabled with the CONFIG_OF_CONTROL option. FDT files are stored in board/nvidia/dts or board/samsung/dts. FDT can be packaged with U-Boot in two ways:
CONFIG_OF_EMBED (only for debugging / development) - it is built as an object file and linked to U-BootCONFIG_OF_SEPARATE - it is built separately and then appended to the U-boot binary (u-boot.bin) using cat or similar. U-Boot locates it at start-up.We use the second approach for Chrome OS, since it allows cros_bundle_firmware to create an image for any board without needing to look around inside U-Boot to change the FDT.
Initially, we used a library called fdt_decode to decode FDT blobs on behalf of different classes of drivers. That approach may become partially useful in future, but we decided to drop it for upstream. There is a still an fdtdec library which helps a lot, but drivers must decode their own nodes.
U-Boot uses header files for configuration. Since the FDT change this has become very simple. We have:
#ifdef CONFIG_OF_CONTROL’ since it is not needed with FDT-based configuration.CONFIG_CHROMEOS and CHROMEOS_BOOTARGS are defined here.TODO: Add description of cros_choose_profile to a more generic page when one is created. In order to simplify the handling of different boards and board variants, a cros_choose_profile tool is used:
cros_choose_profile --help USAGE: /usr/bin/cros_choose_profile [flags] args flags: --board: The name of the board to set up. (default: 'tegra2_seaboard') --build_root: The root location for board sysroots. (default: '/build') --board_overlay: Location of the board overlay. (default: '') --variant: Board variant. (default: '') --profile: The portage configuration profile to use. (default: '') -h,--[no]help: show this help (default: false)
The cros_choose_profile utility selects which board and profile we are using. It is normally run by the setup_board script.
The main U-Boot-related ebuilds are in src/third_party/chromiumos-overlay/sys-boot:
chromeos-u-bootUSE flag, such as USE='developer emerge-tegra2_seaboard' chromeos-u-boot.chroot/build/${BOARD}/firmware directory, named u-boot-normal.bin, u-boot-developer.bin, etc. For Seaboard this directory is chroot/build/tegra2_seaboard/firmware.include/autoconf.mk and System.map, but only for the first variant built. These are used by chromeos-bios (see later).virtual/u-boot pulls this ebuild in)tegra-bct-${BOARD}vritual/tegra-bct package. This ebuild selects configuration files for Flash (SPI or NAND) and SDRAM timings as required.tegra-bct, these functions will be used for building. See src/overlays/overlay-tegra2/eclass/tegra-bct.eclasscbootimage to turn these into a bct file.chroot/build/${BOARD}/u-boot/bct as board.bct and board.cfg.chromeos-bootimagecros_bundle_firmware to create two firmware images for the board. This consists of U-Boot, FDT settings, recovery-mode screens and the required keys for performing a verified boot.The variables U_BOOT_CONFIG_USE and U_BOOT_FDT_USE are currently used to specific the FDT file for U-Boot. These variables are set in the make.defaults file for the board. For example, for tegra2 boards this is in src/overlays/overlay-tegra2/profiles/base/make.defaults.
There is now no need to figure out the FDT or config in the ebuild - you can just use these variables directly.
To check the settings for your board:
emerge-tegra2_seaboard --info |tr ' ' '\n' |grep U_BOOT
There are two main U-Boot repositories on the server: the stable u-boot.git and the unstable u-boot-next.git. Normally you will use the stable repo.
U-Boot is built from an ebuild like this:
emerge-${BOARD} chromeos-u-boot
For example for the Seaboard:
emerge-tegra2_seaboard chromeos-u-boot
This builds it from scratch which takes about 40s on a fast machine.
If you have run cros_workon start chromeos-u-boot (followed by repo sync u-boot) then you can use the incremental build option which takes perhaps 12s.
bin/cros_workon_make chromeos-u-boot
This is the recommended approach since it sets up the options for your board automatically. If you look in the output of this command you should see the make command it is using. If you really want to, you can use this command, which takes the build time down to around 6s.
NOTE: Advanced U-Boot coders only! This can reduce an incremental build to about 1s on a fast machine (16 core). If you are working in u-boot and constantly flashing U-Boot for different Tegra2 boards then you might find this script useful. Run it within your U-Boot source tree. Beware this is not for beginners. Before you use this script, read it through and compare it with the U-Boot ebuild. You can select an FDT to use to change the board. Note: this script could be enhanced to output the resulting u-boot binary to a subdirectory with make ...O=<target_dir>.
#! /bin/sh # Script to build U-Boot without an ebuild and with upstream config files, # then write it to SPI on your board. # # It builds for seaboard by default - use -b to change the board. # For an incremental board, run with no arguments. To clean out and reconfig, # pass the -c flag. compiler=armv7a-cros-linux-gnueabi- if grep -sq Gentoo /etc/lsb-release; then chroot=y # location of src within chroot SRC_ROOT=~/trunk/src gcc=gcc else # Change this to point to your source dir SRC_ROOT=/c/cosarm/src BIN=${SRC_ROOT}/../chroot/usr/bin compiler=${BIN}/${compiler} export PATH=${BIN}:${PATH} gcc=$BIN/gcc echo $PATH fi . "${SRC_ROOT}/scripts/lib/shflags/shflags" DEFINE_boolean config "${FLAGS_FALSE}" "Reconfigure and clean" c DEFINE_boolean good "${FLAGS_FALSE}" "Use known-good U-Boot" g DEFINE_string board "seaboard" \ "Select config: chromeos_tegra2_<board>_<config>_config" b DEFINE_boolean separate "${FLAGS_TRUE}" "Separate device tree" s DEFINE_boolean verified "${FLAGS_FALSE}" "Enable verified boot" V DEFINE_string dt "seaboard" \ "Select device tree: seaboard, kaen, aebl" d DEFINE_boolean build "${FLAGS_TRUE}" "Build U-Boot" B # Parse command line FLAGS "$@" || exit 1 eval set -- "${FLAGS_ARGV}" if [ "$FLAGS_build" -eq "${FLAGS_FALSE}" ]; then if [ "$FLAGS_config" -eq "${FLAGS_TRUE}" ]; then FLAGS_config=${FLAGS_FALSE} echo "Warning: disabled -c since -B was given" fi fi cd $SRC_ROOT/third_party/u-boot/files target=all if [ -n "${FLAGS_ARGV}" ]; then target=${FLAGS_ARGV} fi if [ "$FLAGS_config" -eq "${FLAGS_FALSE}" ]; then # Get the correct board for cros_write_firmware board=$(grep BOARD include/config.mk | awk '{print $3}') if [ -z "${FLAGS_board}" -a "$board" != "${FLAGS_board}" ]; then echo "Warning: U-Boot is configured for $board, " \ "forcing reconfigure" FLAGS_config=${FLAGS_TRUE} fi FLAGS_board=${board} fi BASE+="-s " BASE+="-j15 " BASE+="ARCH=arm CROSS_COMPILE=${compiler} USE_PRIVATE_LIBGCC=yes " BASE+="--no-print-directory " BASE+="HOSTCC=$gcc HOSTSTRIP=true VBOOT=/build/tegra2_${FLAGS_board}/usr " #BASE+="VBOOT_DEBUG=1 " if [ "$FLAGS_separate" -eq "${FLAGS_TRUE}" ]; then BASE+="DEV_TREE_SEPARATE=true " fi BASE+="DEV_TREE_SRC=tegra2-${FLAGS_dt} " board=${FLAGS_board} if [ "${FLAGS_verified}" -eq "${FLAGS_TRUE}" ]; then FLAGS_board=chromeos_tegra2_twostop fi # echo $BASE if [ "$FLAGS_config" -eq "${FLAGS_TRUE}" ]; then make $BASE distclean make $BASE ${FLAGS_board}_config || { echo "Make failed"; exit 1; } make $BASE dep fi if [ "$FLAGS_good" -eq "${FLAGS_TRUE}" ]; then IMAGE=/build/tegra2_${FLAGS_board}/u-boot/u-boot-developer.bin else if [ "$FLAGS_build" -eq "${FLAGS_TRUE}" ]; then make $BASE $target || { echo "Make failed"; exit 1; } fi IMAGE=u-boot.bin fi if [ "$FLAGS_separate" -eq "${FLAGS_TRUE}" ]; then cat $IMAGE u-boot.dtb >u-boot.bin.dtb IMAGE=u-boot.bin.dtb fi bmp="/home/$USER/trunk/src/third_party/chromiumos-overlay/sys-boot/" bmp+="chromeos-bootimage/files/default.bmpblk" cros_bundle_firmware -w -u u-boot.bin -s -b tegra2_aebl --bootsecure \ --bootcmd vboot_twostop --bmpblk ${bmp} #--add-config-int silent_console 1
The method here depends on the platform you are using. Please see the documentation on cros_bundle_firmware also.
There is a firmware writing utility available which can reflash U-Boot on your board. For example, for Seaboard you can write the recovery U-Boot with:
# Connect USB A-A cable to top USB port, reset with recovery button held down If you have a T20-seaboard (no camera attachment on top), please build/flash your firmware with: USE=tegra20-bct emerge-tegra2_seaboard tegra-bct chromeos-bootimage cros_write_firmware -b tegra2_seaboard \ -i /build/tegra2_seaboard/u-boot/legacy_image.bin If you have a T25-seaboard (black camera box above the screen), please build/flash your firmware with: emerge-tegra2_seaboard tegra-bct chromeos-bootimage cros_write_firmware -b tegra2_seaboard \ -i /build/tegra2_seaboard/u-boot/legacy_image.bin
The BCT controls early memory initialization on Tegra2 CPUs. It is something that is customized for every variant of every board.
We need a different BCT for T20 and T25 Seaboards. Up until this point we have just used an old version of the T20 BCT for both products. This is not such a great thing for various reasons, one of which is problems with DVFS. Since we are planning to enable DVFS realsoonnow(TM), you will need this change.
One thing to note: you probably shouldn‘t put “official” builds onto your T20 Seaboard, since they will (I think) clobber the firmware with the T25 version (the default). You’ve been warned.
U-boot accepts user commands to set up its execution environment. The problem with the current implementation is that at the default console baud rate of 115200 u-boot is not running fast enough and the UART gets easily overrun in case a user tries pasting text through terminal connected to the console.
The attached expect script allows to work around the problem. The script is just an example, which can be used it as follows. Start its execution on the workstation which has a USB port connected to the target console
./ttyusb <file with u-boot script>
and then hit reset on the target (if it is not already in u-boot console mode). <file with u-boot script> is a text file including a set of u-boot commands, one per line. Lines starting with # are ignored. ttyusb will send the commands to the console, character by character, making sure that all characters are echoed and the CrOS> prompt is returned after each command. Once all commands are executed, the terminal session becomes the console terminal for the target. To exit the console session type ^a. The serial port device is hardcoded in the script to /dev/ttyUSB1, edit your copy of to get a different tty device used, if necessary.
Current (as of 2011-09-13):
We have 0x4000 0000 (1GB) of memory in our machines. RAM starts at physical address 0x0.
Address 0x Approx. Size** Defined where Notes** 0000 0100 0.25KB 1KBgd->bd->bi_boot_params (TODO: used booting non-FIT images?)Kernel boot parameters area (ATAGs) 0000 8000 32KB 4MBzreladdrNot used by u-boot, but good to keep in mind that this is the location the kernel will eventually decompress / relocate itself to (TODO: will it put any initramdisk here too?). It‘s important there’s room so the decompressed kernel won‘t clobber the FDT. 0010 0000 1MB 8MBCHROMEOS_KERNEL_LOADADDR CHROMEOS_KERNEL_BUFSIZE vboot loads the FIT image here; FDT and zImage will then be relocated elsewhere 0040 8000 4MB + 32KB 4MBCONFIG_LOADADDRArea to load scripts or kernel uImage (prior to decompression); used by legacy u-boot. TODO: Why not use 0x00100000? 00e0 8000 14MB + 32KB 1MBTEXT_BASEStart of U-Boot code region. Data appears immediately after 01ff c000 32MB - 16KB 16KBCONFIG_SYS_BOOTMAPSZ appears to control the 32MB (can be overridden by environment variables). The 16KB comes from the padded size of the kernel’s FDT (as the FDT grows, this should move).U-boot ends up relocating the kernel's copy of the FDT to here. 0200 0000 32MB 512KBCONFIG_CHROMEOS_RAMOOPS_RAM_START CONFIG_CHROMEOS_RAMOOPS_RAM_SIZEKernel preserved area (kcrashmem). This is preserved_start in the kernel, or kcrashmem= environment variable in U-Boot. 0300 0000 48MB ?MBkernel_fdt.itsImage is copied here by u-boot before jumping to. 1c40 6000 512MB - 192MB + 4MB + 24KB 8KBTEGRA_LP0_ADDR TEGRA_LP0_SIZEUsed in suspend / resume. 3768 0000 1GB - ~144MB varies; ~2MBframe-buffer lcd_get_size()