Re: Emdebian sprint - flash-kernel discussion
On 02/22/2011 09:54 PM, Somebody in the thread at some point said:
I ask mostly from a position of ignorance, but is the information in
this database related to the information linaro-media-create keeps about
each board? If so, could it be shared somehow?
It's completely related and I envisioned we could share it some time
even before linaro-image-tools existed ;-)
But thanks for bringing this up, it's a good thing to put on the goals
for the rework: that the data be usage-agnostic and self-contained as
to allow reuse in other places.
Since we discuss this later today going to throw my thoughts out there.
Over the longer term I think it could be possible to arrange things that
- hwpacks as they are
- initrds, and
- Qemu requirement for image composition, maybe whole l-m-c
could in most or all cases be dispensed with. In that situation l-m-c
itself would ideally disappear into composition-host-runnable scripts
down /etc/board-specific.d or /usr/share/whatever.d for hosts that have
a concept of external bootloader and / or kernel composition (ie, not
shoving it in local NAND but SD card). So, at what used to be l-m-c
time you run on the composition host the same scripts that the native
device uses for bootloader and kernel install from the composed rootfs
itself, with suitable abstraction of device names and so on.
Any scripting config left from kernel package install could be batched
and deferred until first boot where it runs natively.
Another kinda-related simplification that would pay dividends is to
enable taking advantage of multi-board kernels within the same arch that
are possible, by having the same deal in terms of multi-board
bootloaders within the same arch. Currently X-loader and U-Boot take a
compile-time config approach that forces them to emit ultra-specific
If that was fixed then it'd be possible to have, eg, a single Omap4
kernel package and a single Omap4 bootloader package that worked on all
supported Omap4 boards and so on.