Hey 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 \ uImage-linaro 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 images 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! :-) Cheers -- Loïc Minier _______________________________________________ linaro-dev mailing list firstname.lastname@example.org http://lists.linaro.org/mailman/listinfo/linaro-dev