[yocto] Custom defconfig is not used
Bruce Ashfield
bruce.ashfield at windriver.com
Sun Nov 3 19:14:25 PST 2013
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 --------------
A non-text attachment was scrubbed...
Name: 0001-kern-tools-use-dylan-branch.patch
Type: application/mbox
Size: 1423 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20131103/2eba237c/attachment.bin>
More information about the yocto
mailing list