date:20161201

Re: [yocto] Shared state doesn't live up to its name?

2016-12-01 Thread Gary Thomas


On 2016-12-01 18:35, Paul Eggleton wrote:

On Thu, 01 Dec 2016 10:27:50 Gary Thomas wrote:

I have a build machine where I build for lots of targets.  On
all of these targets (save a primary), I set the SSTATE_MIRROR
to point to the sstate-cache of the primary target.  I always build
for the primary target first, then later the secondary ones.

For the most part, the sstate mechanism works pretty well, but I
see some anomalies.  For example, why on the same host, built back
to back, would a secondary build target (which uses the primary
as it's SSTATE_MIRROR and that build is complete) need to rebuild
from scratch such NATIVE packages as openssl?  Note that these are
native packages I'm asking about, so in my mind they should always
be sharable.

Any ideas?  Is there something I can look at to investigate this?


bitbake-diffsigs is the basic tool to compare signatures when those have
changed. Find the siginfo / sigdata file for one of the early tasks that
executed and compare them to see what changed.

How are you setting SSTATE_MIRRORS in this scenario btw?


SSTATE_MIRRORS ?= "\
file://.* file:///local/p0382_2016-01-13/sstate-cache/PATH"

I ran a build yesterday that caused me to comment on this pattern.  Here are the
siginfo files for the secondary target (the latest build):

-rw-rw-r-- 1 gthomas gthomas 21240 Dec  1 10:12 
sstate-cache/universal/99/sstate:openssl-native:x86_64-linux:1.0.2j:r0:x86_64:3:99515597e2223aa4413f7f2e4acf6532_configure.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas  8917 Dec  1 10:17 
sstate-cache/universal/a4/sstate:openssl-native:x86_64-linux:1.0.2j:r0:x86_64:3:a49c66a9c786fe100f8e8b6e3bbd1e86_compile.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas 14864 Dec  1 10:18 
sstate-cache/universal/a7/sstate:openssl-native:x86_64-linux:1.0.2j:r0:x86_64:3:a747322ce06467949097c3da58497c7d_install.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas 36490 Dec  1 10:18 
sstate-cache/universal/e6/sstate:openssl-native:x86_64-linux:1.0.2j:r0:x86_64:3:e65ab886428d88f8735dba617268892f_populate_sysroot.tgz.siginfo


Here are the corresponding ones from my primary target:
cb9e0e1440492b85a6a9683b_unpack.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas  6278 Nov 28 08:11 
sstate-cache/44/sstate:openssl-native::1.0.2j:r0::3:44adeda2ff6ac235331af5dae45e45ea_patch.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas  4997 Nov 28 08:11 
sstate-cache/e9/sstate:openssl-native::1.0.2j:r0::3:e9ccda2229e69e2138ad0465a709e33a_fetch.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas 21336 Nov 28 08:13 
sstate-cache/universal/99/sstate:openssl-native:x86_64-linux:1.0.2j:r0:x86_64:3:99515597e2223aa4413f7f2e4acf6532_configure.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas  8833 Nov 28 08:14 
sstate-cache/universal/a4/sstate:openssl-native:x86_64-linux:1.0.2j:r0:x86_64:3:a49c66a9c786fe100f8e8b6e3bbd1e86_compile.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas 14750 Nov 28 08:14 
sstate-cache/universal/a7/sstate:openssl-native:x86_64-linux:1.0.2j:r0:x86_64:3:a747322ce06467949097c3da58497c7d_install.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas 31029 Dec  1 09:45 
sstate-cache/57/sstate:openssl-native::1.0.2j:r0::3:5725888ec8cde61e1417bc0b6ea51c6c_populate_lic.tgz.siginfo
-rw-rw-r-- 1 gthomas gthomas 36502 Dec  1 09:45 
sstate-cache/universal/e6/sstate:openssl-native:x86_64-linux:1.0.2j:r0:x86_64:3:e65ab886428d88f8735dba617268892f_populate_sysroot.tgz.siginfo


Clearly, they are identical and the ones from the primary were built long before
the ones on the secondary target.

I'm still confused why it didn't work as expected.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto-kernel-tools and multiple users

2016-12-01 Thread Philip Balister

On 12/01/2016 08:34 PM, Bruce Ashfield wrote:
> On 12/01/2016 06:09 PM, Trevor Woerner wrote:
>> On Thu 2016-12-01 @ 05:50:21 PM, Bruce Ashfield wrote:
>>> Can you just provide me the details of exactly how you are invoking
>>> the build that triggers the error ?
>>
>> $ git clone git://git.openembedded.org/openembedded-core.git
>> (HEAD @ 11063a01d4511b2688ea7ba2d7359e4e07328c66)
>> $ git clone git://git.yoctoproject.org/meta-raspberrypi
>> (HEAD @ 44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9)
>> $ git clone git://git.openembedded.org/bitbake.git
>> (HEAD @ 0bb188f01e396052b127e170a25246d79a6d6741)
>>
>> $ openembedded-core/oe-init-build-env raspi2-test bitbake
>> $ bitbake-layers add-layer ../meta-raspberrypi
>>
>> $ MACHINE=raspberrypi2 bitbake virtual/kernel
> 
> FYI: I've found the issue and will bundle it into the /tmp/ fix
> tomorrow.

Awesome, I unstuck myself reverting a commit, but looking forward to a
real fix.

Philip

> 
> Bruce
> 
>>
>> Build Configuration:
>> BB_VERSION= "1.32.0"
>> BUILD_SYS = "x86_64-linux"
>> NATIVELSBSTRING   = "opensuse-42.2"
>> TARGET_SYS= "arm-oe-linux-gnueabi"
>> MACHINE   = "raspberrypi2"
>> DISTRO= "nodistro"
>> DISTRO_VERSION= "nodistro.0"
>> TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard
>> cortexa7"
>> TARGET_FPU= "hard"
>> meta  = "master:11063a01d4511b2688ea7ba2d7359e4e07328c66"
>> meta-raspberrypi  = "master:44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9"
>>
>> ERROR: linux-raspberrypi-1_4.4.28+gitAUTOINC+5afda48c34-r0
>> do_kernel_metadata: Function failed: do_kernel_metadata (log file is
>> located at
>> /z/layerindex-master/raspi2-basic-2/tmp-glibc/work/raspberrypi2-oe-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.9670)
>>
>> ERROR: Logfile of failure stored in:
>> /z/layerindex-master/raspi2-basic-2/tmp-glibc/work/raspberrypi2-oe-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.9670
>>
>> Log data follows:
>> | DEBUG: Executing shell function do_kernel_metadata
>> | [ERROR]: processing of file /tmp/tmp.G7DTQu11V3 failed
>> |
>> /z/layerindex-master/raspi2-basic-2/tmp-glibc/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
>> line 29: : No such file or directory
>> |
>> | Context around the error is:
>> |
>> | #
>> | prefix
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/
>>
>> | kconf non-hardware
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
>>
>> | prefix
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/
>>
>> | patch
>> "/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
>>
>> | # run time: 0 seconds
>> | # processed files:
>> | # _cfg
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
>>
>> | # _cfg
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
>>
>> |
>> | See pre-processed file /tmp/tmp.G7DTQu11V3 for more details
>> | #
>> | # scc v0.8
>> | # processed: Thu Dec  1 18:08:50 EST 2016
>> | #
>> | # This is a scc output file, do not edit
>> | #
>> | [ERROR]: processing of file /tmp/tmp.zvbMU6XqZm failed
>> | # _reloc_dir
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux
>> | # _reloc_dir
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux
>> |
>> /z/layerindex-master/raspi2-basic-2/tmp-glibc/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
>> line 29: : No such file or directory
>> |
>> | Context around the error is:
>> |
>> | #
>> | prefix
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/
>>
>> | kconf non-hardware
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
>>
>> | prefix
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/
>>
>> | patch
>> "/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
>>
>> | # run time: 0 seconds
>> | # processed files:
>> | # _cfg
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
>>
>> | # _cfg
>> /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
>>
>> |
>> | See pre-processed file /tmp/tmp.zvbMU6XqZm for more details
>> | ERROR: Function failed: do_kernel_metadata (log file is located at
>> /z/layerindex-master/raspi2-basic-2/tmp-glibc/work/raspberrypi2-oe-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.9670)
>>
>> ERROR: Task
>>

Re: [yocto] yocto-kernel-tools and multiple users

2016-12-01 Thread Bruce Ashfield


On 12/01/2016 06:09 PM, Trevor Woerner wrote:

On Thu 2016-12-01 @ 05:50:21 PM, Bruce Ashfield wrote:

Can you just provide me the details of exactly how you are invoking
the build that triggers the error ?


$ git clone git://git.openembedded.org/openembedded-core.git
(HEAD @ 11063a01d4511b2688ea7ba2d7359e4e07328c66)
$ git clone git://git.yoctoproject.org/meta-raspberrypi
(HEAD @ 44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9)
$ git clone git://git.openembedded.org/bitbake.git
(HEAD @ 0bb188f01e396052b127e170a25246d79a6d6741)

$ openembedded-core/oe-init-build-env raspi2-test bitbake
$ bitbake-layers add-layer ../meta-raspberrypi

$ MACHINE=raspberrypi2 bitbake virtual/kernel


FYI: I've found the issue and will bundle it into the /tmp/ fix
tomorrow.

Bruce



Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "opensuse-42.2"
TARGET_SYS= "arm-oe-linux-gnueabi"
MACHINE   = "raspberrypi2"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard
cortexa7"
TARGET_FPU= "hard"
meta  = "master:11063a01d4511b2688ea7ba2d7359e4e07328c66"
meta-raspberrypi  = "master:44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9"

ERROR: linux-raspberrypi-1_4.4.28+gitAUTOINC+5afda48c34-r0 do_kernel_metadata: 
Function failed: do_kernel_metadata (log file is located at 
/z/layerindex-master/raspi2-basic-2/tmp-glibc/work/raspberrypi2-oe-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.9670)
ERROR: Logfile of failure stored in: 
/z/layerindex-master/raspi2-basic-2/tmp-glibc/work/raspberrypi2-oe-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.9670
Log data follows:
| DEBUG: Executing shell function do_kernel_metadata
| [ERROR]: processing of file /tmp/tmp.G7DTQu11V3 failed
| 
/z/layerindex-master/raspi2-basic-2/tmp-glibc/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
 line 29: : No such file or directory
|
| Context around the error is:
|
| #
| prefix 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/
| kconf non-hardware 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
| prefix 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/
| patch 
"/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
| # run time: 0 seconds
| # processed files:
| # _cfg 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
| # _cfg 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
|
| See pre-processed file /tmp/tmp.G7DTQu11V3 for more details
| #
| # scc v0.8
| # processed: Thu Dec  1 18:08:50 EST 2016
| #
| # This is a scc output file, do not edit
| #
| [ERROR]: processing of file /tmp/tmp.zvbMU6XqZm failed
| # _reloc_dir /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux
| # _reloc_dir /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux
| 
/z/layerindex-master/raspi2-basic-2/tmp-glibc/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
 line 29: : No such file or directory
|
| Context around the error is:
|
| #
| prefix 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/
| kconf non-hardware 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
| prefix 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/
| patch 
"/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
| # run time: 0 seconds
| # processed files:
| # _cfg 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
| # _cfg 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
|
| See pre-processed file /tmp/tmp.zvbMU6XqZm for more details
| ERROR: Function failed: do_kernel_metadata (log file is located at 
/z/layerindex-master/raspi2-basic-2/tmp-glibc/work/raspberrypi2-oe-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.9670)
ERROR: Task 
(/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.4.bb:do_kernel_metadata)
 failed with exit code '1'



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto-kernel-tools and multiple users

2016-12-01 Thread Trevor Woerner

Awesome! Thanks :-)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto-kernel-tools and multiple users

