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
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
