[yocto] Custom defconfig is not used
Bruce Ashfield
bruce.ashfield at windriver.com
Thu Nov 28 07:49:24 PST 2013
On 11/28/2013, 10:37 AM, Diego Sueiro wrote:
> Bruce,
>
> Any updates on this?
Which part ? :) The defconfig "selection" (prioritization) was
explained by instrumenting the SRC_URI processing order, and it
was behaving as expected.
And the patch I attached for the kern-tools to use the dedicated
release branch for dylan fixed the other patching issue you were
seeing.
Cheers,
Bruce
>
> 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 <mailto:bruce.ashfield at windriver.com>> wrote:
>
> On 13-10-29 11 <tel:13-10-29%2011>: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:__4e399f08d596197859214fdb3b0640__3b87bf8789"
> meta-oe =
> "dylan:__a108b2203a997634f87ac687e81712__badaf3c546"
> common-bsp =
> "dylan:__7fdf9c670a10c5031a2d5555c15c45__e453de8c21"
> meta-mine =
> "dylan:__4e399f08d596197859214fdb3b0640__3b87bf8789"
>
> 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>
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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:__3dc4505f0e744177ae4ddff1e1ce8b__31b95dfaa6"
> >> meta-ti =
> "master:__c14c386946e1ea341faeea292580e3__7d538d645d"
> >> meta-alphalem =
> "master:__a5c0e8ff51297a4090cd47d669b4fc__9c94696908"
> >> meta-alphalem-bsp =
> "master:__56086e4dc618e975c9a46491793041__f0d18e47a2"
> >>
> >> 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> <mailto:yocto at yoctoproject.org
> <mailto:yocto at yoctoproject.org>__>
>
> > https://lists.yoctoproject.__org/listinfo/yocto
> <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
>
>
>
>
>
More information about the yocto
mailing list