Summary

Hardware packs miss some pieces of functionality which make them a bit painful to support across releases. linaro-dev@ thread where it was discussed

Implementation

You can track status in the table in the Proposal section below. The fields marked green have been implemented in some way.

Better yet is to have a look at the HardwarePacksV2 documentation.

Current issues

The kernel command-line is currently hardcoded in linaro-image-tools board per board. Having it in the hwpack would allow changing the cmdline over time, and across kernel updates. For instance OMAP platforms moved from ttyS2 to ttyO2 in ~2.6.36 and this makes it challenging to have any good default in linaro-image-tools.

x-loader and u-boot pathnames were hardcoded in linaro-image-tools. This was recently changed so that linaro-image-tools runs "find" on the rootfs to find the MLO and u-boot.bin at the right depth, but really:

  • it's wrong to install the bootloaders in the rootfs, they are only used to create a bootable image and we don't care to upgrade them (nor would we want to)
  • we shouldn't rely on them being in a specific place (e.g. they could be any level down, in any directory, or named weirdly)
  • this requires knowledge of this name in linaro-image-tools
  • it would be helpful not to have to deal with .debs at all for other future image types like e.g. Android or ChromeOS

Would in general be nice to produce hardware packs that can be shared between Ubuntu, Android and ChromeOS images.

Another important issue is the fact that support for multiple boards might be provided in the same .deb, or even by the same kernel (e.g. single -omap kernel for OMAP3 and OMAP4).

Proposal

In a version 2 of the hwpack format, we would provide more precise data such as which serial console to use (if any), which u-boot file to use (if any) whether to generate an u-boot.ini or just an u-boot.scr etc.

The following table proposes field for the hwpack meta-data.

field

type

meaning

board

string

the name of the board for which this hwpack is made redundant

cmdline_append

string

what to append to kernel command-line (the bits that we store in u-boot's bootargs env).

cmdline_prepend?

string

should we have this field?

u_boot

string

u-boot binary file name in the hwpack. implemented

vmlinuz

string

Linux image file name relative to rootfs (vmlinux or vmlinuz)

initrd

string

initrd file name relative to rootfs

(omap_mlo) x-loader

string

x-loader / MLO file name in the hwpack (OMAP specific)

serial_tty

string

/dev device name of the serial console for this kernel

kernel_addr

int

address where u-boot should load the kernel

initrd_addr

int

address where u-boot should load the kernel

load_addr

int

address for uImage generation -- XXX do we really need this?

dtb_file

string

device tree binary filename relative to rootfs

wired_interfaces

string

the interfaces for wired networks, so that we can fix https://bugs.launchpad.net/linaro-image-tools/+bug/629049 partially implemented

wireless_interfaces

string

same as above, but for wireless networks partially implemented

partition_layout

string

bootfs16_rootfs, bootfs_rootfs and reserved_bootfs_rootfs; controls what kind of SD card partition layout we should use when writing images

mmc_id

int

which MMC drive contains the boot filesystem partially implemented

extra_boot_args_options

string

Board specific extra boot args

spl

only used for the samsung board?

spl_offset

only used for the samsung board?

boot_env_offset

only used for the samsung board?

boot_partition_min_size

implemented: boot_min_size, root_min_size and loader_min_size

reserved_partition_min_size

requires specific partition layout this is covered by loader_min_size

snowball_startfiles_cfg

string

file name of snowball data file in hwpack

extra_serial_opts

string

do we need this as well? yes

live_serial_opts

string

do we need this as well? no

The new hwpacks wont be tested with ChromeOS-style and Android-style images, but the design aims at supporting them without changing the hwpacks.

There is no need for Android hwpack support right now, that can be considered later when desired.

Supporting multiple boards in one hwpack is handled separately OneHardwarePackPerSOC.

This work does not cover license/information prompting that may be required for binary blobs in the hwpack as there is not yet such hwpacks that Linaro can build and distribute.

Design

We shouldn't have executable code to do the partitioning (or anything else) in the hardware pack.

The hwpacks will store only the kernel cmdline instead of the whole boot cmd (what's currently returned by get_boot_cmd()) because we don't want them to be able to change the logic of the boot; they just provide data/configuration.

It's likely linaro-hwpack-install wouldn't install the bootloader, but linaro-media-create would.

Unresolved issues

  • load_addr field: we may be able to use the same address for all boards; we need to confirm with someone from KWG
  • do we want an informational field to indicate base distribution (e.g. linaro-m, linaro-n etc.) "just in case"
  • Some fields only make sense for a particular board. Do we handle that by just making those fields optional?
  • Which fields in the proposal are mandatory and which can be left out?
  • Use lookup of standard data at linaro-media-create time could reduce duplication of data
    • Discussed at LDS. It might make sense to duplicate the information in each hwpack, so we'll start from there.
  • Could we take some of the info from the fdt?
    • There may be some that we can take from there. If so then reducing duplication is a good idea.
    • We could do that at linaro-media-create time, or at hwpack-create time

Platform/Specs/11.11/HardwarePacksV2 (last modified 2011-09-14 13:24:59)