2016-12-01 Thread Bruce Ashfield


On 12/01/2016 06:09 PM, Trevor Woerner wrote:

On Thu 2016-12-01 @ 05:50:21 PM, Bruce Ashfield wrote:

Can you just provide me the details of exactly how you are invoking
the build that triggers the error ?


$ git clone git://git.openembedded.org/openembedded-core.git
(HEAD @ 11063a01d4511b2688ea7ba2d7359e4e07328c66)
$ git clone git://git.yoctoproject.org/meta-raspberrypi
(HEAD @ 44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9)
$ git clone git://git.openembedded.org/bitbake.git
(HEAD @ 0bb188f01e396052b127e170a25246d79a6d6741)



perfect. Consider it fixed .. with something that shows up
that easily, I'll fix it when I'm doing the mktmp changes.

Bruce


$ openembedded-core/oe-init-build-env raspi2-test bitbake
$ bitbake-layers add-layer ../meta-raspberrypi

$ MACHINE=raspberrypi2 bitbake virtual/kernel

Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "opensuse-42.2"
TARGET_SYS= "arm-oe-linux-gnueabi"
MACHINE   = "raspberrypi2"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4 callconvention-hard
cortexa7"
TARGET_FPU= "hard"
meta  = "master:11063a01d4511b2688ea7ba2d7359e4e07328c66"
meta-raspberrypi  = "master:44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9"

