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 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 > > >> >> 2013/10/29 Andrea Adami > > >> >> >> I'll jump in one more time... >> >> Have you tried putting defconfig and patch under subdir? >> >> recipes-kernel/linux/linux-yocto-3.2/ >> 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 > > >> >> >> On Tue, Oct 29, 2013 at 11:33 AM, Diego Sueiro >> > wrote: >> > >> > 2013/10/28 Bruce Ashfield > > >> >> >> >> >> 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@yoctoproject.org >> >> > https://lists.yoctoproject.org/listinfo/yocto >> > >> >> I'll jump in one more time... >> >> Have you tried putting defconfig and patch under subdir? >> >> recipes-kernel/linux/linux-yocto-3.2/ >> 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 >> >> >> >> >