[oe] Building a kernel with builtin initramfs

Paul Sokolovsky pmiscml at gmail.com
Fri Feb 15 09:02:30 UTC 2008


Hello,

On Thu, 14 Feb 2008 11:55:28 +0100
"pHilipp Zabel" <philipp.zabel at gmail.com> wrote:

> 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.

Ok, this is not going to work due to timestamps.

> >
> >  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.

Well, that's of course how I started. So, in kernel.bbclass I have

do_compile_modules ()
addtask compile_modules after do_patch

do_install_modules()
addtask install_modules after do_compile_modules

That works, but that's where I stopped: how to package just modules -
fork whole packaging class(es) like compile/install tasks forked above?

> Can we have conditional inter-task dependencies in bitbake recipes?

There're apparently many things bitbake can't, and is not going to do.
For example, running subset of tasks in different context. Consider for
example the fact that initramfs built for glibc-compiled kernel should
be built using uclibc, etc, etc. Recursive invocation is a kinda
meta-solution for such issues, modulo different constraints it
brings ;-). Nontheless, it works - I committed
initrdscripts/initramfs-image-ipk_1.0.bb yesterday.

> 
> regards
> Philipp
> 



-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com




More information about the Openembedded-devel mailing list