ERROR: linux-raspberrypi-1_4.4.28+gitAUTOINC+5afda48c34-r0 do_kernel_metadata: 
Function failed: do_kernel_metadata (log file is located at 
/z/layerindex-master/raspi2-basic-2/tmp-glibc/work/raspberrypi2-oe-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.9670)
ERROR: Logfile of failure stored in: 
/z/layerindex-master/raspi2-basic-2/tmp-glibc/work/raspberrypi2-oe-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.9670
Log data follows:
| DEBUG: Executing shell function do_kernel_metadata
| [ERROR]: processing of file /tmp/tmp.G7DTQu11V3 failed
| 
/z/layerindex-master/raspi2-basic-2/tmp-glibc/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
 line 29: : No such file or directory
|
| Context around the error is:
|
| #
| prefix 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/
| kconf non-hardware 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
| prefix 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/
| patch 
"/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
| # run time: 0 seconds
| # processed files:
| # _cfg 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
| # _cfg 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
|
| See pre-processed file /tmp/tmp.G7DTQu11V3 for more details
| #
| # scc v0.8
| # processed: Thu Dec  1 18:08:50 EST 2016
| #
| # This is a scc output file, do not edit
| #
| [ERROR]: processing of file /tmp/tmp.zvbMU6XqZm failed
| # _reloc_dir /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux
| # _reloc_dir /z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux
| 
/z/layerindex-master/raspi2-basic-2/tmp-glibc/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
 line 29: : No such file or directory
|
| Context around the error is:
|
| #
| prefix 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/
| kconf non-hardware 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
| prefix 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/
| patch 
"/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
| # run time: 0 seconds
| # processed files:
| # _cfg 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
| # _cfg 
/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
|
| See pre-processed file /tmp/tmp.zvbMU6XqZm for more details
| ERROR: Function failed: do_kernel_metadata (log file is located at 
/z/layerindex-master/raspi2-basic-2/tmp-glibc/work/raspberrypi2-oe-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.9670)
ERROR: Task 
(/z/layerindex-master/layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.4.bb:do_kernel_metadata)
 failed with exit code '1'



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH] bxt_rebase: Revert serial console wakeup patch

2016-12-01 Thread Bruce Ashfield


On 12/01/2016 01:43 PM, Jukka Laitinen wrote:

A series of uart patches has been accidentally merged into bxt_rebase. This
one breaks the uart input on Joule, as the board doesn't have a proper pinctrl
configuration to support this.

Reverting this patch restores uart functionality to the previous working state.
This is only ment for bxt_rebase branch.


merged

Bruce



Jukka Laitinen (1):
  Revert "serial: 8250_dw: support serial console wakeup"

 drivers/tty/serial/8250/8250_dw.c | 39 ---
 1 file changed, 39 deletions(-)



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] yocto-kernel-tools and multiple users

2016-12-01 Thread Bruce Ashfield


On 12/01/2016 05:44 PM, Trevor Woerner wrote:

On Thu 2016-12-01 @ 05:28:20 PM, Bruce Ashfield wrote:

Gah, that's my bad. I'm currently in transit for a trip to Europe, but I'll
fix this
to use mktmp and friends tomorrow and send out a patch.


Great, thanks :-)

I think there might be a second issue too.

When scc-cmds/patch.cmd is run from the native sysroot, it errors out as
follows:

| 
/z/layerindex-master/raspi2-basic/tmp-glibc/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
 line 29: : No such file or directory

Line 29 of patch.cmd looks like:

eval echo "\"patches/${cbranch_name}/${relative_patch_dir}/${simple_patch_name}\"" 
>> "${branch_patch_queue}"

I *think* it's complaining about "${branch_patch_queue}" but I can't be
certain. Philip is also seeing this (second) issue too. Does that look like
something you can figure out, or should I keep digging?


I can figure it out, it just looks like not all the parts of the
tools are being installed properly.

Can you just provide me the details of exactly how you are invoking
the build that triggers the error ?

Bruce





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto-kernel-tools and multiple users

2016-12-01 Thread Trevor Woerner

On Thu 2016-12-01 @ 05:28:20 PM, Bruce Ashfield wrote:
> Gah, that's my bad. I'm currently in transit for a trip to Europe, but I'll
> fix this
> to use mktmp and friends tomorrow and send out a patch.

Great, thanks :-)

I think there might be a second issue too.

When scc-cmds/patch.cmd is run from the native sysroot, it errors out as
follows:

| 
/z/layerindex-master/raspi2-basic/tmp-glibc/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
 line 29: : No such file or directory

Line 29 of patch.cmd looks like:

eval echo 
"\"patches/${cbranch_name}/${relative_patch_dir}/${simple_patch_name}\"" >> 
"${branch_patch_queue}"

I *think* it's complaining about "${branch_patch_queue}" but I can't be
certain. Philip is also seeing this (second) issue too. Does that look like
something you can figure out, or should I keep digging?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto-kernel-tools and multiple users

2016-12-01 Thread Bruce Ashfield

On Thu, Dec 1, 2016 at 3:05 PM, Trevor Woerner  wrote:

