[Buildroot] [PATCH 0/5] media image generation

[Buildroot] [PATCH 0/5] media image generation

[Vivien Didelot]

This patchset adds a minimal support to generate final images for a medium
(such as SD card or flash), by providing paths to some genimage config files in
a board directory.

The rationale behind using genimage as the first medium image generation tool,
is that while its configuration syntax is simple, it requires a small overhead
to use, like temporary directories, host dependencies, and images path, that
Buildroot is all aware of.

The first patch explains the convenience of this host tool, and adds the
mechanism to wrap and call genimage against optional config file(s) specified
in the board configuration, as well as the appropriate documentation.

The subsequent patches adds genimage config files for the following platforms:
all Raspberry Pi models, BeagleBone Black, and the Wandboard.

They give good examples to show how Buildroot can be used to create a fully
functional SD card image with a bootloader, some firmware files and a
persistent rootfs, without the need to mount any partition.

Finally, this support simplifies the user experience by providing ready-to-use
boot medium images, and lightening board documentation with self documented
configuration files.

Note: if we happen to include other media image generation tools, the
BR2_TARGET_MEDIA_GENIMAGE_CFG and future options can then simply be moved to a
"Media image generation --->" top-level menu.

Vivien Didelot (5):
  Makefile: add media image generation
  board/raspberrypi: install Device Tree
  board/raspberrypi: add a genimage config
  board/beaglebone: add a genimage config
  board/wandboard: add a genimage config

 Makefile                              |  9 +++++++--
 board/beaglebone/genimage.cfg         | 30 +++++++++++++++++++++++++++++
 board/beaglebone/readme.txt           |  4 ++++
 board/raspberrypi/genimage.cfg        | 32 +++++++++++++++++++++++++++++++
 board/raspberrypi/post-image.sh       |  7 +++++++
 board/raspberrypi/readme.txt          |  9 +++++++--
 board/wandboard/genimage.cfg          | 22 +++++++++++++++++++++
 board/wandboard/readme.txt            |  3 ++-
 configs/beaglebone_defconfig          |  3 +++
 configs/raspberrypi2_defconfig        |  6 ++++++
 configs/raspberrypi_defconfig         |  5 +++++
 configs/raspberrypi_dt_defconfig      |  6 ++++++
 configs/wandboard_defconfig           |  1 +
 docs/manual/customize-media-image.txt | 36 +++++++++++++++++++++++++++++++++++
 docs/manual/customize.txt             |  4 ++++
 support/media/genimage                | 23 ++++++++++++++++++++++
 system/Config.in                      | 26 +++++++++++++++++++++++++
 17 files changed, 221 insertions(+), 5 deletions(-)
 create mode 100644 board/beaglebone/genimage.cfg
 create mode 100644 board/raspberrypi/genimage.cfg
 create mode 100755 board/raspberrypi/post-image.sh
 create mode 100644 board/wandboard/genimage.cfg
 create mode 100644 docs/manual/customize-media-image.txt
 create mode 100755 support/media/genimage

-- 
2.3.3

[Buildroot] [PATCH 1/5] Makefile: add media image generation

[Vivien Didelot]

This patch adds an optional and minimalist support for building medium
images, through a new "target-media-image" step of the build system.

This initial support features, but is not limited to, the "genimage"
host tool, which eases the definition of flash media, partition layout
and final images through a simple syntax.

This patch adds a new BR2_TARGET_MEDIA_GENIMAGE_CFG Kconfig entry to the
"System configuration" menu, which is a space-separated list of config
files (definitions can be split in different files).

BR2_TARGET_MEDIA_GENIMAGE_HOST_DEPENDENCIES is meant to auto-select the
packages that genimage may use, such as mkdosfs or mcopy.

A new support/media directory contains a genimage wrapper, and a new
"Media image generation" section has been added to the manual.

Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
 Makefile                              |  9 +++++++--
 docs/manual/customize-media-image.txt | 36 +++++++++++++++++++++++++++++++++++
 docs/manual/customize.txt             |  4 ++++
 support/media/genimage                | 23 ++++++++++++++++++++++
 system/Config.in                      | 26 +++++++++++++++++++++++++
 5 files changed, 96 insertions(+), 2 deletions(-)
 create mode 100644 docs/manual/customize-media-image.txt
 create mode 100755 support/media/genimage

diff --git a/Makefile b/Makefile
index af043a3..3e0ec32 100644
--- a/Makefile
+++ b/Makefile
@@ -430,11 +430,11 @@ $(BUILD_DIR)/buildroot-config/auto.conf: $(BR2_CONFIG)
 
 prepare: $(BUILD_DIR)/buildroot-config/auto.conf
 
-world: target-post-image
+world: target-media-image
 
 .PHONY: all world toolchain dirs clean distclean source outputmakefile \
 	legal-info legal-info-prepare legal-info-clean printvars \
-	target-finalize target-post-image \
+	target-finalize target-post-image target-media-image \
 	$(TARGETS) $(TARGETS_ROOTFS) \
 	$(TARGETS_DIRCLEAN) $(TARGETS_SOURCE) $(TARGETS_LEGAL_INFO) \
 	$(BUILD_DIR) $(STAGING_DIR) $(TARGET_DIR) \
@@ -626,6 +626,11 @@ target-post-image: $(TARGETS_ROOTFS) target-finalize
 		$(call MESSAGE,"Executing post-image script $(s)"); \
 		$(EXTRA_ENV) $(s) $(BINARIES_DIR) $(call qstrip,$(BR2_ROOTFS_POST_SCRIPT_ARGS))$(sep))
 
+target-media-image: target-post-image
+	@$(foreach cfg, $(call qstrip,$(BR2_TARGET_MEDIA_GENIMAGE_CFG)), \
+		$(call MESSAGE,"Generating media image from $(cfg)"); \
+		$(EXTRA_ENV) support/media/genimage $(cfg)$(sep))
+
 source: $(TARGETS_SOURCE) $(HOST_SOURCE)
 
 external-deps:
diff --git a/docs/manual/customize-media-image.txt b/docs/manual/customize-media-image.txt
new file mode 100644
index 0000000..ee39914
--- /dev/null
+++ b/docs/manual/customize-media-image.txt
@@ -0,0 +1,36 @@
+// -*- mode:doc; -*-
+// vim: set syntax=asciidoc:
+
+=== Media image generation
+
+*Media image generation* allows to define final images for medium such 
+as disk, SD card or flash, _after_ filesystem images, kernel and 
+bootloader have been created, and eventually tweaked by custom scripts 
+(xref:_customization_emphasis_after_emphasis_the_images_have_been_created[]).
+
+Image generation completes the build process and can for example be used 
+to define a fully bootable image (including partition layout, with the 
+bootloader, some firmware files, a kernel and rootfs, at specific 
+offsets, etc.), ready to be dumped on a boot medium.
+
+Actually, the host tool used to generate this image is *genimage*. It
+allows complex definitions as described above, through a convenient
+syntax. The genimage documentation is located at:
+http://git.pengutronix.de/?p=genimage.git;a=blob_plain;f=README.
+
+To enable this feature, specify a space-separated list of genimage 
+config files in config option +BR2_TARGET_MEDIA_GENIMAGE_CFG+ (in the 
++System configuration+ menu). You may indeed want to split the 
+configuration for the different partitions and final image(s). If you 
+specify a relative path, it will be relative to the root of the 
+Buildroot tree.
+
+You can find several examples of genimage configuration, by searching 
+for +BR2_TARGET_MEDIA_GENIMAGE_CFG+ in the +configs+ directory.
+
+Just like post-build and post-image scripts, genimage is run with the
+main Buildroot tree as current working directory. The genimage input and
+output directory are configured to the path of the Buildroot +images+
+output directory. This means that rootfs or others images can be
+specified relative to this directory, and generated media images will be 
+copied there.
diff --git a/docs/manual/customize.txt b/docs/manual/customize.txt
index 484413e..288365e 100644
--- a/docs/manual/customize.txt
+++ b/docs/manual/customize.txt
@@ -23,6 +23,8 @@ Typical actions you may need to perform for a given project are:
 * adding custom user accounts (using +BR2_ROOTFS_USERS_TABLES+)
 * running arbitrary commands after generating the filesystem image
   (using +BR2_ROOTFS_POST_IMAGE_SCRIPT+)
+* defining media image(s) to generate at the end of the process (using
+  +BR2_TARGET_MEDIA_IMAGE_GENIMAGE_CFG+)
 * adding project-specific patches to some packages (using
   +BR2_GLOBAL_PATCH_DIR+)
 * adding project-specific packages
@@ -53,6 +55,8 @@ include::customize-users-tables.txt[]
 
 include::customize-post-image.txt[]
 
