Bug 7474

I reiterate a request (hope i'm not pushing it too much): maybe we can have this in for 1.8. 

Regards,
Andrei

Can someone provide refrences to all the layers and configs for
a test case here ?

I'd rather build against the exact case, versus creating my own.

(In reply to comment #0)
> I've been looking into a request to have Yocto kernel configuration
> fragment support in meta-raspberrypi with a defconfig which is pulled
> from the kernel source tree for the configured machine.
> 
> My understanding is that Yocto expects the defconfig file to be supplied
> in the meta-layer and then configured with SRC_URI += "file://defconfig"
> 
> We'd prefer not to maintain copies of defconfigs, instead using the true
> default configuration from the kernel tree and allowing users to add
> their own .cfg fragments to the SRC_URI via, say, .bbappends.
> 
> It's easy enough to _prepend() a function to copy the appropriate
> defconfig from the kernel source to the working directory, but I am
> having a problem as do_patch() in kernel-yocto.bbclass seems to require
> a defconfig file from the layer itself via use of SRC_URI in find_sccs().
> 
> ...
> 
> I see three use-cases that I believe it would be an enhancement to support
> 
> (1) meta-foo layer provides kernel recipes with a defconfig and optionally
> additionally .cfg kernel configuration fragments in SRC_URI
> 
> My understanding is that this is the currently supported use-case
> 
> (2) meta-foo layer uses a defconfig from the kernel source and optionally
> configures additional .cfg kernel fragments in SRC_URI
> 
> Currently we can copy a board specific defconfig from kernel sources to e.g.
> ${WORKDIR} but as above find_sccs() requires the defconfig to originate from
> within the meta-foo layer. I believe we would need some kind of change
> around kernel-yocto.bbclass to support this
> 
> (3) meta-food layer configures no defconfig but only additional kernel
> fragments via additional .cfg files in SRC_URI
> 
> This is similar to (2) excepting that the kernel recipe in meta-foo doesn't
> deal with defconfigs at all, leaving the kernel build to defaults, but does
> provide kernel configuration fragments which should be applied to that
> default. I am not certain but I do not think this is currently supported as
> it seems that without a defconfig provided by the recipe no attempt is made
> to apply kernel configuration fragments.

#3 is in fact partially supported already. The switch is allowing a in
tree defconfig to be available to the tools as they process any fragments
that may or may not be added via the SRC_URI.

What I don't want to do is introduce another variable to the system
(to specify a defconfig), but at the moment the options are few on that
front.

Bruce

> 
> Associated documentation changes would be required for the above.
> 
> Thanks, ALex

(In reply to comment #1)
> I reiterate a request (hope i'm not pushing it too much): maybe we can have
> this in for 1.8. 
> 

As mentioned on the mailing list, we are well past feature freeze, and
bug fix cut off is very soon as well.

This is going to create a public API if a variable is introduced, and there's
more than a non-zero risk to existing use cases. So treading carefully is
the right thing to do.

There is a trivial work around, which is to follow the typical SRC_URI method
of providing a defconfig, so it isn't like without this enhancement that there's
no way the goal can be acheived.

We have conferences and travel coming up in the next week, so the cycles are
short all around .. but again, I'll do what I can.

Bruce

> Regards,
> Andrei

"Can someone provide refrences to all the layers and configs for
a test case here ?"

I'm using meta-raspberrypi master with poky dizzy. I'll try to put a test case together for you 

"What I don't want to do is introduce another variable to the system
(to specify a defconfig)"

I'm not sure about the appropriate solution but let me throw this out for discussion...

The kernel config patching code uses SRC_URI.

My problem is that file://defconfig in SRC_URI will require that file to be somewhere in my meta-layer hierarchy

However I can easily enough cause a file to be placed into ${WORKDIR} by adding a prepends() function

So I am wondering if it makes any kind of sense at all to allow me to reference a file in SRC_URI that is not pulled in by the fetcher but is instead referenced as being in the work dir

e.g. SRC_URI += "file://${WORKDIR}/defconfig

Then I can put that in there myself and the patching code would use it.

However I can see that might be a messy way to solve the problem as it changes the semantics of what SRC_URI is supposed to be doing...

Simple test case:

If you grab the poky dizzy branch and build core-image-minimal for MACHINE=raspberrypi2 DISTRO=poky (or raspberrypi I imagine) we can see this behaviour.

More specifically this will work as you might expect 

bitbake -f -c virtual/kernel

However the reason this works is that there's a do_configure_prepend() step in the meta-raspberrypi layer which blows away the existing broken configuration.

do_configure_prepend() {
    # Clean .config
    echo "" > ${B}/.config

http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux/linux.inc#n36

There is a dummy defconfig on the SRC_URI command line which you can see here:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux/linux-raspberrypi/defconfig

There is a line that installs the correct defconfig from the source tree here

do_kernel_configme_prepend() {
    install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig || die "No default configuration for ${MACHINE} / ${KERNEL_DEFCONFIG} available."
}

http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux/linux-raspberrypi.inc#n39

So we have the correct defconfig copied in from the kernel source

But the patch step I reference above uses the dummy file from the SRC_URI.

You can see that this file is being used if you

bitbake -f -c configure virtual/kernel
bitbake -c devshell virtual/kernel

cd .meta/cfg/linux-raspberrypi

In there you'll see defconfig, defconfig.santized, and  sl030raspberrypii2ckernel.patch

If you

cat defconfig

You'll see the dummy file has been pulled in -

# Dummy file to get through do_kernel_configme.

Hope that helps?

Cheers, Alex

I failed in my quest to do this without a new variable. While the
approaches worked .. they were fragile, and something that I didn't
want to carry long term.

So I instead implemented something similar to your existing prepend
routine, such that it will copy a defconfig out of the tree and make
it available for configuration.

The change I've made is based on some of my other pending changes, 
so I've pushed them to my zedd/kernel poky-contrib branch:

 git://git.pokylinux.org/poky-contrib zedd/kernel

See the top commit, I've gone with the kernel's naming of this variable
to keep things consistent, but the end result is the same.

Try setting KBUILD_DEFCONFIG in your recipe, and you'll see that the
config is pulled out, named 'defconfig', added to the list of files 
to process, and incorporated into the build.

.. it worked for me.

If this does work for you, the risk is low on this, and I'll send it
out for review Monday.

Thanks Bruce. Acked.

Much appreciated Bruce. I will try to run it up here over the next couple of days and give you some feedback.

Cheers, Alex

Bruce,

I've done a little testing here and the default configuration seems to be being pulled in correctly with e.g.

KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig"

However if I then add a defconfig on SRC_URI that defconfig is not used unless I remove the KBUILD_DEFCONFIG. I am wondering whether it would make user finger trouble less likely if a defconfig provided on the SRC_URI should override anything specified in the KBUILD_DEFCONFIG?

Cheers, Alex

(In reply to comment #10)
> Bruce,
> 
> I've done a little testing here and the default configuration seems to be
> being pulled in correctly with e.g.
> 
> KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig"
> 
> However if I then add a defconfig on SRC_URI that defconfig is not used
> unless I remove the KBUILD_DEFCONFIG. I am wondering whether it would make
> user finger trouble less likely if a defconfig provided on the SRC_URI
> should override anything specified in the KBUILD_DEFCONFIG?

I'd like to keep complexity low, so I started with something a bit
blunt :)

But yes, in this case, not clobbering an existing defconfig (from the
fetcher and in WORKDIR) makes sense, and isn't increasing complexity
much.

I pushed an updated patch to the same branch.

> 
> Cheers, Alex

Hi Bruce,

I've pulled commit #46fa9e30, thanks.

Running into trouble now. My simplest starting test case is to build the MACHINE=raspberrypi2 virtual/kernel with no defconfig and no configuration fragments on the SRC_URI. 

I do have the new variable set to

KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"

This should result (in my understanding) in the defconfig configured about being taken from the kernel tree and used for the build.

I'm then getting an error telling me there's no defconfig or configuration fragments

Log data follows:
| DEBUG: Executing shell function do_kernel_configme
| NOTE: kernel configme
| [INFO] Configuring target/machine combo: "standard/raspberrypi2"
| [INFO] collecting configs in .meta/meta-series
| [ERROR] No configuration fragments found, this typically is a misconfigured BSP.
|         Check that fragments (or defconfigs) are referenced by the board description.
| config of "standard/raspberrypi2" failed

Cheers, Alex

(In reply to comment #12)
> Hi Bruce,
> 
> I've pulled commit #46fa9e30, thanks.
> 
> Running into trouble now. My simplest starting test case is to build the
> MACHINE=raspberrypi2 virtual/kernel with no defconfig and no configuration
> fragments on the SRC_URI. 
> 
> I do have the new variable set to
> 
> KERNEL_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"

Is that a cut and paste ? If so, that's probably our issue,
it should be KBUILD_DEFCONFIG.

(which matches the linux kernel naming).

Bruce

> 
> This should result (in my understanding) in the defconfig configured about
> being taken from the kernel tree and used for the build.
> 
> I'm then getting an error telling me there's no defconfig or configuration
> fragments
> 
> Log data follows:
> | DEBUG: Executing shell function do_kernel_configme
> | NOTE: kernel configme
> | [INFO] Configuring target/machine combo: "standard/raspberrypi2"
> | [INFO] collecting configs in .meta/meta-series
> | [ERROR] No configuration fragments found, this typically is a
> misconfigured BSP.
> |         Check that fragments (or defconfigs) are referenced by the board
> description.
> | config of "standard/raspberrypi2" failed
> 
> Cheers, Alex

>Is that a cut and paste ? If so, that's probably our issue, it should be KBUILD_DEFCONFIG.

Thanks. Yes that was finger trouble on my part. I had been testing with KBUILD_ over the weekend but must have reverted it.

So with that corrected, 

OK - with no defconfig / kernel fragments I see a defconfig pulled into .meta/cfg/raspberrypi that is correct as per the KBUILD_DEFCONFIG_raspberrypi2 definition

OK - with a defconfig on the SRC_URI I see that pulled into .meta/cfg/raspberrypi folder 

OK - with a defconfig on the SRC_URI and an added simple configuration fragment I see both the defconfig and the configuration fragment pulled into .meta/cfg/raspberrypi folder 

NOTOK? - however when have no defconfig but just mmy configuration fragment on the SRC_URI the defconfig no longer appears to be pulled in at all?

Alex

The recipe has what I think is a sensible SRC_URI

SRC_URI = "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y file://build-in-audio.cfg"

The build-in-audio.cfg fragment I am testing is straightforward with

CONFIG_SND=y
CONFIG_SND_BCM2835=y

The default defconfig is set in the recipe with 

KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"

build-in-audio.cfg arrives in ./meta/cfg/linux-raspberrypi fine, but no defconfig file.

I've been testing with my own configuration, so I'll switch gears and fire up
something similar to confirm (or deny!) the result.

Bruce

(In reply to comment #15)
> The recipe has what I think is a sensible SRC_URI
> 
> SRC_URI =
> "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y
> file://build-in-audio.cfg"
> 
> The build-in-audio.cfg fragment I am testing is straightforward with
> 
> CONFIG_SND=y
> CONFIG_SND_BCM2835=y
> 
> The default defconfig is set in the recipe with 
> 
> KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
> 
> build-in-audio.cfg arrives in ./meta/cfg/linux-raspberrypi fine, but no
> defconfig file.

>I've been testing with my own configuration, so I'll switch gears and fire up
something similar to confirm (or deny!) the result.

Great. Let me know if you need anything more from me.

I was able to use meta-raspberrypi and the raspberrypi2 to have a configuration
work properly with this scheme and the 3.18 kernel.

I did push one minor enhancement to the commit, but the functionality is otherwise
unchanged.

To make it work, I did have to comment out the file://defconfig in linux-raspberrypi.inc, 
but otherwise added just what you had:

-----------------------------------
diff --git a/recipes-kernel/linux/linux-raspberrypi.inc b/recipes-kernel/linux/linux-raspberrypi.inc
index 84d4f9eed405..84908246f76c 100644
--- a/recipes-kernel/linux/linux-raspberrypi.inc
+++ b/recipes-kernel/linux/linux-raspberrypi.inc
@@ -5,9 +5,9 @@ SECTION = "kernel"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
 
-SRC_URI += " \
-        file://defconfig \
-        "
+#SRC_URI += " \
+#file://defconfig \
+#"
 
 COMPATIBLE_MACHINE = "raspberrypi"
 
diff --git a/recipes-kernel/linux/linux-raspberrypi_3.18.bb b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
index 921e7024697f..f2e91580f969 100644
--- a/recipes-kernel/linux/linux-raspberrypi_3.18.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_3.18.bb
@@ -3,6 +3,9 @@ LINUX_VERSION ?= "3.18.5"
 SRCREV = "a6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46"
 SRC_URI = "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y \
            file://sl030raspberrypii2ckernel.patch \
+           file://build-in-audio.cfg \
           "
 
+KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
+
---------------

To see that it worked, we can check a few files:

#1:  The config and fragment made it to workdir.
> pwd
poky/build/tmp/work/raspberrypi2-poky-linux-gnueabi/linux-raspberrypi/3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0
[/home/bruc...8ccfd46-r0]> ls
build-in-audio.cfg  defconfig  linux-raspberrypi2-standard-build  sl030raspberrypii2ckernel.patch  temp
[/home/bruc...8ccfd46-r0]> 

#2: the bsp is using it internally in the tools
[/home/bruc...fg/scratch]> pwd
/home/bruce/poky/build/tmp/work-shared/raspberrypi2/kernel-source/.meta/cfg/scratch
[/home/bruc...fg/scratch]> vi raspberrypi2-standard-meta

In that file, you'll see the defconfig, followed by the build-in-audio.cfg and then the kernel
patch: sl030raspberrypii2ckernel.patch

#3: the final .config

[/home/bruc...8ccfd46-r0]> pwd
/home/bruce/poky/build/tmp/work/raspberrypi2-poky-linux-gnueabi/linux-raspberrypi/3.18.5+gita6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46-r0

[/home/bruc...8ccfd46-r0]> grep -E "^CONFIG_CMDLINE=" linux-raspberrypi2-standard-build/.config
CONFIG_CMDLINE="console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"

[/home/bruc...8ccfd46-r0]> grep CONFIG_SND=y linux-raspberrypi2-standard-build/.config 
CONFIG_SND=y

So the defconfig + fragments took effect and made it to our final .config

OK - well thanks for verifying that it is working Bruce. I must be doing something wrong in my checking. I will go back through.

I had removed defconfig from linux-raspberrypi.inc as did you. I had also made some changes to the do_configure_prepend() step as it seemed to be blowing away the build .config and regenerating it. My changes were to take that ${B}/.config as input instead of replacing it. But that shouldn't affect the files in .meta/cfg.

Separately I am confused, as I had problems with that file://sl030raspberrypii2ckernel.patch and as I look at the file it is supposedly patching drivers/i2c/busses/i2c-bcm2708.c I don't see the changes in there. 

I'll go through here in more detail. Thanks again.

(In reply to comment #19)
> OK - well thanks for verifying that it is working Bruce. I must be doing
> something wrong in my checking. I will go back through.
> 
> I had removed defconfig from linux-raspberrypi.inc as did you. I had also
> made some changes to the do_configure_prepend() step as it seemed to be
> blowing away the build .config and regenerating it. My changes were to take
> that ${B}/.config as input instead of replacing it. But that shouldn't
> affect the files in .meta/cfg.
> 
> Separately I am confused, as I had problems with that
> file://sl030raspberrypii2ckernel.patch and as I look at the file it is
> supposedly patching drivers/i2c/busses/i2c-bcm2708.c I don't see the changes
> in there. 

My top commit is this:

Which would be the patch, so everything is triggered properly and works. 

commit 3f8fabf91521107b54850e652f106bd1243b0555
Author: invalid_git config <unknown@unknown>
Date:   Mon Mar 23 12:53:00 2015 -0400

    Fix i2c timing errors.
    
    When Transmitting: Make SDA valid quarter of a cycle after the falling edge of SCL.
    When Receiving: Sample SDA Quarter of a cycle after the rising edge of SCL.
    
    Upstream-Status: Pending
    
    RP 2013/04/21

:100644 100644 526129b98b89... 08300acc1aa6... M        drivers/i2c/busses/i2c-bcm2708.c

I'll likely send this for merge Tuesday, since things are looking good on my end.


> 
> I'll go through here in more detail. Thanks again.

Glad to hear all is now working. Thanks again. I will pull and rebuild when that's' merged in then as I have been having trouble building with what I currently have here.

Hi, 

This bug is marked RESOLVED but the documentation flag is yet to be satisfied.  I have made some changes in the YP docs to attempt to cover the documentation part of this bug.  On a side note.... I think that when a bug like this is "fixed" but has a documentation component, it should not be marked RESOLVED.  I think it should have the ownership set to the documentation person and then it gets on the radar to get it fixed.  Once the doc part is completed, then it can be marked of as RESOLVED.

Here are the changes to the docs.  Please look them over and see if this meets the requirements to get the doc flag turned off.  

 * http://www.yoctoproject.org/docs/1.9/ref-manual/ref-manual.html#var-KBUILD_DEFCONFIG.  This is a new variable.

 * http://www.yoctoproject.org/docs/1.9/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file.  This is a new section in the kernel-dev manual.

 * http://www.yoctoproject.org/docs/1.9/dev-manual/dev-manual.html#creating-a-defconfig-file.  This is a new sub-section to address defconfigs in general, which I found was lacking in the YP doc set.

 * http://www.yoctoproject.org/docs/1.9/kernel-dev/kernel-dev.html#generating-configuration-files.  Step one of this section instructs the user to be sure to run a build at least through the configuration steps.  I have added a bit of rationale to this step.

 * http://www.yoctoproject.org/docs/1.9/dev-manual/dev-manual.html#using-menuconfig.  I also added that 'bitbake linux-yocto -c kernel_configme -f' command to this section for consistency.

Thanks,
Scott

Hi,

Verified with latest master hash of YP:
505a82673ac2487df5ea343a6422c2fc47018831
and for meta-raspberrypi:
20c8e6a5bce17fba97af7365d8bdf04e5c7b17b9
on an Ubuntu machine

Verifying this feature was based on comment#14 and #18

Also had a look on comment's #22 documentation changes. Awaiting on Bruce confirmation for this one, as he's the best to confirm. Will mark as verified after this.

I have reviewed the information that Scott added into manuals in relationship to this enhancement and the clarifications he added.
Seems to be ok, however, some steps I did not do on my own, maybe that would be a proper way to verify the technical accuracy of the added documentation.
I would signal that in the aforementioned sections, there is not a strong consistency in the way the kernel config file can be find in the build directory between different sections of the documentation.

Meaning:
1. In "http://www.yoctoproject.org/docs/1.9/dev-manual/dev-manual.html#using-menuconfig": "Saving the selections updates the .config configuration file. This is the file that the OpenEmbedded build system uses to configure the kernel during the build. You can find and examine this file in the Build Directory in tmp/work/. The actual .config is located in the area where the specific kernel is built. For example, if you were building a Linux Yocto kernel based on the Linux 3.14 kernel and you were building a QEMU image targeted for x86 architecture, the .config file would be located here:

     poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.14.11+git1+84f...
        ...656ed30-r1/linux-qemux86-standard-build"

2. In "http://www.yoctoproject.org/docs/1.9/kernel-dev/kernel-dev.html#generating-configuration-files"": "The resulting .config file is located in ${WORKDIR} under the linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build directory. You can use the entire .config file as the defconfig file as described in the "Changing the Configuration" section."

Regards,
Cristian

as per comment#23 changing state to need info. The feature is verified, but need documentation confirmation

... changing to NEEDINFO

I prepared a patch for meta-raspberrypi to use in-tree defconfig and kernel fragments.

ref: https://lists.yoctoproject.org/pipermail/yocto/2015-October/027034.html

I find that this works, picks up the correct defconfig, and can be used to apply .cfg fragments but when I change SRC_URI I get a build failure.

e.g. I build core-image-minimal successfully against meta-yocto master #505a8267, then change SRC_URI to add

SRC_URI += "file://build-in-audio.cfg"

Where the .cfg file contains

CONFIG_SND=y
CONFIG_SND_BCM2835=y

I then get the following during the kernel build

| make[3]: `arch/arm/boot/dts/bcm2708-rpi-b.dtb' is up to date.
| NOTE: make -j 8 bcm2708-rpi-b-plus.dtb
| make[3]: `arch/arm/boot/dts/bcm2708-rpi-b-plus.dtb' is up to date.
| NOTE: make -j 8 bcm2709-rpi-2-b.dtb
| make[3]: `arch/arm/boot/dts/bcm2709-rpi-2-b.dtb' is up to date.
| NOTE: make -j 8 overlays/hifiberry-amp-overlay.dtb
|   DTC     arch/arm/boot/dts/overlays/hifiberry-amp-overlay.dtb
| ERROR (phandle_references): Reference to non-existent node or label "sound"
|
| ERROR (phandle_references): Reference to non-existent node or label "i2s"
|
| ERROR (phandle_references): Reference to non-existent node or label "i2s"
|
| ERROR (phandle_references): Reference to non-existent node or label "i2c1"
|
| ERROR: Input tree has errors, aborting (use -f to force output)
| make[3]: *** [arch/arm/boot/dts/overlays/hifiberry-amp-overlay.dtb] Error 2
| make[2]: *** [overlays/hifiberry-amp-overlay.dtb] Error 2
| make[1]: *** [sub-make] Error 2
| make: *** [__sub-make] Error 2
| ERROR: oe_runmake failed

If I then run bitbake -c cleansstate virtual/kernel I can follow with a build of core-image-minimal which builds the kernel and completes successfully.

So I am unsure whether this is a misconfiguration on my part or whether there is some kind of fragment related dependency which needs to be picked up when SRC_URI changes?

Hi Alex,

I admit that each time i did the new image, i used the "-c cleansstate". This is part of doing it "clean", but i think your observation is good there. Changing SRC_URI should not determine a build failure. I will test that too.

Thanks Costin

Cristian, 

Regarding Comment 24, I added a cross-reference in the kernel-dev manual that points back to that section in the dev-manual where the .config file has the example for locating it.  I hope this can tie the two areas together better.

See http://www.yoctoproject.org/docs/2.0/kernel-dev/kernel-dev.html#generating-configuration-files.

Thanks, 
Scott

Bruce,

Can you please verify the documentation for this bug.

Thanks,

(In reply to comment #31)
> Bruce,
> 
> Can you please verify the documentation for this bug.
> 
> Thanks,

Ack'd. Will do shortly.

(In reply to comment #32)
> (In reply to comment #31)
> > Bruce,
> > 
> > Can you please verify the documentation for this bug.
> > 
> > Thanks,
> 
> Ack'd. Will do shortly.

The documentation looked fine to me. I've moved this to resolved. We can re-open if we need more.

Hello,

Checked documentation and looks fine.
Also in regards to comment#28, kernel built fine without doing cleansstate.
I applied several SRC_URI changes and worked well.

In order to force rebuild, i changed SRC_URI several times from a) to b) and viceversa:

a)
SRC_URI += "file://defconfig \
            file://myconf.cfg \
            "

b)
SRC_URI += "file://defconfig \
            file://myconf.cfg \
            \
            "

poky:master:0727d2a62c3269f7ba9ef76583bfe0955be6da84

Marking as verified.