[oe] Building a rootfs, without building a kernel

Ben Lau xbenlau at gmail.com
Wed Jul 2 07:36:26 UTC 2008


On Wed, Jul 2, 2008 at 2:14 AM, Philip Balister <philip at balister.org> wrote:
> David Baird wrote:
>>
>> 2008/6/24 Philip Balister <philip at balister.org>:
>>>
>>> I am trying to build a powerpc root file system for a xilinx ml403 board.
>>> Since we do not have a working kernel build for this machine, I tried
>>> commenting out the PREFERRED_PROVIDER for virtual/linux. The build then
>>> tries to build linux-rt. I tried ASSUME_PROVIDED for the kernel when the
>>> preferred provider is not commented out and it still tries to build the
>>> kernel.
>>>
>>> Looking at the dependency graphs seems to suggest the requirement comes
>>> from
>>> the do_rootfs task.
>>>
>>> Does anyone know how to build an image, without building a kernel for a
>>> machine?
>>
>> I have been using this pattern in my BBMASK:
>>
>>    BBMASK = "(linux-ml403-slab-2.6.x_git[.].*)"
>>
>> and then I made up my own task and image .bb files to establish what
>> files I want in my rootfs.  I would also appreciate suggestions on a
>> better way to do what to do this.
>
> I pushed changes to linux-ml403-slab (I think I renamed the recipe
> linux-xilinx-slab) so the compile completes. I don't do anything to prepare
> the kernel for actual use. This lets the images build. When I finally figure
> out how to build kernels for Xilinx FPGA based PPC boards, I'll worry about
> creating a bootable kernel. (Unless someone beats me to it)
>
> Possibly, we should create a dummy kernel bb file since this may be the best
> solution for the general case of people building images without a working
> kernel bb file.
>
> Philip
>

I am not quite understand why OpenEmbedded force to generate kernel
and the dependence would force it to be installed in the user land. As
the kernel is usually installed on another partition. It should not be
a part of the file system image.

Therefore, I usually comment out few lines in task-base and task-boot
to avoid the dependence.




More information about the Openembedded-devel mailing list