+include::customize-media-image.txt[]
+
 include::customize-patches.txt[]
 
 include::customize-packages.txt[]
diff --git a/support/media/genimage b/support/media/genimage
new file mode 100755
index 0000000..11c72ec
--- /dev/null
+++ b/support/media/genimage
@@ -0,0 +1,23 @@
+#!/usr/bin/env bash
+
+# We want to catch any unexpected failure, and exit immediately
+set -e
+
+# Media image generation helper for genimage
+#
+# Call it as:
+#   .../genimage GENIMAGE_CFG
+
+GENIMAGE_CFG="${1}"
+GENIMAGE_DIR="$(mktemp -d output/.genimage.XXXXXXXXXX)"
+
+mkdir -p "${GENIMAGE_DIR}"/{root,tmp}
+
+"${HOST_DIR}/usr/bin/genimage" \
+    --rootpath "${GENIMAGE_DIR}/root" \
+    --tmppath "${GENIMAGE_DIR}/tmp" \
+    --inputpath "${BINARIES_DIR}" \
+    --outputpath "${BINARIES_DIR}" \
+    --config "${GENIMAGE_CFG}"
+
+rm -rf "${GENIMAGE_DIR}"
diff --git a/system/Config.in b/system/Config.in
index 9973cc2..479ac4a 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -452,4 +452,30 @@ config BR2_ROOTFS_POST_SCRIPT_ARGS
 	  directory / images directory. The arguments in this option will be
 	  passed *after* those.
 
+config BR2_TARGET_MEDIA_GENIMAGE_CFG
+	string "genimage config files to prepare media images"
+	default ""
+	help
+	  Specify a space-separated list of configuration files for genimage
+	  to be run after the build has finished and after Buildroot has
+	  packed the files into selected filesystem images.
+
+	  This can for example be used to generate an SD card image with a
+	  vfat boot partition and a ext4 rootfs, or a flash image with
+	  bootloader and kernel at specific offsets.
+
+	  genimage is executed from the main Buildroot source directory,
+	  with input and output paths configured to output/images.
+
+	  The genimage documentation is located at:
+	  http://git.pengutronix.de/?p=genimage.git;a=blob_plain;f=README.
+
+config BR2_TARGET_MEDIA_GENIMAGE_HOST_DEPENDENCIES
+	bool "genimage host dependencies"
+	default y
+	depends on BR2_TARGET_MEDIA_GENIMAGE_CFG != ""
+	select BR2_PACKAGE_HOST_GENIMAGE
+	select BR2_PACKAGE_HOST_DOSFSTOOLS
+	select BR2_PACKAGE_HOST_MTOOLS
+
 endmenu
-- 
2.3.3

[Buildroot] [PATCH 2/5] board/raspberrypi: install Device Tree

[Vivien Didelot]

Add a post-image script to Raspberry Pi configs with a Device Tree
(raspberrypi_dt and raspberrypi2), which calls the mkknlimg tool on the
resulting zImage kernel, in order to install the Device Tree as
described in the board readme file.

Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
 board/raspberrypi/post-image.sh  | 7 +++++++
 configs/raspberrypi2_defconfig   | 1 +
 configs/raspberrypi_dt_defconfig | 1 +
 3 files changed, 9 insertions(+)
 create mode 100755 board/raspberrypi/post-image.sh

diff --git a/board/raspberrypi/post-image.sh b/board/raspberrypi/post-image.sh
new file mode 100755
index 0000000..0d6f265
--- /dev/null
+++ b/board/raspberrypi/post-image.sh
@@ -0,0 +1,7 @@
+#!/bin/bash
+
+set -e
+
+# Call mkknlimg to install the Device Tree
+"${HOST_DIR}/usr/bin/mkknlimg" "${BINARIES_DIR}/zImage" "${BINARIES_DIR}/zImage-dt"
+mv "${BINARIES_DIR}/zImage-dt" "${BINARIES_DIR}/zImage"
diff --git a/configs/raspberrypi2_defconfig b/configs/raspberrypi2_defconfig
index b523a4a..3543307 100644
--- a/configs/raspberrypi2_defconfig
+++ b/configs/raspberrypi2_defconfig
@@ -23,3 +23,4 @@ BR2_LINUX_KERNEL_ZIMAGE=y
 # Install the DTB files, as the RPi2 uses the Device Tree
 BR2_PACKAGE_RPI_FIRMWARE=y
 BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi2/post-image.sh"
diff --git a/configs/raspberrypi_dt_defconfig b/configs/raspberrypi_dt_defconfig
index ca62084..0c203bf 100644
--- a/configs/raspberrypi_dt_defconfig
+++ b/configs/raspberrypi_dt_defconfig
@@ -20,3 +20,4 @@ BR2_LINUX_KERNEL_ZIMAGE=y
 # Install the DTB files
 BR2_PACKAGE_RPI_FIRMWARE=y
 BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi/post-image.sh"
-- 
2.3.3

[Buildroot] [PATCH 3/5] board/raspberrypi: add a genimage config

[Vivien Didelot]

This patch adds a "genimage.cfg" genimage config file for the Raspberry
Pi, to use with a persistent rootfs. This config applies to all models,
i.e. A, B, A+, B+, and B2. The final generated "sdcard.img" image is
ready to use and contains the setup explained in the board readme.txt
file: a bootable vfat partition with the rpi-firmware files, and an ext4
rootfs partition.

The defconfig and readme file have been slightly changed to add the
generation of the rootfs.ext4 filesystem.

Tested on a Raspberry Pi B.

Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
 board/raspberrypi/genimage.cfg   | 32 ++++++++++++++++++++++++++++++++
 board/raspberrypi/readme.txt     |  9 +++++++--
 configs/raspberrypi2_defconfig   |  5 +++++
 configs/raspberrypi_defconfig    |  5 +++++
 configs/raspberrypi_dt_defconfig |  5 +++++
 5 files changed, 54 insertions(+), 2 deletions(-)
 create mode 100644 board/raspberrypi/genimage.cfg

diff --git a/board/raspberrypi/genimage.cfg b/board/raspberrypi/genimage.cfg
new file mode 100644
index 0000000..c674cab
--- /dev/null
+++ b/board/raspberrypi/genimage.cfg
@@ -0,0 +1,32 @@
+image boot.vfat {
+  vfat {
+    files = {
+      "rpi-firmware/bcm2708-rpi-b.dtb",
+      "rpi-firmware/bcm2708-rpi-b-plus.dtb",
+      "rpi-firmware/bcm2709-rpi-2-b.dtb",
+      "rpi-firmware/bootcode.bin",
+      "rpi-firmware/config.txt",
+      "rpi-firmware/fixup.dat",
+      "rpi-firmware/start.elf",
+      "zImage"
+    }
+  }
+  size = 10M
+}
+
+image sdcard.img {
+  hdimage {
+  }
+
+  partition boot {
+    partition-type = 0xC
+    bootable = "true"
+    image = "boot.vfat"
+  }
+
+  partition rootfs {
+    partition-type = 0x83
+    image = "rootfs.ext4"
+    size = 512M
+  }
+}
diff --git a/board/raspberrypi/readme.txt b/board/raspberrypi/readme.txt
index b513ca3..439d2f0 100644
--- a/board/raspberrypi/readme.txt
+++ b/board/raspberrypi/readme.txt
@@ -16,6 +16,9 @@ Buildroot, you have to choose whether you will use:
 
 Also, a good source of information is http://elinux.org/R-Pi_Hub
 
+Note: Buildroot already prepared an "sdcard.img" image for a persistent
+rootfs, but this document explains how to do it manually.
+
 How to build it
 ===============
 
@@ -61,6 +64,7 @@ After building, you should obtain this tree:
 
     output/images/
     +-- rootfs.tar                              [0]
+    +-- rootfs.ext4                             [0]
     +-- rpi-firmware/
     |   +-- bcm2708-rpi-b.dtb
     |   +-- bcm2708-rpi-b-plus.dtb
@@ -71,8 +75,9 @@ After building, you should obtain this tree:
     |   `-- start.elf
     `-- zImage
 
-[0] Note for Volatile: rootfs.tar will only be there if you kept
-    "tar the root filesystem" option selected in "Filesystem images".
+[0] Note for Volatile: rootfs.tar and rootfs.ext4 will only be there if
+    you kept "tar the root filesystem" and "ext2/3/4 root filesystem"
+    options selected in "Filesystem images".
 
 Prepare you SDCard
 ==================
