This page describes the new hwpacks configuration file syntax.

Hardware Packs Configuration File Syntax (V3)

The new hwpack configuration file syntax is based on the YAML 1.1 syntax.

Remarks

  • Do not use tabulation characters for indentation, only use spaces.
    See here.

  • Numbers can be passed as quoted or not, like this:

    a_number: 0
    b_number: '1'
    Both syntax are correct, in the former case the parser will interpret it as a number, in the latter as a string.
  • Boolean values can be expressed as True, true, False and false.

Syntax Reference

General Fields

The following parameters can be used only once in a hwpack configuration file, and they apply to the file as a whole. They are tied to the resulting hwpack archive.

format

The format of the file, in this case has to be 3.0. Example:

format: 3.0
name

The name the created hwpack archive will have.
A string, spaces are not allowed. Example:

name: panda-hwpack
architectures

Sequence (list) of architectures the hwpack config file applies to. Example:

architectures:
 - armhf
 - armel
origin

An optional value indicating from who, or which organization the hwpack configuration file comes.
A string, spaces are allowed. Example:

origin: Linaro
maintainer

The maintainer of the hwpack: a developer, team or organization, along with their email address to be contacted about problems with the hwpack.
String, spaces are allowed. Example:

maintainer: Example Team <[email protected]>

Specific Fields

support

An optional value specifying whether the hardware pack is supported.
Possible values are: supported or unsupported. Example:

support: unsupported
assume_installed

Sequence (list) of packages that are assumed installed by the tool. Example:

assume_installed:
 - linaro-headless
 - linaro-tools
include_debs

Boolean (True or False) indicating whether the hardware pack archive should contain deb files. Example:

include_debs: True
dtb_files

Sequence (list) of DTB files relative to the target rootfs. They are expected to be installed by a package listed in the packages field, and are supposed to be common to all the bootloaders. Example:

dtb_files:
 - [path/]rename.dtb : boot/dt-*-linaro-omap/omap4-panda.dtb

path is optional, if not present in the target it will be created. It is possible also to define only the path, without renaming like in this case:

dtb_files:
 - path/ : boot/dt-*-linaro-omap/omap4-panda.dtb

The omap4-panda.dtb file will be copied into path without being renamed.

dtb_file

DTB file relative to the target rootfs. It is expected to be installed by a package listed in the packages field, and is supposed to be common to all the bootloaders. Example:

dtb_file: boot/dt-*-linaro-omap/omap4-panda.dtb
dtb_addr

DTB address. It is assumed to be the same for all the bootloaders. Example:

dtb_addr: 0x815f0000
serial_tty

Board serial device. Example:

serial_tty: tty01
extra_serial_options

Sequence (list) of extra options to be passed. Example:

extra_serial_options:
 - console=tty0
 - console=ttyO2,115200n8
mmc_id

MMC id to use in fatload mmc <mmc_id>, the second part is used to calculate mmc_part_offset. Example:

mmc_id: 0:1
packages

A sequence (list) of packages to be installed in the rootfs. This should contain a kernel package but not a u-boot package. All dependencies will be automatically included. Example:

packages:
 - linux-image-linaro-omap
 - linux-headers-linaro-omap
 - libegl1-sgx-omap3
partition_layout

The partition to create.
Valid values are: bootfs_rootfs, bootfs16_rootfs or reserved_bootfs_rootfs. Example:

partition_layout: bootfs16_rootfs
kernel_file

Kernel file relative to the target rootfs. This is expected to be installed by a package listed in the packages field. Example:

kernel_file: boot/vmlinuz-*-linaro-omap
kernel_addr

Example:

kernel_addr: 0x80200000
initrd_file

Initrd file relative to the target rootfs. This is expected to be installed by a package listed in the packages field. Example:

initrd_file: boot/initrd.img-*-linaro-omap
initrd_addr

Example:

initrd_addr: 0x81600000
load_addr

Example:

load_addr: 0x80008000
boot_script

Filename of the boot script to be created in the bootfs. Example:

boot_script: boot.scr
loader_start

Start of the loader partition. Example:

loader_start: 256
wired_interfaces

Sequence (list) of wired interfaces that can be used. Example:

wired_interfaces:
 - eth0
 - eth1
wireless_interfaces

Sequence (list) of wireless interfaces that can be used. Example:

wireless_interfaces:
 - wlan0
 - wlan1
boot_min_size
Not used at the moment.
root_min_size
Not used at the moment.
loader_min_size
Not used at the moment.

Samsung Parameters

Samsung u-boot layout on SD cards is flexible in its placement of bootloader binaries.

BL1 is the initial bootloader and starts of sector 1. It is size may be 32s or 48s. BL2 is the u-boot binary which may be placed right after BL1 or after ENV. In case BL2 is placed right after BL2, ENV is placed after BL2, else it is placed right after BL1.

All the following values are in terms of 'sectors'.

