On Fri, Aug 23, 2013 at 2:56 PM, Jason Wessel <jason.wes...@windriver.com> wrote: > On 08/23/2013 01:16 AM, Khem Raj wrote: >> On Thu, Aug 22, 2013 at 4:04 PM, Jason Wessel >> <jason.wes...@windriver.com> wrote: >>> This patch aims to fix the following two cases for the INITRAMFS generation. >>> 1) Allow an image recipe to specify a paired INITRAMFS recipe such >>> as core-image-minimal-initramfs. This allows building a base >>> image which always generates the needed initramfs image in one step >>> 2) Allow building a single binary which contains a kernel and >>> the initramfs. >> I think this could be a bit simpler. Have a full kernel image recipe ( >> kernel + initramfs) >> separate. It fits into the equation nicely. The final image can bundle >> initramfs which has modules from practically same kernel build is >> staged step 1 of kernel build which >> automatically happens today for any image build. > > The changes I put together are work around the circular dependency problem. > Staging and using another recipe is certainly an option. > > What I really wanted to do was have just another image type not unlike cpio, > ext3, etc... But this was not possible because there was no way to get back > to the point that the kernel could be re-linked and make the call to the > kernel methods and get the context correct. I had tried using the internal > method for exec_task from the image recipe context but there appeared to be > no direct way to get this to work. > > > > >> >> The new recipe for kernel+initramfs requires the existing kernel >> recipes and tweaks the .config to enable INITRAMFS_IMAGE >> >> You can share the sources for both stages where kernel is built like >> gcc is putting the sources under work-shared and building all gcc >> recipes out of this location. > > > Ideally we could use the sysroot to regenerate the combined image, but this > was not low hanging fruit. If we came up with a way to generate the combined > kernel+initramfs image directly from the sysroot this could easily be > controlled by just having it as an IMAGE_FEATURE as opposed to making > distinct image types. > > > Jason. > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core
Some more thoughts: I'd like to point out that we introduced a variable called INITRAMFS_FSTYPES http://cgit.openembedded.org/openembedded-core/commit/meta/conf/bitbake.conf?id=17f7f3a43e863d9e2a16dd02face5137a4f4b225 and that we have an initial initramfs framework (modular, similar to the one in oe-classic) : http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/initrdscripts?id=7b69ad2167a1f0e57db82817b98a0cbcb70a0dd3 Maybe this framework could be extended for the typical simple needs ( I know our linux-yocto-tiny-kexecboot is a rather complicated example). Cheers Andrea _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