diff --git a/configs/raspberrypi2_defconfig b/configs/raspberrypi2_defconfig
index 3543307..fe61d94 100644
--- a/configs/raspberrypi2_defconfig
+++ b/configs/raspberrypi2_defconfig
@@ -24,3 +24,8 @@ BR2_LINUX_KERNEL_ZIMAGE=y
 BR2_PACKAGE_RPI_FIRMWARE=y
 BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y
 BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi2/post-image.sh"
+
+# Image generation (persistent)
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_MEDIA_GENIMAGE_CFG="board/raspberrypi2/genimage.cfg"
diff --git a/configs/raspberrypi_defconfig b/configs/raspberrypi_defconfig
index 835657c..d36f3c0 100644
--- a/configs/raspberrypi_defconfig
+++ b/configs/raspberrypi_defconfig
@@ -20,3 +20,8 @@ BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="c256eb9968c8997dce47350d2075e42f1b3991d3"
 BR2_LINUX_KERNEL_USE_DEFCONFIG=y
 BR2_LINUX_KERNEL_DEFCONFIG="bcmrpi_quick"
 BR2_LINUX_KERNEL_ZIMAGE=y
+
+# Image generation (persistent)
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_MEDIA_GENIMAGE_CFG="board/raspberrypi/genimage.cfg"
diff --git a/configs/raspberrypi_dt_defconfig b/configs/raspberrypi_dt_defconfig
index 0c203bf..effc5d8 100644
--- a/configs/raspberrypi_dt_defconfig
+++ b/configs/raspberrypi_dt_defconfig
@@ -21,3 +21,8 @@ BR2_LINUX_KERNEL_ZIMAGE=y
 BR2_PACKAGE_RPI_FIRMWARE=y
 BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y
 BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi/post-image.sh"
+
+# Image generation (persistent)
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_MEDIA_GENIMAGE_CFG="board/raspberrypi/genimage.cfg"
-- 
2.3.3

[Buildroot] [PATCH 4/5] board/beaglebone: add a genimage config

[Vivien Didelot]

This patch adds a "genimage.cfg" genimage config file for the BeagleBone
(classic and black). The final generated "sdcard.img" image is ready to
use and contains the setup explained in the board readme.txt file: a
bootable vfat partition with the kernel, bootloader and DTB files, and
an ext2 rootfs partition.

The defconfig and readme file have been slightly changed to enable this
feature.

Tested on a BeagleBone Black.

Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
 board/beaglebone/genimage.cfg | 30 ++++++++++++++++++++++++++++++
 board/beaglebone/readme.txt   |  4 ++++
 configs/beaglebone_defconfig  |  3 +++
 3 files changed, 37 insertions(+)
 create mode 100644 board/beaglebone/genimage.cfg

diff --git a/board/beaglebone/genimage.cfg b/board/beaglebone/genimage.cfg
new file mode 100644
index 0000000..91ed021
--- /dev/null
+++ b/board/beaglebone/genimage.cfg
@@ -0,0 +1,30 @@
+image boot.vfat {
+  vfat {
+    files = {
+      "am335x-boneblack.dtb",
+      "am335x-bone.dtb",
+      "MLO",
+      "u-boot.img",
+      "uEnv.txt",
+      "zImage"
+    }
+  }
+  size = 10M
+}
+
+image sdcard.img {
+  hdimage {
+  }
+
+  partition boot {
+    partition-type = 0xC
+    bootable = "true"
+    image = "boot.vfat"
+  }
+
+  partition rootfs {
+    partition-type = 0x83
+    image = "rootfs.ext2"
+    size = 512M
+  }
+}
diff --git a/board/beaglebone/readme.txt b/board/beaglebone/readme.txt
index c6d0aa0..80a27f9 100644
--- a/board/beaglebone/readme.txt
+++ b/board/beaglebone/readme.txt
@@ -5,6 +5,9 @@ Intro
 To be able to use BeagleBone board with the images generated by
 Buildroot, you have prepare the SDCard.
 
+Note: Buildroot already prepared an "sdcard.img" in the output/images/
+directory, but this document explains how to do it manually.
+
 How to build it
 ===============
 
@@ -41,6 +44,7 @@ and second where you will write rootfs.
 
 Copy the files to boot partition
 
+  $ cd output/images/
   $ cp MLO u-boot.img zImage uEnv.txt *.dtb /media/zzzzz
 
 where /media/zzzzz is the mount point
diff --git a/configs/beaglebone_defconfig b/configs/beaglebone_defconfig
index ddb583c..052c794 100644
--- a/configs/beaglebone_defconfig
+++ b/configs/beaglebone_defconfig
@@ -40,3 +40,6 @@ BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/beaglebone/linux-3.12.config"
 BR2_LINUX_KERNEL_ZIMAGE=y
 BR2_LINUX_KERNEL_DTS_SUPPORT=y
 BR2_LINUX_KERNEL_INTREE_DTS_NAME="am335x-bone am335x-boneblack"
+
+# image generation
+BR2_TARGET_MEDIA_GENIMAGE_CFG="board/beaglebone/genimage.cfg"
-- 
2.3.3

[Buildroot] [PATCH 5/5] board/wandboard: add a genimage config

[Vivien Didelot]

This patch adds a "genimage.cfg" genimage config file for the Wandboard.
The final generated "sdcard.img" image is ready to use and contains the
setup explained in the board readme.txt file: U-Boot, its environment,
and an Ext4 rootfs partition.

The defconfig and readme file have been slightly changed to enable this
feature.

Tested on a Wandboard Solo.

Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
 board/wandboard/genimage.cfg | 22 ++++++++++++++++++++++
 board/wandboard/readme.txt   |  3 ++-
 configs/wandboard_defconfig  |  1 +
 3 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 board/wandboard/genimage.cfg

diff --git a/board/wandboard/genimage.cfg b/board/wandboard/genimage.cfg
new file mode 100644
index 0000000..15783f0
--- /dev/null
+++ b/board/wandboard/genimage.cfg
@@ -0,0 +1,22 @@
+image sdcard.img {
+  hdimage {
+  }
+
+  partition u-boot {
+    in-partition-table = "no"
+    image = "u-boot.imx"
+    offset = 1024
+  }
+
+  partition u-boot-env {
+    in-partition-table = "no"
+    image = "uboot-env.bin"
+    offset = 393216
+  }
+
+  partition rootfs {
+    partition-type = 0x83
+    image = "rootfs.ext2"
+    size = 512M
+  }
+}
diff --git a/board/wandboard/readme.txt b/board/wandboard/readme.txt
index 4dd9c2c..88842b0 100644
--- a/board/wandboard/readme.txt
+++ b/board/wandboard/readme.txt
@@ -2,7 +2,8 @@ Minimal board support for the Wandboard
 
 Wandboard's homepage is here: http://www.wandboard.org/
 
-This config is only tested with the dual core wandboard.
+Note: Buildroot already prepared an "sdcard.img" image ready to boot, but this 
+document explains how to do it manually.
 
 Installing:
 
diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig
index 0a6ba50..c0da795 100644
--- a/configs/wandboard_defconfig
+++ b/configs/wandboard_defconfig
@@ -4,6 +4,7 @@ BR2_KERNEL_HEADERS_VERSION=y
 BR2_DEFAULT_KERNEL_VERSION="3.0.101"
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_0=y
 BR2_TARGET_GENERIC_GETTY_PORT="ttymxc0"
+BR2_TARGET_MEDIA_GENIMAGE_CFG="board/wandboard/genimage.cfg"
 BR2_TARGET_ROOTFS_EXT2=y
 BR2_TARGET_ROOTFS_EXT2_4=y
 BR2_TARGET_UBOOT=y
-- 
2.3.3

[Buildroot] [PATCH 2/5] board/raspberrypi: install Device Tree

[Yann E. MORIN]

Vivien, All,

On 2015-03-17 18:51 -0400, Vivien Didelot spake thusly:
> Add a post-image script to Raspberry Pi configs with a Device Tree
> (raspberrypi_dt and raspberrypi2), which calls the mkknlimg tool on the
> resulting zImage kernel, in order to install the Device Tree as
> described in the board readme file.

No, it is not "installing" the device tree. It merely appends a marker
at the end of the kernel image.

That marker instructs the RPi bootloader that the kernel is Device Tree
aware, and thus the bootloader will load the device tree blobs; if the
marker is missing, the bootloader will not load a device tree blob, and
will pass ATAGS.

Regards,
Yann E. MORIN.

> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> ---
>  board/raspberrypi/post-image.sh  | 7 +++++++
>  configs/raspberrypi2_defconfig   | 1 +
>  configs/raspberrypi_dt_defconfig | 1 +
>  3 files changed, 9 insertions(+)
>  create mode 100755 board/raspberrypi/post-image.sh
> 
> diff --git a/board/raspberrypi/post-image.sh b/board/raspberrypi/post-image.sh
> new file mode 100755
> index 0000000..0d6f265
> --- /dev/null
> +++ b/board/raspberrypi/post-image.sh
> @@ -0,0 +1,7 @@
> +#!/bin/bash
> +
> +set -e
> +
> +# Call mkknlimg to install the Device Tree
> +"${HOST_DIR}/usr/bin/mkknlimg" "${BINARIES_DIR}/zImage" "${BINARIES_DIR}/zImage-dt"
> +mv "${BINARIES_DIR}/zImage-dt" "${BINARIES_DIR}/zImage"
> diff --git a/configs/raspberrypi2_defconfig b/configs/raspberrypi2_defconfig
> index b523a4a..3543307 100644
> --- a/configs/raspberrypi2_defconfig
> +++ b/configs/raspberrypi2_defconfig
> @@ -23,3 +23,4 @@ BR2_LINUX_KERNEL_ZIMAGE=y
>  # Install the DTB files, as the RPi2 uses the Device Tree
>  BR2_PACKAGE_RPI_FIRMWARE=y
>  BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y
> +BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi2/post-image.sh"
> diff --git a/configs/raspberrypi_dt_defconfig b/configs/raspberrypi_dt_defconfig
> index ca62084..0c203bf 100644
> --- a/configs/raspberrypi_dt_defconfig
> +++ b/configs/raspberrypi_dt_defconfig
> @@ -20,3 +20,4 @@ BR2_LINUX_KERNEL_ZIMAGE=y
>  # Install the DTB files
>  BR2_PACKAGE_RPI_FIRMWARE=y
>  BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y
> +BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi/post-image.sh"
> -- 
> 2.3.3
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 2/5] board/raspberrypi: install Device Tree

[Vivien Didelot]

Hi Yann,

> > Add a post-image script to Raspberry Pi configs with a Device Tree
> > (raspberrypi_dt and raspberrypi2), which calls the mkknlimg tool on the
> > resulting zImage kernel, in order to install the Device Tree as
> > described in the board readme file.
> 
> No, it is not "installing" the device tree. It merely appends a marker
> at the end of the kernel image.
> 
> That marker instructs the RPi bootloader that the kernel is Device Tree
> aware, and thus the bootloader will load the device tree blobs; if the
> marker is missing, the bootloader will not load a device tree blob, and
> will pass ATAGS.

Indeed, I misunderstood the statement from the readme file. Depending on
how this patchset goes, I'll add this comment to the post-image script
in a follow-up patch or in a new version.

Thanks for the explanation,
-v

[Buildroot] [PATCH 1/5] Makefile: add media image generation

[Yann E. MORIN]

Vivien, All,

On 2015-03-17 18:51 -0400, Vivien Didelot spake thusly:
> This patch adds an optional and minimalist support for building medium
> images, through a new "target-media-image" step of the build system.

As discussed on IRC, I wonder why you need to add a new target in the
top-level Makefile, rather than re-use the filesystem infra. something
like:

fs/Config.in

    # Existing filesystems, up to:
    source "fs/yaffs2/Config.in"
    commet "Aggregate filesystems"  # Or whatever prompt that has meaning
    source "fs/genimage/Config.in"


fs/genimage/Config.in

    config BR2_TARGET_ROOTFS_GENIMAGE
        bool "genimage"
        select BR2_PACKAGE_HOST_GENIMAGE

    config BR2_TARGET_ROOTFS_GENIMAGE_CFG
        string "path to genimage config files"
        depends on BR2_TARGET_ROOTFS_GENIMAGE


fs/genimge/genimage.mk

    ROOTFS_GENIMAGE_DEPENDENCIES = host-genimage
    ROOTFS_GENIMAGE_DEPENDENCIES += $(if $(BR2_TARGET_ROOTFS_EXT2),rootfs-ext2)
    ROOTFS_GENIMAGE_DEPENDENCIES += $(if $(BR2_TARGET_ROOTFS_SQUASHFS),rootfs-squashfs)
    # And so on...

    define ROOTFS_GENIMAGE_CMD
        $(foreach cfg,$(call qstrip,$(BR2_TARGET_ROOTFS_GENIMAGE_CFG)),\
            TMPDIR="$$(mktemp -d $(BUILD_DIR)/.genimage.XXXXXXXXXX)" || exit 1; \
            $(INSTALL) -d -m 0755 $${TMPDIR}/{root,tmp} || exit 1; \
            $(EXTRA_ENV) $(HOST_DIR)/usr/bin/genimage \
                --rootpath $(TARGET_DIR) \
                --tmppath $${RMPDIR}/tmp \
                --inputpath $(BIANRIES_DIR) \
                --outputpath $(BIANRIES_DIR) \
                --config $(cfg) || exit 1; \
            rm -rf $${TMPDIR} || exit 1$(sep))
    endef


And then there's no need to add another top-level Makefile rule.

[--SNIP--]
> diff --git a/support/media/genimage b/support/media/genimage

As shown above, I don;t think you need a wrapper just to create a temp
dir... ;-)

> new file mode 100755
> index 0000000..11c72ec
> --- /dev/null
> +++ b/support/media/genimage
> @@ -0,0 +1,23 @@
> +#!/usr/bin/env bash
> +
> +# We want to catch any unexpected failure, and exit immediately

Except in this case, you'll get leftovers from the temporary directory.

Catch failures with:

    cleanup() {
        local ret=${?}
        [ -z "${GENIMAGE_DIR}" ] || rm -rf "${GENIMAGE_DIR}"
        exit ${ret}
    }
    trap cleanup ERR

> +set -e
> +
> +# Media image generation helper for genimage
> +#
> +# Call it as:
> +#   .../genimage GENIMAGE_CFG
> +
> +GENIMAGE_CFG="${1}"
> +GENIMAGE_DIR="$(mktemp -d output/.genimage.XXXXXXXXXX)"
> +
> +mkdir -p "${GENIMAGE_DIR}"/{root,tmp}
> +
> +"${HOST_DIR}/usr/bin/genimage" \
> +    --rootpath "${GENIMAGE_DIR}/root" \

Why don't you use $(TARGET_DIR) ?

> +    --tmppath "${GENIMAGE_DIR}/tmp" \
> +    --inputpath "${BINARIES_DIR}" \
> +    --outputpath "${BINARIES_DIR}" \
> +    --config "${GENIMAGE_CFG}"
> +
> +rm -rf "${GENIMAGE_DIR}"
> diff --git a/system/Config.in b/system/Config.in
> index 9973cc2..479ac4a 100644
> --- a/system/Config.in
> +++ b/system/Config.in
> @@ -452,4 +452,30 @@ config BR2_ROOTFS_POST_SCRIPT_ARGS
>  	  directory / images directory. The arguments in this option will be
>  	  passed *after* those.
>  
> +config BR2_TARGET_MEDIA_GENIMAGE_CFG
> +	string "genimage config files to prepare media images"
> +	default ""
> +	help
> +	  Specify a space-separated list of configuration files for genimage
> +	  to be run after the build has finished and after Buildroot has
> +	  packed the files into selected filesystem images.
> +
> +	  This can for example be used to generate an SD card image with a
> +	  vfat boot partition and a ext4 rootfs, or a flash image with
> +	  bootloader and kernel at specific offsets.
> +
> +	  genimage is executed from the main Buildroot source directory,
> +	  with input and output paths configured to output/images.
> +
> +	  The genimage documentation is located at:
> +	  http://git.pengutronix.de/?p=genimage.git;a=blob_plain;f=README.
> +
> +config BR2_TARGET_MEDIA_GENIMAGE_HOST_DEPENDENCIES
> +	bool "genimage host dependencies"
> +	default y
> +	depends on BR2_TARGET_MEDIA_GENIMAGE_CFG != ""
> +	select BR2_PACKAGE_HOST_GENIMAGE
> +	select BR2_PACKAGE_HOST_DOSFSTOOLS
> +	select BR2_PACKAGE_HOST_MTOOLS

Why do you force-select dosfstools and mtools? What if the generated
image has no fat partition (like probably a lot of embedded devices)?

Just leave it to the user to make an informed selection of the required
tools.

I've had a quick look at the examples you provide in later patches,
especially the RPi ones. You laways only have a single rootfs partition,
and there is no setup where you'd have (Rpi for example):

    /dev/mmcblk0p1  -->  fat       -->  -
    /dev/mmcblk0p2  -->  squashfs  -->  /
    /dev/mmcblk0p3  -->  ext4      -->  /usr/

You always rely on Buildroot to build the filesystems that get mounted,
which means it is not possible to have a multi-parition setup (and I'm
not talking boot partitions, which are not mounted at all).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/5] Makefile: add media image generation

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu, 19 Mar 2015 01:04:45 +0100, Yann E. MORIN wrote:

> I've had a quick look at the examples you provide in later patches,
> especially the RPi ones. You laways only have a single rootfs partition,
> and there is no setup where you'd have (Rpi for example):
> 
>     /dev/mmcblk0p1  -->  fat       -->  -
>     /dev/mmcblk0p2  -->  squashfs  -->  /
>     /dev/mmcblk0p3  -->  ext4      -->  /usr/

Well, the examples are "defconfig" style examples, so in the spirit of
Buildroot, they should implement the simplest case possible. It's then
up to the user to further refine the configuration to adapt the
filesystem layout to his needs.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/5] Makefile: add media image generation

[Yann E. MORIN]

Thomas, Vivien, All,

On 2015-03-19 09:27 +0100, Thomas Petazzoni spake thusly:
> On Thu, 19 Mar 2015 01:04:45 +0100, Yann E. MORIN wrote:
> > I've had a quick look at the examples you provide in later patches,
> > especially the RPi ones. You laways only have a single rootfs partition,
> > and there is no setup where you'd have (Rpi for example):
> > 
> >     /dev/mmcblk0p1  -->  fat       -->  -
> >     /dev/mmcblk0p2  -->  squashfs  -->  /
> >     /dev/mmcblk0p3  -->  ext4      -->  /usr/
> 
> Well, the examples are "defconfig" style examples, so in the spirit of
> Buildroot, they should implement the simplest case possible. It's then
> up to the user to further refine the configuration to adapt the
> filesystem layout to his needs.

Sorry, I might not have been clear: I think the defconfig are indeed OK.

However, what I wonder about, is that all those defconfigs rely on the
image already generated by Buildroot, and I fail to see how one would
write a mutli-partition genimage config file.

Furthermore, I've read the genimage docs (a mere README, far from being
complete), and it does not look obvious to me.

Also, rather than letting Buildroot build the filesystem images and then
aggregate that with genimage, it would be meuch more interesting (IMHO)
to provide an example that lets genimage do the filesystem. That would
be a good example on how to do it.

Also, in the case of multiple partitions, I wonder how /etc/fstab is
updated (since the current examples only use a pre-generated filesystem
image, they can't update fstab).

It might even be interesting to have an example (e.g. in the manual or
somewhere else...) with a more complex setup, like a multi-partition
setup where parts are inherited from Buildroot (the rootfs) and others
are generated by genimage, or whatever seemingly complex setup we can
come up with...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/5] Makefile: add media image generation

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu, 19 Mar 2015 09:44:35 +0100, Yann E. MORIN wrote:

> However, what I wonder about, is that all those defconfigs rely on the
> image already generated by Buildroot, and I fail to see how one would
> write a mutli-partition genimage config file.
> 
> Furthermore, I've read the genimage docs (a mere README, far from being
> complete), and it does not look obvious to me.
> 
> Also, rather than letting Buildroot build the filesystem images and then
> aggregate that with genimage, it would be meuch more interesting (IMHO)
> to provide an example that lets genimage do the filesystem. That would
> be a good example on how to do it.

Well, the boot.vfat image in the raspberry pi example is a good
illustration of this: the FAT filesystem image is not created by
Buildroot, but by genimage itself.

> Also, in the case of multiple partitions, I wonder how /etc/fstab is
> updated (since the current examples only use a pre-generated filesystem
> image, they can't update fstab).

Using a post-build script ?

> It might even be interesting to have an example (e.g. in the manual or
> somewhere else...) with a more complex setup, like a multi-partition
> setup where parts are inherited from Buildroot (the rootfs) and others
> are generated by genimage, or whatever seemingly complex setup we can
> come up with...

Yes, I agree it would be interesting to have more complicated cases
covered in the Buildroot manual.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1/5] Makefile: add media image generation

[Vivien Didelot]

Hi Yann, Thomas,

> > However, what I wonder about, is that all those defconfigs rely on
> > the image already generated by Buildroot, and I fail to see how one
> > would write a mutli-partition genimage config file.

I don't really get your point, since the defconfigs define the needed
fragment images to create (bootloader, kernel, rootfs types, etc.), then
the related genimage config file uses them to compose a final media
image. You can easily add new partition blocks in this config if you
need to.

Something like this for the Rpi:

    [...]

    image sdcard.img {
      hdimage {
      }

      partition boot {
        partition-type = 0xC
        bootable = "true"
        image = "boot.vfat"
      }

      partition rootfs {
        partition-type = 0x83
        image = "rootfs.ext4"
        size = 512M
      }

      partition data {
        partition-type = 0x83
        size = 2G
      }
    }

Then you have this final image:

$ fdisk -l output/images/sdcard.img 

    Disk output/images/sdcard.img: 522 MiB, 547357184 bytes, 1069057 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0x00000000

    Device                    Boot   Start     End Sectors  Size Id Type
    output/images/sdcard.img1 *          1   20480   20480   10M  c W95 FAT32 (LBA)
    output/images/sdcard.img2        20481 1069056 1048576  512M 83 Linux
    output/images/sdcard.img3      1069057 5263360 4194304    2G 83 Linux

> > Furthermore, I've read the genimage docs (a mere README, far from
> > being complete), and it does not look obvious to me.

I agree, the tool is minimalist, as its documentation. I'm working on
improving it at the same time and already upstreamed some additions to
the readme file.

> > Also, rather than letting Buildroot build the filesystem images and
> > then aggregate that with genimage, it would be meuch more
> > interesting (IMHO) to provide an example that lets genimage do the
> > filesystem. That would be a good example on how to do it.
> 
> Well, the boot.vfat image in the raspberry pi example is a good
> illustration of this: the FAT filesystem image is not created by
> Buildroot, but by genimage itself.

Exactly. Yann, I think I see where you are going, by discussing about
putting genimage as a fs option.

Looks like you see genimage simply as a tool to generate a filesystem
image (e.g., rootfs.ext2). This is possible for sure, but in the case of
Buildroot, genimage would preferably be used as a final composition tool
to create the media image (including all fragments created by
Buildroot), ready to be dumped.

That's why I find confusing to add genimage as a filesystem entry, as
you proposed in patch 1/5, since this naturally comes *after* the
generation of the fragments and the eventual post-image hook.

> > Also, in the case of multiple partitions, I wonder how /etc/fstab is
> > updated (since the current examples only use a pre-generated
> > filesystem image, they can't update fstab).
> 
> Using a post-build script ?

Indeed. Genimage also supports pre and post image hook commands, but I
would prefer to let Buildroot do this kind of customization.

> > It might even be interesting to have an example (e.g. in the manual
> > or somewhere else...) with a more complex setup, like a
> > multi-partition setup where parts are inherited from Buildroot (the
> > rootfs) and others are generated by genimage, or whatever seemingly
> > complex setup we can come up with...
> 
> Yes, I agree it would be interesting to have more complicated cases
> covered in the Buildroot manual.

Sure! For the moment I prefered to add simple genimage config files
which match exactly the setup described in the board readme files, until
we agree on this patchset. Then I'd be willing to add more complex
examples if needed.

Thomas, in the meantime, what do you think about the implementation and
what Yann suggested? Would a top directory "media/" make sense? Let me
know what needs to be changed.

Thanks guys for your time,
-v

[Buildroot] [PATCH 1/5] Makefile: add media image generation

[Yann E. MORIN]

Vivien, Thomas, All,

On 2015-03-19 13:37 -0400, Vivien Didelot spake thusly:
> > > However, what I wonder about, is that all those defconfigs rely on
> > > the image already generated by Buildroot, and I fail to see how one
> > > would write a mutli-partition genimage config file.
> 
> I don't really get your point, since the defconfigs define the needed
> fragment images to create (bootloader, kernel, rootfs types, etc.), then
> the related genimage config file uses them to compose a final media
> image. You can easily add new partition blocks in this config if you
> need to.
> 
> Something like this for the Rpi:
> 
>     [...]
> 
>     image sdcard.img {
>       hdimage {
>       }
> 
>       partition boot {
>         partition-type = 0xC
>         bootable = "true"
>         image = "boot.vfat"
>       }
> 
>       partition rootfs {
>         partition-type = 0x83
>         image = "rootfs.ext4"
>         size = 512M
>       }
> 
>       partition data {
>         partition-type = 0x83
>         size = 2G
>       }
>     }
> 
> Then you have this final image:
> 
> $ fdisk -l output/images/sdcard.img 
> 
>     Disk output/images/sdcard.img: 522 MiB, 547357184 bytes, 1069057 sectors
>     Units: sectors of 1 * 512 = 512 bytes
>     Sector size (logical/physical): 512 bytes / 512 bytes
>     I/O size (minimum/optimal): 512 bytes / 512 bytes
>     Disklabel type: dos
>     Disk identifier: 0x00000000
> 
>     Device                    Boot   Start     End Sectors  Size Id Type
>     output/images/sdcard.img1 *          1   20480   20480   10M  c W95 FAT32 (LBA)
>     output/images/sdcard.img2        20481 1069056 1048576  512M 83 Linux
>     output/images/sdcard.img3      1069057 5263360 4194304    2G 83 Linux

This still raises some questions:

  - you still have a *single* partition with the full system; what if I
    wanted to have /var as a separate partition?

  - how is your 'data' partition formatted? Where is it mounted?

> > > Furthermore, I've read the genimage docs (a mere README, far from
> > > being complete), and it does not look obvious to me.
> 
> I agree, the tool is minimalist, as its documentation. I'm working on
> improving it at the same time and already upstreamed some additions to
> the readme file.