> I believe a recent change in the yocto-kernel-tools is causing some funny
> issue I saw this morning on my overnight jenkins builds.
>
> commit 08463d684c1952e74c25344cddace4c3f24c739d
> Date:   Mon Oct 31 14:30:12 2016 -0400
>
> scc: exit on error
>
> If there is an error in the processing of the input files, scc
> should exit and inform the user.
>
> scc is executed on a combined/preprocessed file and as a result
> it doesn't have the granularity to see each input file
> individually.
>
> Rather than moving preprocessing into scc (from spp), we can
> trap
> the line number of the error and dump context around the line.
> This
> gives the user a pointer to the input file and the specific
> line
> that caused the problem.
>
> Signed-off-by: Bruce Ashfield 
>
> diff --git a/tools/scc b/tools/scc
> index b6ab747..0294103 100755
> --- a/tools/scc
> +++ b/tools/scc
> @@ -238,18 +238,37 @@ process_file()
>  done
>
>  unset PATH
> -if [ -n "${verbose}" ]; then
> -eval . $in $outfile_append
> -else
> -# hide stderr if we aren't verbose
> -eval . $in $outfile_append 2> /dev/null
> -fi
> +(
> +set -e
> +eval . $in $outfile_append > /tmp/scc-output 2>&1
> +)
> +)
>
> -if [ $? -ne 0 ]; then
> -echo "[ERROR]: processing of file $in failed"
> -exit 1
> +if [ $? -ne 0 ]; then
> +echo "[ERROR]: processing of file $in failed"
> +cat /tmp/scc-output
> +
> +# look for common errors so we can point to the right
> input file
> +
> +# 1) /tmp/tmp.gfN6WsbDHN: line 403: cat: No such file or
> directory
> +# "grep -oh" will only output what matches, which
> gets us "line 404: .."
> +# cut gets us the second field, which is the line
> number
> +line=$(cat /tmp/scc-output | grep -oh "line.*:" | cut -f2
> -d' ' | sed 's/://g')
> +if [ -n "$line" ]; then
> +let start_line=$line-20
> +let end_line=$line+10
> +if [ $start_line -lt 0 ]; then
> +start_line=0
> +fi
> +echo ""
> +echo "Context around the error is:"
> +echo ""
> +sed -n -e "$start_line,$end_line p" -e "$end_line q"
> $in | sed 's/^//'
> +echo ""
> +echo "See pre-processed file $in for more details"
>  fi
> -)
> +exit 1
> +fi
>
>  return 0
>  }
>
> In order to catch errors, scc's output is being hardcoded to
> /tmp/scc-output.
> But on my box there are two users who perform builds: jenkins and myself.
> When
> the second person comes along to do a build it finds inadequate
> permissions on
> /tmp/scc-output.
>
> Is anyone else seeing this?
>



Gah, that's my bad. I'm currently in transit for a trip to Europe, but I'll
fix this
to use mktmp and friends tomorrow and send out a patch.

Bruce


> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't set march=armv5te

2016-12-01 Thread Bryan Evenson

Martin,

OK, so regardless of what the arch was finally getting set at, in this case 
since “-marm” was in the GCC compiler options it was always compiling all the 
code in ARM mode and never in Thumb mode, correct?

It still bugs me why the architecture name changed (I’ve traced through the 
machine include path several times), but if at the end of the day it’ll be 
compiling the same code then I’ll move on to some more productive tasks.

Thanks,
Bryan

From: Martin Jansa [mailto:martin.ja...@gmail.com]
Sent: Thursday, December 01, 2016 2:06 PM
To: Bryan Evenson 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Can't set march=armv5te

Using and not using thumb was also controlled not only by TUNE_FEATURES 
(MACHINE defines that) but also by ARM_INSTRUCTION_SET (DISTRO defines that).

So you weren't building with thumb enabled even when you were seeing armv5te 
before.

On Thu, Dec 1, 2016 at 5:26 PM, Bryan Evenson 
> wrote:
I'm in the process of upgrading from the dizzy branch to the fido branch, and 
I'm still a little confused about some tune changes that I'm seeing.  I'm using 
an Atmel AT91SAM9G25 processor.  The meta-atmel layer that I am using had 
incorrectly set DEFAULTTUNE = "arm926ejs" which had been setting the 
architecture to "arm926ejste".  They fixed that here: 
https://github.com/linux4sam/meta-atmel/commit/47238062c04ca97c2ea0570576072ad5b46ce261
 and according to the commit message it should now be building with DEFAULTTUNE 
(and the resulting architecture) set to "armv5te".  However, when I build using 
my autobuilder I am getting an architecture of "armv5e".  From my 
understanding, this means the compiler thinks the processor does not have Thumb 
support.  I've tried "arm926ejs" and "armv5te" for DEFAULTTUNE settings and it 
hasn't made any difference.

I've checked the working directories for a few packages, and previously the 
relevant gcc options were being set to: "-march=armv5te -marm -mthumb-interwork 
-mtune=arm926ej-s".  Now they are being set to: "-march=armv5e -marm  
-mthumb-interwork".  How do I get it back to building with march=armv5te?

Here is the autobuilder configuration that I am using:

[nightly-atmel-demo-fido]
builders: 'builder1'
repos: [{'poky':

{'repourl':'git://git.yoctoproject.org/poky',
 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp', 
'yocto':'meta-yocto', 'poky':'meta-poky'},
 'branch':'fido'}},
{'meta-atmel':

{'repourl':'git://github.com/linux4sam/meta-atmel.git',
 'branch':'fido'}},
{'meta-openembedded':
{'autoinclude':False, 
'repourl':'git://git.openembedded.org/meta-openembedded',
 'branch':'fido'}},
{'meta-qt5':

{'repourl':'git://github.com/meta-qt5/meta-qt5.git',
 'branch':'fido'}}]
steps: [{'SetDest':{}},
{'CheckOutLayers': {}},
{'RunPreamble': {}},
{'GetDistroVersion' : {'distro': 'poky'}},
{'CreateAutoConf': {'machine': 'at91sam9x5ek', 'SDKMACHINE': 'i686', 
'distro': 'poky-atmel', 'buildhistory': True, 'packages': 'ipk', 'atextappend': 
'EXTRA_IMAGE_FEATURES = ""\nDEFAULTTUNE = "armv5te"\n'}},
{'CreateBBLayersConf': {'buildprovider' : 'yocto', 'layerdirs':
['meta-atmel', 'meta-qt5', 'meta-openembedded/meta-oe', 
'meta-openembedded/meta-networking', 'meta-openembedded/meta-python']}},
{'BuildImages': {'images': 'atmel-demo-image'}},
{'SyncPersistDB' : {'commit' : True, 'distro':'poky'}},
{'PublishLayerTarballs':{}},
{'PublishArtifacts': {'artifacts': ['at91sam9x5ek', 'ipk']}}]
scheduler: [{'nightly-scheduler-atmel-fido' :
{'type':'Nightly',
 'hour':'1',
 'minute':'15',}}]

