From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Elvis Dowson <elvis.dowson@gmail.com>
Cc: Yocto Discussion Mailing List <yocto@yoctoproject.org>
Subject: Re: How to specify a machine defconfig for a linux recipe
Date: Thu, 3 May 2012 17:57:41 -0400 [thread overview]
Message-ID: <4FA2FF55.3010202@windriver.com> (raw)
In-Reply-To: <E6B74C60-DDCA-4C71-BE97-3DFF81257C34@gmail.com>
On 12-05-03 05:42 PM, Elvis Dowson wrote:
> Hi,
>
> On May 3, 2012, at 9:55 PM, Elvis Dowson wrote:
>
>> How can I specify a machine defconfig for a linux recipe?
>>
>> For example, if I set
>>
>> # kernel provider
>> PREFERRED_PROVIDER_virtual/kernel = "linux-omap3"
>>
>> and try to build my machine, I get the following errors:
>>
>> ERROR: Function failed: Fetcher failure for URL: 'file://defconfig'. Unable to fetch URL from any source.
>> NOTE: package linux-omap3-3.2-r0: task do_fetch: Failed
>> ERROR: Task 125 (/tool/yocto/meta-gumstix/recipes-kernel/linux/linux-omap3_3.2.bb, do_fetch) failed with exit code '1'
>> NOTE: Tasks Summary: Attempted 304 tasks of which 302 didn't need to be rerun and 1 failed.
>>
>> Summary: 1 task failed:
>> /tool/yocto/meta-gumstix/recipes-kernel/linux/linux-omap3_3.2.bb, do_fetch
>
> I solved this one.
>
> Turns out, since I defined a new machine called overo-fire-chestnut43, I had to also create a folder called overo-fire-chestnut43 to hold the defconfig file as follows:
>
> meta-gumstix/recipes-kernel/linux/linux-omap3/overo-fire-chestnut43/defconfig
>
> I recall, the trend was to move away from user supplied defconfigs, and have it get generated automatically by the build process, and then specify some hints. Is there any example of how I can modify the existing meta-gumstix or any other meta-layer, to get the defconfig to get generated automatically?
Are you thinking about the linux-yocto config fragment support ?
Or maybe something else ? If you were thinking about the fragments,
it would only replace your defconfigs directly when you use a linux-yocto
kernel tree (and it's included meta branch with configuration frags).
In that scenario, you only put your board specific fragments on the end,
and let the rest be constructed.
When I return home next week, I will have some patches for 1.3 that make
the fragments apply more easily to any git repository, but in either
case (1.2 or 1.3), you'd still need to build up a series of fragments
outside the tree, or migrate to linux-yocto* for maxium re-use.
Cheers,
Bruce
>
> Best regards,
>
> Elvis Dowson
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
next prev parent reply other threads:[~2012-05-03 21:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-03 19:55 How to specify a machine defconfig for a linux recipe Elvis Dowson
2012-05-03 21:42 ` Elvis Dowson
2012-05-03 21:57 ` Bruce Ashfield [this message]
2012-05-03 22:03 ` Denys Dmytriyenko
2012-05-03 22:09 ` Bruce Ashfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FA2FF55.3010202@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=elvis.dowson@gmail.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.