On Thu, May 03, 2012 at 05:57:41PM -0400, Bruce Ashfield wrote: > 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.
Bruce, I'd be willing to start using config fragments for our kernels in meta-ti, when this feature is not tightly bundled with linux-yocto kernel. While we might want to eventually start using the entire linux-yocto framework for our kernels, it may take longer time due to many internal constraints. And having config fragments available as a separate feature would be very helpful and enable us to take baby steps... :) That's what we discussed last month at the Yocto BSP Summit. Thanks. -- Denys _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
