On Thu, Jul 23, 2020 at 2:34 PM Andrey Zhizhikin <[email protected]> wrote: > > Hey guys, > > Sorry for jumping into this thread a bit later - I saw that it has > been sorted out already. > > On Thu, Jul 23, 2020 at 6:06 PM Ryan Harkin <[email protected]> wrote: > > > > > > > > On Thu, 23 Jul 2020 at 16:05, Bruce Ashfield <[email protected]> > > wrote: > >> > >> On Thu, Jul 23, 2020 at 9:38 AM Ryan Harkin <[email protected]> wrote: > >> > > >> > Hi Bruce, > >> > > >> > On Thu, 23 Jul 2020 at 13:27, Bruce Ashfield <[email protected]> > >> > wrote: > >> >> > >> >> On Thu, Jul 23, 2020 at 5:34 AM Ryan Harkin <[email protected]> > >> >> wrote: > >> >> > > >> >> > Hi Bruce, Steve, > >> >> > > >> >> > Thanks for your replies and the help. > >> >> > > >> >> > On Thu, 23 Jul 2020 at 04:33, Steve Sakoman <[email protected]> wrote: > >> >> >> > >> >> >> On Wed, Jul 22, 2020 at 3:58 PM Bruce Ashfield > >> >> >> <[email protected]> wrote: > >> >> >> > > >> >> >> > On Wed, Jul 22, 2020 at 5:27 PM Ryan Harkin > >> >> >> > <[email protected]> wrote: > >> >> >> > > > >> >> >> > > Just an FYI, but when this was submitted, my imx7s-warp builds > >> >> >> > > began to fail when building linux-fslc from meta-freescale / > >> >> >> > > meta-freescale-3rdparty. > >> >> >> > > > >> >> >> > > I'm not sure why yet, I've only discovered the problem, but I > >> >> >> > > thought I'd report it in case anyone else sees the problem. > >> >> >> > > > >> >> >> > > >> >> >> > Someone already sent a dunfell backport request for a follow up > >> >> >> > patch to this. > >> >> >> > > >> >> >> > It went to the poky list, but I just replied to it and copied > >> >> >> > oe-core. > >> >> >> > >> >> >> Both patches are already in dunfell! > >> >> >> > >> >> >> https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=7ecc81baeacaa1149a4947791200e8819c3df677 > >> >> >> https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=11089e06bfb3d0defb52825ffba978d085385569 > >> >> > > >> >> > > >> >> > Yes, they are present. I guess I should have checked the error > >> >> > messages more closely during git bisect rather than stopping as soon > >> >> > as the build failed. > >> >> > > >> >> > After Bruce's 7ecc81baea patch, I see this error: > >> >> > > >> >> > ERROR: linux-fslc-5.4.46+gitAUTOINC+38d6c3525e-r0 do_kernel_metadata: > >> >> > Could not locate BSP definition for imx7s-warp/standard and no > >> >> > defconfig was provided > >> >> > > >> >> > Then, after 11089e06bf, I see the error I originally posted from my > >> >> > CI job, but reproduced here from a local build: > > This was the patch I've introduced and seeing those errors were quite > a surprise to me. I have also an internal CI that builds > meta-freescale off the dunfell branch - and I never had any issues > with it. > > >> >> > > >> >> > ERROR: linux-fslc-5.4.46+gitAUTOINC+38d6c3525e-r0 do_kernel_configme: > >> >> > Execution of > >> >> > '/data/warp7/workspace-dunfell/build-rpb/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/run.do_kernel_configme.31899' > >> >> > failed with exit code 1: > >> >> > WARNING: exit code 1 from a shell command. > >> >> > > >> >> > ERROR: Logfile of failure stored in: > >> >> > /data/warp7/workspace-dunfell/build-rpb/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/log.do_kernel_configme.31899 > >> >> > Log data follows: > >> >> > | DEBUG: Executing python function extend_recipe_sysroot > >> >> > | NOTE: Direct dependencies are > >> >> > ['/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/meta-arm/meta-arm-toolchain/recipes-devtools/gcc/gcc-cross_arm-9.2.bb:do_populate_sysroot', > >> >> > > >> >> > 'virtual:native:/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-extended/bc/bc_1.07.1.bb:do_populate_sysroot', > >> >> > > >> >> > '/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-devtools/binutils/binutils-cross_2.34.bb:do_populate_sysroot', > >> >> > > >> >> > 'virtual:native:/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-devtools/bison/bison_3.5.3.bb:do_populate_sysroot', > >> >> > > >> >> > '/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_populate_sysroot', > >> >> > > >> >> > '/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', > >> >> > > >> >> > 'virtual:native:/data/warp7/workspace-dunfell/build-rpb/conf/../../layers/openembedded-core/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot'] > >> >> > | NOTE: Installed into sysroot: [] > >> >> > | NOTE: Skipping as already exists in sysroot: ['gcc-cross-arm', > >> >> > 'bc-native', 'binutils-cross-arm', 'bison-native', 'quilt-native', > >> >> > 'kern-tools-native', 'patch-native', 'readline-native', > >> >> > 'flex-native', 'automake-native', 'texinfo-dummy-native', > >> >> > 'autoconf-native', 'libtool-native', 'gnu-config-native', > >> >> > 'xz-native', 'gettext-minimal-native', 'libmpc-native', 'gmp-native', > >> >> > 'zlib-native', 'mpfr-native', 'linux-libc-headers', 'attr-native', > >> >> > 'ncurses-native', 'm4-native', 'pkgconfig-native'] > >> >> > | DEBUG: Python function extend_recipe_sysroot finished > >> >> > | DEBUG: Executing shell function do_kernel_configme > >> >> > | WARNING: exit code 1 from a shell command. > >> >> > | ERROR: Execution of > >> >> > '/data/warp7/workspace-dunfell/build-rpb/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/run.do_kernel_configme.31899' > >> >> > failed with exit code 1: > >> >> > | WARNING: exit code 1 from a shell command. > >> >> > > >> >> > I haven't yet looked at what these patches do, but I'm expecting > >> >> > there's something to update in the linux-fslc recipe, unless there's > >> >> > another issue in the defconfig patches. > >> >> > > >> >> > >> >> We've had multiple reports that with those patches the linux-fslc > >> >> recipe is building. So something else may be going on in your setup. > > If there were some reports - I haven't seen them... > > Bruce, do you happen to have any reference to them? I'm trying to > merge and maintain linux-fslc[-imx] kernels, and so far I've never > seen any failures. Or maybe they were reported on some mailing lists > I'm not in.
They were deeper follow ups to some of the threads here and on linux-yocto. Nothing too obvious. Just in case anyone is reading this and thinking the issue was ever with the linux-fslc* kernels .. that isn't the case. It just happened to be the one that people were using that showed the issue introduced by my defconfig juggling. > > >> > > >> > > >> > That's reassuring. > >> > > >> >> > >> >> If you have a set of layers and build steps, can you send them to me ? > >> >> I can spin up a local build and see if I get the same behaviour. > >> > > >> > > >> > Thanks for the offer. I'm based on Linaro's "OE-RPB" setup. > >> > > >> > My own layer is quite simple: > >> > https://git.linaro.org/people/ryan.harkin/meta-warp7.git/log/?h=dunfell > >> > > >> > I mostly provide a new image definition and a simple u-boot patch to > >> > change the console UART for our CI system. I don't have a kernel recipe > >> > overlaying linux-fslc. > >> > > >> > My basic steps to clone and build are: > >> > -------------------------- > >> > mkdir /data/warp7/workspace-dunfell > >> > cd /data/warp7/workspace-dunfell > >> > repo init -u \ > >> > https://git.linaro.org/people/ryan.harkin/oe-rpb-manifest.git \ > >> > -b dunfell > >> > repo sync > >> > > >> > # link in shared downloads and sstate-cache > >> > ln -s /linaro/oe-rpb/downloads . && ln -s /linaro/oe-rpb/sstate-cache . > >> > > >> > export MACHINE=imx7s-warp ; export DISTRO=rpb ; . setup-environment > >> > bitbake warp7-console-image > >> > -------------------------- > >> > > >> > >> I'm spinning up a build now (but as usual, I'm fighting some > >> infrastructure issues and can't get repo to install). > > > > > > It looks like you can stand down on this... > > > >> > >> > >> Steve mentioned two patches ... but can you also confirm that: > >> [kernel-yocto: account for extracted defconfig in elements check] is > >> in the branch you are building ? > > > > > > That patch wasn't in my dunfell branch, so I cherry-picked it from master > > locally and now the build is working again. > > Meanwhile, doing a "git remote update" and I see the patch is now on top of > > the dunfell branch as of today, and my build is working again. > > Glad to see that it is solved for you! I've run the build for > meta-freescale linux-fslc yesterday - it went through like a breeze... > I don't think there was a significant update on dunfell, but I can > start the build now anyway... It'll be fine once Steve does the next release. We just got unlucky and picked up 2 of the defconfig correction patches before he bug report came in. So everything is ok, and with the latest dunfell queue there aren't any issues. Bruce > > > > > Great, thanks for your help folks. > > > > Regards, > > Ryan. > > > > > > > >> > >> > >> Bruce > >> > >> > >> > Right now, I've pinned oo-core to my last known working build from > >> > before your recent defconfig patch, so you'll want to go into > >> > layer/openembedded-core and checkout the latest commits. > >> > > >> > For reference, my pinned commit: > >> > cabaf5654d 2020-07-06 iso-codes: switch upstream branch master -> main > >> > [Hongxu Jia] > >> > > >> > Local testing tells me that the repo works fine for me all the way up to > >> > just before your commit, at this point: > >> > 2399fdf98a 2020-07-03 classes/archive: do_configure should not depend > >> > on do_ar_p.. [Joshua Watt] > >> > > >> > I'm building on an Ubuntu 18.04 host locally. > >> > > >> > Regards, > >> > Ryan. > >> > > >> > > >> >> > >> >> > >> >> Bruce > >> >> > >> >> > Regards, > >> >> > Ryan. > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> Steve > >> >> >> > >> >> >> > > Here's a link to my failing build for reference: > >> >> >> > > https://ci.linaro.org/job/warp7-openembedded-dunfell/67/DISTRO=rpb,MACHINE=imx7s-warp,label=docker-buster-amd64/consoleText > >> >> >> > > > >> >> >> > > And a snippet from the failure: > >> >> >> > > > >> >> >> > > ERROR: linux-fslc-5.4.46+gitAUTOINC+38d6c3525e-r0 > >> >> >> > > do_kernel_configme: Execution of > >> >> >> > > '/srv/oe/build/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/run.do_kernel_configme.7123' > >> >> >> > > failed with exit code 1: > > Oh, this is actually a good reminder: I have to bump up the kernel > version! It's been merged into the linux-fslc repo, but I didn't > update recipes so far... Vacation time... :) Latest update would > include v5.4.51 tag. > > >> >> >> > > WARNING: exit code 1 from a shell command. > >> >> >> > > > >> >> >> > > ERROR: Logfile of failure stored in: > >> >> >> > > /srv/oe/build/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/log.do_kernel_configme.7123 > >> >> >> > > Log data follows: > >> >> >> > > | DEBUG: Executing python function extend_recipe_sysroot > >> >> >> > > | NOTE: Direct dependencies are > >> >> >> > > ['virtual:native:/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/bison/bison_3.5.3.bb:do_populate_sysroot', > >> >> >> > > > >> >> >> > > '/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', > >> >> >> > > > >> >> >> > > '/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/binutils/binutils-cross_2.34.bb:do_populate_sysroot', > >> >> >> > > > >> >> >> > > '/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_populate_sysroot', > >> >> >> > > > >> >> >> > > 'virtual:native:/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', > >> >> >> > > > >> >> >> > > 'virtual:native:/srv/oe/build/conf/../../layers/openembedded-core/meta/recipes-extended/bc/bc_1.07.1.bb:do_populate_sysroot', > >> >> >> > > > >> >> >> > > '/srv/oe/build/conf/../../layers/meta-arm/meta-arm-toolchain/recipes-devtools/gcc/gcc-cross_arm-9.2.bb:do_populate_sysroot'] > >> >> >> > > | NOTE: Installed into sysroot: [] > >> >> >> > > | NOTE: Skipping as already exists in sysroot: ['bison-native', > >> >> >> > > 'kern-tools-native', 'binutils-cross-arm', 'quilt-native', > >> >> >> > > 'patch-native', 'bc-native', 'gcc-cross-arm', 'flex-native', > >> >> >> > > 'texinfo-dummy-native', 'gnu-config-native', 'readline-native', > >> >> >> > > 'libtool-native', 'automake-native', 'autoconf-native', > >> >> >> > > 'xz-native', 'linux-libc-headers', 'gmp-native', > >> >> >> > > 'libmpc-native', 'mpfr-native', 'zlib-native', > >> >> >> > > 'gettext-minimal-native', 'attr-native', 'm4-native', > >> >> >> > > 'ncurses-native', 'pkgconfig-native'] > >> >> >> > > | DEBUG: Python function extend_recipe_sysroot finished > >> >> >> > > | DEBUG: Executing shell function do_kernel_configme > >> >> >> > > | WARNING: exit code 1 from a shell command. > >> >> >> > > | ERROR: Execution of > >> >> >> > > '/srv/oe/build/tmp-rpb-glibc/work/imx7s_warp-linaro-linux-gnueabi/linux-fslc/5.4.46+gitAUTOINC+38d6c3525e-r0/temp/run.do_kernel_configme.7123' > >> >> >> > > failed with exit code 1: > >> >> >> > > | WARNING: exit code 1 from a shell command. > >> >> >> > > | > >> >> >> > > NOTE: recipe linux-fslc-5.4.46+gitAUTOINC+38d6c3525e-r0: task > >> >> >> > > do_kernel_configme: Failed > >> >> >> > > ERROR: Task > >> >> >> > > (/srv/oe/build/conf/../../layers/meta-freescale/recipes-kernel/linux/linux-fslc_5.4.bb:do_kernel_configme) > >> >> >> > > failed with exit code '1' > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > On Mon, 6 Jul 2020 at 17:38, Steve Sakoman <[email protected]> > >> >> >> > > wrote: > >> >> >> > >> > >> >> >> > >> On Mon, Jul 6, 2020 at 6:29 AM Bruce Ashfield > >> >> >> > >> <[email protected]> wrote: > >> >> >> > >> > > >> >> >> > >> > We have a fixup patch for this one in test right now, so we > >> >> >> > >> > don't want > >> >> >> > >> > this patch, without the follow up. > >> >> >> > >> > > >> >> >> > >> > But this is useful for dunfell, since it was an unexpected > >> >> >> > >> > behaviour > >> >> >> > >> > that needed to be fixed. > >> >> >> > >> > >> >> >> > >> Thanks, I'll drop this patch from the pull request and include > >> >> >> > >> it > >> >> >> > >> along with the fixup patch in next week's patch set. > >> >> >> > >> > >> >> >> > >> Steve > >> >> >> > >> > >> >> >> > >> > On Mon, Jul 6, 2020 at 12:11 PM Steve Sakoman > >> >> >> > >> > <[email protected]> wrote: > >> >> >> > >> > > > >> >> >> > >> > > From: Bruce Ashfield <[email protected]> > >> >> >> > >> > > > >> >> >> > >> > > It is uncommon that a BSP definition and a defconfig are > >> >> >> > >> > > used in > >> >> >> > >> > > a single configuration. That being said, it is a valid way > >> >> >> > >> > > to > >> >> >> > >> > > organize kernel configuration meta data. > >> >> >> > >> > > > >> >> >> > >> > > When a defconfig is used, either on the src_uri or from in > >> >> >> > >> > > the kernel tree, it is normally expected that it is the > >> >> >> > >> > > baseline, > >> >> >> > >> > > with all options applied on top of it. > >> >> >> > >> > > > >> >> >> > >> > > With this commit, we detect either type of defconfig and > >> >> >> > >> > > ensure > >> >> >> > >> > > that it is used first, followed by the fragments in their > >> >> >> > >> > > previous order. This allows existing configuration stacks to > >> >> >> > >> > > remain the same, while ensuring that a defconfig combined > >> >> >> > >> > > stack > >> >> >> > >> > > works as expected. > >> >> >> > >> > > > >> >> >> > >> > > Signed-off-by: Bruce Ashfield <[email protected]> > >> >> >> > >> > > Signed-off-by: Richard Purdie > >> >> >> > >> > > <[email protected]> > >> >> >> > >> > > (cherry picked from commit > >> >> >> > >> > > e6845327b69396d843a2f3c4c3ac9400ae9caedf) > >> >> >> > >> > > Signed-off-by: Steve Sakoman <[email protected]> > >> >> >> > >> > > --- > >> >> >> > >> > > meta/classes/kernel-yocto.bbclass | 33 > >> >> >> > >> > > ++++++++++++++++++++----------- > >> >> >> > >> > > 1 file changed, 21 insertions(+), 12 deletions(-) > >> >> >> > >> > > > >> >> >> > >> > > diff --git a/meta/classes/kernel-yocto.bbclass > >> >> >> > >> > > b/meta/classes/kernel-yocto.bbclass > >> >> >> > >> > > index 5bc627066e..41d8620e67 100644 > >> >> >> > >> > > --- a/meta/classes/kernel-yocto.bbclass > >> >> >> > >> > > +++ b/meta/classes/kernel-yocto.bbclass > >> >> >> > >> > > @@ -131,7 +131,7 @@ do_kernel_metadata() { > >> >> >> > >> > > else > >> >> >> > >> > > cp -f > >> >> >> > >> > > ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} > >> >> >> > >> > > ${WORKDIR}/defconfig > >> >> >> > >> > > fi > >> >> >> > >> > > - sccs="${WORKDIR}/defconfig" > >> >> >> > >> > > + > >> >> >> > >> > > in_tree_defconfig="${WORKDIR}/defconfig" > >> >> >> > >> > > else > >> >> >> > >> > > bbfatal "A KBUILD_DEFCONFIG > >> >> >> > >> > > '${KBUILD_DEFCONFIG}' was specified, but not present in the > >> >> >> > >> > > source tree" > >> >> >> > >> > > fi > >> >> >> > >> > > @@ -153,14 +153,24 @@ do_kernel_metadata() { > >> >> >> > >> > > patches="${@" ".join(find_patches(d,''))}" > >> >> >> > >> > > feat_dirs="${@" > >> >> >> > >> > > ".join(find_kernel_feature_dirs(d))}" > >> >> >> > >> > > > >> >> >> > >> > > - # a quick check to make sure we don't have > >> >> >> > >> > > duplicate defconfigs > >> >> >> > >> > > - # If there's a defconfig in the SRC_URI, did we > >> >> >> > >> > > also have one from > >> >> >> > >> > > - # the KBUILD_DEFCONFIG processing above ? > >> >> >> > >> > > - if [ -n "$sccs" ]; then > >> >> >> > >> > > - # we did have a defconfig from above. remove > >> >> >> > >> > > any that might be in the src_uri > >> >> >> > >> > > - sccs_from_src_uri=$(echo $sccs_from_src_uri | > >> >> >> > >> > > awk '{ if ($0!="defconfig") { print $0 } }' RS=' ') > >> >> >> > >> > > + # a quick check to make sure we don't have > >> >> >> > >> > > duplicate defconfigs If > >> >> >> > >> > > + # there's a defconfig in the SRC_URI, did we also > >> >> >> > >> > > have one from the > >> >> >> > >> > > + # KBUILD_DEFCONFIG processing above ? > >> >> >> > >> > > + src_uri_defconfig=$(echo $sccs_from_src_uri | awk > >> >> >> > >> > > '{ if ($0=="defconfig") { print $0 } }' RS=' ') > >> >> >> > >> > > + # drop and defconfig's from the src_uri variable, > >> >> >> > >> > > we captured it just above here if it existed > >> >> >> > >> > > + sccs_from_src_uri=$(echo $sccs_from_src_uri | awk > >> >> >> > >> > > '{ if ($0!="defconfig") { print $0 } }' RS=' ') > >> >> >> > >> > > + if [ -n "$in_tree_defconfig" ]; then > >> >> >> > >> > > + sccs_defconfig=$in_tree_defconfig > >> >> >> > >> > > + if [ -n "$src_uri_defconfig" ]; then > >> >> >> > >> > > + bbwarn "[NOTE]: defconfig was > >> >> >> > >> > > supplied both via KBUILD_DEFCONFIG and SRC_URI. Dropping > >> >> >> > >> > > SRC_URI defconfig" > >> >> >> > >> > > + fi > >> >> >> > >> > > + else > >> >> >> > >> > > + # if we didn't have an in-tree one, make > >> >> >> > >> > > our defconfig the one > >> >> >> > >> > > + # from the src_uri. Note: there may not > >> >> >> > >> > > have been one from the > >> >> >> > >> > > + # src_uri, so this can be an empty variable. > >> >> >> > >> > > + sccs_defconfig=$src_uri_defconfig > >> >> >> > >> > > fi > >> >> >> > >> > > - sccs="$sccs $sccs_from_src_uri" > >> >> >> > >> > > + sccs="$sccs_from_src_uri" > >> >> >> > >> > > > >> >> >> > >> > > # check for feature directories/repos/branches that > >> >> >> > >> > > were part of the > >> >> >> > >> > > # SRC_URI. If they were supplied, we convert them > >> >> >> > >> > > into include directives > >> >> >> > >> > > @@ -187,11 +197,10 @@ do_kernel_metadata() { > >> >> >> > >> > > # expand kernel features into their full path > >> >> >> > >> > > equivalents > >> >> >> > >> > > bsp_definition=$(spp ${includes} --find > >> >> >> > >> > > -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) > >> >> >> > >> > > if [ -z "$bsp_definition" ]; then > >> >> >> > >> > > - echo "$sccs" | grep -q defconfig > >> >> >> > >> > > - if [ $? -ne 0 ]; then > >> >> >> > >> > > + if [ -z "$sccs_defconfig" ]; then > >> >> >> > >> > > bbfatal_log "Could not locate BSP > >> >> >> > >> > > definition for ${KMACHINE}/${LINUX_KERNEL_TYPE} and no > >> >> >> > >> > > defconfig was provided" > >> >> >> > >> > > fi > >> >> >> > >> > > - > >> >> >> > >> > > + else > >> >> >> > >> > > # if the bsp definition has "define > >> >> >> > >> > > KMETA_EXTERNAL_BSP t", > >> >> >> > >> > > # then we need to set a flag that will > >> >> >> > >> > > instruct the next > >> >> >> > >> > > # steps to use the BSP as both > >> >> >> > >> > > configuration and patches. > >> >> >> > >> > > @@ -206,7 +215,7 @@ do_kernel_metadata() { > >> >> >> > >> > > elements="`echo -n ${bsp_definition} ${sccs} > >> >> >> > >> > > ${patches} ${KERNEL_FEATURES}`" > >> >> >> > >> > > if [ -n "${elements}" ]; then > >> >> >> > >> > > echo "${bsp_definition}" > > >> >> >> > >> > > ${S}/${meta_dir}/bsp_definition > >> >> >> > >> > > - scc --force -o > >> >> >> > >> > > ${S}/${meta_dir}:cfg,merge,meta ${includes} > >> >> >> > >> > > ${bsp_definition} ${sccs} ${patches} ${KERNEL_FEATURES} > >> >> >> > >> > > + scc --force -o > >> >> >> > >> > > ${S}/${meta_dir}:cfg,merge,meta ${includes} $sccs_defconfig > >> >> >> > >> > > $bsp_definition $sccs $patches ${KERNEL_FEATURES} > >> >> >> > >> > > if [ $? -ne 0 ]; then > >> >> >> > >> > > bbfatal_log "Could not generate > >> >> >> > >> > > configuration queue for ${KMACHINE}." > >> >> >> > >> > > fi > >> >> >> > >> > > -- > >> >> >> > >> > > 2.17.1 > >> >> >> > >> > > > >> >> >> > >> > > > >> >> >> > >> > > >> >> >> > >> > > >> >> >> > >> > > >> >> >> > >> > -- > >> >> >> > >> > - Thou shalt not follow the NULL pointer, for chaos and > >> >> >> > >> > madness await > >> >> >> > >> > thee at its end > >> >> >> > >> > - "Use the force Harry" - Gandalf, Star Trek II > >> >> >> > >> > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > - Thou shalt not follow the NULL pointer, for chaos and madness > >> >> >> > await > >> >> >> > thee at its end > >> >> >> > - "Use the force Harry" - Gandalf, Star Trek II > >> >> > >> >> > >> >> > >> >> -- > >> >> - Thou shalt not follow the NULL pointer, for chaos and madness await > >> >> thee at its end > >> >> - "Use the force Harry" - Gandalf, Star Trek II > >> > >> > >> > >> -- > >> - Thou shalt not follow the NULL pointer, for chaos and madness await > >> thee at its end > >> - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > -- > Regards, > Andrey. -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140906): https://lists.openembedded.org/g/openembedded-core/message/140906 Mute This Topic: https://lists.openembedded.org/mt/75336267/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