The resulting build configuration:
Build Configuration:
BB_VERSION= "1.26.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "at91sam9x5ek"
DISTRO= "poky-atmel"
DISTRO_VERSION= "1.8.2"
TUNE_FEATURES = "arm armv5 thumb dsp"
TARGET_FPU= "soft"
meta
meta-yocto
meta-yocto-bsp= "fido:c9f0a99050ec0050f0dbcd55d0cd2ab18848113f"
meta-atmel= "fido:dd595e6e8ec7010cf646a9ca356b2e01f10e274c"
meta-qt5  = "fido:90919b9d86988e7da01fa2c0a07246b5b5600a5d"
meta-oe
meta-networking
meta-python   = "fido:902964a4da26e46018d2a8d17dcdda1ac4627a39"

TUNE_FEATURES includes "thumb", but the compiler options aren't set for 
armv5te.  I've tried changing the DEFAULTTUNE specification in CreateAutoConf 
to "arm926ejs" and I've had the same results.  How do I get the architecture 
set back correctly for the processor I'm using?

Thanks,
Bryan

[yocto] yocto-kernel-tools and multiple users

2016-12-01 Thread Trevor Woerner

I believe a recent change in the yocto-kernel-tools is causing some funny
issue I saw this morning on my overnight jenkins builds.

commit 08463d684c1952e74c25344cddace4c3f24c739d
Date:   Mon Oct 31 14:30:12 2016 -0400

scc: exit on error

If there is an error in the processing of the input files, scc
should exit and inform the user.

scc is executed on a combined/preprocessed file and as a result
it doesn't have the granularity to see each input file individually.

Rather than moving preprocessing into scc (from spp), we can trap
the line number of the error and dump context around the line. This
gives the user a pointer to the input file and the specific line
that caused the problem.

Signed-off-by: Bruce Ashfield 

diff --git a/tools/scc b/tools/scc
index b6ab747..0294103 100755
--- a/tools/scc
+++ b/tools/scc
@@ -238,18 +238,37 @@ process_file()
 done
 
 unset PATH
-if [ -n "${verbose}" ]; then
-eval . $in $outfile_append
-else
-# hide stderr if we aren't verbose
-eval . $in $outfile_append 2> /dev/null
-fi
+(
+set -e
+eval . $in $outfile_append > /tmp/scc-output 2>&1
+)
+)
 
-if [ $? -ne 0 ]; then
-echo "[ERROR]: processing of file $in failed"
-exit 1
+if [ $? -ne 0 ]; then
+echo "[ERROR]: processing of file $in failed"
+cat /tmp/scc-output
+
+# look for common errors so we can point to the right input 
file
+
+# 1) /tmp/tmp.gfN6WsbDHN: line 403: cat: No such file or 
directory
+# "grep -oh" will only output what matches, which gets us 
"line 404: .."
+# cut gets us the second field, which is the line number
+line=$(cat /tmp/scc-output | grep -oh "line.*:" | cut -f2 -d' 
' | sed 's/://g')
+if [ -n "$line" ]; then
+let start_line=$line-20
+let end_line=$line+10
+if [ $start_line -lt 0 ]; then
+start_line=0
+fi
+echo ""
+echo "Context around the error is:"
+echo ""
+sed -n -e "$start_line,$end_line p" -e "$end_line q" $in | 
sed 's/^//'
+echo ""
+echo "See pre-processed file $in for more details"
 fi
-)
+exit 1
+fi
 
 return 0
 }

In order to catch errors, scc's output is being hardcoded to /tmp/scc-output.
But on my box there are two users who perform builds: jenkins and myself. When
the second person comes along to do a build it finds inadequate permissions on
/tmp/scc-output.

Is anyone else seeing this?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't set march=armv5te

2016-12-01 Thread Martin Jansa

The package architecture was change to match with compiler flags used in
build.

Most people were assuming that they are using thumb when they have seen "t"
in package arch, but because default value of ARM_INSTRUCTION_SET is "arm"
they in most cases weren't actually building with -mthumb.

On Thu, Dec 1, 2016 at 8:54 PM, Bryan Evenson 
wrote:

> Martin,
>
>
>
> OK, so regardless of what the arch was finally getting set at, in this
> case since “-marm” was in the GCC compiler options it was always compiling
> all the code in ARM mode and never in Thumb mode, correct?
>
>
>
> It still bugs me why the architecture name changed (I’ve traced through
> the machine include path several times), but if at the end of the day it’ll
> be compiling the same code then I’ll move on to some more productive tasks.
>
>
>
> Thanks,
>
> Bryan
>
>
>
> *From:* Martin Jansa [mailto:martin.ja...@gmail.com]
> *Sent:* Thursday, December 01, 2016 2:06 PM
> *To:* Bryan Evenson 
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Can't set march=armv5te
>
>
>
> Using and not using thumb was also controlled not only by TUNE_FEATURES
> (MACHINE defines that) but also by ARM_INSTRUCTION_SET (DISTRO defines
> that).
>
>
>
> So you weren't building with thumb enabled even when you were seeing
> armv5te before.
>
>
>
> On Thu, Dec 1, 2016 at 5:26 PM, Bryan Evenson 
> wrote:
>
> I'm in the process of upgrading from the dizzy branch to the fido branch,
> and I'm still a little confused about some tune changes that I'm seeing.
> I'm using an Atmel AT91SAM9G25 processor.  The meta-atmel layer that I am
> using had incorrectly set DEFAULTTUNE = "arm926ejs" which had been setting
> the architecture to "arm926ejste".  They fixed that here:
> https://github.com/linux4sam/meta-atmel/commit/
> 47238062c04ca97c2ea0570576072ad5b46ce261 and according to the commit
> message it should now be building with DEFAULTTUNE (and the resulting
> architecture) set to "armv5te".  However, when I build using my autobuilder
> I am getting an architecture of "armv5e".  From my understanding, this
> means the compiler thinks the processor does not have Thumb support.  I've
> tried "arm926ejs" and "armv5te" for DEFAULTTUNE settings and it hasn't made
> any difference.
>
> I've checked the working directories for a few packages, and previously
> the relevant gcc options were being set to: "-march=armv5te -marm
> -mthumb-interwork -mtune=arm926ej-s".  Now they are being set to:
> "-march=armv5e -marm  -mthumb-interwork".  How do I get it back to building
> with march=armv5te?
>
> Here is the autobuilder configuration that I am using:
>
> [nightly-atmel-demo-fido]
> builders: 'builder1'
> repos: [{'poky':
> {'repourl':'git://git.yoctoproject.org/poky',
>  'layerversion':{'core':'meta',
> 'yoctobsp':'meta-yocto-bsp', 'yocto':'meta-yocto', 'poky':'meta-poky'},
>  'branch':'fido'}},
> {'meta-atmel':
> {'repourl':'git://github.com/linux4sam/meta-atmel.git',
>  'branch':'fido'}},
> {'meta-openembedded':
> {'autoinclude':False, 'repourl':'git://git.
> openembedded.org/meta-openembedded',
>  'branch':'fido'}},
> {'meta-qt5':
> {'repourl':'git://github.com/meta-qt5/meta-qt5.git',
>  'branch':'fido'}}]
> steps: [{'SetDest':{}},
> {'CheckOutLayers': {}},
> {'RunPreamble': {}},
> {'GetDistroVersion' : {'distro': 'poky'}},
> {'CreateAutoConf': {'machine': 'at91sam9x5ek', 'SDKMACHINE':
> 'i686', 'distro': 'poky-atmel', 'buildhistory': True, 'packages': 'ipk',
> 'atextappend': 'EXTRA_IMAGE_FEATURES = ""\nDEFAULTTUNE = "armv5te"\n'}},
> {'CreateBBLayersConf': {'buildprovider' : 'yocto', 'layerdirs':
> ['meta-atmel', 'meta-qt5', 'meta-openembedded/meta-oe',
> 'meta-openembedded/meta-networking', 'meta-openembedded/meta-python']}},
> {'BuildImages': {'images': 'atmel-demo-image'}},
> {'SyncPersistDB' : {'commit' : True, 'distro':'poky'}},
> {'PublishLayerTarballs':{}},
> {'PublishArtifacts': {'artifacts': ['at91sam9x5ek', 'ipk']}}]
> scheduler: [{'nightly-scheduler-atmel-fido' :
> {'type':'Nightly',
>  'hour':'1',
>  'minute':'15',}}]
>
> The resulting build configuration:
> Build Configuration:
> BB_VERSION= "1.26.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-12.04"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "at91sam9x5ek"
> DISTRO= "poky-atmel"
> DISTRO_VERSION= "1.8.2"
> TUNE_FEATURES = "arm armv5 thumb dsp"
> TARGET_FPU= "soft"
> meta
> meta-yocto
> meta-yocto-bsp= "fido:c9f0a99050ec0050f0dbcd55d0cd2ab18848113f"
> meta-atmel= "fido:dd595e6e8ec7010cf646a9ca356b2e01f10e274c"
> meta-qt5  = "fido:90919b9d86988e7da01fa2c0a07246b5b5600a5d"
>

