This page collects idea on a rework of the flash-kernel package.
Move to being data-driven and move data out of the script
Currently flash-kernel hardcodes the u-boot load address or simply the name of the supported boards and many other things. Instead, it should read board data from a database as to avoid mixing code with data.
Because flash-kernel can brick your device, it should be well tested. It currently doesn't have any kind of testsuite.
SD card support
Many modern ARM boards boot from SD, sometimes only from SD; it would be helpful to support this as a boot method.
Device Tree support
Device Tree is getting increasingly important for ARM boards, and requires installation of an additional .dtb file.
Sometimes, it's important to upgrade the bootloader (e.g. to add Device Tree support or to fix the bootloader early init code to setup the hardware properly); it would be nice if flash-kernel would provide a way to do that.
This idea was dismissed as that's too large a job for flash-kernel which has enough hats already; this should be implemented in a separate tool on top of the same board data information.
Allow creating bootable image
flash-kernel knows a lot about how boards boot; it would be useful if it would just take kernel + initrd + rootfs as input and write a bootable image as an output; this could be used from debian-cd, the debian-installer package etc.
Notes from Emdebian Sprint 2011/02/23
The topic of flash-kernel was brough up at the Emdebian Sprint in Cambridge on 2011/02/23.
The above ideas were discussed; the discussion covered a lot of ground, including d-i support for installation to flash, support for alternate bootloaders (RedBoot, U-Boot, but also Qi, and perhaps UEFI in the future, or simply Linux as the bootloader).
Everybody agreed that the code needed cleaning up and that the data would better be split out.
It turned out that there were many places where the data which flash-kernel currently holds might be useful; so not only should flash-kernel split board data out into separate files, it might even make sense to move this data to some shared source package, "board-data" for instance.
The data should be versioned, and should be usage-agnostic; it should come with sufficient documentation as to allow proper use in multiple places.