As of September 2012, the way in which a board's disk layout is specified has changed. Previously, all boards shared the same disk layout. Now boards can define their own layout, with different partitioning ordering and sizes.
A board may specify it's own layout by placing a layout file in overlay-<board>/scripts/disk_layout.json, but if no layout file is found here, a default one in scripts/build_library/legacy_disk_layout.json will be used.
A layout file consists of a "base" layout, plus zero or more other types of layout. Common types would be "usb" and "vm". Each of these layouts is made up of one or more partitions.
The base layout is special, since it's the layout on which all other layouts get overlaid upon. The base layout represents the "installed" layout, the way things should be once the image has been installed onto a device. The "usb" layout represents how things should look on a USB image (typically, this means that ROOT-B is 1 block long).
Here's an example of a partition entry in a layout:
The "num" field defines the numerical ID of the partition in the GPT. The "label" field defines the name of the partition in the GPT table and also the label of the filesystem if the given partition has a filesystem. The "blocks" field defines the number of blocks in size the partition is. Optionally, you can also specify the "fs_blocks" field. This defines how large the filesystem on the given partition should be. If you don't specify "fs_blocks", the entire partition is used.
The block size for a partition and a filesystem is defined at the top of the layout file, in the metadata section:
Both of these values should be specified in bytes.