Yes, I saw those patches of yours. That's great! :-)

> > > Also, rather than letting Buildroot build the filesystem images and
> > > then aggregate that with genimage, it would be meuch more
> > > interesting (IMHO) to provide an example that lets genimage do the
> > > filesystem. That would be a good example on how to do it.
> > 
> > Well, the boot.vfat image in the raspberry pi example is a good
> > illustration of this: the FAT filesystem image is not created by
> > Buildroot, but by genimage itself.
> 
> Exactly. Yann, I think I see where you are going, by discussing about
> putting genimage as a fs option.
> 
> Looks like you see genimage simply as a tool to generate a filesystem
> image (e.g., rootfs.ext2). This is possible for sure, but in the case of
> Buildroot, genimage would preferably be used as a final composition tool
> to create the media image (including all fragments created by
> Buildroot), ready to be dumped.

Nah, I think I fully grasp what genimage is for. ;-)

And what you propose is good, but it does not cover all the bases. Last
time we talked about an "aggregation" tool, we cojncluded that either we
do it right, i.e. we cover more than the basics, or we don;t do it at
all.

Note: to be honest, I don't much like genimage all by itself (presonal
preference), and I don't think I'm ready to use it, for already having
my own solution [0]. But I am interested to have a solution included in
Buildroot, and if genimage does the deal, I'm perfectly fine with it.

That's why I'm trying to comment here and see where we're going...


[0] My solution is named genimages (plural!) and basically does the same
thing as genimage does. And last I tried to include that in Buildroot, I
was confronted to many problems, that are not due to genimages itself,
as genimage does have the same problem: once the tarball or the other
filesystem images are generated, we can *not* tweak the content of that.
Hence we can not add new entries in /etc/fstab, and so on... The only
solution is to do it before we build the filesystem images, that is, in
target-finalize.

Hence my genimages implementation is split in two: one script that is
run as post-build and can tweak the target-dir at will, and another
script that is run as post-image and gets its input from rootfs.tar
and generates whatever partitions are configured in an configuration
file (the format is different from the one of genimage, but basically
the same information is provided).

Then, here's an interesting case:
  - initramfs-based system (i.e. the full system in initramfs)
  - a /data partition on a block device

How do you handle that? ;-)

As far as I see, what you propose with genimage has the exact same
issues so far, and is even more constrained in that it can't generate
more than one FS partition for the system, and can't add new entries in
fstab, thus still requiring more than 'just' genimage.

> That's why I find confusing to add genimage as a filesystem entry, as
> you proposed in patch 1/5, since this naturally comes *after* the
> generation of the fragments and the eventual post-image hook.

Well, as we discussed on IRC: in our "filesystems" sub-menu, we have:
  - 9 (real) filesystems: cloop, cramfs, ext, iso, jffs2, romfs,
    squashfs, ubifs, yaffs2
  - 2 archive formats: tar and cpio
  - 1 virtual filesyste: (initramfs

And the initramfs case even already depends on cpio, so having genimage
added in that sub-menu and depend on whatever filesystem is enabled is
also just as much acceptable, I think.

Or better yet: do not depend on *any* filesystem, and let genimage
generate them automatically. I guess something like the follwoing would
work, too:

    image boot.vfat {
      vfat {
        files = {
          "rpi-firmware/bcm2708-rpi-b.dtb",
          "rpi-firmware/bcm2708-rpi-b-plus.dtb",
          "rpi-firmware/bcm2709-rpi-2-b.dtb",
          "rpi-firmware/bootcode.bin",
          "rpi-firmware/config.txt",
          "rpi-firmware/fixup.dat",
          "rpi-firmware/start.elf",
          "zImage"
        }
      }
      size = 10M
    }

    image sdcard.img {
      hdimage {
      }

      partition boot {
        partition-type = 0xC
        bootable = "true"
        image = "boot.vfat"
      }

      partition rootfs {
        partition-type = 0x83
        name = "root"
        ext2 {
        }
        mountpoint = "/"
        size = 512M
      }

      partition data {
        partition-type = 0x83
        name = "root"
        ext4 {
        }
        mountpoint = "/var"
        size = 2G
      }
    }

Does that sound studpid? ;-)

> > > Also, in the case of multiple partitions, I wonder how /etc/fstab is
> > > updated (since the current examples only use a pre-generated
> > > filesystem image, they can't update fstab).
> > 
> > Using a post-build script ?
> 
> Indeed. Genimage also supports pre and post image hook commands, but I
> would prefer to let Buildroot do this kind of customization.

Hmm... I think Thomas was speaking of BR2_ROOTFS_POST_BUILD_SCRIPT.

And if we have to either leave to the user to provide a post-build
script, or provide our own (automatically called when genimage is
enabled) that parses the genimage .cfg file, to tweak fstab, I think
we're missign something.

> > > It might even be interesting to have an example (e.g. in the manual
> > > or somewhere else...) with a more complex setup, like a
> > > multi-partition setup where parts are inherited from Buildroot (the
> > > rootfs) and others are generated by genimage, or whatever seemingly
> > > complex setup we can come up with...
> > 
> > Yes, I agree it would be interesting to have more complicated cases
> > covered in the Buildroot manual.
> 
> Sure! For the moment I prefered to add simple genimage config files
> which match exactly the setup described in the board readme files, until
> we agree on this patchset. Then I'd be willing to add more complex
> examples if needed.

Yes, that's perfectly understandable. Thanks! :-)

Regards,
Yann E. MORIN.

> Thomas, in the meantime, what do you think about the implementation and
> what Yann suggested? Would a top directory "media/" make sense? Let me
> know what needs to be changed.
> 
> Thanks guys for your time,
> -v

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/5] Makefile: add media image generation

[Vivien Didelot]

Hi Yann,

If I understand correctly, you are saying that genimage may not cover
every use cases. And that is totally fine.

With this patchset, I didn't mean to implement in Buildroot the
*ultimate* framework for media image generation, but simply provide an
*optional* and convenient path to the user.

I think we want to provide flexibility and do not dictate a specific
way. Unless I misunderstood the Buildroot way, we want to keep things as
simple and explicit as possible. If the user wants to have a separate
/var mountpoint (*), tweaking the fstab in a post-build script or
injecting a complete one seems perfectly fine to me.

IMHO, some scripts to parse configuration files and update fstab and
such automatically seems complicated and over-engineered to me.

If we want to add more tools in the future, this is very good. Similar
to the actual "Init system" where you can choose between BusyBox,
systemV, etc., you may want to use different composition tools for
different projects.

This might be prematurate for the moment, but we can imagine the
following menu in the future:

    Media image generation  --->
        [*] genimage
        (board/raspberrypi/genimage.cfg) Path to genimage config files
        [ ] genimages ;-)
        [ ] wic


We are using genimage for several projects and we didn't need much so
far. Other people seem to share the same experience.

(*) genimage does have a "mountpoint" option for partitions btw, but I
have not played with it yet.

Thanks,
-v

