There are a bunch of places where we generate uImages and which
 duplicate information.

 a kernel build most commonly outputs a zImage; this is then converted
 to an uImage for u-boot consumption with some rune like:
    mkimage -A arm -O linux -T kernel -C none \
        -a 0x80008000 -e 0x80008000 -n Linux \
        -d vmlinuz-2.6.35-1001-omap \

 Linaro's platform wants to output media for various boards, probably as
 a single rootfs + separate boot bits for each SoC, but probably as
 multiple [ rootfs + boot bits ] for now.

 I'd also like to setup daily kernel builds where people can directly
 grab uImages for testing.

 Linaro's platform provides .debs with zImage which get converted to an
 updated uImage at upgrade time (and get flashed when that makes sense).

 So there are already three places where this data is relevant:
 a) daily kernel builds
 b) live-helper image builds
 c) flash-kernel helper for kernel upgrade

 Finally, there are two other places in the .deb ecosystem where this
 data is also copied: in debian-installer (both in Debian and Ubuntu),
 and in debian-cd (mostly in Ubuntu, but applies to Debian).
 d) debian-installer is a package in charge of collecting the bootloader
    and kernel pieces and generating installation media such as netboot
    files which contain the installer
 e) debian-cd is standalone software to create installation media such
    as ISOs or SD card images
 These two pieces are not used by Linaro right now, but it makes sense
 to try to come up with a solution which is usable by these pieces too.

 So there is way too much duplication of this data; there are some
 duplications we could possibly avoid, for instance we could try calling
 flash-kernel's logic from live-helper, but it's not really a good
 approach for the debian-installer build, debian-cd, or the daily kernel
 builds.  flash-kernel currently relies on being run on the target
 because it pokes /proc/cpuinfo, /proc/mtd and /dev/mtdblock*, or in
 Ubuntu the boot SD card; it's a "host install", not an installation
 towards a target.

 We want a solution which is usable from a x86 build host to create an
 ARM image (daily kernel builds, debian-cd).

 I see two ways to approach this problem:
 - data driven: we have data files for each board which document the
   addresses to pass to mkimage; all interested software parses the data
   and uses it to generate images
 - scripts: we have scripts for each board to do any board specific
   stuff; all interested software calls into the scripts to generate

 I think what would likely work is a combination of the two.  We should
 have generic "task" scripts ("I want to generate a bootloader kernel
 image from a zImage"), and board-specific scripts for board-specific
 logic -- I think we don't really need board-specific scripts for Linaro
 because we try to unify all platforms to the same boot interface, but
 in practice it will be needed for other architectures and we can only
 get wide acceptance of such a replacement if we support more than just
 u-boot.  This should all be backed by plain simple data files as much
 as possible so that extending support to one more board can often be
 done by dropping a data file in a directory.

 So what kind of operations do we want to be able to do?

 * generate an u-boot kernel image from a zImage
   - input: zImage, kernel load address
   - output: uImage
 * generate an u-boot initrd image from an initrd.gz
   - input: initrd.gz, initrd load address
   - output: uInitrd
 * generate a mostly boilerplate u-boot boot script with specific
   cmdline opts
   - input: cmdline opts, script load address
   - output: boot.cmd

 I wonder whether we want to wrap other operations such as:
 * writing the kernel/initrd/script to flash or to a specific partition
   according to config
 * creation of boot media (partition table, vfat etc.)
 * other bootloaders

 Comments welcome!  Other use cases, existing software, whatever!  :-)

Loïc Minier

linaro-dev mailing list

Reply via email to