[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Emdebian sprint - flash-kernel discussion

On 02/22/2011 09:54 PM, Somebody in the thread at some point said:

Hi -


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
  ago:
   http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg00254.html
  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 bootloader binaries.
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. 

-Andy
Reply to: