date:20160701

Re: [yocto] ICECC build failures?

2016-07-01 Thread Takashi Matsuzawa

Thank you for your comment.

So they are.  I will try to mask them one by one then.

From: Peter Bergin 
Sent: Friday, July 1, 2016 1:05 PM
To: Takashi Matsuzawa; yocto@yoctoproject.org
Subject: Re: [yocto] ICECC build failures?

Hi,

On 07/01/2016 03:18 AM, Takashi Matsuzawa wrote:

Hello Yocto.

Recently I am trying icecc with bitbake and amd halfway satisfied.
Good to see batch of my compilation jobs consumed by my build machines on icemon
is not bad.

However, I can see my builds fail in certain condition eveytime and
wonder if it is a known issue and a workaround exists?

Symptom is the follows.

1) Using x86_64 build host and build machies.  All of them are running
Ubutnu 16.04.
2) My image is based on Fido (18.0).
3) I am just doing INHERIT += "icecc" and the jobs are shared with
build machines correctly.
4) x86 (genericx86) build is OK with and without icecee.
5) imx (sabre6qauto) build is OK without icecc, but NG (fails) with icecc.

The following is the failure log.
It says relocation record error during linkage.  I googled for a while
and learned similar error could be seen if there is binutils (libtool)
version mistmatch.

Maybe a) the host-provided native toolchain and b) yocto-provided
native/cross toolchain have version mismatch?  But I do not see this
error when I am not using icecc.  I just think if it is OK without
icecc, the same should be expected even if I use icecc (it just runs
the same toolchain on different PCs?)

| x86_64-pokysdk-linux-libtool: link: x86_64-pokysdk-linux-gcc
--sysroot=/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux
-shared   .libs/conf.o .libs/confmisc.o .libs/input.o .libs/output.o
.libs/async.o .libs/error.o .libs/dlmisc.o .libs/socket.o
.libs/shmarea.o .libs/userfile.o .libs/names.o   -Wl,--whole-archive
control/.libs/libcontrol.a mixer/.libs/libmixer.a pcm/.libs/libpcm.a
timer/.libs/libtimer.a rawmidi/.libs/librawmidi.a
hwdep/.libs/libhwdep.a seq/.libs/libseq.a ucm/.libs/libucm.a
alisp/.libs/libalisp.a -Wl,--no-whole-archive
-L/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/usr/lib
-L/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/lib
-lm -ldl -lpthread -lrt
--sysroot=/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux
-O2 -Wl,--version-script=Versions -Wl,--no-undefined -Wl,-rpath-link
-Wl,/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/usr/lib
-Wl,-rpath -Wl,/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/usr/lib
-Wl,-O1 -Wl,-rpath-link
-Wl,/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-nativesdk-pokysdk-linux/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/lib
-Wl,-rpath -Wl,/opt/narwhal/3.14.52-1.1.1/sysroots/x86_64-pokysdk-linux/lib
-Wl,-O1   -Wl,-soname -Wl,libasound.so.2 -o .libs/libasound.so.2.0.0
| 
/mnt/ssd2/yocto/dev/tmp/imx-wk1/sysroots/x86_64-linux/usr/libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/4.9.2/ld:
.libs/conf.o: relocation R_X86_64_32 against `.rodata.str1.1' can not
be used when making a shared object; recompile with -fPIC
| .libs/conf.o: error adding symbols: Bad value
| collect2: error: ld returned 1 exit status
| Makefile:484: recipe for target 'libasound.la' failed
| make[2]: *** [libasound.la] Error 1
| make[2]: Leaving directory
'/mnt/ssd2/yocto/dev/tmp/imx-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-alsa-lib/1.0.28-r0/build/src'
| Makefile:538: recipe for target 'all-recursive' failed
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory
'/mnt/ssd2/yocto/dev/tmp/imx-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-alsa-lib/1.0.28-r0/build/src'
| Makefile:399: recipe for target 'all-recursive' failed
| make: *** [all-recursive] Error 1
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/mnt/ssd2/yocto/dev/tmp/imx-wk1/work/x86_64-nativesdk-pokysdk-linux/nativesdk-alsa-lib/1.0.28-r0/temp/log.do_compile.31561)

Some packages does not work with ICECC in a similar way some package do not 
work with PARALLEL_MAKE. You can work with the variable ICECC_USER_PACKAGE_BL 
to disable ICECC compilation for the failing packages.

Best regards,
/Peter
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Shorter build time?

2016-07-01 Thread Takashi Matsuzawa

Hmm, thank you for your comments.

So, they may be talking about single-thread nature within a python program, and 
as for bitbake python tasks they should be working in parallel.

There seems to be PyPy, Stackless Python, etc. but I am not sure they can be 
tried 'in-place' to see if they work faster.

From: Daniel. 
Sent: Saturday, July 2, 2016 2:13 AM
To: Burton, Ross
Cc: Takashi Matsuzawa; yocto@yoctoproject.org
Subject: Re: [yocto] Shorter build time?

So we have full parallelism :)

2016-07-01 14:01 GMT-03:00 Burton, Ross :
>
> On 1 July 2016 at 17:37, Daniel.  wrote:
>>
>> I read that python can't execute multiple threads simultaneously, but
>> that wouldn't be a problem if each python task is executed at its own
>> interpreter instance (process). This last statement is what I don't
>> really know, some experts on Yocto's internals may clarify that, maybe
>
>
> Yes, each worker is a separate Python process.
>
> Ross

--
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] customizing system configuration files in my image

2016-07-01 Thread Zhenhua Luo

Usually I do it by adding bbappend of corresponding packages to override 
original files, the interfaces is provided by init-ifupdown, the inittab is 
provided by sysvinit-inittab.

An example: 
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/recipes-core/init-ifupdown


Best Regards,

Zhenhua

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Ottavio Campana
Sent: Friday, July 01, 2016 5:12 PM
To: yocto@yoctoproject.org
Subject: [yocto] customizing system configuration files in my image

Hello,

I would like to customize an image I am developing based on core image minimal.

Particularly, I'd like to customize the files /etc/network/interfaces and 
/etc/inittab .

What should I do achieve that?

Thank you

Ottavio

--
[Videotec Logo]

Ottavio Campana
Product Manager - Electronic R Department

Office +39.0445.697.411  Fax +39.0445.697.414
Address  VIDEOTEC S.p.A. - Via Friuli, 6 - 36015 Schio (Vicenza) - Italy


Any information herein transmitted only concerns the person or the company 
named in the address and is deemed to be confidential It is strictly forbidden 
to transmit, post, forward or otherwise use said information to anyone other 
than the recipient. If you have received this message by mistake, please 
contact the sender and delete any relevant information from your computer. This 
mailbox is only meant for sending and receiving messages pertaining business 
matters and any other use for personal purposes is forbidden and unauthorized. 
Therefore, any email sent and received will be handled as ordinary business 
messages and subject to the company's own rules, and may thus be read also by 
people other than the user named in the mailbox address.

[Twitter Logo blue]   [Youtube logo red] 
[Linkedin logo blue] 




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

Re: [yocto] [Recipe reporting system] Upgradable recipe name list

2016-07-01 Thread Aníbal Limón



On 07/01/2016 04:31 PM, recipe-rep...@yoctoproject.org wrote:
> This mail was sent out by Recipe reporting system.
> 
> This message list those recipes which need to be upgraded. If maintainers
> believe some of them needn't to upgrade at this time, they can fill
> RECIPE_NO_UPDATE_REASON in respective recipe file to ignore this remainder
> until newer upstream version was detected.
> 
> Example:
> RECIPE_NO_UPDATE_REASON = "Version 2.0 is unstable"
> 
> You can check the detail information at:
> 
> http://recipes.yoctoproject.org/
> 
> Package   VersionUpstream version  Maintainer 
>   NoUpgradeReason
>   -    
> ---  --
> perl  5.22.1 5.24.0Alejandro Hernandez
> texinfo   6.06.1   Alejandro Hernandez
> ruby  2.2.5  2.3.1 Alejandro Hernandez
> python3   3.5.1  3.5.2 Alejandro Hernandez
> python-native 2.7.11 2.7.12Alejandro Hernandez
> python3-git   1.0.2  2.0.6 Alejandro Hernandez
> cronie1.5.0  1.5.1 Alejandro Hernandez
> swig  3.0.8  3.0.10Alejandro Hernandez
> python-git2.0.5  2.0.6 Alejandro Hernandez
> python3-setuptools22.0.5 23.1.0Alejandro Hernandez
> python-setuptools 22.0.5 23.1.0Alejandro Hernandez
> perl-native   5.22.1 5.24.0Alejandro Hernandez
> python3-native3.5.1  3.5.2 Alejandro Hernandez
> python2.7.11 2.7.12Alejandro Hernandez
> liberation-fonts  1.04   2.00.1Alexander Kanavin  
>   2.x depends on fontforge pa...
> bdwgc 7.4.2  7.4.4 Alexander Kanavin
> vala  0.30.1 0.32.1Alexander Kanavin
> epiphany  3.18.4 3.20.3Alexander Kanavin
> libwnck3  3.14.1 3.20.1Alexander Kanavin
> nss   3.23   3.24  Alexander Kanavin
> libarchive3.2.0  3.2.1 Alexander Kanavin
> gnutls3.4.11 3.5.1 Alexander Kanavin
> ffmpeg3.0.2  3.1.1 Alexander Kanavin
> bash-completion   2.12.3   Alexander Kanavin
> btrfs-tools   4.5.3  4.6.1 Alexander Kanavin
> mpg1231.23.4 1.23.6Alexander Kanavin
> babeltrace1.3.2  1.4.0 Alexander Kanavin
> mkelfimage4.0+gitX   4.4+gitAUTOINC+58...  Alexander Kanavin  
>   mkelfimage has been removed...
> desktop-file-util...  0.22   0.23  Alexander Kanavin
> apt   1.0.10.1   1.2.14Aníbal Limón
> apt-native1.0.10.1   1.2.14Aníbal Limón
> pinentry  0.9.2  0.9.7 Armin Kuster
> linux-libc-headers4.44.6.3 Bruce Ashfield
> guilt-native  0.35+gitX  0.36+gitAUTOINC+2...  Bruce Ashfield
> at3.1.18 3.1.20Chen Qi
> byacc 20160324   20160606  Chen Qi
> cups  2.1.3  2.1.4 Chen Qi
> sudo  1.8.16 1.8.17p1  Chen Qi
> sysstat   11.3.4 11.3.5Chen Qi
> u-boot-fw-utils   v2016.03+gitX  v2016.05+gitAUTOI...  Denys Dmytriyenko
> u-boot-mkimagev2016.03+gitX  v2016.05+gitAUTOI...  Denys Dmytriyenko
> u-bootv2016.03+gitX  v2016.05+gitAUTOI...  Denys Dmytriyenko
> createrepo0.4.11 0.10.4Hongxu Jia 
>   Versions after 0.9.* use YU...
> ncurses   6.0+20160319   6.0+20160625  Hongxu Jia
> libgcrypt 1.7.0  1.7.1 Hongxu Jia
> gnupg 2.1.12 2.1.13Hongxu Jia
> libinput  1.3.0  1.3.3 Jussi Kukkonen
> weston1.10.0 1.11.0Jussi Kukkonen
> matchbox-config-gtk   0.22 Jussi Kukkonen
> matchbox-terminal 0.12 Jussi Kukkonen
> sato-screenshot   0.22 Jussi Kukkonen
> settings-daemon   0.0.2  2 Jussi Kukkonen
> xf86-input-evdev  2.10.2 2.10.3Jussi Kukkonen
> xf86-input-synaptics

[yocto] [Recipe reporting system] Upgradable recipe name list

2016-07-01 Thread recipe-report

This mail was sent out by Recipe reporting system.

This message list those recipes which need to be upgraded. If maintainers
believe some of them needn't to upgrade at this time, they can fill
RECIPE_NO_UPDATE_REASON in respective recipe file to ignore this remainder
until newer upstream version was detected.

Example:
RECIPE_NO_UPDATE_REASON = "Version 2.0 is unstable"

You can check the detail information at:

http://recipes.yoctoproject.org/

Package   VersionUpstream version  Maintainer   
NoUpgradeReason
  -    ---  
--
perl  5.22.1 5.24.0Alejandro Hernandez
texinfo   6.06.1   Alejandro Hernandez
ruby  2.2.5  2.3.1 Alejandro Hernandez
python3   3.5.1  3.5.2 Alejandro Hernandez
python-native 2.7.11 2.7.12Alejandro Hernandez
python3-git   1.0.2  2.0.6 Alejandro Hernandez
cronie1.5.0  1.5.1 Alejandro Hernandez
swig  3.0.8  3.0.10Alejandro Hernandez
python-git2.0.5  2.0.6 Alejandro Hernandez
python3-setuptools22.0.5 23.1.0Alejandro Hernandez
python-setuptools 22.0.5 23.1.0Alejandro Hernandez
perl-native   5.22.1 5.24.0Alejandro Hernandez
python3-native3.5.1  3.5.2 Alejandro Hernandez
python2.7.11 2.7.12Alejandro Hernandez
liberation-fonts  1.04   2.00.1Alexander Kanavin
2.x depends on fontforge pa...
bdwgc 7.4.2  7.4.4 Alexander Kanavin
vala  0.30.1 0.32.1Alexander Kanavin
epiphany  3.18.4 3.20.3Alexander Kanavin
libwnck3  3.14.1 3.20.1Alexander Kanavin
nss   3.23   3.24  Alexander Kanavin
libarchive3.2.0  3.2.1 Alexander Kanavin
gnutls3.4.11 3.5.1 Alexander Kanavin
ffmpeg3.0.2  3.1.1 Alexander Kanavin
bash-completion   2.12.3   Alexander Kanavin
btrfs-tools   4.5.3  4.6.1 Alexander Kanavin
mpg1231.23.4 1.23.6Alexander Kanavin
babeltrace1.3.2  1.4.0 Alexander Kanavin
mkelfimage4.0+gitX   4.4+gitAUTOINC+58...  Alexander Kanavin
mkelfimage has been removed...
desktop-file-util...  0.22   0.23  Alexander Kanavin
apt   1.0.10.1   1.2.14Aníbal Limón
apt-native1.0.10.1   1.2.14Aníbal Limón
pinentry  0.9.2  0.9.7 Armin Kuster
linux-libc-headers4.44.6.3 Bruce Ashfield
guilt-native  0.35+gitX  0.36+gitAUTOINC+2...  Bruce Ashfield
at3.1.18 3.1.20Chen Qi
byacc 20160324   20160606  Chen Qi
cups  2.1.3  2.1.4 Chen Qi
sudo  1.8.16 1.8.17p1  Chen Qi
sysstat   11.3.4 11.3.5Chen Qi
u-boot-fw-utils   v2016.03+gitX  v2016.05+gitAUTOI...  Denys Dmytriyenko
u-boot-mkimagev2016.03+gitX  v2016.05+gitAUTOI...  Denys Dmytriyenko
u-bootv2016.03+gitX  v2016.05+gitAUTOI...  Denys Dmytriyenko
createrepo0.4.11 0.10.4Hongxu Jia   
Versions after 0.9.* use YU...
ncurses   6.0+20160319   6.0+20160625  Hongxu Jia
libgcrypt 1.7.0  1.7.1 Hongxu Jia
gnupg 2.1.12 2.1.13Hongxu Jia
libinput  1.3.0  1.3.3 Jussi Kukkonen
weston1.10.0 1.11.0Jussi Kukkonen
matchbox-config-gtk   0.22 Jussi Kukkonen
matchbox-terminal 0.12 Jussi Kukkonen
sato-screenshot   0.22 Jussi Kukkonen
settings-daemon   0.0.2  2 Jussi Kukkonen
xf86-input-evdev  2.10.2 2.10.3Jussi Kukkonen
xf86-input-synaptics  1.8.3  1.8.99.1  Jussi Kukkonen
matchbox-theme-sato   0.22 Jussi Kukkonen
sgmlspl-native1.1+gitX   1.03+gitAUTOINC+f...  Jussi Kukkonen
wayland

[yocto] [Recipe reporting system] Upgradable recipe name list

2016-07-01 Thread recipe-report

This mail was sent out by Recipe reporting system.

This message list those recipes which need to be upgraded. If maintainers
believe some of them needn't to upgrade at this time, they can fill
RECIPE_NO_UPDATE_REASON in respective recipe file to ignore this remainder
until newer upstream version was detected.

Example:
RECIPE_NO_UPDATE_REASON = "Version 2.0 is unstable"

You can check the detail information at:

http://recipes.yoctoproject.org/

Package   VersionUpstream version  Maintainer   
NoUpgradeReason
  -    ---  
--
perl  5.22.1 5.24.0Alejandro Hernandez
texinfo   6.06.1   Alejandro Hernandez
ruby  2.2.5  2.3.1 Alejandro Hernandez
python3   3.5.1  3.5.2 Alejandro Hernandez
python-native 2.7.11 2.7.12Alejandro Hernandez
python3-git   1.0.2  2.0.6 Alejandro Hernandez
cronie1.5.0  1.5.1 Alejandro Hernandez
swig  3.0.8  3.0.10Alejandro Hernandez
python-git2.0.5  2.0.6 Alejandro Hernandez
python3-setuptools22.0.5 23.1.0Alejandro Hernandez
python-setuptools 22.0.5 23.1.0Alejandro Hernandez
perl-native   5.22.1 5.24.0Alejandro Hernandez
python3-native3.5.1  3.5.2 Alejandro Hernandez
python2.7.11 2.7.12Alejandro Hernandez
liberation-fonts  1.04   2.00.1Alexander Kanavin
2.x depends on fontforge pa...
bdwgc 7.4.2  7.4.4 Alexander Kanavin
vala  0.30.1 0.32.1Alexander Kanavin
epiphany  3.18.4 3.20.3Alexander Kanavin
libwnck3  3.14.1 3.20.1Alexander Kanavin
nss   3.23   3.24  Alexander Kanavin
libarchive3.2.0  3.2.1 Alexander Kanavin
gnutls3.4.11 3.5.1 Alexander Kanavin
ffmpeg3.0.2  3.1.1 Alexander Kanavin
bash-completion   2.12.3   Alexander Kanavin
btrfs-tools   4.5.3  4.6.1 Alexander Kanavin
mpg1231.23.4 1.23.6Alexander Kanavin
babeltrace1.3.2  1.4.0 Alexander Kanavin
mkelfimage4.0+gitX   4.4+gitAUTOINC+58...  Alexander Kanavin
mkelfimage has been removed...
desktop-file-util...  0.22   0.23  Alexander Kanavin
apt   1.0.10.1   1.2.14Aníbal Limón
apt-native1.0.10.1   1.2.14Aníbal Limón
pinentry  0.9.2  0.9.7 Armin Kuster
linux-libc-headers4.44.6.3 Bruce Ashfield
guilt-native  0.35+gitX  0.36+gitAUTOINC+2...  Bruce Ashfield
at3.1.18 3.1.20Chen Qi
byacc 20160324   20160606  Chen Qi
cups  2.1.3  2.1.4 Chen Qi
sudo  1.8.16 1.8.17p1  Chen Qi
sysstat   11.3.4 11.3.5Chen Qi
u-boot-fw-utils   v2016.03+gitX  v2016.05+gitAUTOI...  Denys Dmytriyenko
u-boot-mkimagev2016.03+gitX  v2016.05+gitAUTOI...  Denys Dmytriyenko
u-bootv2016.03+gitX  v2016.05+gitAUTOI...  Denys Dmytriyenko
createrepo0.4.11 0.10.4Hongxu Jia   
Versions after 0.9.* use YU...
ncurses   6.0+20160319   6.0+20160625  Hongxu Jia
libgcrypt 1.7.0  1.7.1 Hongxu Jia
gnupg 2.1.12 2.1.13Hongxu Jia
libinput  1.3.0  1.3.3 Jussi Kukkonen
weston1.10.0 1.11.0Jussi Kukkonen
matchbox-config-gtk   0.22 Jussi Kukkonen
matchbox-terminal 0.12 Jussi Kukkonen
sato-screenshot   0.22 Jussi Kukkonen
settings-daemon   0.0.2  2 Jussi Kukkonen
xf86-input-evdev  2.10.2 2.10.3Jussi Kukkonen
xf86-input-synaptics  1.8.3  1.8.99.1  Jussi Kukkonen
matchbox-theme-sato   0.22 Jussi Kukkonen
sgmlspl-native1.1+gitX   1.03+gitAUTOINC+f...  Jussi Kukkonen
wayland

Re: [yocto] Shorter build time?

2016-07-01 Thread Daniel.

So we have full parallelism :)

2016-07-01 14:01 GMT-03:00 Burton, Ross :
>
> On 1 July 2016 at 17:37, Daniel.  wrote:
>>
>> I read that python can't execute multiple threads simultaneously, but
>> that wouldn't be a problem if each python task is executed at its own
>> interpreter instance (process). This last statement is what I don't
>> really know, some experts on Yocto's internals may clarify that, maybe
>
>
> Yes, each worker is a separate Python process.
>
> Ross



-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Shorter build time?

2016-07-01 Thread Burton, Ross

On 1 July 2016 at 17:37, Daniel.  wrote:

> I read that python can't execute multiple threads simultaneously, but
> that wouldn't be a problem if each python task is executed at its own
> interpreter instance (process). This last statement is what I don't
> really know, some experts on Yocto's internals may clarify that, maybe
>

Yes, each worker is a separate Python process.

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

Re: [yocto] Shorter build time?

2016-07-01 Thread Daniel.

Hi Takashi,

I read that python can't execute multiple threads simultaneously, but
that wouldn't be a problem if each python task is executed at its own
interpreter instance (process). This last statement is what I don't
really know, some experts on Yocto's internals may clarify that, maybe
:)

Regards,

2016-06-30 22:29 GMT-03:00 Takashi Matsuzawa :
>
> Hello Yocto.
>
> Well, this may not be a very new topic, but I wonder if you have recent 
> suggetions.
> So far I have tried the followings and see some improvement, making the build 
> time to days to hours.
>
> 1) All of the directories, DL_DIR, SSTATE_CACHE, TMPDIR, DEPLOY_DIR are on 
> SSD.
> 2) .repo and working directory (where I synch my recipes) also on SSD.
> 3) Set BB_NUMBER_PARSE_THREADS/PARALLEL_MAKE/BB_NUMBER_THREADS to something 
> like 20, 30, etc.
> 4) Enable use of ICECC.
> 5) Use pigz, pbzip2, pxz instead of gzip, bzip2 and xz.
>
> I can see with 3-5), I am benefited from my multicore PCs and see some 
> scaling effects (if I can add more PCs or CPU core.)
> However I think there is i the build not paralleled or distributed easily.
>
> i) python tasks
> They say python has slimitation of being single thread, and could be a bottle 
> neck since most of yocto build tasks are in python, if not native/cross 
> toolchain jobs.
>
> ii) zip / tar tasks
> e.g. seeing rootfs taking forever, jobs not distributed to the other machines.
> I understand it is writing files to one target tree and doing a bit tar/zip 
> for the files, being one big job though.
>
> I wonder if I can do anything with i) and ii) at least to make them processed 
> in parallel.
> ICECC only can dispatch gcc jobs I believe.
> Any previous attemps to do the similar to non-gcc jobs?
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-autobuilder][PATCH] bin/release_scripts/release.py: Add some basic logging

2016-07-01 Thread Joshua G Lock

On Wed, 2016-06-29 at 16:08 -0700, Graydon, Tracy wrote:
> This patch adds some basic logging to help find failure point should
> the script
> barf due to lost ssh session, etc. Without it, finding where to
> resume is not
> particularly entertaining.
> 
> Signed-off-by: Graydon, Tracy 
> ---
>  bin/release_scripts/release.py | 43
> +++---
>  1 file changed, 40 insertions(+), 3 deletions(-)
> 
> diff --git a/bin/release_scripts/release.py
> b/bin/release_scripts/release.py
> index 89f68be..b62b48c 100755
> --- a/bin/release_scripts/release.py
> +++ b/bin/release_scripts/release.py
> @@ -10,6 +10,7 @@ __maintainer__ = "Tracy Graydon"
>  __email__ = "tracy.gray...@intel.com"
>  '''



> @@ -348,9 +355,18 @@ if __name__ == '__main__':
>  os.system("clear")
>  print
> 
> +logfile = 'staging.log'
> +try:
> +os.remove(logfile)
> +except OSError:
> +pass
> +
> +logging.basicConfig(format='%(levelname)s:%(message)s',filename=
> logfile,level=logging.INFO)
> +
>  VHOSTS = "/srv/www/vhosts"
>  AB_BASE = os.path.join(VHOSTS,
> "autobuilder.yoctoproject.org/pub/releases")
>  DL_DIR = os.path.join(VHOSTS,
> "downloads.yoctoproject.org/releases")
> +DL_BASE = os.path.join(DL_DIR, "/releases/yocto")

This will result in DL_BASE being /releases/yocto

You shouldn't include a path separator in any of the components after
the first. From the os.path.join() docs:

"If a component is an absolute path, all previous components are thrown
away and joining continues from the absolute path component."

i.e.

>>> import os
>>> os.path.join('/some', 'path', 'foo', 'bar')
'/some/path/foo/bar'
>>> os.path.join('/some', 'path', '/foo', 'bar')
'/foo/bar'


Cheers,

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

Re: [yocto] setcap using recipe

2016-07-01 Thread Burton, Ross

On 1 July 2016 at 15:03, Mathieu Allard  wrote:

> I think that the main issue here is that the pkg_postinst function runs
> its action at the rootfs creation time, and not on the target as advised by
> Ross.
>

Yes, as I said in the first suggestion you'll need to ensure this runs on
the target (check $D and exit 1 if its set).

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

[yocto] Yocto Project Status WW27

2016-07-01 Thread Richard Purdie

Current Dev Position: YP 2.2 M2
Next Deadline: YP 2.2 M2 cut off would be: 7/18/16

SWAT team rotation: Armin -> Bill
(https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team)

Key Status/Updates:

* QA test report for 2.2 M1 is looking reasonable. There are some issues in 
toaster, 
  wic and eclipse but nothing that looks like it would block the milestone.

* The release is very “front loaded” with many things being targeted for M1, 
  then slipping to M2 and not many things targeted for M2/M3. We need to 
  get better at load balancing bugs.

Key YP 2.2 Dates:

YP 2.2 M1 release would be: 6/24/16
YP 2.2 M2 cut off would be: 7/18/16
YP 2.2 M2 release would be: 7/29/16
YP 2.2 M3 cut off would be: 8/29/16
YP 2.2 M3 release would be: 9/9/16
YP 2.2 M4 cut off would be: 10/3/16
YP 2.2 M4 release would be: 10/28/16

Tracking Metrics:WDD 2718 (last week 2745)
(https://wiki.yoctoproject.org/charts/combo.html)

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.2_Status
https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_2.2_Features

[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Failed to cross compile kernel with Yocto toolchain

2016-07-01 Thread Zhenhua Luo

Thanks a lot for your comments, Daniel. 

Can somebody please shed light on how to fix the issue in Yocto recipes?  


Best Regards,

Zhenhua

> -Original Message-
> From: Daniel. [mailto:danielhi...@gmail.com]
> Sent: Friday, July 01, 2016 4:48 AM
> To: Zhenhua Luo 
> Cc: Khem Raj ; yocto@yoctoproject.org
> Subject: Re: [yocto] Failed to cross compile kernel with Yocto toolchain
> 
> The problem is that ccache is not finding the compiler after environment-
> setup*.sh is sourced.Your error message can be foud at:
> https://github.com/ccache/ccache/blob/master/ccache.c#L2075. It seems that
> its searching for "gcc" when I though that kernel would search for
> "${CROSS_COMPILE}gcc"
> 
> 2016-06-29 22:54 GMT-03:00 Zhenhua Luo :
> > I think you mean /usr/lib64/ccache/gcc instead of /usr/lib64/gcc, it is a 
> > valid
> link.
> >
> > $ source /opt/poky/2.1+snapshot/environment-setup-ppce500mc-poky-
> linux
> > $ which gcc
> > /usr/lib64/ccache/gcc
> > $
> > $ ls -l /usr/lib64/ccache/gcc
> > lrwxrwxrwx 1 root root 16 Jun 29 18:22 /usr/lib64/ccache/gcc ->
> > ../../bin/ccache $ ls -l /usr/bin/ccache -rwxr-xr-x 1 root root 128584
> > Jan 26 14:58 /usr/bin/ccache $
> >
> >
> > Best Regards,
> >
> > Zhenhua
> >
> >> -Original Message-
> >> From: Daniel. [mailto:danielhi...@gmail.com]
> >> Sent: Wednesday, June 29, 2016 8:14 PM
> >> To: Zhenhua Luo 
> >> Cc: Khem Raj ; yocto@yoctoproject.org
> >> Subject: Re: [yocto] Failed to cross compile kernel with Yocto
> >> toolchain
> >>
> >> Is /usr/lib64/gcc a file or a link? Is it a valid link?
> >>
> >> 2016-06-29 5:52 GMT-03:00 Zhenhua Luo :
> >> > The /usr/lib64/ccache is added in PATH by /etc/profile.d/ccache.sh
> >> > when ccache is installed on Fedora host, the issue disappears if
> >> > one of the following changes is done.
> >> >
> >> > 1.   Remove /usr/lib64/ccache from PATH
> >> >
> >> > 2.   Move /usr/lib64/ccache after /usr/bin in PATH
> >> >
> >> > 3.   Set CCACHE_PATH equals to PATH
> >> >
> >> > 4.   Unset CCACHE_PATH
> >> >
> >> >
> >> >
> >> > Another observation, before sourcing
> >> > environment-setup--poky-linux,
> >> > gcc can be found even if /usr/lib64/ccache is in prepend to PATH,
> >> > but after sourcing the environment-setup--poky-linux script,
> >> > the gcc can’t be found, this should be a bug of the
> >> > environment-setup--poky-linux
> >> > script. Should I open a Bugzilla ticket to track it?
> >> >
> >> >
> >> >
> >> > $ echo $PATH
> >> >
> >> > /usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/us
> >> > r/l
> >> > ocal/sbin:/usr/sbin:/home/bjsimics/.local/bin:/home/bjsimics/bin
> >> >
> >> > which gcc
> >> >
> >> > /usr/lib64/ccache/gcc
> >> >
> >> > $ gcc -v
> >> >
> >> > Using built-in specs.
> >> >
> >> > COLLECT_GCC=/usr/bin/gcc
> >> >
> >> > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-
> >> wra
> >> > pper
> >> >
> >> > Target: x86_64-redhat-linux
> >> >
> >> > Configured with: ../configure --enable-bootstrap
> >> > --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto
> >> > --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
> >> > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
> >> > --enable-threads=posix --enable-checking=release --enable-multilib
> >> > --with-system-zlib --enable-__cxa_atexit
> >> > --disable-libunwind-exceptions --enable-gnu-unique-object
> >> > --enable-linker-build-id --with-linker-hash-style=gnu
> >> > --enable-plugin --enable-initfini-array --disable-libgcj
> >> > --with-default-libstdcxx-abi=gcc4-compatible --with-isl
> >> > --enable-libmpx --enable-gnu-indirect-function --with-tune=generic
> >> > --with-arch_32=i686 --build=x86_64-redhat-linux
> >> >
> >> > Thread model: posix
> >> >
> >> > gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC)
> >> >
> >> > $
> >> >
> >> > $ source /opt/poky/2.1+snapshot/environment-setup-ppce500mc-poky-
> >> linux
> >> >
> >> > $
> >> >
> >> > $ echo $PATH
> >> >
> >> > /opt/poky/2.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/p
> >> > oky
> >> > /2.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/sbin:/opt/poky/2.1+
> >> > sna
> >> > pshot/sysroots/x86_64-pokysdk-linux/bin:/opt/poky/2.1+snapshot/sysr
> >> > oot
> >> > s/x86_64-pokysdk-linux/sbin:/opt/poky/2.1+snapshot/sysroots/x86_64-
> >> > pok
> >> > ysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/opt/poky/2.1+snapsh
> >> > ot/
> >> > sysroots/x86_64-pokysdk-linux/usr/bin/powerpc-poky-linux:/opt/poky/
> >> > 2.1
> >> > +snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/powerpc-poky-linux-
> >> > +ucl
> >> > ibc:/opt/poky/2.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/po
> >> > wer
> >> > pc-poky-linux-musl:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/loc
> >> > al/
> >> > bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/bjsimics/.local/bin:/h
> >> > ome
> >> > /bjsimics/bin
> >> >
> >> > $
> >>

Re: [yocto] Xorg failing with SEGV after Krogoth update

2016-07-01 Thread Khem Raj

On Thu, Jun 30, 2016 at 10:24 PM, Allan Chandler
 wrote:
> We recently did (attempted? ) an upgrade of our Yocto embedded build system
> from Fido to Krogoth and, other than one rather massive issue, it all went
> well.
>
>
>
> The massive issue is the fact that  X11 is apparently not starting
> correctly. The embedded device boots okay since we can see in via a serial
> console as well as connecting via SSH.
>
>
>
> We've narrowed the actual issue down to the Xorg executable, after following
> the process the the rc5.d Xserver satrtup scripts and xinit - basically,
> Xorg is dumping core with the following output:
>

may be you can enable coredump and collect it for offline post mortem
setting ulimit -c unlimited e.g. when you run the suspected program will dump it

>
>
> X.Org X Server 1.18.0
>
> Release Date: 2015-11-09
>
> X Protocol Version 11, Revision 0
>
> Build Operating System: Linux 3.19.0-25-generic x86_64
>
> Current Operating System: Linux imx6 3.14.28+g2b0ab6d #1 SMP PREEMPT Thu
> Jun 30 12:20:09 AWST 2016 armv7l
>
> Kernel command line: console=ttymxc0,115200 consoleblank=0
> root=/dev/mmcblk3p2 rootwait
>
> Build Date: 30 June 2016  01:38:24PM
>
>
>
> Current version of pixman: 0.32.8
>
> Before reporting problems, check http://wiki.x.org
>
> to make sure that you have the latest version.
>
> Markers: (--) probed, (**) from config file, (==) default setting,
>
> (++) from command line, (!!) notice, (II) informational,
>
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>
> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Jul  1 00:12:43 2016
>
> (==) Using config file: "/etc/X11/xorg.conf"
>
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
>
> (==) No Layout section.  Using the first Screen section.
>
> (==) No screen section available. Using defaults.
>
> (**) |-->Screen "Default Screen Section" (0)
>
> (**) |   |-->Monitor ""
>
> (==) No device specified for screen "Default Screen Section".
>
> Using the first device section listed.
>
> (**) |   |-->Device "i.MX Accelerated Framebuffer Device"
>
> (==) No monitor specified for screen "Default Screen Section".
>
> Using a default monitor configuration.
>
> (**) Option "BlankTime" "0"
>
> (**) Option "StandbyTime" "0"
>
> (**) Option "SuspendTime" "0"
>
> (**) Option "OffTime" "0"
>
> (==) Automatically adding devices
>
> (==) Automatically enabling devices
>
> (==) Automatically adding GPU devices
>
> (==) Max clients allowed: 256, resource mask: 0x1f
>
> (WW) The directory "/usr/share/fonts/X11/misc/" does not exist.
>
> Entry deleted from font path.
>
> (WW) The directory "/usr/share/fonts/X11/TTF/" does not exist.
>
> Entry deleted from font path.
>
> (WW) The directory "/usr/share/fonts/X11/OTF/" does not exist.
>
> Entry deleted from font path.
>
> (WW) The directory "/usr/share/fonts/X11/Type1/" does not exist.
>
> Entry deleted from font path.
>
> (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
>
> Entry deleted from font path.
>
> (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
>
> Entry deleted from font path.
>
> (==) FontPath set to:
>
>
>
> (==) ModulePath set to "/usr/lib/xorg/modules"
>
> (II) The server relies on udev to provide the list of input devices.
>
> If no devices become available, reconfigure udev or disable
> AutoAddDevices.
>
> (II) Loader magic: 0x1c3a20
>
> (II) Module ABI versions:
>
> X.Org ANSI C Emulation: 0.4
>
> X.Org Video Driver: 20.0
>
> X.Org XInput driver : 22.1
>
> X.Org Server Extension : 9.0
>
> (II) xfree86: Adding drm device (/dev/dri/card0)
>
> (II) no primary bus or device found
>
> falling back to /sys/devices/platform/Vivante GCCore/drm/card0
>
> (II) LoadModule: "glx"
>
> (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
>
> (II) Module glx: vendor="X.Org Foundation"
>
> compiled for 1.18.0, module version = 1.0.0
>
> ABI class: X.Org Server Extension, version 9.0
>
> (==) AIGLX enabled
>
> (II) LoadModule: "vivante"
>
> (II) Loading /usr/lib/xorg/modules/drivers/vivante_drv.so
>
> (II) Module vivante: vendor="X.Org Foundation"
>
> compiled for 1.18.0, module version = 1.0.0
>
> Module class: X.Org Video Driver
>
> ABI class: X.Org Video Driver, version 20.0
>
> (II) VIVANTE: driver for vivante fb: VivanteGC500, VivanteGC2100,
>
> VivanteGCCORE
>
> (--) using VT number 3
>
>
>
> (WW) Falling back to old probe method for vivante
>
> (II) Loading sub module "fbdevhw"
>
> (II) LoadModule: "fbdevhw"
>
>

[linux-yocto] [PATCH 7/7] usb: typec: Use strtobool instead of kstrtobool for 4.4 kernel

2016-07-01 Thread Pranav Tipnis

Upstream-Status: Inappropriate [other]
 Type C support has been backported from kernel
 4.7-rc which does not need this change.

Type C support has been backported from 4.7 kernel which has
kstrtobool function to convert string to bool. In 4.4 kernel,
we have strtobool instead. This patch changes the API used to
convert string to bool.

Signed-off-by: Pranav Tipnis 
---
 drivers/usb/typec/typec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
index bbfd6e5..341380a 100644
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -625,7 +625,7 @@ typec_altmode_active_store(struct device *dev, struct 
device_attribute *attr,
bool activate;
int ret;
 
-   ret = kstrtobool(buf, );
+   ret = strtobool(buf, );
if (ret)
return ret;
 
-- 
1.9.1

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

[linux-yocto] [PATCH 4/7] acpi/pmic: modify the pen function signature to take bit field

2016-07-01 Thread Pranav Tipnis

From: Bin Gao 

Upstream-Status: Submitted [https://patchwork.kernel.org/patch/9196245/]
 This patch was submitted by Bin Gao.

Issue description: On some pmics, the policy enable for thermal alerts
refers to different bit fields of the same registers, whereas on other
pmics, the policy enable refers to the same bit field on different
registers. Previous implementation did not provide the flexibility for
supporting the first approach.

Solution: Modified the policy enable function to take bit field as well.
The use of bit field is left to the pmic specific opregion driver.

Signed-off-by: Yegnesh Iyer 
Signed-off-by: Bin Gao 
---
 drivers/acpi/pmic/intel_pmic.c | 13 +++--
 drivers/acpi/pmic/intel_pmic.h |  4 ++--
 drivers/acpi/pmic/intel_pmic_crc.c |  5 +++--
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index bd772cd..410e96f 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -131,7 +131,7 @@ static int pmic_thermal_aux(struct intel_pmic_opregion 
*opregion, int reg,
 }
 
 static int pmic_thermal_pen(struct intel_pmic_opregion *opregion, int reg,
-   u32 function, u64 *value)
+   int bit, u32 function, u64 *value)
 {
struct intel_pmic_opregion_data *d = opregion->data;
struct regmap *regmap = opregion->regmap;
@@ -140,12 +140,12 @@ static int pmic_thermal_pen(struct intel_pmic_opregion 
*opregion, int reg,
return -ENXIO;
 
if (function == ACPI_READ)
-   return d->get_policy(regmap, reg, value);
+   return d->get_policy(regmap, reg, bit, value);
 
if (*value != 0 && *value != 1)
return -EINVAL;
 
-   return d->update_policy(regmap, reg, *value);
+   return d->update_policy(regmap, reg, bit, *value);
 }
 
 static bool pmic_thermal_is_temp(int address)
@@ -170,13 +170,13 @@ static acpi_status intel_pmic_thermal_handler(u32 
function,
 {
struct intel_pmic_opregion *opregion = region_context;
struct intel_pmic_opregion_data *d = opregion->data;
-   int reg, result;
+   int reg, bit, result;
 
if (bits != 32 || !value64)
return AE_BAD_PARAMETER;
 
result = pmic_get_reg_bit(address, d->thermal_table,
- d->thermal_table_count, , NULL);
+ d->thermal_table_count, , );
if (result == -ENOENT)
return AE_BAD_PARAMETER;
 
@@ -187,7 +187,8 @@ static acpi_status intel_pmic_thermal_handler(u32 function,
else if (pmic_thermal_is_aux(address))
result = pmic_thermal_aux(opregion, reg, function, value64);
else if (pmic_thermal_is_pen(address))
-   result = pmic_thermal_pen(opregion, reg, function, value64);
+   result = pmic_thermal_pen(opregion, reg, bit,
+   function, value64);
else
result = -EINVAL;
 
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index d4e90af..e8bfa7b 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -12,8 +12,8 @@ struct intel_pmic_opregion_data {
int (*update_power)(struct regmap *r, int reg, int bit, bool on);
int (*get_raw_temp)(struct regmap *r, int reg);
int (*update_aux)(struct regmap *r, int reg, int raw_temp);
-   int (*get_policy)(struct regmap *r, int reg, u64 *value);
-   int (*update_policy)(struct regmap *r, int reg, int enable);
+   int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
+   int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
struct pmic_table *power_table;
int power_table_count;
struct pmic_table *thermal_table;
diff --git a/drivers/acpi/pmic/intel_pmic_crc.c 
b/drivers/acpi/pmic/intel_pmic_crc.c
index 42df46a..0582da5 100644
--- a/drivers/acpi/pmic/intel_pmic_crc.c
+++ b/drivers/acpi/pmic/intel_pmic_crc.c
@@ -141,7 +141,8 @@ static int intel_crc_pmic_update_aux(struct regmap *regmap, 
int reg, int raw)
regmap_update_bits(regmap, reg - 1, 0x3, raw >> 8) ? -EIO : 0;
 }
 
-static int intel_crc_pmic_get_policy(struct regmap *regmap, int reg, u64 
*value)
+static int intel_crc_pmic_get_policy(struct regmap *regmap,
+   int reg, int bit, u64 *value)
 {
int pen;
 
@@ -152,7 +153,7 @@ static int intel_crc_pmic_get_policy(struct regmap *regmap, 
int reg, u64 *value)
 }
 
 static int intel_crc_pmic_update_policy(struct regmap *regmap,
-   int reg, int enable)
+   int reg, int bit, int enable)
 {
int alert0;
 
-- 
1.9.1

-- 
___

[linux-yocto] [PATCH 2/7] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

2016-07-01 Thread Pranav Tipnis

Upstream-Status: Submitted [https://lkml.org/lkml/2016/6/29/350]
 This patch was submitted by Heikki Krogerus on
 lkml.org.

This adds driver for the USB Type-C PHY on Intel WhiskeyCove
PMIC which is available on some of the Intel Broxton SoC
based platforms.

Signed-off-by: Heikki Krogerus 
---
 drivers/usb/typec/Kconfig   |  14 ++
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/typec_wcove.c | 371 
 3 files changed, 386 insertions(+)
 create mode 100644 drivers/usb/typec/typec_wcove.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index b229fb9..7a345a4 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -4,4 +4,18 @@ menu "USB PD and Type-C drivers"
 config TYPEC
tristate
 
+config TYPEC_WCOVE
+   tristate "Intel WhiskeyCove PMIC USB Type-C PHY driver"
+   depends on ACPI
+   depends on INTEL_SOC_PMIC
+   depends on INTEL_PMC_IPC
+   select TYPEC
+   help
+ This driver adds support for USB Type-C detection on Intel Broxton
+ platforms that have Intel Whiskey Cove PMIC. The driver can detect the
+ role and cable orientation.
+
+ To compile this driver as module, choose M here: the module will be
+ called typec_wcove
+
 endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 1012a8b..b9cb862 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_TYPEC)+= typec.o
+obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
diff --git a/drivers/usb/typec/typec_wcove.c b/drivers/usb/typec/typec_wcove.c
new file mode 100644
index 000..c7c2d28
--- /dev/null
+++ b/drivers/usb/typec/typec_wcove.c
@@ -0,0 +1,371 @@
+/**
+ * typec_wcove.c - WhiskeyCove PMIC USB Type-C PHY driver
+ *
+ * Copyright (C) 2016 Intel Corporation
+ * Author: Heikki Krogerus 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register offsets */
+#define WCOVE_CHGRIRQ0 0x4e09
+#define WCOVE_PHYCTRL  0x5e07
+
+#define USBC_CONTROL1  0x7001
+#define USBC_CONTROL2  0x7002
+#define USBC_CONTROL3  0x7003
+#define USBC_CC1_CTRL  0x7004
+#define USBC_CC2_CTRL  0x7005
+#define USBC_STATUS1   0x7007
+#define USBC_STATUS2   0x7008
+#define USBC_STATUS3   0x7009
+#define USBC_IRQ1  0x7015
+#define USBC_IRQ2  0x7016
+#define USBC_IRQMASK1  0x7017
+#define USBC_IRQMASK2  0x7018
+
+/* Register bits */
+
+#define USBC_CONTROL1_MODE_DRP(r)  ((r & ~0x7) | 4)
+
+#define USBC_CONTROL2_UNATT_SNKBIT(0)
+#define USBC_CONTROL2_UNATT_SRCBIT(1)
+#define USBC_CONTROL2_DIS_ST   BIT(2)
+
+#define USBC_CONTROL3_PD_DIS   BIT(1)
+
+#define USBC_CC_CTRL_VCONN_EN  BIT(1)
+
+#define USBC_STATUS1_DET_ONGOING   BIT(6)
+#define USBC_STATUS1_RSLT(r)   (r & 0xf)
+#define USBC_RSLT_NOTHING  0
+#define USBC_RSLT_SRC_DEFAULT  1
+#define USBC_RSLT_SRC_1_5A 2
+#define USBC_RSLT_SRC_3_0A 3
+#define USBC_RSLT_SNK  4
+#define USBC_RSLT_DEBUG_ACC5
+#define USBC_RSLT_AUDIO_ACC6
+#define USBC_RSLT_UNDEF15
+#define USBC_STATUS1_ORIENT(r) ((r >> 4) & 0x3)
+#define USBC_ORIENT_NORMAL 1
+#define USBC_ORIENT_REVERSE2
+
+#define USBC_STATUS2_VBUS_REQ  BIT(5)
+
+#define USBC_IRQ1_ADCDONE1 BIT(2)
+#define USBC_IRQ1_OVERTEMP BIT(1)
+#define USBC_IRQ1_SHORTBIT(0)
+
+#define USBC_IRQ2_CC_CHANGEBIT(7)
+#define USBC_IRQ2_RX_PDBIT(6)
+#define USBC_IRQ2_RX_HRBIT(5)
+#define USBC_IRQ2_RX_CRBIT(4)
+#define USBC_IRQ2_TX_SUCCESS   BIT(3)
+#define USBC_IRQ2_TX_FAIL  BIT(2)
+
+#define USBC_IRQMASK1_ALL  (USBC_IRQ1_ADCDONE1 | USBC_IRQ1_OVERTEMP | \
+USBC_IRQ1_SHORT)
+
+#define USBC_IRQMASK2_ALL  (USBC_IRQ2_CC_CHANGE | USBC_IRQ2_RX_PD | \
+USBC_IRQ2_RX_HR | USBC_IRQ2_RX_CR | \
+USBC_IRQ2_TX_SUCCESS | USBC_IRQ2_TX_FAIL)
+
+struct wcove_typec {
+   struct mutex lock; /* device lock */
+   struct device *dev;
+   struct regmap *regmap;
+   struct typec_port *port;
+   struct typec_capability cap;
+   struct typec_connection con;
+   struct typec_partner partner;
+};
+
+enum wcove_typec_func {
+   WCOVE_FUNC_DRIVE_VBUS = 1,
+

[linux-yocto] [PATCH 0/7] USB Type C backport on linux-yocto-4.4 bxt-rebase branch

2016-07-01 Thread Pranav Tipnis

This patch set backports USB Type C support on linux-yocto-4.4
from kernel version 4.7-rc. These patches have been submitted
upstream and the approval is in progress, hence may not be
final. The patches have been rebased on bxt-rebase branch.

Bin Gao (2):
  acpi/pmic: modify the pen function signature to take bit field
  acpi/pmic: Add opregion driver for Intel BXT WhiskeyCove PMIC

Felipe Balbi (1):
  acpi/pmic: Add support for PMIC regs operation region

Pranav Tipnis (4):
  usb: USB Type-C connector class
  usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
  mfd: intel_soc_pmic_bxtwc: Add Intel BXT WhiskeyCove PMIC ADC thermal
channel mapping and USB type-C resources
  usb: typec: Use strtobool instead of kstrtobool for 4.4 kernel

 Documentation/ABI/testing/sysfs-class-typec |  236 +
 Documentation/usb/typec.txt |  103 +++
 MAINTAINERS |9 +
 drivers/acpi/Kconfig|6 +
 drivers/acpi/Makefile   |1 +
 drivers/acpi/pmic/intel_pmic.c  |   82 +-
 drivers/acpi/pmic/intel_pmic.h  |4 +-
 drivers/acpi/pmic/intel_pmic_bxtwc.c|  424 +
 drivers/acpi/pmic/intel_pmic_crc.c  |5 +-
 drivers/mfd/intel_soc_pmic_bxtwc.c  |  126 ++-
 drivers/usb/Kconfig |2 +
 drivers/usb/Makefile|2 +
 drivers/usb/typec/Kconfig   |   21 +
 drivers/usb/typec/Makefile  |2 +
 drivers/usb/typec/typec.c   | 1277 +++
 drivers/usb/typec/typec_wcove.c |  371 
 include/linux/mfd/intel_soc_pmic.h  |   21 +
 include/linux/usb/typec.h   |  260 ++
 18 files changed, 2940 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-typec
 create mode 100644 Documentation/usb/typec.txt
 create mode 100644 drivers/acpi/pmic/intel_pmic_bxtwc.c
 create mode 100644 drivers/usb/typec/Kconfig
 create mode 100644 drivers/usb/typec/Makefile
 create mode 100644 drivers/usb/typec/typec.c
 create mode 100644 drivers/usb/typec/typec_wcove.c
 create mode 100644 include/linux/usb/typec.h

-- 
1.9.1

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

Re: [yocto] Failed to cross compile kernel with Yocto toolchain

2016-07-01 Thread Khem Raj

you can try to set HOSTCC=/usr/bin/gcc along when you call make may be
via EXTRA_OEMAKE, problem you have is that kernel is expecting gcc to
be used for host utilties and ccache has overrides for gcc which may
not be working in all situations. Ideally you should just uninstall
ccache from your build host.

On Fri, Jul 1, 2016 at 1:45 AM, Zhenhua Luo  wrote:
> Thanks a lot for your comments, Daniel.
>
> Can somebody please shed light on how to fix the issue in Yocto recipes?
>
>
> Best Regards,
>
> Zhenhua
>
>> -Original Message-
>> From: Daniel. [mailto:danielhi...@gmail.com]
>> Sent: Friday, July 01, 2016 4:48 AM
>> To: Zhenhua Luo 
>> Cc: Khem Raj ; yocto@yoctoproject.org
>> Subject: Re: [yocto] Failed to cross compile kernel with Yocto toolchain
>>
>> The problem is that ccache is not finding the compiler after environment-
>> setup*.sh is sourced.Your error message can be foud at:
>> https://github.com/ccache/ccache/blob/master/ccache.c#L2075. It seems that
>> its searching for "gcc" when I though that kernel would search for
>> "${CROSS_COMPILE}gcc"
>>
>> 2016-06-29 22:54 GMT-03:00 Zhenhua Luo :
>> > I think you mean /usr/lib64/ccache/gcc instead of /usr/lib64/gcc, it is a 
>> > valid
>> link.
>> >
>> > $ source /opt/poky/2.1+snapshot/environment-setup-ppce500mc-poky-
>> linux
>> > $ which gcc
>> > /usr/lib64/ccache/gcc
>> > $
>> > $ ls -l /usr/lib64/ccache/gcc
>> > lrwxrwxrwx 1 root root 16 Jun 29 18:22 /usr/lib64/ccache/gcc ->
>> > ../../bin/ccache $ ls -l /usr/bin/ccache -rwxr-xr-x 1 root root 128584
>> > Jan 26 14:58 /usr/bin/ccache $
>> >
>> >
>> > Best Regards,
>> >
>> > Zhenhua
>> >
>> >> -Original Message-
>> >> From: Daniel. [mailto:danielhi...@gmail.com]
>> >> Sent: Wednesday, June 29, 2016 8:14 PM
>> >> To: Zhenhua Luo 
>> >> Cc: Khem Raj ; yocto@yoctoproject.org
>> >> Subject: Re: [yocto] Failed to cross compile kernel with Yocto
>> >> toolchain
>> >>
>> >> Is /usr/lib64/gcc a file or a link? Is it a valid link?
>> >>
>> >> 2016-06-29 5:52 GMT-03:00 Zhenhua Luo :
>> >> > The /usr/lib64/ccache is added in PATH by /etc/profile.d/ccache.sh
>> >> > when ccache is installed on Fedora host, the issue disappears if
>> >> > one of the following changes is done.
>> >> >
>> >> > 1.   Remove /usr/lib64/ccache from PATH
>> >> >
>> >> > 2.   Move /usr/lib64/ccache after /usr/bin in PATH
>> >> >
>> >> > 3.   Set CCACHE_PATH equals to PATH
>> >> >
>> >> > 4.   Unset CCACHE_PATH
>> >> >
>> >> >
>> >> >
>> >> > Another observation, before sourcing
>> >> > environment-setup--poky-linux,
>> >> > gcc can be found even if /usr/lib64/ccache is in prepend to PATH,
>> >> > but after sourcing the environment-setup--poky-linux script,
>> >> > the gcc can’t be found, this should be a bug of the
>> >> > environment-setup--poky-linux
>> >> > script. Should I open a Bugzilla ticket to track it?
>> >> >
>> >> >
>> >> >
>> >> > $ echo $PATH
>> >> >
>> >> > /usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/us
>> >> > r/l
>> >> > ocal/sbin:/usr/sbin:/home/bjsimics/.local/bin:/home/bjsimics/bin
>> >> >
>> >> > which gcc
>> >> >
>> >> > /usr/lib64/ccache/gcc
>> >> >
>> >> > $ gcc -v
>> >> >
>> >> > Using built-in specs.
>> >> >
>> >> > COLLECT_GCC=/usr/bin/gcc
>> >> >
>> >> > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-
>> >> wra
>> >> > pper
>> >> >
>> >> > Target: x86_64-redhat-linux
>> >> >
>> >> > Configured with: ../configure --enable-bootstrap
>> >> > --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto
>> >> > --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
>> >> > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
>> >> > --enable-threads=posix --enable-checking=release --enable-multilib
>> >> > --with-system-zlib --enable-__cxa_atexit
>> >> > --disable-libunwind-exceptions --enable-gnu-unique-object
>> >> > --enable-linker-build-id --with-linker-hash-style=gnu
>> >> > --enable-plugin --enable-initfini-array --disable-libgcj
>> >> > --with-default-libstdcxx-abi=gcc4-compatible --with-isl
>> >> > --enable-libmpx --enable-gnu-indirect-function --with-tune=generic
>> >> > --with-arch_32=i686 --build=x86_64-redhat-linux
>> >> >
>> >> > Thread model: posix
>> >> >
>> >> > gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC)
>> >> >
>> >> > $
>> >> >
>> >> > $ source /opt/poky/2.1+snapshot/environment-setup-ppce500mc-poky-
>> >> linux
>> >> >
>> >> > $
>> >> >
>> >> > $ echo $PATH
>> >> >
>> >> > /opt/poky/2.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/p
>> >> > oky
>> >> > /2.1+snapshot/sysroots/x86_64-pokysdk-linux/usr/sbin:/opt/poky/2.1+
>> >> > sna
>> >> > pshot/sysroots/x86_64-pokysdk-linux/bin:/opt/poky/2.1+snapshot/sysr
>> >> > oot
>> >> > s/x86_64-pokysdk-linux/sbin:/opt/poky/2.1+snapshot/sysroots/x86_64-
>> >> > pok
>> >> >

Re: [yocto] setcap using recipe

2016-07-01 Thread Daniel.

Hmmm I see,

Well, I didn't note that. And yeah, that command should be ran at
first boot, (that feature saved my life a bunch of times :) )

Regards,

2016-07-01 11:03 GMT-03:00 Mathieu Allard :
> Hello,
>
> I think that the main issue here is that the pkg_postinst function runs its 
> action at the rootfs creation time, and not on the target as advised by Ross.
>
> The chapter 5.3.16, "post-installation scripts" in the mega-manual offers 
> some detailed explanations on how to make it run after the first boot.
>
>
> Regards,
>
> Mathieu
>
>
> - Original Message -
> From: "Daniel." 
> To: "Kumar, Shrawan" 
> Cc: yocto@yoctoproject.org
> Sent: Friday, July 1, 2016 3:54:15 PM
> Subject: Re: [yocto] setcap using recipe
>
> Does your target filesystem support it? ubifs doesn't :(
> http://www.linux-mtd.infradead.org/doc/ubifs.html#L_xattr
>
> 2016-07-01 9:53 GMT-03:00 Kumar, Shrawan :
>> Hello Ross,
>>
>>
>>
>> None of the approach is working .  I have attached the  recipe where I am
>> trying to execute postinst . It builds successfully , But when I run getcap
>> on the target , does not return the set capabilities.
>>
>>
>>
>> Help will be highly appreciated .
>>
>>
>>
>> Regards
>>
>> Shrawan
>>
>> From: Burton, Ross [mailto:ross.bur...@intel.com]
>> Sent: Friday, June 24, 2016 6:40 PM
>>
>>
>> To: Kumar, Shrawan
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] setcap using recipe
>>
>>
>>
>> Looks like using setcap directly is broken currently, there are two
>> workarounds:
>>
>>
>>
>> 1) use a postinst to invoke setcap on the target instead
>>
>> 2) test the patch for pseudo that is on this list ([PATCH] Add capset pseudo
>> function that always succeeds) and verify that it fixes the problem for you.
>>
>>
>>
>> Ross
>>
>>
>>
>> On 24 June 2016 at 13:31, Kumar, Shrawan  wrote:
>>
>> I am using Yocto 2.0.2
>>
>>
>>
>> Thanks and Regards
>>
>> Shrawan
>>
>>
>>
>> From: Burton, Ross [mailto:ross.bur...@intel.com]
>> Sent: Friday, June 24, 2016 5:56 PM
>>
>>
>> To: Kumar, Shrawan
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] setcap using recipe
>>
>>
>>
>> What version of OE/Yocto are you using?  Old versions of pseudo didn't
>> support xattrs at all.
>>
>>
>>
>> Ross
>>
>>
>>
>> On 24 June 2016 at 13:23, Kumar, Shrawan  wrote:
>>
>> Thanks Ross for your quick turn around , I am getting below error
>>
>>
>>
>> “Unable le to set CAP_SETFCAP effective capability: Operation not
>> permitted.”
>>
>>
>>
>> But when I use# sudo setcap cap_net_raw+ep  helloworldon command
>> line I am able to set the cap.
>>
>>
>>
>> To achieve the sudo realization  in recipe , I tried  as below , but no
>> luck…… Can you suggest something here  ?
>>
>>
>>
>> fakeroot do_install() {
>>
>> install -d ${D}${bindir}
>>
>> install -m 0755 helloworld ${D}${bindir}
>>
>> install -d ${D}/lib/systemd/system
>>
>> install -m 0755 hello.service ${D}/lib/systemd/system/
>>
>>  setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>>
>>
>>
>> }
>>
>>
>>
>> Thanks and Regards
>>
>> Shrawan
>>
>>
>>
>> From: Burton, Ross [mailto:ross.bur...@intel.com]
>> Sent: Friday, June 24, 2016 5:09 PM
>> To: Kumar, Shrawan
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] setcap using recipe
>>
>>
>>
>> Hi,
>>
>>
>>
>> On 24 June 2016 at 11:41, Kumar, Shrawan  wrote:
>>
>> Is there a way to  add a capability to a binary (cap_net_raw+ep),into a
>> recipe?
>>
>>
>>
>> Example :
>>
>> do_install() {
>>
>>install -d ${D}${bindir}
>>
>>install -m 0755 helloworld ${D}${bindir}
>>
>>install -d ${D}/lib/systemd/system
>>
>>install -m 0755 hello.service ${D}/lib/systemd/system/
>>
>>setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>>
>> }
>>
>>
>>
>> If yes is this correct approach to achieve the same from  package recipe
>> itself ?
>>
>>
>> capabilities on files are just extended attributes, so assuming that you
>> have a fairly recent Yocto and your host and target filesystems support
>> extended attributes, yes this should work.
>>
>>
>>
>> Ross
>>
>>
>>
>>
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
> --
> "Do or do not. There is no try"
>   Yoda Master
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setcap using recipe

2016-07-01 Thread Mathieu Allard

Hello,

I think that the main issue here is that the pkg_postinst function runs its 
action at the rootfs creation time, and not on the target as advised by Ross.

The chapter 5.3.16, "post-installation scripts" in the mega-manual offers some 
detailed explanations on how to make it run after the first boot.


Regards,

Mathieu


- Original Message -
From: "Daniel." 
To: "Kumar, Shrawan" 
Cc: yocto@yoctoproject.org
Sent: Friday, July 1, 2016 3:54:15 PM
Subject: Re: [yocto] setcap using recipe

Does your target filesystem support it? ubifs doesn't :(
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_xattr

2016-07-01 9:53 GMT-03:00 Kumar, Shrawan :
> Hello Ross,
>
>
>
> None of the approach is working .  I have attached the  recipe where I am
> trying to execute postinst . It builds successfully , But when I run getcap
> on the target , does not return the set capabilities.
>
>
>
> Help will be highly appreciated .
>
>
>
> Regards
>
> Shrawan
>
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, June 24, 2016 6:40 PM
>
>
> To: Kumar, Shrawan
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] setcap using recipe
>
>
>
> Looks like using setcap directly is broken currently, there are two
> workarounds:
>
>
>
> 1) use a postinst to invoke setcap on the target instead
>
> 2) test the patch for pseudo that is on this list ([PATCH] Add capset pseudo
> function that always succeeds) and verify that it fixes the problem for you.
>
>
>
> Ross
>
>
>
> On 24 June 2016 at 13:31, Kumar, Shrawan  wrote:
>
> I am using Yocto 2.0.2
>
>
>
> Thanks and Regards
>
> Shrawan
>
>
>
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, June 24, 2016 5:56 PM
>
>
> To: Kumar, Shrawan
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] setcap using recipe
>
>
>
> What version of OE/Yocto are you using?  Old versions of pseudo didn't
> support xattrs at all.
>
>
>
> Ross
>
>
>
> On 24 June 2016 at 13:23, Kumar, Shrawan  wrote:
>
> Thanks Ross for your quick turn around , I am getting below error
>
>
>
> “Unable le to set CAP_SETFCAP effective capability: Operation not
> permitted.”
>
>
>
> But when I use# sudo setcap cap_net_raw+ep  helloworldon command
> line I am able to set the cap.
>
>
>
> To achieve the sudo realization  in recipe , I tried  as below , but no
> luck…… Can you suggest something here  ?
>
>
>
> fakeroot do_install() {
>
> install -d ${D}${bindir}
>
> install -m 0755 helloworld ${D}${bindir}
>
> install -d ${D}/lib/systemd/system
>
> install -m 0755 hello.service ${D}/lib/systemd/system/
>
>  setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>
>
>
> }
>
>
>
> Thanks and Regards
>
> Shrawan
>
>
>
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, June 24, 2016 5:09 PM
> To: Kumar, Shrawan
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] setcap using recipe
>
>
>
> Hi,
>
>
>
> On 24 June 2016 at 11:41, Kumar, Shrawan  wrote:
>
> Is there a way to  add a capability to a binary (cap_net_raw+ep),into a
> recipe?
>
>
>
> Example :
>
> do_install() {
>
>install -d ${D}${bindir}
>
>install -m 0755 helloworld ${D}${bindir}
>
>install -d ${D}/lib/systemd/system
>
>install -m 0755 hello.service ${D}/lib/systemd/system/
>
>setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>
> }
>
>
>
> If yes is this correct approach to achieve the same from  package recipe
> itself ?
>
>
> capabilities on files are just extended attributes, so assuming that you
> have a fairly recent Yocto and your host and target filesystems support
> extended attributes, yes this should work.
>
>
>
> Ross
>
>
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
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] setcap using recipe

2016-07-01 Thread Daniel.

Does your target filesystem support it? ubifs doesn't :(
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_xattr

2016-07-01 9:53 GMT-03:00 Kumar, Shrawan :
> Hello Ross,
>
>
>
> None of the approach is working .  I have attached the  recipe where I am
> trying to execute postinst . It builds successfully , But when I run getcap
> on the target , does not return the set capabilities.
>
>
>
> Help will be highly appreciated .
>
>
>
> Regards
>
> Shrawan
>
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, June 24, 2016 6:40 PM
>
>
> To: Kumar, Shrawan
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] setcap using recipe
>
>
>
> Looks like using setcap directly is broken currently, there are two
> workarounds:
>
>
>
> 1) use a postinst to invoke setcap on the target instead
>
> 2) test the patch for pseudo that is on this list ([PATCH] Add capset pseudo
> function that always succeeds) and verify that it fixes the problem for you.
>
>
>
> Ross
>
>
>
> On 24 June 2016 at 13:31, Kumar, Shrawan  wrote:
>
> I am using Yocto 2.0.2
>
>
>
> Thanks and Regards
>
> Shrawan
>
>
>
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, June 24, 2016 5:56 PM
>
>
> To: Kumar, Shrawan
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] setcap using recipe
>
>
>
> What version of OE/Yocto are you using?  Old versions of pseudo didn't
> support xattrs at all.
>
>
>
> Ross
>
>
>
> On 24 June 2016 at 13:23, Kumar, Shrawan  wrote:
>
> Thanks Ross for your quick turn around , I am getting below error
>
>
>
> “Unable le to set CAP_SETFCAP effective capability: Operation not
> permitted.”
>
>
>
> But when I use# sudo setcap cap_net_raw+ep  helloworldon command
> line I am able to set the cap.
>
>
>
> To achieve the sudo realization  in recipe , I tried  as below , but no
> luck…… Can you suggest something here  ?
>
>
>
> fakeroot do_install() {
>
> install -d ${D}${bindir}
>
> install -m 0755 helloworld ${D}${bindir}
>
> install -d ${D}/lib/systemd/system
>
> install -m 0755 hello.service ${D}/lib/systemd/system/
>
>  setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>
>
>
> }
>
>
>
> Thanks and Regards
>
> Shrawan
>
>
>
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, June 24, 2016 5:09 PM
> To: Kumar, Shrawan
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] setcap using recipe
>
>
>
> Hi,
>
>
>
> On 24 June 2016 at 11:41, Kumar, Shrawan  wrote:
>
> Is there a way to  add a capability to a binary (cap_net_raw+ep),into a
> recipe?
>
>
>
> Example :
>
> do_install() {
>
>install -d ${D}${bindir}
>
>install -m 0755 helloworld ${D}${bindir}
>
>install -d ${D}/lib/systemd/system
>
>install -m 0755 hello.service ${D}/lib/systemd/system/
>
>setcap cap_net_raw+ep  ${D}${bindir}/helloworld
>
> }
>
>
>
> If yes is this correct approach to achieve the same from  package recipe
> itself ?
>
>
> capabilities on files are just extended attributes, so assuming that you
> have a fairly recent Yocto and your host and target filesystems support
> extended attributes, yes this should work.
>
>
>
> Ross
>
>
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux] Regarding "systemd" support with refpolicy-minimum v20151208

2016-07-01 Thread Shrikant Bobade

Hi,

Using refpolicy-minimum v20151208 with systemd as init manager,

I am facing few issues during enforcing mode,
1. systemd service status check, start & stop
2. auditd logfile error, so it is mixing with the boot log.
3. also other avc denials related to tmpfs & other types etc..


setup details:poky and meta-selinux: both at master head & systemd enabled.
with these SELinux booleans enabled: i.systemd_tmpfiles_manage_all
ii.allow_mount_anyfile

captured the avc denial to fix the systemd execution well, attached
SELinux-Modules.txt :- the allow rules generated using audit tools.
I am trying to merge these module into actual refpolicy modules, so we get
the out of box experience for smooth systemd execution.
Observed policy store seems corrupted some time, when start inserting the
prepared policy modules allow rules into actual refpolicy modules..

Does anyone also faced similar issues?

Any pointers or references will be a great help.


Thanks
Shrikant
# SELinux Modules 



require {
type unconfined_t;
type init_t;
class system reload;
}

#= unconfined_t ==
allow unconfined_t init_t:system reload;

##

require {
type tmpfs_t;
type auditd_t;
class file create;
}

#= auditd_t ==
allow auditd_t tmpfs_t:file create;

##

require {
type tmpfs_t;
type auditd_t;
class file { open read };
}

#= auditd_t ==
allow auditd_t tmpfs_t:file { open read };

##

require {
type tmpfs_t;
type auditd_t;
class file append;
}

#= auditd_t ==
allow auditd_t tmpfs_t:file append;

##

require {
type tmpfs_t;
type auditd_t;
class file getattr;
}

#= auditd_t ==
allow auditd_t tmpfs_t:file getattr;

##

require {
type tmpfs_t;
type auditd_t;
class file setattr;
}

#= auditd_t ==
allow auditd_t tmpfs_t:file setattr;


require {
type tmpfs_t;
type auditd_t;
class dir open;
}

#= auditd_t ==
allow auditd_t tmpfs_t:dir open;

##

require {
type tmpfs_t;
type auditd_t;
class dir read;
}

#= auditd_t ==
allow auditd_t tmpfs_t:dir read;

##

require {
type tmpfs_t;
type auditd_t;
class dir open;
}

#= auditd_t ==
allow auditd_t tmpfs_t:dir open;



require {
type tmpfs_t;
type initrc_t;
type auditd_t;
class unix_dgram_socket sendto;
class dir search;
}

#= auditd_t ==
allow auditd_t initrc_t:unix_dgram_socket sendto;
allow auditd_t tmpfs_t:dir search;


require {
type tmpfs_t;
type auditd_t;
class dir add_name;
}

#= auditd_t ==
allow auditd_t tmpfs_t:dir add_name;


##

require {
type tmpfs_t;
type auditd_t;
class dir write;
}

#= auditd_t ==
allow auditd_t tmpfs_t:dir write;

##

require {
type var_run_t;
type init_t;
type syslogd_t;
type systemd_tmpfiles_t;
type initrc_t;
type klogd_t;
type chkpwd_t;
type local_login_t;
type proc_t;
type getty_t;
type tmpfs_t;
type mount_t;
class capability2 audit_read;
class file read;
class filesystem getattr;
class unix_dgram_socket sendto;
class shm create;
class dir search;
}

#= chkpwd_t ==
allow chkpwd_t proc_t:filesystem getattr;

#= getty_t ==
allow getty_t tmpfs_t:dir search;

#= init_t ==
allow init_t self:capability2 audit_read;

#= klogd_t ==

# This avc is allowed in the current policy
allow klogd_t initrc_t:unix_dgram_socket sendto;

#= local_login_t ==
allow local_login_t var_run_t:file read;

#= mount_t ==
allow mount_t proc_t:filesystem getattr;

#= syslogd_t ==
allow syslogd_t self:shm create;

#=

Re: [yocto] customizing system configuration files in my image

2016-07-01 Thread Daniel.

After that you can create a image recipe and inherit from that .bbclass. If
you don't want to create a .bbclass you can use this same aproach directly
on your image recipe :)

Regards,

2016-07-01 10:16 GMT-03:00 Daniel. :

> Hi Ottavio,
>
> There is more than way to do it. In your case I would use
> ROOTFS_POSTPROCESS_COMMAND to modify files prior the creation of the rootfs.
>
> You may:
> - Create a .bbclass for your image inheriting core-image for example.
> - Create a shell function to do some sed magic.
> - Setup that function to run at rootfs creation.
>
> Here is a example, I hope this helps :)
> https://gist.github.com/gkos/4e981dffb929886cd8a6c5ed738b7b08
>
> Regards,
>
> 2016-07-01 6:11 GMT-03:00 Ottavio Campana :
>
>> Hello,
>>
>>
>>
>> I would like to customize an image I am developing based on core image
>> minimal.
>>
>>
>>
>> Particularly, I’d like to customize the files /etc/network/interfaces and
>> /etc/inittab .
>>
>>
>>
>> What should I do achieve that?
>>
>>
>>
>> Thank you
>>
>>
>>
>> Ottavio
>>
>>
>>
>> --
>>
>> [image: Videotec Logo] 
>>
>> *Ottavio Campana*
>> *Product Manager - Electronic R Department*
>>
>> Office +39.0445.697.411  Fax +39.0445.697.414
>> Address  VIDEOTEC S.p.A. - Via Friuli, 6 - 36015 Schio (Vicenza) - Italy
>>
>>
>>
>>
>> *Any information herein transmitted only concerns the person or the
>> company named in the address and is deemed to be confidential It is
>> strictly forbidden to transmit, post, forward or otherwise use said
>> information to anyone other than the recipient. If you have received this
>> message by mistake, please contact the sender and delete any relevant
>> information from your computer. This mailbox is only meant for sending and
>> receiving messages pertaining business matters and any other use for
>> personal purposes is forbidden and unauthorized. Therefore, any email sent
>> and received will be handled as ordinary business messages and subject to
>> the company's own rules, and may thus be read also by people other than the
>> user named in the mailbox address. *
>>
>> [image: Twitter Logo blue]    [image:
>> Youtube logo red]    [image: Linkedin
>> logo blue] 
>>
>>
>>
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
>
> --
> *"Do or do not. There is no try"*
>   *Yoda Master*
>



-- 
*"Do or do not. There is no try"*
  *Yoda Master*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] README: update with systemd & virtual/refpolicy details

2016-07-01 Thread bobadeshrikant

From: Shrikant Bobade 

add init manager user guidelines and examples for using refpolicy with
perticular version and type.

Signed-off-by: Shrikant Bobade 
---
 README | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 284d862..dabaa41 100644
--- a/README
+++ b/README
@@ -65,6 +65,8 @@ An "oe-selinux" distribution is also included as a 
convienence for people
 working with this layer, without the additional Poky meta data.  This
 approach may work, but is not generally tested by the maintainers.
 
+e.g. DISTRO="poky-selinux"
+
 
 Using different versions of linux-yocto
 ---
@@ -75,6 +77,7 @@ currently supported: v3.14, v3.19, v4.1(by default).
 * enable the preferred linux-yocto to local.conf or oe-selinux.conf
 e.g. PREFERRED_VERSION_linux-yocto_qemuarm = "3.19%"
 
+
 Using different versions of refpolicy
 -
 To prepare selinux enabled images using different ver. of refpolicy,
@@ -86,8 +89,28 @@ By default refpolicy from git builds head commit of master 
branch, we can update
 SRCREV for refpolicy and refpolicy-contrib as appropriate at refpolicy_git.inc
 to check refpolicy as per required commits.
 
-* enable the preferred refpolicy-mls to local.conf or oe-selinux.conf
-e.g. REFERRED_VERSION_refpolicy-mls = "2.20140311"
+* enable the preferred refpolicy-minimum to local.conf or oe-selinux.conf
+e.g. PREFERRED_VERSION_refpolicy-minimum = "2.20151208"
+
+
+Using perticular refpolicy policy type
+--
+Provider "virtual/refpolicy" used to set perticular refpolicy type.
+
+* enabled refpolicy-minimum from refpolicy types at config level
+e.g. PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-minimum"
+
+
+Using different init manager
+
+By default selinux enabled images coming up with "sysvinit" as init manager,
+we can use "systemd" as an init manager using below changes to local.conf
+
+* enable systemd as init manager changes to local.conf
+DISTRO_FEATURES_remove = " sysvinit"
+DISTRO_FEATURES_append = " systemd"
+VIRTUAL-RUNTIME_init_manager = "systemd"
+DISTRO_FEATURES_BACKFILL_CONSIDERED = ""
 
 
 License
-- 
1.9.1

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

Re: [yocto] customizing system configuration files in my image

2016-07-01 Thread Daniel.

Hi Ottavio,

There is more than way to do it. In your case I would use
ROOTFS_POSTPROCESS_COMMAND to modify files prior the creation of the rootfs.

You may:
- Create a .bbclass for your image inheriting core-image for example.
- Create a shell function to do some sed magic.
- Setup that function to run at rootfs creation.

Here is a example, I hope this helps :)
https://gist.github.com/gkos/4e981dffb929886cd8a6c5ed738b7b08

Regards,

2016-07-01 6:11 GMT-03:00 Ottavio Campana :

> Hello,
>
>
>
> I would like to customize an image I am developing based on core image
> minimal.
>
>
>
> Particularly, I’d like to customize the files /etc/network/interfaces and
> /etc/inittab .
>
>
>
> What should I do achieve that?
>
>
>
> Thank you
>
>
>
> Ottavio
>
>
>
> --
>
> [image: Videotec Logo] 
>
> *Ottavio Campana*
> *Product Manager - Electronic R Department*
>
> Office +39.0445.697.411  Fax +39.0445.697.414
> Address  VIDEOTEC S.p.A. - Via Friuli, 6 - 36015 Schio (Vicenza) - Italy
>
>
>
>
> *Any information herein transmitted only concerns the person or the
> company named in the address and is deemed to be confidential It is
> strictly forbidden to transmit, post, forward or otherwise use said
> information to anyone other than the recipient. If you have received this
> message by mistake, please contact the sender and delete any relevant
> information from your computer. This mailbox is only meant for sending and
> receiving messages pertaining business matters and any other use for
> personal purposes is forbidden and unauthorized. Therefore, any email sent
> and received will be handled as ordinary business messages and subject to
> the company's own rules, and may thus be read also by people other than the
> user named in the mailbox address. *
>
> [image: Twitter Logo blue]    [image:
> Youtube logo red]    [image: Linkedin
> logo blue] 
>
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>


-- 
*"Do or do not. There is no try"*
  *Yoda Master*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setcap using recipe

2016-07-01 Thread Kumar, Shrawan

Hello Ross,

None of the approach is working .  I have attached the  recipe where I am 
trying to execute postinst . It builds successfully , But when I run getcap on 
the target , does not return the set capabilities.

Help will be highly appreciated .

Regards
Shrawan
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, June 24, 2016 6:40 PM
To: Kumar, Shrawan
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] setcap using recipe

Looks like using setcap directly is broken currently, there are two workarounds:

1) use a postinst to invoke setcap on the target instead
2) test the patch for pseudo that is on this list ([PATCH] Add capset pseudo 
function that always succeeds) and verify that it fixes the problem for you.

Ross

On 24 June 2016 at 13:31, Kumar, Shrawan 
> wrote:
I am using Yocto 2.0.2

Thanks and Regards
Shrawan

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, June 24, 2016 5:56 PM

To: Kumar, Shrawan
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] setcap using recipe

What version of OE/Yocto are you using?  Old versions of pseudo didn't support 
xattrs at all.

Ross

On 24 June 2016 at 13:23, Kumar, Shrawan 
> wrote:
Thanks Ross for your quick turn around , I am getting below error

“Unable le to set CAP_SETFCAP effective capability: Operation not permitted.”

But when I use# sudo setcap cap_net_raw+ep  helloworldon command 
line I am able to set the cap.

To achieve the sudo realization  in recipe , I tried  as below , but no luck…… 
Can you suggest something here  ?

fakeroot do_install() {
install -d ${D}${bindir}
install -m 0755 helloworld ${D}${bindir}
install -d ${D}/lib/systemd/system
install -m 0755 hello.service ${D}/lib/systemd/system/
 setcap cap_net_raw+ep  ${D}${bindir}/helloworld

}

Thanks and Regards
Shrawan

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, June 24, 2016 5:09 PM
To: Kumar, Shrawan
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] setcap using recipe

Hi,

On 24 June 2016 at 11:41, Kumar, Shrawan 
> wrote:

Is there a way to  add a capability to a binary (cap_net_raw+ep),into a recipe?

Example :

do_install() {

   install -d ${D}${bindir}

   install -m 0755 helloworld ${D}${bindir}

   install -d ${D}/lib/systemd/system

   install -m 0755 hello.service ${D}/lib/systemd/system/

   setcap cap_net_raw+ep  ${D}${bindir}/helloworld

}

If yes is this correct approach to achieve the same from  package recipe itself 
?

capabilities on files are just extended attributes, so assuming that you have a 
fairly recent Yocto and your host and target filesystems support extended 
attributes, yes this should work.

Ross

HelloWorld_0.1.bb
Description: HelloWorld_0.1.bb
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH 4/5] drivers/usb: Make Axxia USB Use Coherent Memory for DMA

2016-07-01 Thread Daniel Dragomir

From: John Jacques 

Even with 'dma-coherent' in the device tree USB node, the XHCI
driver creates devices without copying the 'archdata' structure,
where the dma_coherent field is defined.  To handle this, set
the dma_coherent field in all devices that are created by the
XHCI driver (match 'xhci-hcd' in the device name).

Signed-off-by: John Jacques 
---
 drivers/usb/dwc3/dwc3-axxia.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-axxia.c b/drivers/usb/dwc3/dwc3-axxia.c
index 59321b8..a0de833 100644
--- a/drivers/usb/dwc3/dwc3-axxia.c
+++ b/drivers/usb/dwc3/dwc3-axxia.c
@@ -79,6 +79,20 @@ static int axxia_dwc3_remove(struct platform_device *pdev)
return 0;
 }
 
+void
+arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+
+   printk("setup_pdev_archdata %s\n", pdev->name);
+
+   if (strncmp(pdev->name, "xhci-hcd", strlen("xhci-hcd")) == 0) {
+   printk("setting dma_coherent\n");
+   pdev->dev.archdata.dma_coherent = 1;
+
+   }
+
+}
+
 static const struct of_device_id adwc3_of_match[] = {
{ .compatible = "intel,axxia-dwc3", },
{},
-- 
1.9.1

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

[linux-yocto] [PATCH 5/5] drivers/net: Disable Pause Frames in the Axxia Network Interface

2016-07-01 Thread Daniel Dragomir

From: John Jacques 

Signed-off-by: John Jacques 
---
 drivers/net/ethernet/intel/axxia/nemac.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/intel/axxia/nemac.c 
b/drivers/net/ethernet/intel/axxia/nemac.c
index ee6a240..4a3ab72 100644
--- a/drivers/net/ethernet/intel/axxia/nemac.c
+++ b/drivers/net/ethernet/intel/axxia/nemac.c
@@ -507,17 +507,12 @@ nemac_link_up(struct nemac_priv *priv)
writel(gmii_ctrl, priv->reg + NEM_GMAC_ANEG_CTRL_R);
writel(rgmii_clk, priv->reg + NEM_DMA_MISC_CTL);
 
-   if (phy_dev->pause) {
-   /* Enable GMAC and DMA to act on and send PAUSE frames */
-   nemac_set(priv, NEM_GMAC_ENABLE_R,
- GMAC_RX_PAUSE_EN | GMAC_TX_PAUSE_EN);
-   nemac_set(priv, NEM_DMA_CTL, DMACTL_ALLOW_TX_PAUSE);
-   } else {
-   /* Disable use of PAUSE frames */
-   nemac_clr(priv, NEM_GMAC_ENABLE_R,
- GMAC_RX_PAUSE_EN | GMAC_TX_PAUSE_EN);
-   nemac_clr(priv, NEM_DMA_CTL, DMACTL_ALLOW_TX_PAUSE);
-   }
+   /* Pause frames are a problem on the Axxia development board,
+* so don't enable them.
+*/
+
+   nemac_clr(priv, NEM_GMAC_ENABLE_R, GMAC_RX_PAUSE_EN | GMAC_TX_PAUSE_EN);
+   nemac_clr(priv, NEM_DMA_CTL, DMACTL_ALLOW_TX_PAUSE);
 
/* Enable RX */
nemac_set(priv, NEM_GMAC_ENABLE_R, GMAC_RX_EN);
-- 
1.9.1

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

[linux-yocto] [PATCH 2/5] board/axxia: SPI Updates for Victoria

2016-07-01 Thread Daniel Dragomir

From: John Jacques 

Change the max frequency and add the backup serial flash.

Signed-off-by: John Jacques 
---
 arch/arm64/boot/dts/intel/axm5616-victoria.dts | 44 +-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/intel/axm5616-victoria.dts 
b/arch/arm64/boot/dts/intel/axm5616-victoria.dts
index 0498184..22b5094 100644
--- a/arch/arm64/boot/dts/intel/axm5616-victoria.dts
+++ b/arch/arm64/boot/dts/intel/axm5616-victoria.dts
@@ -83,7 +83,49 @@
#size-cells = <1>;
compatible = "s25fl016k";
reg = <0>;
-   spi-max-frequency = <2500>;
+   spi-max-frequency = <500>;
+   pl022,com-mode = <1>;
+
+   partition@0 {
+   label = "spl-0";
+   reg = <0x0 0x4>;
+   };
+   partition@4 {
+   label = "spl-1";
+   reg = <0x4 0x4>;
+   };
+   partition@8 {
+   label = "parameters-0";
+   reg = <0x8 0x1>;
+   };
+   partition@9 {
+   label = "parameters-1";
+   reg = <0x9 0x1>;
+   };
+   partition@a {
+   label = "env-0";
+   reg = <0xa 0x1>;
+   };
+   partition@b {
+   label = "env-1";
+   reg = <0xb 0x1>;
+   };
+   partition@10 {
+   label = "u-boot-0";
+   reg = <0x10 0x20>;
+   };
+   partition@30 {
+   label = "u-boot-1";
+   reg = <0x30 0x20>;
+   };
+   };
+
+   flash@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "s25fl016k";
+   reg = <1>;
+   spi-max-frequency = <500>;
pl022,com-mode = <1>;
 
partition@0 {
-- 
1.9.1

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

[linux-yocto] [PATCH 1/5] axxia: PCI Updates for 5600 Hardware

2016-07-01 Thread Daniel Dragomir

From: John Jacques 

Signed-off-by: John Jacques 
---
 arch/arm64/boot/dts/intel/axm5616-victoria.dts |  5 
 drivers/pci/host/pcie-axxia.c  | 36 +-
 2 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/intel/axm5616-victoria.dts 
b/arch/arm64/boot/dts/intel/axm5616-victoria.dts
index d37b693..0498184 100644
--- a/arch/arm64/boot/dts/intel/axm5616-victoria.dts
+++ b/arch/arm64/boot/dts/intel/axm5616-victoria.dts
@@ -120,3 +120,8 @@
};
};
 };
+
+ {
+
+   status = "okay";
+};
diff --git a/drivers/pci/host/pcie-axxia.c b/drivers/pci/host/pcie-axxia.c
index 28d4ccc..f309195 100644
--- a/drivers/pci/host/pcie-axxia.c
+++ b/drivers/pci/host/pcie-axxia.c
@@ -109,12 +109,10 @@ static inline uint32_t axxia_mmio_read_32(uintptr_t addr)
 int
 axxia_is_x9(void)
 {
-   unsigned int pfuse;
-   static void __iomem *base;
+   if (of_find_compatible_node(NULL, NULL, "lsi,axm5616"))
+   return 1;
 
-   base = ioremap(AXXIA_SYSCON_BASE, 0x1024);
-   pfuse = axxia_mmio_read_32((uintptr_t)(base + 0x34));
-   return (0xb == (pfuse & 0x1f));
+   return 0;
 }
 
 struct axxia_pcie {
@@ -205,13 +203,17 @@ static int axxia_pcie_wr_own_conf(struct pcie_port *pp, 
int where,
 
 static void axxia_pcie_prog_viewport_cfg0(struct pcie_port *pp, u32 busdev)
 {
+   u32 upper_base;
+
/* Program viewport 0 : OUTBOUND : CFG0 */
axxia_pcie_writel_rc(pp,
PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0,
PCIE_ATU_VIEWPORT);
axxia_pcie_writel_rc(pp, pp->cfg0_base, PCIE_ATU_LOWER_BASE);
-if (!axxia_is_x9())
-   axxia_pcie_writel_rc(pp, (pp->cfg0_base >> 32), PCIE_ATU_UPPER_BASE);
+   /* set upper base bits [1:0] for X9, bits[7:0] for XLF */
+   upper_base = (pp->cfg0_base >> 32);
+   upper_base &= (axxia_is_x9()) ? 0x3 : 0xff;
+   axxia_pcie_writel_rc(pp, upper_base, PCIE_ATU_UPPER_BASE);
axxia_pcie_writel_rc(pp, pp->cfg0_base + pp->cfg0_size - 1,
PCIE_ATU_LIMIT);
axxia_pcie_writel_rc(pp, busdev, PCIE_ATU_LOWER_TARGET);
@@ -223,14 +225,18 @@ if (!axxia_is_x9())
 
 static void axxia_pcie_prog_viewport_cfg1(struct pcie_port *pp, u32 busdev)
 {
+   u32 upper_base;
+
/* Program viewport 1 : OUTBOUND : CFG1 */
axxia_pcie_writel_rc(pp,
PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX1,
PCIE_ATU_VIEWPORT);
axxia_pcie_writel_rc(pp, PCIE_ATU_TYPE_CFG1, PCIE_ATU_CR1);
axxia_pcie_writel_rc(pp, pp->cfg1_base, PCIE_ATU_LOWER_BASE);
-if (!axxia_is_x9())
-   axxia_pcie_writel_rc(pp, (pp->cfg1_base >> 32), PCIE_ATU_UPPER_BASE);
+   upper_base = (pp->cfg1_base >> 32);
+   upper_base &= (axxia_is_x9()) ? 0x3 : 0xff;
+   axxia_pcie_writel_rc(pp, upper_base, PCIE_ATU_UPPER_BASE);
+
axxia_pcie_writel_rc(pp, pp->cfg1_base + pp->cfg1_size - 1,
PCIE_ATU_LIMIT);
axxia_pcie_writel_rc(pp, busdev, PCIE_ATU_LOWER_TARGET);
@@ -240,14 +246,17 @@ if (!axxia_is_x9())
 
 static void axxia_pcie_prog_viewport_mem_outbound(struct pcie_port *pp)
 {
+   u32 upper_base;
+
/* Program viewport 0 : OUTBOUND : MEM */
axxia_pcie_writel_rc(pp,
PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX2,
PCIE_ATU_VIEWPORT);
axxia_pcie_writel_rc(pp, PCIE_ATU_TYPE_MEM, PCIE_ATU_CR1);
axxia_pcie_writel_rc(pp, pp->mem_mod_base, PCIE_ATU_LOWER_BASE);
-if (!axxia_is_x9())
-   axxia_pcie_writel_rc(pp, (pp->mem_mod_base >> 32), PCIE_ATU_UPPER_BASE);
+   upper_base = (pp->mem_mod_base >> 32);
+   upper_base &= (axxia_is_x9()) ? 0x3 : 0xff;
+   axxia_pcie_writel_rc(pp, upper_base, PCIE_ATU_UPPER_BASE);
axxia_pcie_writel_rc(pp, pp->mem_mod_base + pp->mem_size - 1,
PCIE_ATU_LIMIT);
axxia_pcie_writel_rc(pp, pp->mem_bus_addr, PCIE_ATU_LOWER_TARGET);
@@ -490,7 +499,7 @@ int axxia_pcie_link_up(struct pcie_port *pp)
 
axxia_cc_gpreg_readl(pp, PEI_SII_PWR_MGMT_REG, _state);
smlh_state = (smlh_state & PEI_SMLH_LINK_STATE) >> 4;
-   if (smlh_state != 0x11) {
+   if ((smlh_state != 0x11) && (smlh_state != 0x23)) {
pr_info("smlh_state = 0x%x\n", smlh_state);
pr_err("PCIe LINK IS NOT UP\n");
return 0;
@@ -555,11 +564,14 @@ void axxia_pcie_setup_rc(struct pcie_port *pp)
val |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
PCI_COMMAND_MASTER | PCI_COMMAND_SERR;
axxia_pcie_writel_rc(pp, val, PCI_COMMAND);
+   axxia_pcie_writel_rc(pp, 0x1037201, 0x8a8);
 
/* LTSSM enable */
axxia_cc_gpreg_readl(pp, PEI_GENERAL_CORE_CTL_REG, );
+   msleep(100);
val |= 0x1;
axxia_cc_gpreg_writel(pp, 0x1, PEI_GENERAL_CORE_CTL_REG);
+   msleep(100);
 }
 
 static int

[linux-yocto] [PATCH 0/5] Intel Axxia updates to linux-yocto-4.1

2016-07-01 Thread Daniel Dragomir

Hello Bruce!

This series of patches brings improvements for USB, PCI AND NETWORK
drivers and add some features in Victoria board Device Tree. 

NOTE: All the following patches are for both axxia branches:
standard/axxia/base and standard/preempt-rt/axxia/base,

Axxia internal tag: 1.33

Thank you,
Daniel Dragomir

John Jacques (5):
  axxia: PCI Updates for 5600 Hardware
  board/axxia: SPI Updates for Victoria
  axxia: Add USB to the Victoria Device Tree
  drivers/usb: Make Axxia USB Use Coherent Memory for DMA
  drivers/net: Disable Pause Frames in the Axxia Network Interface

 arch/arm64/boot/dts/intel/axm5616-victoria.dts | 53 +-
 arch/arm64/boot/dts/intel/axm56xx.dtsi |  2 +-
 drivers/net/ethernet/intel/axxia/nemac.c   | 17 +++--
 drivers/pci/host/pcie-axxia.c  | 36 +++--
 drivers/usb/dwc3/dwc3-axxia.c  | 14 +++
 5 files changed, 97 insertions(+), 25 deletions(-)

-- 
1.9.1

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

[yocto] Toaster fail to luanch bitbake

2016-07-01 Thread Richard Zhang

Hi:

After setup toaster I can't finish build progress with bitbake.

   

some ERROR log into :

/opt/yocto/poky/build-toaster-4/toaster_ui.log 

ERROR: can't set event mask: None


Is this ERROR come with Environment variant?


Thanks.


Richard Zhang







signature.asc
Description: OpenPGP digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] customizing system configuration files in my image

2016-07-01 Thread Ottavio Campana

Hello,

I would like to customize an image I am developing based on core image minimal.

Particularly, I'd like to customize the files /etc/network/interfaces and 
/etc/inittab .

What should I do achieve that?

Thank you

Ottavio

--
[Videotec Logo]

Ottavio Campana
Product Manager - Electronic R Department

Office +39.0445.697.411  Fax +39.0445.697.414
Address  VIDEOTEC S.p.A. - Via Friuli, 6 - 36015 Schio (Vicenza) - Italy


Any information herein transmitted only concerns the person or the company 
named in the address and is deemed to be confidential It is strictly forbidden 
to transmit, post, forward or otherwise use said information to anyone other 
than the recipient. If you have received this message by mistake, please 
contact the sender and delete any relevant information from your computer. This 
mailbox is only meant for sending and receiving messages pertaining business 
matters and any other use for personal purposes is forbidden and unauthorized. 
Therefore, any email sent and received will be handled as ordinary business 
messages and subject to the company's own rules, and may thus be read also by 
people other than the user named in the mailbox address.

[Twitter Logo blue]   [Youtube logo red] 
[Linkedin logo blue] 




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

Re: [yocto] Per image customizations

2016-07-01 Thread Diego

In data lunedì 27 giugno 2016 16:11:30, Paul Eggleton ha scritto:
> On Mon, 06 Jun 2016 15:27:17 Diego wrote:
> > Hi Oleksandr,
> > 
> > In data venerdì 3 giugno 2016 20:56:32, Oleksandr Poznyak ha scritto:
> > > I found that that’s an issue with rpm packages. I didn't expect there
> > > might
> > > be some issue with rpm. If you really don't care which package
> > > management
> > > system to use, switch to deb:
> > > 
> > > PACKAGE_CLASSES = "package_deb"
> > 
> > Thanks for looking at the problem, unfortunately migrating away from rpm
> > is
> > not an option for me at the moment. Is there a bug report for this rpm
> > problem? Should I open one?
> 
> I'm not aware of one - could you please file a bug? Have you found any
> further information?
> 

Hi Paul and all,

I've created one here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9863

Don't know if bug is categorized correctly, but at least it is a starting 
point.

Thanks,
Diego

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

Re: [yocto] [meta-raspberrypi] Disable kernel option via fragment Rpi3

2016-07-01 Thread Sandro Stiller


Hi Jonathan,

Am 25.06.2016 um 06:44 schrieb Jonathan Haws:


I've tried adding
kernel configuration fragments to disable this option, but with no luck.


Kernel config fragments are currently not supported in meta-raspberrypi.
There is a patch for this here:
https://lists.yoctoproject.org/pipermail/yocto/2015-October/027034.html

It has to be modified a little bit to apply:
https://github.com/sstiller/meta-raspberrypi/commit/0a8ee50c264d6472ea12dcf56e55e04d763962a0
(add ".patch" to the url to download a patch)

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

Re: [yocto] ICECC build failures?

Re: [yocto] Shorter build time?

Re: [yocto] customizing system configuration files in my image

Re: [yocto] [Recipe reporting system] Upgradable recipe name list

[yocto] [Recipe reporting system] Upgradable recipe name list

[yocto] [Recipe reporting system] Upgradable recipe name list

Re: [yocto] Shorter build time?

Re: [yocto] Shorter build time?

Re: [yocto] Shorter build time?

Re: [yocto] [yocto-autobuilder][PATCH] bin/release_scripts/release.py: Add some basic logging

Re: [yocto] setcap using recipe

[yocto] Yocto Project Status WW27

Re: [yocto] Failed to cross compile kernel with Yocto toolchain

Re: [yocto] Xorg failing with SEGV after Krogoth update

[linux-yocto] [PATCH 7/7] usb: typec: Use strtobool instead of kstrtobool for 4.4 kernel

[linux-yocto] [PATCH 4/7] acpi/pmic: modify the pen function signature to take bit field

[linux-yocto] [PATCH 2/7] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

[linux-yocto] [PATCH 0/7] USB Type C backport on linux-yocto-4.4 bxt-rebase branch

Re: [yocto] Failed to cross compile kernel with Yocto toolchain

Re: [yocto] setcap using recipe

Re: [yocto] setcap using recipe

Re: [yocto] setcap using recipe

[yocto] [meta-selinux] Regarding "systemd" support with refpolicy-minimum v20151208

Re: [yocto] customizing system configuration files in my image

[yocto] [meta-selinux][PATCH] README: update with systemd & virtual/refpolicy details

Re: [yocto] customizing system configuration files in my image

Re: [yocto] setcap using recipe

[linux-yocto] [PATCH 4/5] drivers/usb: Make Axxia USB Use Coherent Memory for DMA

[linux-yocto] [PATCH 5/5] drivers/net: Disable Pause Frames in the Axxia Network Interface

[linux-yocto] [PATCH 2/5] board/axxia: SPI Updates for Victoria

[linux-yocto] [PATCH 1/5] axxia: PCI Updates for 5600 Hardware

[linux-yocto] [PATCH 0/5] Intel Axxia updates to linux-yocto-4.1

[yocto] Toaster fail to luanch bitbake

[yocto] customizing system configuration files in my image

Re: [yocto] Per image customizations

Re: [yocto] [meta-raspberrypi] Disable kernel option via fragment Rpi3

36 matches

Site Navigation

Mail list logo

Footer information