[oe] Building a kernel with builtin initramfs

pHilipp Zabel philipp.zabel at gmail.com
Thu Feb 14 10:55:28 UTC 2008


On Thu, Feb 14, 2008 at 3:54 AM, Paul Sokolovsky <pmiscml at gmail.com> wrote:
> Hello,
>
>  Sometimes, it may be necessary to have a kernel with builtin initramfs.
>  Initramfs commonly kernel modules, so we have kernel build recursion.
>  Standard way to break this loop is to split procedure causing recursion
>  into independent steps, so we'd first build kernel modules, then build
>  initramfs, then build a kernel image.
>
>  The question, is how to express this with bitbake and OE. Skipping
>  various ideas, here's the one which promise viability:
>
>  1. Have a kernel-modules.bb, which will execute bitbake recursively to
>  build a PREFERRED_PROVIDER_virtual/kernel, and will pass a special flag
>  variable.
>
>  2. Detecting that flag, kernel.bbclass will build/package only modules.
>
>  3. Then, have a kernel-initramfs.bb (DEPENDS=kernel-modules) which will
>  take a variable defining which initramfs image to build, if any, and
>  execute bitbake recursively with IMAGE_FSTYPES=cpio.gz on that.
>
>  4. Make a task in kernel.bbclass depend on kernel-initramfs.bb (build
>  task of it).
>
>
>  Again, that appears to be something working, at least from 1st look.
>  However, it introduces new trick - recursive execution of bitbake,
>  what, as far as I know, never happened so far. Well, for "make" such
>  usage is commodity, and the fact that it is required 2 times in the
>  above scenario show that it is useful ;-).
>
>
>  Other ideas?

Split the module generation out of the main compile/install/package
tasks in kernel.bbclass and have kernel-initrmfs.bb's do_initramfs
depend on that.
Can we have conditional inter-task dependencies in bitbake recipes?

regards
Philipp




More information about the Openembedded-devel mailing list