> > > > However, what I wonder about, is that all those defconfigs rely on
> > > > the image already generated by Buildroot, and I fail to see how one
> > > > would write a mutli-partition genimage config file.
> > 
> > I don't really get your point, since the defconfigs define the needed
> > fragment images to create (bootloader, kernel, rootfs types, etc.), then
> > the related genimage config file uses them to compose a final media
> > image. You can easily add new partition blocks in this config if you
> > need to.
> > 
> > Something like this for the Rpi:
> > 
> >     [...]
> > 
> >     image sdcard.img {
> >       hdimage {
> >       }
> > 
> >       partition boot {
> >         partition-type = 0xC
> >         bootable = "true"
> >         image = "boot.vfat"
> >       }
> > 
> >       partition rootfs {
> >         partition-type = 0x83
> >         image = "rootfs.ext4"
> >         size = 512M
> >       }
> > 
> >       partition data {
> >         partition-type = 0x83
> >         size = 2G
> >       }
> >     }
> > 
> > Then you have this final image:
> > 
> > $ fdisk -l output/images/sdcard.img
> > 
> >     Disk output/images/sdcard.img: 522 MiB, 547357184 bytes, 1069057
> >     sectors
> >     Units: sectors of 1 * 512 = 512 bytes
> >     Sector size (logical/physical): 512 bytes / 512 bytes
> >     I/O size (minimum/optimal): 512 bytes / 512 bytes
> >     Disklabel type: dos
> >     Disk identifier: 0x00000000
> > 
> >     Device                    Boot   Start     End Sectors  Size Id Type
> >     output/images/sdcard.img1 *          1   20480   20480   10M  c W95
> >     FAT32 (LBA)
> >     output/images/sdcard.img2        20481 1069056 1048576  512M 83 Linux
> >     output/images/sdcard.img3      1069057 5263360 4194304    2G 83 Linux
> 
> This still raises some questions:
> 
>   - you still have a *single* partition with the full system; what if I
>     wanted to have /var as a separate partition?
> 
>   - how is your 'data' partition formatted? Where is it mounted?
> 
> > > > Furthermore, I've read the genimage docs (a mere README, far from
> > > > being complete), and it does not look obvious to me.
> > 
> > I agree, the tool is minimalist, as its documentation. I'm working on
> > improving it at the same time and already upstreamed some additions to
> > the readme file.
> 
> Yes, I saw those patches of yours. That's great! :-)
> 
> > > > Also, rather than letting Buildroot build the filesystem images and
> > > > then aggregate that with genimage, it would be meuch more
> > > > interesting (IMHO) to provide an example that lets genimage do the
> > > > filesystem. That would be a good example on how to do it.
> > > 
> > > Well, the boot.vfat image in the raspberry pi example is a good
> > > illustration of this: the FAT filesystem image is not created by
> > > Buildroot, but by genimage itself.
> > 
> > Exactly. Yann, I think I see where you are going, by discussing about
> > putting genimage as a fs option.
> > 
> > Looks like you see genimage simply as a tool to generate a filesystem
> > image (e.g., rootfs.ext2). This is possible for sure, but in the case of
> > Buildroot, genimage would preferably be used as a final composition tool
> > to create the media image (including all fragments created by
> > Buildroot), ready to be dumped.
> 
> Nah, I think I fully grasp what genimage is for. ;-)
> 
> And what you propose is good, but it does not cover all the bases. Last
> time we talked about an "aggregation" tool, we cojncluded that either we
> do it right, i.e. we cover more than the basics, or we don;t do it at
> all.
> 
> Note: to be honest, I don't much like genimage all by itself (presonal
> preference), and I don't think I'm ready to use it, for already having
> my own solution [0]. But I am interested to have a solution included in
> Buildroot, and if genimage does the deal, I'm perfectly fine with it.
> 
> That's why I'm trying to comment here and see where we're going...
> 
> 
> [0] My solution is named genimages (plural!) and basically does the same
> thing as genimage does. And last I tried to include that in Buildroot, I
> was confronted to many problems, that are not due to genimages itself,
> as genimage does have the same problem: once the tarball or the other
> filesystem images are generated, we can *not* tweak the content of that.
> Hence we can not add new entries in /etc/fstab, and so on... The only
> solution is to do it before we build the filesystem images, that is, in
> target-finalize.
> 
> Hence my genimages implementation is split in two: one script that is
> run as post-build and can tweak the target-dir at will, and another
> script that is run as post-image and gets its input from rootfs.tar
> and generates whatever partitions are configured in an configuration
> file (the format is different from the one of genimage, but basically
> the same information is provided).
> 
> Then, here's an interesting case:
>   - initramfs-based system (i.e. the full system in initramfs)
>   - a /data partition on a block device
> 
> How do you handle that? ;-)
> 
> As far as I see, what you propose with genimage has the exact same
> issues so far, and is even more constrained in that it can't generate
> more than one FS partition for the system, and can't add new entries in
> fstab, thus still requiring more than 'just' genimage.
> 
> > That's why I find confusing to add genimage as a filesystem entry, as
> > you proposed in patch 1/5, since this naturally comes *after* the
> > generation of the fragments and the eventual post-image hook.
> 
> Well, as we discussed on IRC: in our "filesystems" sub-menu, we have:
>   - 9 (real) filesystems: cloop, cramfs, ext, iso, jffs2, romfs,
>     squashfs, ubifs, yaffs2
>   - 2 archive formats: tar and cpio
>   - 1 virtual filesyste: (initramfs
> 
> And the initramfs case even already depends on cpio, so having genimage
> added in that sub-menu and depend on whatever filesystem is enabled is
> also just as much acceptable, I think.
> 
> Or better yet: do not depend on *any* filesystem, and let genimage
> generate them automatically. I guess something like the follwoing would
> work, too:
> 
>     image boot.vfat {
>       vfat {
>         files = {
>           "rpi-firmware/bcm2708-rpi-b.dtb",
>           "rpi-firmware/bcm2708-rpi-b-plus.dtb",
>           "rpi-firmware/bcm2709-rpi-2-b.dtb",
>           "rpi-firmware/bootcode.bin",
>           "rpi-firmware/config.txt",
>           "rpi-firmware/fixup.dat",
>           "rpi-firmware/start.elf",
>           "zImage"
>         }
>       }
>       size = 10M
>     }
> 
>     image sdcard.img {
>       hdimage {
>       }
> 
>       partition boot {
>         partition-type = 0xC
>         bootable = "true"
>         image = "boot.vfat"
>       }
> 
>       partition rootfs {
>         partition-type = 0x83
>         name = "root"
>         ext2 {
>         }
>         mountpoint = "/"
>         size = 512M
>       }
> 
>       partition data {
>         partition-type = 0x83
>         name = "root"
>         ext4 {
>         }
>         mountpoint = "/var"
>         size = 2G
>       }
>     }
> 
> Does that sound studpid? ;-)
> 
> > > > Also, in the case of multiple partitions, I wonder how /etc/fstab is
> > > > updated (since the current examples only use a pre-generated
> > > > filesystem image, they can't update fstab).
> > > 
> > > Using a post-build script ?
> > 
> > Indeed. Genimage also supports pre and post image hook commands, but I
> > would prefer to let Buildroot do this kind of customization.
> 
> Hmm... I think Thomas was speaking of BR2_ROOTFS_POST_BUILD_SCRIPT.
> 
> And if we have to either leave to the user to provide a post-build
> script, or provide our own (automatically called when genimage is
> enabled) that parses the genimage .cfg file, to tweak fstab, I think
> we're missign something.
> 
> > > > It might even be interesting to have an example (e.g. in the manual
> > > > or somewhere else...) with a more complex setup, like a
> > > > multi-partition setup where parts are inherited from Buildroot (the
> > > > rootfs) and others are generated by genimage, or whatever seemingly
> > > > complex setup we can come up with...
> > > 
> > > Yes, I agree it would be interesting to have more complicated cases
> > > covered in the Buildroot manual.
> > 
> > Sure! For the moment I prefered to add simple genimage config files
> > which match exactly the setup described in the board readme files, until
> > we agree on this patchset. Then I'd be willing to add more complex
> > examples if needed.
> 
> Yes, that's perfectly understandable. Thanks! :-)
> 
> Regards,
> Yann E. MORIN.
> 
> > Thomas, in the meantime, what do you think about the implementation and
> > what Yann suggested? Would a top directory "media/" make sense? Let me
> > know what needs to be changed.

[Buildroot] [PATCH 1/5] Makefile: add media image generation

[Arnout Vandecappelle]

On 19/03/15 01:04, Yann E. MORIN wrote:
> As discussed on IRC, I wonder why you need to add a new target in the
> top-level Makefile, rather than re-use the filesystem infra. something
> like:
> 
> fs/Config.in
> 
>     # Existing filesystems, up to:
>     source "fs/yaffs2/Config.in"
>     commet "Aggregate filesystems"  # Or whatever prompt that has meaning
>     source "fs/genimage/Config.in"
> 
> 
> fs/genimage/Config.in
> 
>     config BR2_TARGET_ROOTFS_GENIMAGE
>         bool "genimage"
>         select BR2_PACKAGE_HOST_GENIMAGE
> 
>     config BR2_TARGET_ROOTFS_GENIMAGE_CFG
>         string "path to genimage config files"
>         depends on BR2_TARGET_ROOTFS_GENIMAGE
> 
> 
> fs/genimge/genimage.mk
> 
>     ROOTFS_GENIMAGE_DEPENDENCIES = host-genimage
>     ROOTFS_GENIMAGE_DEPENDENCIES += $(if $(BR2_TARGET_ROOTFS_EXT2),rootfs-ext2)
>     ROOTFS_GENIMAGE_DEPENDENCIES += $(if $(BR2_TARGET_ROOTFS_SQUASHFS),rootfs-squashfs)
>     # And so on...
> 
>     define ROOTFS_GENIMAGE_CMD
>         $(foreach cfg,$(call qstrip,$(BR2_TARGET_ROOTFS_GENIMAGE_CFG)),\
>             TMPDIR="$$(mktemp -d $(BUILD_DIR)/.genimage.XXXXXXXXXX)" || exit 1; \
>             $(INSTALL) -d -m 0755 $${TMPDIR}/{root,tmp} || exit 1; \
>             $(EXTRA_ENV) $(HOST_DIR)/usr/bin/genimage \
>                 --rootpath $(TARGET_DIR) \
>                 --tmppath $${RMPDIR}/tmp \
>                 --inputpath $(BIANRIES_DIR) \
>                 --outputpath $(BIANRIES_DIR) \
>                 --config $(cfg) || exit 1; \
>             rm -rf $${TMPDIR} || exit 1$(sep))
>     endef
> 
> 
> And then there's no need to add another top-level Makefile rule.

 But this approach looks more complicated, and if a new fs target is added the
genimage thing also has to be updated... So I'm more in favour of the original
proposal.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 1/5] Makefile: add media image generation