[yocto] Can't set march=armv5te

2016-12-01 Thread Bryan Evenson

I'm in the process of upgrading from the dizzy branch to the fido branch, and 
I'm still a little confused about some tune changes that I'm seeing.  I'm using 
an Atmel AT91SAM9G25 processor.  The meta-atmel layer that I am using had 
incorrectly set DEFAULTTUNE = "arm926ejs" which had been setting the 
architecture to "arm926ejste".  They fixed that here: 
https://github.com/linux4sam/meta-atmel/commit/47238062c04ca97c2ea0570576072ad5b46ce261
 and according to the commit message it should now be building with DEFAULTTUNE 
(and the resulting architecture) set to "armv5te".  However, when I build using 
my autobuilder I am getting an architecture of "armv5e".  From my 
understanding, this means the compiler thinks the processor does not have Thumb 
support.  I've tried "arm926ejs" and "armv5te" for DEFAULTTUNE settings and it 
hasn't made any difference.

I've checked the working directories for a few packages, and previously the 
relevant gcc options were being set to: "-march=armv5te -marm -mthumb-interwork 
-mtune=arm926ej-s".  Now they are being set to: "-march=armv5e -marm  
-mthumb-interwork".  How do I get it back to building with march=armv5te?

Here is the autobuilder configuration that I am using:

[nightly-atmel-demo-fido]
builders: 'builder1'
repos: [{'poky':
{'repourl':'git://git.yoctoproject.org/poky',
 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp', 
'yocto':'meta-yocto', 'poky':'meta-poky'},
 'branch':'fido'}},
{'meta-atmel':
{'repourl':'git://github.com/linux4sam/meta-atmel.git',
 'branch':'fido'}},
{'meta-openembedded':
{'autoinclude':False, 
'repourl':'git://git.openembedded.org/meta-openembedded',
 'branch':'fido'}},
{'meta-qt5':
{'repourl':'git://github.com/meta-qt5/meta-qt5.git',
 'branch':'fido'}}]
steps: [{'SetDest':{}},
{'CheckOutLayers': {}},
{'RunPreamble': {}},
{'GetDistroVersion' : {'distro': 'poky'}},
{'CreateAutoConf': {'machine': 'at91sam9x5ek', 'SDKMACHINE': 'i686', 
'distro': 'poky-atmel', 'buildhistory': True, 'packages': 'ipk', 'atextappend': 
'EXTRA_IMAGE_FEATURES = ""\nDEFAULTTUNE = "armv5te"\n'}},
{'CreateBBLayersConf': {'buildprovider' : 'yocto', 'layerdirs':
['meta-atmel', 'meta-qt5', 'meta-openembedded/meta-oe', 
'meta-openembedded/meta-networking', 'meta-openembedded/meta-python']}},
{'BuildImages': {'images': 'atmel-demo-image'}},
{'SyncPersistDB' : {'commit' : True, 'distro':'poky'}},
{'PublishLayerTarballs':{}},
{'PublishArtifacts': {'artifacts': ['at91sam9x5ek', 'ipk']}}]
scheduler: [{'nightly-scheduler-atmel-fido' :
{'type':'Nightly',
 'hour':'1',
 'minute':'15',}}]

The resulting build configuration:
Build Configuration:
BB_VERSION= "1.26.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.04"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "at91sam9x5ek"
DISTRO= "poky-atmel"
DISTRO_VERSION= "1.8.2"
TUNE_FEATURES = "arm armv5 thumb dsp"
TARGET_FPU= "soft"
meta  
meta-yocto
meta-yocto-bsp= "fido:c9f0a99050ec0050f0dbcd55d0cd2ab18848113f"
meta-atmel= "fido:dd595e6e8ec7010cf646a9ca356b2e01f10e274c"
meta-qt5  = "fido:90919b9d86988e7da01fa2c0a07246b5b5600a5d"
meta-oe   
meta-networking   
meta-python   = "fido:902964a4da26e46018d2a8d17dcdda1ac4627a39"