samsung_bl1_start

Start of Samsung BL1. Example:

samsung_bl1_start: 1
samsung_bl1_len

Length of Samsung BL1. Example:

samsung_bl1_len: 32
samsung_env_start

Start of Samsung ENV. Example:

samsung_env_start: 32
samsung_env_len

Length of Samsung ENV. Example:

samsung_env_len: 32
samsung_bl2_start

Start of Samsung BL2. Example:

samsung_bl2_start: 1024
samsung_bl2_len

Length of Samsung BL2. Example:

samsung_bl2_len: 1024

Snowball Parameters

snowball_startup_files_config

Path to the Snowball startup files configuration. The actual file is contained in startfiles.deb in the resulting hwpack archive. Example:

snowball_startup_files_config: startfiles.cfg

Multiple Sources

sources

Mapping of mappings (a-la Python dictionary) with repositories to take packages from. Example:

sources:
 ubuntu: http://ports.ubuntu.com/ubuntu-ports precise main universe
 updates: http://ports.ubuntu.com/ubuntu-ports precise-updates main universe
Do not use quotes or double quotes in here.

Multiple Bootloaders

bootloaders

Defines a mapping of mappings (a-la Python dictionary) with the various bootloaders supported. Syntax is:

bootloaders:
 BOOTLOADER_NAME:
  ...
 BOOTLOADER_NAME:
  ...

Where BOOTLOADER_NAME can be: u_boot or uefi. A more practical example:

bootloaders:
 u_boot:
  ...
 uefi:
  ...

The BOOTLOADER_NAME specific configuration values have to be indented with respect to the bootloader name.

The following fields are part of the bootloaders section.

Bootloaders Specific Fields

The following fields can be used inside each of the multiple bootloaders sub-sections.

package

The package containing the bootloader binary. The package will not be installed in the target rootfs. Example:

package: u-boot-linaro-omap4-panda
file

The file that will be extracted from the bootloader package. Example:

file: usr/lib/u-boot/omap4_panda/u-boot.img
in_boot_part

Boolean (True or False) indicating whether the file has to be copied in the boot partition. Example:

in_boot_part: True
copy_files
A list of files to copy from an optionally named packages to an optionally named destination (has to be under /boot). If the destination isn't set, files will be copied to /boot. There are two formats:

Without explicit package name, in this case the bootloader package will be used:

copy_files:
 - file1 : dest_file_path
 - file2

With explicit source package(s):

copy_files:
  source_package:
   - source_file_path : dest_file_path
   - source_file_without_explicit_destination
  source_package2:
   - source_file2
Note that either 1st or 2nd format should be used, they cannot be mixed in the same bootloader section.
dd

The desired seek offset to dd the file to the boot device at the specified offset. If it is not specified, the binary will not be dd-ed. Example:

dd: 64
extra_boot_options

A sequence (list) of extra options to be passed. Example:

bootloaders:
 extra_boot_options:
  - earlyprintk
  - fixrtc
  - nocompcache
  - vram=48M
  - omapfb.vram=0:24M
  - mem=456M@0x80000000
  - mem=512M@0xA0000000
spl_package

Package containing the spl binary. The package will not be installed in the target rootfs. It may be the same package as package. Example:

spl_package: x-loader-omap4-panda
spl_file

The spl file that will be extracted from the spl_package. Example:

spl_file: usr/lib/x-loader/omap4430panda/MLO
spl_in_boot_part

Boolean (True or False) indicating whether the spl_file has to be copied in the boot partition. Example:

spl_in_boot: False
spl_dd

Set to the desired seek offset to dd the spl_file to the boot device at the specified offset. If this is not specified, the spl binary will not be dd-ed. Example:

spl_dd: 64
env_dd

Boolean (True or False) indicating whether to dd the env to the boot device. Since this is only used for Samsung boards, the samsung_env_start and samsung_env_len fields are used. Example:

env_dd: True

Multiple Boards

boards

Defines a mapping of mappings (a-la Python dictionary) with the various boards this hwpack configuration file applies to. Syntax is:

boards:
 BOARD_NAME:
  ...
 BOARD_NAME:
  ...

Where BOARD_NAME is the name of the hardware board that piece of configuration applies to. A more practical example:

boards:
 panda:
  ...
 beagleboard:
  ...

The BOARD_NAME specific configuration values have to be indented with respect to the board name.

Each of the previously defined specific parameters, multiple sources, and multiple bootloaders, can be used inside each of the BOARD_NAME sub-sections. If one value is defined also outside of these sub-sections, the sub-section one prevails.

Notes

  • In YAML, a sequence (list) can be defined also with the following syntax:

    sequence: [value, value]
  • In YAML, a mapping of mappings (dictionary) can be defined also with the following syntax:

    mappings: {mapping: value, mapping: value}

HardwarePacksV3 (last modified 2013-08-22 09:01:45)