[Arnout Vandecappelle]

On 19/03/15 21:31, Vivien Didelot wrote:
> Hi Yann,
> 
> If I understand correctly, you are saying that genimage may not cover
> every use cases. And that is totally fine.
> 
> With this patchset, I didn't mean to implement in Buildroot the
> *ultimate* framework for media image generation, but simply provide an
> *optional* and convenient path to the user.

 I completely agree with this statement. And I think that was also the
conclusion from the genimages patch series: it's nice to have something that
allows you to generate an SD card image, but not at the cost of adding too much
complexity to buildroot.

 However...

[snip]
> If we want to add more tools in the future, this is very good. Similar
> to the actual "Init system" where you can choose between BusyBox,
> systemV, etc., you may want to use different composition tools for
> different projects.

 Here I disagree, I see no reason to support more than one image generation
system. It's not something that ends up on the target, it's just part of the
build process, so just an implementation detail. It would be like offering the
choice between fakeroot or fakeroot-ng...

 We _may_ choose to switch to a different media generation system in the future,
but that's a different story.


 Regards,
 Arnout

> 
> This might be prematurate for the moment, but we can imagine the
> following menu in the future:
> 
>     Media image generation  --->
>         [*] genimage
>         (board/raspberrypi/genimage.cfg) Path to genimage config files
>         [ ] genimages ;-)
>         [ ] wic
> 
> 
> We are using genimage for several projects and we didn't need much so
> far. Other people seem to share the same experience.
> 
> (*) genimage does have a "mountpoint" option for partitions btw, but I
> have not played with it yet.
> 
> Thanks,
> -v
[snip]


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 0/5] media image generation

[Arnout Vandecappelle]

 Hi Vivien,

On 17/03/15 23:51, Vivien Didelot wrote:
> This patchset adds a minimal support to generate final images for a medium
> (such as SD card or flash), by providing paths to some genimage config files in
> a board directory.

 I agree with this idea, but I think the proposed implementation is still a bit
too ambitious.


> The rationale behind using genimage as the first medium image generation tool,
> is that while its configuration syntax is simple, it requires a small overhead
> to use, like temporary directories, host dependencies, and images path, that
> Buildroot is all aware of.
> 
> The first patch explains the convenience of this host tool, and adds the
> mechanism to wrap and call genimage against optional config file(s) specified
> in the board configuration, as well as the appropriate documentation.
> 
> The subsequent patches adds genimage config files for the following platforms:
> all Raspberry Pi models, BeagleBone Black, and the Wandboard.

 I think this would be the first thing to do: add genimage config files for
these boards, and use them in their respective post-build script.

 Then we can see if adding infrastructure to further support it is worthwhile. A
less invasive second step could be to put a genimage wrapper script in
support/scripts so that you don't need a new copy for every board.


> They give good examples to show how Buildroot can be used to create a fully
> functional SD card image with a bootloader, some firmware files and a
> persistent rootfs, without the need to mount any partition.
> 
> Finally, this support simplifies the user experience by providing ready-to-use
> boot medium images, and lightening board documentation with self documented
> configuration files.

 As part of that plan, I would remove the documentation from the readme (just
keep the reference to the website that explains it), and instead move it to the
configuration file.

> 
> Note: if we happen to include other media image generation tools, the
> BR2_TARGET_MEDIA_GENIMAGE_CFG and future options can then simply be moved to a
> "Media image generation --->" top-level menu.
> 
> Vivien Didelot (5):
>   Makefile: add media image generation
>   board/raspberrypi: install Device Tree
>   board/raspberrypi: add a genimage config
>   board/beaglebone: add a genimage config
>   board/wandboard: add a genimage config
> 
>  Makefile                              |  9 +++++++--
>  board/beaglebone/genimage.cfg         | 30 +++++++++++++++++++++++++++++
>  board/beaglebone/readme.txt           |  4 ++++
>  board/raspberrypi/genimage.cfg        | 32 +++++++++++++++++++++++++++++++
>  board/raspberrypi/post-image.sh       |  7 +++++++
>  board/raspberrypi/readme.txt          |  9 +++++++--
>  board/wandboard/genimage.cfg          | 22 +++++++++++++++++++++
>  board/wandboard/readme.txt            |  3 ++-
>  configs/beaglebone_defconfig          |  3 +++
>  configs/raspberrypi2_defconfig        |  6 ++++++
>  configs/raspberrypi_defconfig         |  5 +++++
>  configs/raspberrypi_dt_defconfig      |  6 ++++++
>  configs/wandboard_defconfig           |  1 +
>  docs/manual/customize-media-image.txt | 36 +++++++++++++++++++++++++++++++++++
>  docs/manual/customize.txt             |  4 ++++
>  support/media/genimage                | 23 ++++++++++++++++++++++
>  system/Config.in                      | 26 +++++++++++++++++++++++++
>  17 files changed, 221 insertions(+), 5 deletions(-)

 This diffstat speaks for itself: it's adding 220 lines of complexity :-)

 Regards,
 Arnout

>  create mode 100644 board/beaglebone/genimage.cfg
>  create mode 100644 board/raspberrypi/genimage.cfg
>  create mode 100755 board/raspberrypi/post-image.sh
>  create mode 100644 board/wandboard/genimage.cfg
>  create mode 100644 docs/manual/customize-media-image.txt
>  create mode 100755 support/media/genimage
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 0/5] media image generation

[Vivien Didelot]

Hi Arnout,

> > This patchset adds a minimal support to generate final images for a
> > medium (such as SD card or flash), by providing paths to some
> > genimage config files in a board directory.
> 
>  I agree with this idea, but I think the proposed implementation is
>  still a bit too ambitious.
> 
> 
> > The rationale behind using genimage as the first medium image
> > generation tool, is that while its configuration syntax is simple,
> > it requires a small overhead to use, like temporary directories,
> > host dependencies, and images path, that Buildroot is all aware of.
> > 
> > The first patch explains the convenience of this host tool, and adds
> > the mechanism to wrap and call genimage against optional config
> > file(s) specified in the board configuration, as well as the
> > appropriate documentation.
> > 
> > The subsequent patches adds genimage config files for the following
> > platforms: all Raspberry Pi models, BeagleBone Black, and the
> > Wandboard.
> 
>  I think this would be the first thing to do: add genimage config
>  files for these boards, and use them in their respective post-build
>  script.
> 
>  Then we can see if adding infrastructure to further support it is
>  worthwhile. A less invasive second step could be to put a genimage
>  wrapper script in support/scripts so that you don't need a new copy
>  for every board.
> 
> > They give good examples to show how Buildroot can be used to create
> > a fully functional SD card image with a bootloader, some firmware
> > files and a persistent rootfs, without the need to mount any
> > partition.
> > 
> > Finally, this support simplifies the user experience by providing
> > ready-to-use boot medium images, and lightening board documentation
> > with self documented configuration files.
> 
>  As part of that plan, I would remove the documentation from the
>  readme (just keep the reference to the website that explains it), and
>  instead move it to the configuration file.

I totally agree with your approach. I'll start the other way around with
one or two boards then we'll see how it goes. As long as the boards 
documentation and support are simplified, I'm happy :-)

Best,
-v