TUNE_FEATURES includes "thumb", but the compiler options aren't set for 
armv5te.  I've tried changing the DEFAULTTUNE specification in CreateAutoConf 
to "arm926ejs" and I've had the same results.  How do I get the architecture 
set back correctly for the processor I'm using?

Thanks,
Bryan Evenson
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Shared state doesn't live up to its name?

2016-12-01 Thread Paul Eggleton

On Thu, 01 Dec 2016 10:27:50 Gary Thomas wrote:
> I have a build machine where I build for lots of targets.  On
> all of these targets (save a primary), I set the SSTATE_MIRROR
> to point to the sstate-cache of the primary target.  I always build
> for the primary target first, then later the secondary ones.
> 
> For the most part, the sstate mechanism works pretty well, but I
> see some anomalies.  For example, why on the same host, built back
> to back, would a secondary build target (which uses the primary
> as it's SSTATE_MIRROR and that build is complete) need to rebuild
> from scratch such NATIVE packages as openssl?  Note that these are
> native packages I'm asking about, so in my mind they should always
> be sharable.
> 
> Any ideas?  Is there something I can look at to investigate this?

bitbake-diffsigs is the basic tool to compare signatures when those have 
changed. Find the siginfo / sigdata file for one of the early tasks that 
executed and compare them to see what changed.

How are you setting SSTATE_MIRRORS in this scenario btw?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] AUH: status email indicates the URL of the log folder

2016-12-01 Thread Edwin Plauchu

Upgrade status email should indicate the URL of the log folder instead of the 
tar URL

[YOCTO #10670]

Signed-off-by: Edwin Plauchu 
---
 upgradehelper.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 239fd88..3954e1f 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -616,7 +616,7 @@ class Updater(object):
 publish_work_url = ''
 
 statistics_summary = self.statistics.get_summary(
-publish_work_url, os.path.basename(work_tarball))
+publish_work_url, self.uh_work_dir)
 
 statistics_file = os.path.join(self.uh_work_dir,
 "statistics_summary")
-- 
2.9.3

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH] bxt_rebase: Revert serial console wakeup patch

2016-12-01 Thread Jukka Laitinen

A series of uart patches has been accidentally merged into bxt_rebase. This
one breaks the uart input on Joule, as the board doesn't have a proper pinctrl
configuration to support this.

Reverting this patch restores uart functionality to the previous working state.
This is only ment for bxt_rebase branch.

Jukka Laitinen (1):
  Revert "serial: 8250_dw: support serial console wakeup"

 drivers/tty/serial/8250/8250_dw.c | 39 ---
 1 file changed, 39 deletions(-)

-- 
2.7.4

-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH] Revert "serial: 8250_dw: support serial console wakeup"

2016-12-01 Thread Jukka Laitinen

This reverts commit 4a6b554d2f7830772d95912a66fd14b109004e3e.

The reverted patch broke the uart functionality in Joule, which doesn't
have a proper pinctrl configuration for this purpose.

Signed-off-by: Jukka Laitinen 
---
 drivers/tty/serial/8250/8250_dw.c | 39 ---
 1 file changed, 39 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 9906cb5..c3b6edf 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -14,7 +14,6 @@
  * raised, the LCR needs to be rewritten and the uart status register read.
  */
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -22,9 +21,7 @@
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -330,7 +327,6 @@ static int dw8250_probe(struct platform_device *pdev)
int irq = platform_get_irq(pdev, 0);
struct uart_port *p = 
struct dw8250_data *data;
-   struct gpio_desc *wake;
int err;
u32 val;
 
@@ -469,26 +465,6 @@ static int dw8250_probe(struct platform_device *pdev)
uart.dma = >dma;
}
 
