[yocto] Custom defconfig is not used
Diego Sueiro
diego.sueiro at gmail.com
Thu Nov 28 07:37:03 PST 2013
Bruce,
Any updates on this?
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
On Mon, Nov 4, 2013 at 1:14 AM, Bruce Ashfield <bruce.ashfield at windriver.com
> wrote:
> On 13-10-29 11:31 AM, Diego Sueiro wrote:
>
>> Bruce,
>>
>> I've created new build setup with this configuration:
>>
>> BB_VERSION = "1.18.0"
>> BUILD_SYS = "x86_64-linux"
>> NATIVELSBSTRING = "Ubuntu-12.10"
>> TARGET_SYS = "arm-poky-linux-gnueabi"
>> MACHINE = "beaglebone"
>> DISTRO = "poky"
>> DISTRO_VERSION = "1.4.2"
>> TUNE_FEATURES = "armv7a vfp neon"
>> TARGET_FPU = "vfp-neon"
>> meta
>> meta-yocto
>> meta-yocto-bsp = "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
>> meta-oe = "dylan:a108b2203a997634f87ac687e81712badaf3c546"
>> common-bsp = "dylan:7fdf9c670a10c5031a2d5555c15c45e453de8c21"
>> meta-mine = "dylan:4e399f08d596197859214fdb3b06403b87bf8789"
>>
>> common-bsp comes from meta-beagleboard.
>> meta-oe needed to be added because of machine_kernel_pr.bbclass.
>>
>> bblayers.conf:
>>
>> LCONF_VERSION = "6"
>> BBPATH = "${TOPDIR}"
>> BBFILES ?= ""
>> BBLAYERS ?= " \
>> ${TOPDIR}/meta \
>> ${TOPDIR}/meta-yocto \
>> ${TOPDIR}/meta-yocto-bsp \
>> ${TOPDIR}/meta-openembedded/meta-oe \
>> ${TOPDIR}/meta-beagleboard/common-bsp \
>> ${TOPDIR}/meta-mine \
>> "
>>
>> meta-mine:
>>
>> conf/layer.conf:
>>
>> BBPATH .= ":${LAYERDIR}"
>> BBFILES += "${LAYERDIR}/recipes*/*/*.bb
>> ${LAYERDIR}/recipes*/*/*.bbappend"
>> BBFILE_COLLECTIONS += "my-layer"
>> BBFILE_PATTERN_my-layer := "^${LAYERDIR}/"
>> BBFILE_PRIORITY_my-layer = "10"
>>
>> recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 1):
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
>> COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
>> SRC_URI += " file://defconfig \
>> "
>>
>> recipes-kernel/linux/linux-mainline-3.8/defconfig (scenario 1):
>>
>> http://pastebin.com/qd8B3C5K
>>
>>
>> recipes-kernel/linux/linux-mainline_3.8.bbappend (scenario 2):
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.8:"
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>> COMPATIBLE_MACHINE_beaglebone = "(beaglebone)"
>> SRC_URI += " file://config-addons.cfg \
>> "
>>
>> recipes-kernel/linux/linux-mainline-3.8/config-addons.cfg (scenario
>> 2):
>>
>> CONFIG_WATCHDOG_NOWAYOUT=y
>>
>> CONFIG_NTFS_FS=y
>> CONFIG_NTFS_RW=y
>>
>>
>>
>> Results:
>>
>> * Scenario 1: Full defconfig replacement
>>
>>
>> ${WORKDIR}/defconfig comes from meta-beagleboard instead of meta-mine
>>
>> ${S}/.config comes from meta-beagleboard instead of meta-mine
>>
>
> FYI: I went silent on this, since I was running a few experiments in the
> background. Mainly on scenario 2, but I can say that I see the same
> behaviour
> with scenario #1 as you do. Whether or not I use the yocto kernel tooling,
> or the core kernel processing, I see exactly the same defconfig used.
>
> The issue you are seeing is distinct from the kernel processing, since
> the defconfig isn't treated any differently than anything else on the
> SRC_URI from the fetcher point of view ... and it is the fetcher which
> is matching file://defconfig from the meta-beagleboard layer before the
> one you have in meta-mine, since FILESEXTRAPATHS are searched after the
> FILESPATH for the elements in the SRC_URI. But I'm not a fetcher expert,
> that's my understanding and empirical evidence.
>
> As a debug, I called src_patches() in patches.bbclass explicitly, and
> it is obvious that the source of the defconfig is from meta-beagleboard.
> Renaming the file in meta-beagleboard, allows the one in meta-mine to
> be found, since the search continues.
>
> So for this question, your issue is with the ordering of the elements
> on the SRC_URI, and you can have your layer prioritized by making sure
> it is in the search paths first.
>
> This may or may not contradict the docs, and there are several threads
> ongoing about SRC_URI ordering in the various branches .. so I'm simply
> watching and waiting on this one.
>
>
>> * Scenario 2: Config fragments
>>
>>
>> "bitbake linux-mainline" got stuck on do_patch
>>
>> log.do_patch:
>>
>> DEBUG: Executing shell function do_patch
>>
>> WARNING: no meta data branch found ...
>>
>> Switched to branch 'linux-3.8.y'
>>
>> [INFO] validating against known patches
>> (beaglebone-standard-meta)
>>
>>
> As for this. I debugged it over the weekend, and you wouldn't see this on
> master, but the tools on the dylan branch aren't using the proper
> kern-tools
> SRCREVS. As such, I backported a change from master, and switched the
> kern-tools to use the dylan branch.
>
> What you were seeing as a hang, was really just an extremely long run
> of the patch processing, the 700+ patches in the beagleboard kernel
> recipe were being detected multiple times, and expanding to 47K entries.
>
> Which the patch I've attached here, I was able to patch and configure the
> kernel with the same layers. Note: the run still takes a long time, since
> even applying 700 patches at a couple of seconds per patch .. takes a
> good chunk of time.
>
> I've added Paul Eggleton to the cc: list, since I'm not sure if dylan is
> still being updated, but if it is, the patch I'm attaching should be
> applied to fix the kern-tools situation in that branch.
>
> Cheers,
>
> Bruce
>
>
>>
>> Regards,
>>
>> --
>> *dS
>> Diego Sueiro
>>
>> /*long live rock 'n roll*/
>>
>>
>> 2013/10/29 Diego Sueiro <diego.sueiro at gmail.com
>> <mailto:diego.sueiro at gmail.com>>
>>
>> 2013/10/29 Andrea Adami <andrea.adami at gmail.com
>> <mailto:andrea.adami at gmail.com>>
>>
>>
>> I'll jump in one more time...
>>
>> Have you tried putting defconfig and patch under <machine> subdir?
>>
>> recipes-kernel/linux/linux-yocto-3.2/<machine>
>> defconfig
>> my-own.patch
>>
>> I've recently added two similar entries for 3.10 and it works.
>> Afaik it was impossible to put a common patch under
>> /linux-yocto-.3.2
>> at the time.
>>
>>
>> Andrea,
>>
>> I did it before and not worked.
>> I'll do it again just to make sure.
>>
>>
>> Regards,
>>
>> --
>> *dS
>> Diego Sueiro
>>
>> /*long live rock 'n roll*/
>>
>>
>> 2013/10/29 Andrea Adami <andrea.adami at gmail.com
>> <mailto:andrea.adami at gmail.com>>
>>
>>
>> On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro
>> <diego.sueiro at gmail.com <mailto:diego.sueiro at gmail.com>> wrote:
>> >
>> > 2013/10/28 Bruce Ashfield <bruce.ashfield at windriver.com
>> <mailto:bruce.ashfield at windriver.com>>
>>
>> >>
>> >> I'm using dylan for my yocto checkout (not oe-core
>> standalone, since
>> >> this is a yocto list/question),
>> >
>> > I thought that opemenbedded-core and poky were sharing the
>> same core
>> > components, classes and functions.
>> >
>> >>
>> >> My build shows:
>> >>
>> >> meta
>> >> meta-yocto
>> >> meta-yocto-bsp =
>> "dylan:3dc4505f0e744177ae4ddff1e1ce8b31b95dfaa6"
>> >> meta-ti =
>> "master:c14c386946e1ea341faeea292580e37d538d645d"
>> >> meta-alphalem =
>> "master:a5c0e8ff51297a4090cd47d669b4fc9c94696908"
>> >> meta-alphalem-bsp =
>> "master:56086e4dc618e975c9a46491793041f0d18e47a2"
>> >>
>> >> Mike indicated that he was using dylan for meta-ti, but that
>> doesn't
>> >> make a difference either, since for our purposed. It's
>> kernel.bbclass
>> >> and the yocto kernel processing that matters.
>> >
>> > I'll build a setup with yocto (dylan), meta-beagleboard
>> (dylan) and
>> > meta-mine to check if I can reproduce the issues.
>> >
>> >>
>> >> In meta-alphalem-bsp, I have linux-mainline_3.2.bbappend,
>> with the
>> >> following content:
>> >>
>> >> > cat linux-mainline_3.2.bbappend
>> >> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.2:"
>> >>
>> >> inherit kernel
>> >> require recipes-kernel/linux/linux-yocto.inc
>> >>
>> >> COMPATIBLE_MACHINE = "(beagleboard)"
>> >>
>> >> SRC_URI_append = " file://defconfig"
>> >> SRC_URI_append = " file://my_frag.cfg"
>> >>
>> >> And I added a fragment which has:
>> >>
>> >> > cat my_frag.cfg
>> >> CONFIG_WATCHDOG_NOWAYOUT=y
>> >> CONFIG_NTFS_FS=y
>> >> CONFIG_NTFS_RW=y
>> >>
>> >> When both are applied to the kernel build, we should see
>> CONFIG_NTFS_FS
>> >> transition from =m to =y:
>> >>
>> >> > grep CONFIG_NTFS_FS *
>> >> defconfig:CONFIG_NTFS_FS=m
>> >> my_frag.cfg:CONFIG_NTFS_FS=y
>> >>
>> >> After invoking linux-mainline's configure task, I see the
>> following:
>> >>
>> >> > grep CONFIG_NTFS_FS linux-beagleboard-standard-
>> build/.config
>> >> CONFIG_NTFS_FS=y
>> >>
>> >> And other elements of the defconfig and fragment are
>> properly applied
>> >> to the configuration phase.
>> >>
>> >> I'm also seeing good results on master, which means that I'm
>> at a
>> >> standstill to reproduce any problems.
>> >>
>> >> Diego: can you confirm for me what triggers you are seeing
>> that shows
>> >> the defconfig and fragment are not used. I assume the config
>> options
>> >> are not present, but I just want to be sure.
>> >
>> > For the full defconfig replacement after doing a do_configure
>> I've checked
>> > .config on ${S} and it did not included my CONFIGS.
>> > For config fragment it got stuck on do_patch task.
>> >
>> >
>> >
>> > Regards,
>> >
>> > --
>> > *dS
>> > Diego Sueiro
>> >
>> > /*long live rock 'n roll*/
>> >
>> > _______________________________________________
>> > yocto mailing list
>> > yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
>>
>> > https://lists.yoctoproject.org/listinfo/yocto
>> >
>>
>> I'll jump in one more time...
>>
>> Have you tried putting defconfig and patch under <machine> subdir?
>>
>> recipes-kernel/linux/linux-yocto-3.2/<machine>
>> defconfig
>> my-own.patch
>>
>> I've recently added two similar entries for 3.10 and it works.
>> Afaik it was impossible to put a common patch under
>> /linux-yocto-.3.2
>> at the time.
>>
>> Regards
>>
>> Andrea
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20131128/96ee32a4/attachment.html>
More information about the yocto
mailing list