Skip to contentSkip to conversation

is there a known issue with how SRC_URI uses OVERRIDES to locate .scc files?

DISCUSSION Robert P. J. Day 3 participants 11 messages Apr 20, 2016 – Apr 21, 2016

lore
Share & tools
lore

Robert P. J. Day

author
#0 lore raw

(i'm using wind river linux for this, but i'm getting the impression
that this might be coming from YP, so i'm going to ask here.)

while i'm trying to reduce this to a minimal test case, here's the
really annoying issue i'm running into.

i created a BSP layer, and under recipes-kernel/linux/ i created
three subdirs to hold SRC_URI content:

 * linux-windriver-3.14/         (3.14-specific)
 * linux-windriver-4.1/          (4.1-specific)
 * linux-windriver/              (applicable to either kernel)

in addition, i have subdirectories for three possible target boards, and i also extended MACHINEOVERRIDES to define a common grouping for two of those boards. and here's the problem.

i have files:

* uio.scc
* uio.cfg
* uio.patch

that used to apply to the two common boards, but should now apply to all three, for all kernels. so i used to have the directory structure:

linux-windriver/
common/ (represents the 2 out of 3 related boards)
uio.scc
uio.cfg
uio.patch

and the uio stuff was located just fine when building for either of the two target boards for which "common" was my extension to MACHINEOVERRIDES.

now that it applies to all three boards, i did this just as a test
(as you can see, unnecessary duplication of the uio files):

linux-windriver/
uio.scc
uio.cfg
uio.patch
common/
uio.scc
uio.cfg
uio.patch

and all three boards can now build. however, when i went to get rid of the redundant stuff and reduce it to:

linux-windriver/
uio.scc
uio.cfg
uio.patch
common/
... remaining stuff that still applies only to common ...

i can still build that third board, but now the two "common" boards fail to process the kernel fragment uio.cfg. having moved that completely common uio content out of the subdirectory and right under linux-windriver now breaks the boards for which there is still a subdirectory, for no reason that i can see.

it's as if, once the build process sees a more specific
MACHINEOVERRIDES directory from which to get content, it will no longer look elsewhere, even above for more generically appropriate content.

am i misunderstanding something? it seems that the common thread
running through all my problems with this is *.cfg files at the top level of one of these directories.

anyone seen anything like this?

rday

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#1 lore raw
Quoted 71 lines · Robert P. J. Day

(i'm using wind river linux for this, but i'm getting the impression
that this might be coming from YP, so i'm going to ask here.)

while i'm trying to reduce this to a minimal test case, here's the
really annoying issue i'm running into.

i created a BSP layer, and under recipes-kernel/linux/ i created
three subdirs to hold SRC_URI content:

 * linux-windriver-3.14/         (3.14-specific)
 * linux-windriver-4.1/          (4.1-specific)
 * linux-windriver/              (applicable to either kernel)

in addition, i have subdirectories for three possible target boards, and i also extended MACHINEOVERRIDES to define a common grouping for two of those boards. and here's the problem.

i have files:

* uio.scc
* uio.cfg
* uio.patch

that used to apply to the two common boards, but should now apply to all three, for all kernels. so i used to have the directory structure:

linux-windriver/
common/ (represents the 2 out of 3 related boards)
uio.scc
uio.cfg
uio.patch

and the uio stuff was located just fine when building for either of the two target boards for which "common" was my extension to MACHINEOVERRIDES.

now that it applies to all three boards, i did this just as a test
(as you can see, unnecessary duplication of the uio files):

linux-windriver/
uio.scc
uio.cfg
uio.patch
common/
uio.scc
uio.cfg
uio.patch

and all three boards can now build. however, when i went to get rid of the redundant stuff and reduce it to:

linux-windriver/
uio.scc
uio.cfg
uio.patch
common/
... remaining stuff that still applies only to common ...

i can still build that third board, but now the two "common" boards fail to process the kernel fragment uio.cfg. having moved that completely common uio content out of the subdirectory and right under linux-windriver now breaks the boards for which there is still a subdirectory, for no reason that i can see.

it's as if, once the build process sees a more specific
MACHINEOVERRIDES directory from which to get content, it will no longer look elsewhere, even above for more generically appropriate content.

Quoted 5 lines

am i misunderstanding something? it seems that the common thread
running through all my problems with this is *.cfg files at the top level of one of these directories.

anyone seen anything like this?

Did you check FILESPATH variable to see order of directories how they are searched?

e.g.:

$ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g; s/:/\n/g;"
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/
Signature · 1 line
Martin 'JaMa' Jansa     jabber: [email protected]
author
#2 lore raw
Quoted 93 lines · Martin Jansa
Quoted 71 lines · Robert P. J. Day

(i'm using wind river linux for this, but i'm getting the impression
that this might be coming from YP, so i'm going to ask here.)

while i'm trying to reduce this to a minimal test case, here's the
really annoying issue i'm running into.

i created a BSP layer, and under recipes-kernel/linux/ i created
three subdirs to hold SRC_URI content:

 * linux-windriver-3.14/         (3.14-specific)
 * linux-windriver-4.1/          (4.1-specific)
 * linux-windriver/              (applicable to either kernel)

in addition, i have subdirectories for three possible target boards, and i also extended MACHINEOVERRIDES to define a common grouping for two of those boards. and here's the problem.

i have files:

* uio.scc
* uio.cfg
* uio.patch

that used to apply to the two common boards, but should now apply to all three, for all kernels. so i used to have the directory structure:

linux-windriver/
common/ (represents the 2 out of 3 related boards)
uio.scc
uio.cfg
uio.patch

and the uio stuff was located just fine when building for either of the two target boards for which "common" was my extension to MACHINEOVERRIDES.

now that it applies to all three boards, i did this just as a test
(as you can see, unnecessary duplication of the uio files):

linux-windriver/
uio.scc
uio.cfg
uio.patch
common/
uio.scc
uio.cfg
uio.patch

and all three boards can now build. however, when i went to get rid of the redundant stuff and reduce it to:

linux-windriver/
uio.scc
uio.cfg
uio.patch
common/
... remaining stuff that still applies only to common ...

i can still build that third board, but now the two "common" boards fail to process the kernel fragment uio.cfg. having moved that completely common uio content out of the subdirectory and right under linux-windriver now breaks the boards for which there is still a subdirectory, for no reason that i can see.

it's as if, once the build process sees a more specific
MACHINEOVERRIDES directory from which to get content, it will no longer look elsewhere, even above for more generically appropriate content.

Quoted 5 lines

am i misunderstanding something? it seems that the common thread
running through all my problems with this is *.cfg files at the top level of one of these directories.

anyone seen anything like this?

Did you check FILESPATH variable to see order of directories how they are searched?

e.g.:

$ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g; s/:/\n/g;"
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86
Quoted 8 lines
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/

yes, and they all look fine, but here's the latest development which
should clarify things.

here's the structure of the generic linux-windriver/ directory,
under which the search should look for anything which hasn't matched anything more specific in terms of a kernel version:

linux-windriver/

├── 0001-UIO-support-for-FPGA-select-CONFIG_UIO_XII_FPGA-y.patch
├  mxeiii
   ... mxe board specific stuff but *no* uio-related stuff
├── uio.cfg
└── uio.scc

so what we have is the UIO stuff *immediately* under
linux-windriver/, which is where it should be found (there is no other UIO content anywhere else in the recipe directory).

after doing the configure, here's the content of
bitbake_build/tmp/work-shared/ax/kernel-source/.kernel-meta/cfg/standard/ax/config.log:

[INFO] Sanitizing .kernel-meta/cfg/ax/new_board.cfg [INFO] Sanitizing .kernel-meta/cfg/linux-windriver/uio.cfg [INFO] Sanitizing .kernel-meta/cfg/kernel-meta/cfg/systemd.cfg

note carefully how that second line shows clearly where the uio.cfg file is being found(?): linux-windriver/uio.cfg

and that's for the board that works.

however, for the second board (the mxeiii for which there *is* a
subdirectory that should be examined), here's the equivalent config.log file:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg [INFO] Sanitizing .kernel-meta/cfg/uio.cfg [ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist

note the difference in the second line in the two cases -- the subdirectory name "linux-windriver" has disappeared, hence the second case fails miserably in locating the config fragment file uio.cfg.

it's as if (and i'm just making this up now) the fact that a more
specific "mxeiii" subdirectory under linux-windriver/ somehow screws up the search process. (if i redundantly duplicate those UIO files in the mxeiii/ subdirectory, then everything works fine, but that should *not* be necessary.)

is there something about the SRC_URI search order that i'm unaware
of? should each SRC_URI item start a brand new, independent search? i've been fighting with this for a while, and it simply makes no sense to me.

rday

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#3 lore raw
Quoted 163 lines · Robert P. J. Day
Quoted 76 lines · Martin Jansa
Quoted 75 lines · Robert P. J. Day

(i'm using wind river linux for this, but i'm getting the impression
that this might be coming from YP, so i'm going to ask here.)

while i'm trying to reduce this to a minimal test case, here's the
really annoying issue i'm running into.

i created a BSP layer, and under recipes-kernel/linux/ i created
three subdirs to hold SRC_URI content:

 * linux-windriver-3.14/         (3.14-specific)
 * linux-windriver-4.1/          (4.1-specific)
 * linux-windriver/              (applicable to either kernel)

in addition, i have subdirectories for three possible target boards, and i also extended MACHINEOVERRIDES to define a common grouping for two of those boards. and here's the problem.

i have files:

* uio.scc
* uio.cfg
* uio.patch

that used to apply to the two common boards, but should now apply to all three, for all kernels. so i used to have the directory structure:

linux-windriver/
common/ (represents the 2 out of 3 related boards)
uio.scc
uio.cfg
uio.patch

and the uio stuff was located just fine when building for either of the two target boards for which "common" was my extension to MACHINEOVERRIDES.

now that it applies to all three boards, i did this just as a test
(as you can see, unnecessary duplication of the uio files):

linux-windriver/
uio.scc
uio.cfg
uio.patch
common/
uio.scc
uio.cfg
uio.patch

and all three boards can now build. however, when i went to get rid of the redundant stuff and reduce it to:

linux-windriver/
uio.scc
uio.cfg
uio.patch
common/
... remaining stuff that still applies only to common ...

i can still build that third board, but now the two "common" boards fail to process the kernel fragment uio.cfg. having moved that completely common uio content out of the subdirectory and right under linux-windriver now breaks the boards for which there is still a subdirectory, for no reason that i can see.

it's as if, once the build process sees a more specific
MACHINEOVERRIDES directory from which to get content, it will no longer look elsewhere, even above for more generically appropriate content.

am i misunderstanding something? it seems that the common thread
running through all my problems with this is *.cfg files at the top level of one of these directories.

Quoted 7 lines
Quoted 1 line

anyone seen anything like this?

Did you check FILESPATH variable to see order of directories how they are searched?

e.g.:

$ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g;

s/:/\n/g;"

Quoted 1 line

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro

Quoted 1 line

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro

Quoted 1 line

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro

Quoted 1 line

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86

Quoted 2 lines

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86

Quoted 1 line

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall

Quoted 2 lines

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall

Quoted 1 line

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86

Quoted 3 lines

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86 /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586

Quoted 5 lines

/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586 /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586 /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/ /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/ /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/

yes, and they all look fine, but here's the latest development which
should clarify things.

here's the structure of the generic linux-windriver/ directory,
under which the search should look for anything which hasn't matched anything more specific in terms of a kernel version:

linux-windriver/

├── 0001-UIO-support-for-FPGA-select-CONFIG_UIO_XII_FPGA-y.patch
├  mxeiii
   ... mxe board specific stuff but *no* uio-related stuff
├── uio.cfg
└── uio.scc

so what we have is the UIO stuff *immediately* under
linux-windriver/, which is where it should be found (there is no other UIO content anywhere else in the recipe directory).

after doing the configure, here's the content of

bitbake_build/tmp/work-shared/ax/kernel-source/.kernel-meta/cfg/standard/ax/config.log:

[INFO] Sanitizing .kernel-meta/cfg/ax/new_board.cfg [INFO] Sanitizing .kernel-meta/cfg/linux-windriver/uio.cfg [INFO] Sanitizing .kernel-meta/cfg/kernel-meta/cfg/systemd.cfg

note carefully how that second line shows clearly where the uio.cfg file is being found(?): linux-windriver/uio.cfg

and that's for the board that works.

however, for the second board (the mxeiii for which there *is* a
subdirectory that should be examined), here's the equivalent config.log file:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg [INFO] Sanitizing .kernel-meta/cfg/uio.cfg [ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist

note the difference in the second line in the two cases -- the subdirectory name "linux-windriver" has disappeared, hence the second case fails miserably in locating the config fragment file uio.cfg.

it's as if (and i'm just making this up now) the fact that a more
specific "mxeiii" subdirectory under linux-windriver/ somehow screws up the search process. (if i redundantly duplicate those UIO files in the mxeiii/ subdirectory, then everything works fine, but that should *not* be necessary.)

Quoted 5 lines

is there something about the SRC_URI search order that i'm unaware
of? should each SRC_URI item start a brand new, independent search? i've been fighting with this for a while, and it simply makes no sense to me.

You haven't supplied your SRC_URI in the question ... what does it look like ?

It has no relation to the SRC_URI, probably a run of the mill bug in the processing code.
I'd suggest taking it up with Wind River support.

Alternatively, if you have this somewhere that I clone and launch a test build, I can
help you out .. but I won't be able to easily reproduce that situation from scratch.

Cheers,

Bruce

Quoted 20 lines

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday

========================================================================

--
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
author
#4 lore raw
Quoted 155 lines · Bruce Ashfield

On Wed, Apr 20, 2016 at 2:31 PM, Robert P. J. Day <[email protected]> wrote:
On Wed, 20 Apr 2016, Martin Jansa wrote:

> On Wed, Apr 20, 2016 at 12:42:42PM -0400, Robert P. J. Day wrote:
> >
> >   (i'm using wind river linux for this, but i'm getting the impression > > that this might be coming from YP, so i'm going to ask here.)
> >
> >   while i'm trying to reduce this to a minimal test case, here's the > > really annoying issue i'm running into.
> >
> >   i created a BSP layer, and under recipes-kernel/linux/ i created > > three subdirs to hold SRC_URI content:
> >
> >  * linux-windriver-3.14/         (3.14-specific)
> >  * linux-windriver-4.1/          (4.1-specific)
> >  * linux-windriver/              (applicable to either kernel)
> >
> > in addition, i have subdirectories for three possible target boards, > > and i also extended MACHINEOVERRIDES to define a common grouping for > > two of those boards. and here's the problem.
> >
> >   i have files:
> >
> >  * uio.scc
> >  * uio.cfg
> >  * uio.patch
> >
> > that used to apply to the two common boards, but should now apply to > > all three, for all kernels.  so i used to have the directory
> > structure:
> >
> >   linux-windriver/
> >     common/               (represents the 2 out of 3 related boards) > >       uio.scc
> >       uio.cfg
> >       uio.patch
> >
> > and the uio stuff was located just fine when building for either of > > the two target boards for which "common" was my extension to
> > MACHINEOVERRIDES.
> >
> >   now that it applies to all three boards, i did this just as a test > > (as you can see, unnecessary duplication of the uio files):
> >
> >   linux-windriver/
> >     uio.scc
> >     uio.cfg
> >     uio.patch
> >     common/
> >       uio.scc
> >       uio.cfg
> >       uio.patch
> >
> > and all three boards can now build. however, when i went to get rid of > > the redundant stuff and reduce it to:
> >
> >   linux-windriver/
> >     uio.scc
> >     uio.cfg
> >     uio.patch
> >     common/
> >       ... remaining stuff that still applies only to common ...
> >
> > i can still build that third board, but now the two "common" boards > > fail to process the kernel fragment uio.cfg. having moved that
> > completely common uio content out of the subdirectory and right under > > linux-windriver now breaks the boards for which there is still a > > subdirectory, for no reason that i can see.
> >
> >   it's as if, once the build process sees a more specific
> > MACHINEOVERRIDES directory from which to get content, it will no > > longer look elsewhere, even above for more generically appropriate > > content.
> >
> >   am i misunderstanding something? it seems that the common thread > > running through all my problems with this is *.cfg files at the top > > level of one of these directories.
> >
> >   anyone seen anything like this?
>
> Did you check FILESPATH variable to see order of directories how they > are searched?
>
> e.g.:
> $ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g; s/:/\n/g;" > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86 > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86 > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86 > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86 > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86 > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86 > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586 > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586 > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586 > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/ > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/ > /OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/

  yes, and they all look fine, but here's the latest development which should clarify things.

  here's the structure of the generic linux-windriver/ directory, under which the search should look for anything which hasn't matched anything more specific in terms of a kernel version:

linux-windriver/

├── 0001-UIO-support-for-FPGA-select-CONFIG_UIO_XII_FPGA-y.patch
├  mxeiii
   ... mxe board specific stuff but *no* uio-related stuff
├── uio.cfg
└── uio.scc

  so what we have is the UIO stuff *immediately* under linux-windriver/, which is where it should be found (there is no other UIO content anywhere else in the recipe directory).

  after doing the configure, here's the content of bitbake_build/tmp/work-shared/ax/kernel-source/.kernel-meta/cfg/standard/ax/config.log:

[INFO] Sanitizing .kernel-meta/cfg/ax/new_board.cfg [INFO] Sanitizing .kernel-meta/cfg/linux-windriver/uio.cfg [INFO] Sanitizing .kernel-meta/cfg/kernel-meta/cfg/systemd.cfg

note carefully how that second line shows clearly where the uio.cfg file is being found(?): linux-windriver/uio.cfg

and that's for the board that works.

  however, for the second board (the mxeiii for which there *is* a subdirectory that should be examined), here's the equivalent config.log file:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg [INFO] Sanitizing .kernel-meta/cfg/uio.cfg [ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist

note the difference in the second line in the two cases -- the subdirectory name "linux-windriver" has disappeared, hence the second case fails miserably in locating the config fragment file uio.cfg.

  it's as if (and i'm just making this up now) the fact that a more specific "mxeiii" subdirectory under linux-windriver/ somehow screws up the search process. (if i redundantly duplicate those UIO files in the mxeiii/ subdirectory, then everything works fine, but that should *not* be necessary.)

Quoted 7 lines

  is there something about the SRC_URI search order that i'm unaware of? should each SRC_URI item start a brand new, independent search? i've been fighting with this for a while, and it simply makes no sense to me.

You haven't supplied your SRC_URI in the question ... what does it look like ?

the first part is:

SRC_URI += " \
        file://new_board.scc \
        file://uio.scc \

"

there's more but the above is where the problem appears.

Quoted 3 lines

It has no relation to the SRC_URI, probably a run of the mill bug in the processing code. I'd suggest taking it up with Wind River support.

already have, the person i chatted with muttered something about
backtracking to YP code which is why i thought i would ask here. i've seen problems related to this before which seem related to kernel config fragment files being at the very top of a kernel recipe subdirectory.

Quoted 3 lines

Alternatively, if you have this somewhere that I clone and launch a test build, I can help you out .. but I won't be able to easily reproduce that situation from scratch.

i'm building a minimal test case to see if i can duplicate this. but
i've definitely reproduced this issue several times today alone.

rday

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
author
#5 lore raw
In reply to Bruce Ashfield

ok, i've narrowed this down to a fairly trivial case, so allow me to
describe it. first, in my kernel recipes directory structure, i have subdirectories:

linux-windriver-3.14/
linux-windriver-4.1/
linux-windriver/

and that last directory contains:

$ tree linux-windriver
linux-windriver
├── mxeiii            (target board in question)
│   ├── mm.patch
│   └── mm.scc
├── ssd_sil.cfg
├── ssd_sil.patch
├── ssd_sil.scc
├── uio.cfg
├── uio.patch
└── uio.scc

so, that directory contains two SRC_URI items *immediately*
underneath, and one more further under mxeiii/, which is my target board.

first experiment:

SRC_URI += " \
        file://new_board.scc \           (adding this has no effect)
        file://uio.scc \
        file://ssd_sil.scc \

"

so (other than new_board.scc), i am processing only .scc files immediately under linux-windriver/. and that works fine:

  $ make linux-windriver.configure

and i can list bitbake_build/tmp/work-shared/mxeiii/kernel-source/.kernel-meta/cfg/standard/mxeiii/config.log:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
[INFO] Sanitizing .kernel-meta/cfg/scratch/obj/home/rpjday/swe/recipes-kernel/linux/linux-windriver/uio.cfg [INFO] Sanitizing .kernel-meta/cfg/scratch/obj/home/rpjday/swe/recipes-kernel/linux/linux-windriver/ssd_sil.cfg [INFO] Sanitizing .kernel-meta/cfg/kernel-meta/cfg/systemd.cfg

so far, so good.

now, let's extend SRC_URI to pick up one more item, but this one
from the lower mxeiii/ directory:

SRC_URI += " \
        file://new_board.scc \
        file://uio.scc \
        file://ssd_sil.scc \
        file://mm.scc \              <----- new item

"

after a clean and configure:

ERROR: Function failed: do_kernel_configme (log file is located at /home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/log.do_kernel_configme.11821)
ERROR: Logfile of failure stored in:
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/log.do_kernel_configme.11821 Log data follows:

| DEBUG: Executing shell function do_kernel_configme
| NOTE: kernel configme
| [INFO] Configuring target/machine combo: "standard/mxeiii"
| ERROR: could not sanitize configuration fragments
|    errors are logged in

/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work-shared/mxeiii/kernel-source/.kernel-meta/cfg/standard/mxeiii/config.log | WARNING:
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/run.do_kernel_configme.11821:1 exit 1 from
| configme ${configmeflags} --reconfig --output
/home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/linux-mxeiii-standard-build standard mxeiii
| ERROR: Function failed: do_kernel_configme (log file is located at /home/rpjday/Builds/swe/8/m/bitbake_build/tmp/work/mxeiii-wrs-linux/linux-windriver/4.1-r0/temp/do_kernel_configme/log.do_kernel_configme.11821)
ERROR: Task 6
(/home/rpjday/Builds/swe/8/m/layers/wr-kernel/recipes-kernel/linux/linux-windriver_4.1.bb,
do_kernel_configme) failed with exit code '1'

and here's the config.log file from that attempt:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg [INFO] Sanitizing .kernel-meta/cfg/uio.cfg [ERROR] Kern frag .kernel-meta/cfg/uio.cfg does not exist

Notice how this differs from the first two lines from the successful configure before:

[INFO] Sanitizing .kernel-meta/cfg/mxeiii/new_board.cfg
[INFO] Sanitizing .kernel-meta/cfg/scratch/obj/home/rpjday/swe/recipes-kernel/linux/linux-windriver/uio.cfg

The pattern appears to be that, once the SRC_URI search is forced to enter that mxeiii/ subdirectory to find something, the search for previously found SRC_URI items gets totally borked.

I've tried this several times, and the behaviour is consistent.

rday

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
author
#6 lore raw
In reply to Bruce Ashfield
Quoted 10 lines · Bruce Ashfield

You haven't supplied your SRC_URI in the question ... what does it look like ?

It has no relation to the SRC_URI, probably a run of the mill bug in the processing code. I'd suggest taking it up with Wind River support.

Alternatively, if you have this somewhere that I clone and launch a test build, I can help you out .. but I won't be able to easily reproduce that situation from scratch.

ok, i found what appears to be a cheap workaround for this, and i'm
curious if this makes any sense. recall original kernel recipe directory structure:

linux-windriver/

    uio.*
    ssd.*
    mxeiii/
      mm.*

when SRC_URI mentioned only that first-level stuff (uio, ssd), then the configure step worked fine. but as soon as i added the mm.scc file to SRC_URI, it just seems that any descent into a lower-level directory based on OVERRIDES totally bones the search process. so, i wondered, how can i work around this?

oh, wait, no problem. see, all target boards are powerpc, so
"powerpc" is one of the possible OVERRIDES. obviously, there is no *actual* value in using an OVERRIDE for which *every* *single* *board* is compatible ... oh, wait, there is.

so i restructured:

linux-windriver/

    mxeiii/
      mm.*
    powerpc/
      uio.*
      ssd.*

it looks idiotic to take the uio.* and ssd.* content, which should be generic, and deliberately put it in a subdirectory, unless that subdirectory represents an OVERRIDE which matches every board and, ta da, solves the problem.

i need a drink.

rday

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
#7 lore raw
Quoted 43 lines · Robert P. J. Day
Quoted 10 lines · Bruce Ashfield

You haven't supplied your SRC_URI in the question ... what does it look like ?

It has no relation to the SRC_URI, probably a run of the mill bug in the processing code. I'd suggest taking it up with Wind River support.

Alternatively, if you have this somewhere that I clone and launch a test build, I can help you out .. but I won't be able to easily reproduce that situation from scratch.

ok, i found what appears to be a cheap workaround for this, and i'm
curious if this makes any sense. recall original kernel recipe directory structure:

linux-windriver/

    uio.*
    ssd.*
    mxeiii/
      mm.*

when SRC_URI mentioned only that first-level stuff (uio, ssd), then the configure step worked fine. but as soon as i added the mm.scc file to SRC_URI, it just seems that any descent into a lower-level directory based on OVERRIDES totally bones the search process. so, i wondered, how can i work around this?

oh, wait, no problem. see, all target boards are powerpc, so
"powerpc" is one of the possible OVERRIDES. obviously, there is no *actual* value in using an OVERRIDE for which *every* *single* *board* is compatible ... oh, wait, there is.

so i restructured:

linux-windriver/

    mxeiii/
      mm.*
    powerpc/
      uio.*
      ssd.*
Quoted 6 lines

it looks idiotic to take the uio.* and ssd.* content, which should be generic, and deliberately put it in a subdirectory, unless that subdirectory represents an OVERRIDE which matches every board and, ta da, solves the problem.

i need a drink.

Following up to the list. I was able to take a reproducer for this and indeed find some *really*
old code that didn't handle a trailing / properly. The end result was the inability to find the
configuration fragments that were not in subdirectories.

Amazing ability to shoot through corner cases and trigger the problem.

I've made the minor tweak to the processing and will let it soak for a bit .. but this should
now be solved.

.. now I need a drink.

Bruce

Quoted 17 lines

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday

========================================================================

Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
author
#8 lore raw
Quoted 51 lines · Bruce Ashfield

On Wed, Apr 20, 2016 at 6:37 PM, Robert P. J. Day <[email protected]> wrote:
On Wed, 20 Apr 2016, Bruce Ashfield wrote:

> You haven't supplied your SRC_URI in the question ... what does it > look like ?
>
> It has no relation to the SRC_URI, probably a run of the mill bug in > the processing code. I'd suggest taking it up with Wind River > support.
>
> Alternatively, if you have this somewhere that I clone and launch a > test build, I can help you out .. but I won't be able to easily > reproduce that situation from scratch.

  ok, i found what appears to be a cheap workaround for this, and i'm curious if this makes any sense.  recall original kernel recipe directory structure:

  linux-windriver/
    uio.*
    ssd.*
    mxeiii/
      mm.*

when SRC_URI mentioned only that first-level stuff (uio, ssd), then the configure step worked fine. but as soon as i added the mm.scc file to SRC_URI, it just seems that any descent into a lower-level directory based on OVERRIDES totally bones the search process. so, i wondered, how can i work around this?

  oh, wait, no problem. see, all target boards are powerpc, so "powerpc" is one of the possible OVERRIDES. obviously, there is no *actual* value in using an OVERRIDE for which *every* *single* *board* is compatible ... oh, wait, there is.

  so i restructured:

  linux-windriver/
    mxeiii/
      mm.*
    powerpc/
      uio.*
      ssd.*

it looks idiotic to take the uio.* and ssd.* content, which should be generic, and deliberately put it in a subdirectory, unless that subdirectory represents an OVERRIDE which matches every board and, ta da, solves the problem.

Quoted 7 lines

  i need a drink.

Following up to the list. I was able to take a reproducer for this and indeed find some *really* old code that didn't handle a trailing / properly. The end result was the inability to find the configuration fragments that were not in subdirectories.

just to be clear, there was no problem finding config fragments that
were not in subdirectories until i somehow triggered the bug by *adding* an item that *was* in a subdirectory, and that's when things went to hell.

so the "bug" apparently never manifested itself until i triggered it
by doing something else. does that sound about right?

rday

#9 lore raw
Quoted 71 lines · Robert P. J. Day
Quoted 3 lines · Bruce Ashfield

On Wed, Apr 20, 2016 at 6:37 PM, Robert P. J. Day <[email protected]>

Quoted 3 lines · wrote:

On Wed, 20 Apr 2016, Bruce Ashfield wrote:

> You haven't supplied your SRC_URI in the question ... what does

it

Quoted 3 lines

> look like ?
>
> It has no relation to the SRC_URI, probably a run of the mill

bug in

Quoted 4 lines

> the processing code. I'd suggest taking it up with Wind River > support.
>
> Alternatively, if you have this somewhere that I clone and

launch a

Quoted 4 lines

> test build, I can help you out .. but I won't be able to easily > reproduce that situation from scratch.

ok, i found what appears to be a cheap workaround for this, and

i'm

Quoted 11 lines

curious if this makes any sense. recall original kernel recipe directory structure:

linux-windriver/
uio.*
ssd.*
mxeiii/
mm.*

when SRC_URI mentioned only that first-level stuff (uio, ssd), then the configure step worked fine. but as soon as i added the mm.scc

file

Quoted 2 lines

to SRC_URI, it just seems that any descent into a lower-level directory based on OVERRIDES totally bones the search process. so,

i

Quoted 5 lines

wondered, how can i work around this?

oh, wait, no problem. see, all target boards are powerpc, so
"powerpc" is one of the possible OVERRIDES. obviously, there is no *actual* value in using an OVERRIDE for which *every* *single*

*board*

Quoted 4 lines

is compatible ... oh, wait, there is.

so i restructured:

Quoted 8 lines

linux-windriver/
mxeiii/
mm.*
powerpc/
uio.*
ssd.*

it looks idiotic to take the uio.* and ssd.* content, which should

be

Quoted 2 lines

generic, and deliberately put it in a subdirectory, unless that subdirectory represents an OVERRIDE which matches every board and,

ta

Quoted 9 lines

da, solves the problem.

i need a drink.

Following up to the list. I was able to take a reproducer for this and indeed find some *really* old code that didn't handle a trailing / properly. The end result was the inability to find the configuration fragments that were not in subdirectories.

Quoted 8 lines

just to be clear, there was no problem finding config fragments that
were not in subdirectories until i somehow triggered the bug by *adding* an item that *was* in a subdirectory, and that's when things went to hell.

so the "bug" apparently never manifested itself until i triggered it
by doing something else. does that sound about right?

Correct. The subdirs were getting a trailing / and hence when the fragments were
all gathered up (in case the original location is remote), they were being dumped
into .kernel-meta/cfg/<the absolute path to the fragment>/foo.cfg.

Later on the configuration was looking for them in just <subdir>/foo.cfg .. and
couldn't find them.

Bloody trailing slashes!

Bruce

Quoted 2 lines

rday

Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
author
#10 lore raw
In reply to Martin Jansa
Quoted 93 lines · Martin Jansa
Quoted 71 lines · Robert P. J. Day

(i'm using wind river linux for this, but i'm getting the impression
that this might be coming from YP, so i'm going to ask here.)

while i'm trying to reduce this to a minimal test case, here's the
really annoying issue i'm running into.

i created a BSP layer, and under recipes-kernel/linux/ i created
three subdirs to hold SRC_URI content:

 * linux-windriver-3.14/         (3.14-specific)
 * linux-windriver-4.1/          (4.1-specific)
 * linux-windriver/              (applicable to either kernel)

in addition, i have subdirectories for three possible target boards, and i also extended MACHINEOVERRIDES to define a common grouping for two of those boards. and here's the problem.

i have files:

* uio.scc
* uio.cfg
* uio.patch

that used to apply to the two common boards, but should now apply to all three, for all kernels. so i used to have the directory structure:

linux-windriver/
common/ (represents the 2 out of 3 related boards)
uio.scc
uio.cfg
uio.patch

and the uio stuff was located just fine when building for either of the two target boards for which "common" was my extension to MACHINEOVERRIDES.

now that it applies to all three boards, i did this just as a test
(as you can see, unnecessary duplication of the uio files):

linux-windriver/
uio.scc
uio.cfg
uio.patch
common/
uio.scc
uio.cfg
uio.patch

and all three boards can now build. however, when i went to get rid of the redundant stuff and reduce it to:

linux-windriver/
uio.scc
uio.cfg
uio.patch
common/
... remaining stuff that still applies only to common ...

i can still build that third board, but now the two "common" boards fail to process the kernel fragment uio.cfg. having moved that completely common uio content out of the subdirectory and right under linux-windriver now breaks the boards for which there is still a subdirectory, for no reason that i can see.

it's as if, once the build process sees a more specific
MACHINEOVERRIDES directory from which to get content, it will no longer look elsewhere, even above for more generically appropriate content.

Quoted 5 lines

am i misunderstanding something? it seems that the common thread
running through all my problems with this is *.cfg files at the top level of one of these directories.

anyone seen anything like this?

Did you check FILESPATH variable to see order of directories how they are searched?

e.g.:

$ bitbake -e sed | grep ^FILESPATH= | sed "s/FILESPATH=\"//g; s/\"$//g; s/:/\n/g;"
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/nodistro
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemux86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/qemuall
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/x86
Quoted 8 lines
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/x86
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/i586
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed-4.2.2/
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/sed/
/OE/build/oe-core/openembedded-core/meta/recipes-extended/sed/files/

BTW, my (heavily-snipped) FILESPATH includes:

/home/rpjday/swe/recipes-kernel/linux/linux-windriver-4.1/mxeiii /home/rpjday/swe/recipes-kernel/linux/linux-windriver/mxeiii /home/rpjday/swe/recipes-kernel/linux/linux-windriver-4.1/ /home/rpjday/swe/recipes-kernel/linux/linux-windriver/

i chopped out quite a number of lines that have no value to this build, but you can see the search order, particularly the second and fourth lines:

/home/rpjday/swe/recipes-kernel/linux/linux-windriver/mxeiii /home/rpjday/swe/recipes-kernel/linux/linux-windriver/

which, as i understand it, means it will look in that mxeiii-specific directory and, failing that, then look in the higher level one. that's how i'm reading FILESPATH, what am i somehow misinterpreting?

rday

Signature · 7 lines
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================