-   /* Set up RxD or CTS pin as wake source */
-   wake = gpiod_get(>dev, "rx", GPIOD_IN);
-   if (IS_ERR(wake))
-   wake = gpiod_get(>dev, "cts", GPIOD_IN);
-   if (!IS_ERR(wake)) {
-   irq = gpiod_to_irq(wake);
-   if (irq >= 0) {
-   device_init_wakeup(>dev, true);
-   err = dev_pm_set_dedicated_wake_irq(>dev, irq);
-   if (err) {
-   dev_warn(>dev,
-"Can't set dedicated wake IRQ: %d\n",
-err);
-   } else {
-   irq_set_irq_type(irq, IRQ_TYPE_EDGE_BOTH);
-   }
-   }
-   gpiod_put(wake);
-   }
-
data->line = serial8250_register_8250_port();
if (data->line < 0) {
err = data->line;
@@ -526,9 +502,6 @@ static int dw8250_remove(struct platform_device *pdev)
 
pm_runtime_get_sync(>dev);
 
-   dev_pm_clear_wake_irq(>dev);
-   device_init_wakeup(>dev, false);
-
serial8250_unregister_port(data->line);
 
if (!IS_ERR(data->rst))
@@ -571,8 +544,6 @@ static int dw8250_runtime_suspend(struct device *dev)
 {
struct dw8250_data *data = dev_get_drvdata(dev);
 
-   pinctrl_pm_select_sleep_state(dev);
-
if (!IS_ERR(data->clk))
clk_disable_unprepare(data->clk);
 
@@ -585,7 +556,6 @@ static int dw8250_runtime_suspend(struct device *dev)
 static int dw8250_runtime_resume(struct device *dev)
 {
struct dw8250_data *data = dev_get_drvdata(dev);
-   struct uart_8250_port *up = serial8250_get_port(data->line);
 
if (!IS_ERR(data->pclk))
clk_prepare_enable(data->pclk);
@@ -593,15 +563,6 @@ static int dw8250_runtime_resume(struct device *dev)
if (!IS_ERR(data->clk))
clk_prepare_enable(data->clk);
 
-   pinctrl_pm_select_default_state(dev);
-
-   /* Restore context */
-   serial8250_do_restore_context(>port);
-
-   /*
-*  TODO: Check if it needs more than it's done in
-*  serial8250_console_restore()
-*/
return 0;
 }
 #endif
-- 
2.7.4

-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [meta-swupd][PATCH 2/2] swupd-client: don't unconditionally depend on bash

2016-12-01 Thread Patrick Ohly

On Mon, 2016-11-21 at 16:29 +, André Draszik wrote:
> The swupd client itself does not depend on bash anymore since
> version 3.3.0. Any posix shell is fine. So let's move the
> runtime dependency to the appropriate place.
> 
> If some layer's oe-swupd-helpers.bbappend does introduce
> a bash dependency, it should just state that dependency
> itself.
> 
> As the shell now be provided by bash or busybox, also add
> an appropriate entry to SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS.

Makes sense, I'll submit soon.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-swupd][PATCH 1/2] oe-swupd-helpers: convert scripts to posix shell

2016-12-01 Thread Patrick Ohly

On Mon, 2016-11-21 at 16:29 +, André Draszik wrote:
> These scripts don't do much and there's no reason for
> them to require bash as interpreter.

Makes sense, I'll submit soon.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] update mechanisms (was: Re: [meta-swupd][PATCH] bsdiff: update to latest version)

2016-12-01 Thread Patrick Ohly

On Thu, 2016-12-01 at 10:26 +, André Draszik wrote:
> On Thu, 2016-12-01 at 08:42 +0100, Patrick Ohly wrote:
> > On Wed, 2016-11-30 at 17:19 +, André Draszik wrote:
> > > I liked swupd for its ability to be used both for initial provisioning
> > 
> > You mean installing from the update repository? That's something that
> > Clear Linux OS can do with their installer, but nothing like that has
> > been tried with a Yocto-based build. That doesn't mean that it can't be
> > done, it's just work.
> 
> Yes. In our case we can only provision the NOR flash in the factory (which
> is too small for the real file system), so I have the swupd-client inside a
> small initramfs in NOR flash, and from there I can provision NAND flash
> using swupd verify -i

Interesting, I hadn't thought of using it like that. When doing this,
does it download the "from-0" pack files?

"swupd bundle-add" uses those; I'm less sure about verify. It would have
to detect that it misses all files from the os-core bundle and then as a
special optimization get the pack file instead of individual files.

Speaking of bundles, is that concept something that you find useful for
your purposes? It's not strictly needed for a pure system update
mechanism.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Shared state doesn't live up to its name?

2016-12-01 Thread Martin Jansa

Compare the signatures of these 2 native builds.

I'm still using sstate-diff-machines.sh to create archives of sstate
signatures for interesting builds, so that I can easily compare them with
other builds or the same build performed on different builder to see why
something wasn't reused form sstate.

On Thu, Dec 1, 2016 at 10:27 AM, Gary Thomas  wrote:

> I have a build machine where I build for lots of targets.  On
> all of these targets (save a primary), I set the SSTATE_MIRROR
> to point to the sstate-cache of the primary target.  I always build
> for the primary target first, then later the secondary ones.
>
> For the most part, the sstate mechanism works pretty well, but I
> see some anomalies.  For example, why on the same host, built back
> to back, would a secondary build target (which uses the primary
> as it's SSTATE_MIRROR and that build is complete) need to rebuild
> from scratch such NATIVE packages as openssl?  Note that these are
> native packages I'm asking about, so in my mind they should always
> be sharable.
>
> Any ideas?  Is there something I can look at to investigate this?
>
> Thanks
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] update mechanisms (was: Re: [meta-swupd][PATCH] bsdiff: update to latest version)

2016-12-01 Thread André Draszik

On Thu, 2016-12-01 at 08:42 +0100, Patrick Ohly wrote:
> On Wed, 2016-11-30 at 17:19 +, André Draszik wrote:
> > I liked swupd for its ability to be used both for initial provisioning
> 
> You mean installing from the update repository? That's something that
> Clear Linux OS can do with their installer, but nothing like that has
> been tried with a Yocto-based build. That doesn't mean that it can't be
> done, it's just work.

Yes. In our case we can only provision the NOR flash in the factory (which
is too small for the real file system), so I have the swupd-client inside a
small initramfs in NOR flash, and from there I can provision NAND flash
using swupd verify -i

All yocto based, but in its current state not in a generally useful shape
for a wider audience.

> >  as
> > well as for incremental updates. The latter being important when you
> > have
> > *loads* of devices, where it doesn't seem to make sense to download a
> > full
> > image for a tiny change to each device (think cellular!),
> 
> That's indeed one of the strengths of swupd. OSTree comes close in terms
> of some key characteristics (file-based, persistent /etc and /var). It
> would be interesting to know how efficient updating via OSTree is.

True.


A.

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Shared state doesn't live up to its name?

2016-12-01 Thread Gary Thomas


I have a build machine where I build for lots of targets.  On
all of these targets (save a primary), I set the SSTATE_MIRROR
to point to the sstate-cache of the primary target.  I always build
for the primary target first, then later the secondary ones.

For the most part, the sstate mechanism works pretty well, but I
see some anomalies.  For example, why on the same host, built back
to back, would a secondary build target (which uses the primary
as it's SSTATE_MIRROR and that build is complete) need to rebuild
from scratch such NATIVE packages as openssl?  Note that these are
native packages I'm asking about, so in my mind they should always
be sharable.

Any ideas?  Is there something I can look at to investigate this?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Shared state doesn't live up to its name?

Re: [yocto] yocto-kernel-tools and multiple users

Re: [yocto] yocto-kernel-tools and multiple users

Re: [yocto] yocto-kernel-tools and multiple users

Re: [yocto] yocto-kernel-tools and multiple users

Re: [linux-yocto] [PATCH] bxt_rebase: Revert serial console wakeup patch

Re: [yocto] yocto-kernel-tools and multiple users

Re: [yocto] yocto-kernel-tools and multiple users

Re: [yocto] yocto-kernel-tools and multiple users

Re: [yocto] Can't set march=armv5te

[yocto] yocto-kernel-tools and multiple users

Re: [yocto] Can't set march=armv5te

[yocto] Can't set march=armv5te

Re: [yocto] Shared state doesn't live up to its name?

[yocto] [PATCH] AUH: status email indicates the URL of the log folder

[linux-yocto] [PATCH] bxt_rebase: Revert serial console wakeup patch

[linux-yocto] [PATCH] Revert "serial: 8250_dw: support serial console wakeup"

Re: [yocto] [meta-swupd][PATCH 2/2] swupd-client: don't unconditionally depend on bash

Re: [yocto] [meta-swupd][PATCH 1/2] oe-swupd-helpers: convert scripts to posix shell

Re: [yocto] update mechanisms (was: Re: [meta-swupd][PATCH] bsdiff: update to latest version)

Re: [yocto] Shared state doesn't live up to its name?

Re: [yocto] update mechanisms (was: Re: [meta-swupd][PATCH] bsdiff: update to latest version)

[yocto] Shared state doesn't live up to its name?

23 matches

Site Navigation

Mail list logo

Footer information