[yocto] CONF_VERSION and LCONF_VERSION details

2019-10-23 Thread keith . derrick
Could someone explain how these work and what the permissible values are? The 
documentation is sadly lacking in details beyond that they are incremented when 
a file changes incompatibly.


Specifically, what counts as "incompatible"? The contents of the file (i.e. the 
templates have been updated so the generated file in build/conf needs to be 
replaced), or the format of the files? Also, is TEMPLATECONF considered at all?


In my case, we have our own templates and thus set TEMPLATECONF before sourcing 
oe-init-build-env. But running bitbake seems to compare the LCONF_VERSION from 
build/conf (for example) against the template in poky/meta-poky/conf rather 
than the ones in our layer. Is this because we still have DISTRO set to "poky" 
or will it always do that?


I had updated our templates, bumped the version numbers, and then ran 
oe-init-build-env (actually our own wrapper) in the expectation that it would 
updated the files under build/conf from the updated templates. Instead it did 
nothing, and I got errors when I ran bitbake and it found the values differed,


Is it that the values must always match those in meta-poky, even if you have 
your own distro (i.e. DISTRO set to something else)? Should TEMPLATECONF be set 
in our custom local.conf.sample?


Thanks

Keith Derrick

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


Re: [yocto-announce] [ANNOUNCEMENT] Yocto Project 3.0 (Zeus 22.0.0) Released

2019-10-23 Thread Tummalapalli, Vineela
Changing the subject..

Hello,

We are pleased to announce the Yocto Project 3.0 (zeus-22.0.0) Release is now 
available for download.

http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/poky-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/poky-zeus-22.0.0.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/RELEASENOTES

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/testreport.txt

Thank you for everyone's contributions to this release.

Vineela Tummalapalli
Yocto Project Build and Release
vineela.tummalapa...@intel.com

- ---
yocto-3.0 Release Notes
- ---

- --
Repositories/Downloads
- --

Repository Name: Poky
Repository Location: https://git.yoctoproject.org/git/poky
Branch: zeus
Tag: yocto-3.0
Git revision: 94f6b31befda5c496f65e863a6f8152b42d7ebf0
Release Artefact: poky-zeus-22.0.0
md5: bb0925e0b338bf3d9ebed72b30679e36
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/poky-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/poky-zeus-22.0.0.tar.bz2

Repository Name: openembedded-core
Repository Location: https://git.openembedded.org/openembedded-core
Branch: zeus
Tag: 2019-10
Git revision: 59938780e7e776d87146002ea939b185f8704408
Release Artefact: oecore-zeus-22.0.0
md5: e2fec576ee37d4f613540ecac7f4c63e
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/oecore-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/oecore-zeus-22.0.0.tar.bz2

Repository Name: meta-mingw
Repository Location: https://git.yoctoproject.org/git/meta-mingw
Branch: zeus
Tag: yocto-3.0
Git revision: 756963cc28ebc163df7d7f4b4ee004c18d3d3260
Release Artefact: meta-mingw-zeus-22.0.0
md5: 9b59518e18af36a2f1520885841d3834
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/meta-mingw-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/meta-mingw-zeus-22.0.0.tar.bz2

Repository Name: meta-intel
Repository Location: https://git.yoctoproject.org/git/meta-intel
Branch: zeus
Tag: yocto-3.0
Git revision: 13fcf624491cdd0d9b3eb78a4f0cd1781b482b51
Release Artefact: meta-intel-zeus-22.0.0
md5: e6fb4a143d61d2552dd637dc23ea791e
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/meta-intel-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/meta-intel-zeus-22.0.0.tar.bz2

Repository Name: meta-gplv2
Repository Location: https://git.yoctoproject.org/git/meta-gplv2
Branch: zeus
Tag: yocto-3.0
Git revision: 9ca96786fd851150b518388bcb166efa0b4dfff9
Release Artefact: meta-gplv2-zeus-22.0.0
md5: ed9d383a1cd85afb7d37eb567a21c84a
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/meta-gplv2-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/meta-gplv2-zeus-22.0.0.tar.bz2

Repository Name: bitbake
Repository Location: https://git.openembedded.org/bitbake
Branch: zeus
Tag: yocto-3.0
Git revision: 5d83d828cacb58ccb7c464e799c85fd2d2a50ccc
Release Artefact: bitbake-zeus-22.0.0
md5: a5036bdfdfc3ee47a98d6e12660e84aa
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/bitbake-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/bitbake-zeus-22.0.0.tar.bz2

- ---
New Features / Enhancements
- ---

* Linux kernel 5.2/4.19, gcc 9.2, glibc 2.30 and ~260 other recipe upgrades
* Build change equivalence is detected and used to avoid rebuilding unchanged 
components (BETA)
  - See "Hash Equivalence" sample entry in local.conf.sample for usage 
instructions.
* Automated testing improvements:
  - Enabled test suites for gcc, glibc, binutils
  - Add ptest ptest support to elfutils, m4, gettext
  - Fixes for many ptest test failures
  - testimage: consider QB_DEFAULT_FSTYPE
  - oe-selftest: implement console keepalive output
  - Support for LTP / LTP compliance
  - Added core-image-sato-ptest-fast image to execute 'fast' subset of ptests
  - resulttool: Add log subcommand
  - resulttool: enable loading results directly from an http/https URL
  - resulttool: add manual test case configuration option
  - resulttool: Add option to dump all ptest logs
* Architecture / machine-specific enhancements:
  - New "qemuriscv64" emulated RISC-V 64-bit machine
  - qemu: Add ppc64 to QEMU_TARGETS
  - qemuarm64: Add QB_CPU_KVM to allow kvm acceleration
  - New tune file for ARM Cortex-A53-Cortex-A57
  - New tune file for arm1176jz-s CPU
  - meson.bbclass: Handle microblaze* mapping to cpu family
  - meson.bbclass: Make meson support aarch64_be.
  - libffi: added RISC-V support
  - icu: added armeb support
  - runqemu: added support for kvm on aarch64
  - beaglebone-yocto machine now set up to support booting images with runqemu
  - qemux86: make it possible to use higher 

[yocto] [yocto-announce] [ANNOUNCEMENT] Yocto Project 3.0 (warrior 22.0.0) Released

2019-10-23 Thread Tummalapalli, Vineela
Hello,

We are pleased to announce the Yocto Project 3.0 (zeus-22.0.0) Release is now 
available for download.

http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/poky-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/poky-zeus-22.0.0.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/RELEASENOTES

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/testreport.txt

Thank you for everyone's contributions to this release.

Vineela Tummalapalli 
Yocto Project Build and Release
vineela.tummalapa...@intel.com

- ---
yocto-3.0 Release Notes
- ---

- --
Repositories/Downloads
- --

Repository Name: Poky
Repository Location: https://git.yoctoproject.org/git/poky
Branch: zeus
Tag: yocto-3.0
Git revision: 94f6b31befda5c496f65e863a6f8152b42d7ebf0
Release Artefact: poky-zeus-22.0.0
md5: bb0925e0b338bf3d9ebed72b30679e36
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/poky-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/poky-zeus-22.0.0.tar.bz2

Repository Name: openembedded-core
Repository Location: https://git.openembedded.org/openembedded-core
Branch: zeus
Tag: 2019-10
Git revision: 59938780e7e776d87146002ea939b185f8704408
Release Artefact: oecore-zeus-22.0.0
md5: e2fec576ee37d4f613540ecac7f4c63e
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/oecore-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/oecore-zeus-22.0.0.tar.bz2

Repository Name: meta-mingw
Repository Location: https://git.yoctoproject.org/git/meta-mingw
Branch: zeus
Tag: yocto-3.0
Git revision: 756963cc28ebc163df7d7f4b4ee004c18d3d3260
Release Artefact: meta-mingw-zeus-22.0.0
md5: 9b59518e18af36a2f1520885841d3834
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/meta-mingw-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/meta-mingw-zeus-22.0.0.tar.bz2

Repository Name: meta-intel
Repository Location: https://git.yoctoproject.org/git/meta-intel
Branch: zeus
Tag: yocto-3.0
Git revision: 13fcf624491cdd0d9b3eb78a4f0cd1781b482b51
Release Artefact: meta-intel-zeus-22.0.0
md5: e6fb4a143d61d2552dd637dc23ea791e
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/meta-intel-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/meta-intel-zeus-22.0.0.tar.bz2

Repository Name: meta-gplv2
Repository Location: https://git.yoctoproject.org/git/meta-gplv2
Branch: zeus
Tag: yocto-3.0
Git revision: 9ca96786fd851150b518388bcb166efa0b4dfff9
Release Artefact: meta-gplv2-zeus-22.0.0
md5: ed9d383a1cd85afb7d37eb567a21c84a
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/meta-gplv2-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/meta-gplv2-zeus-22.0.0.tar.bz2

Repository Name: bitbake
Repository Location: https://git.openembedded.org/bitbake
Branch: zeus
Tag: yocto-3.0
Git revision: 5d83d828cacb58ccb7c464e799c85fd2d2a50ccc
Release Artefact: bitbake-zeus-22.0.0
md5: a5036bdfdfc3ee47a98d6e12660e84aa
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.0/bitbake-zeus-22.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.0/bitbake-zeus-22.0.0.tar.bz2

- ---
New Features / Enhancements
- ---

* Linux kernel 5.2/4.19, gcc 9.2, glibc 2.30 and ~260 other recipe upgrades
* Build change equivalence is detected and used to avoid rebuilding unchanged 
components (BETA)
  - See "Hash Equivalence" sample entry in local.conf.sample for usage 
instructions.
* Automated testing improvements:
  - Enabled test suites for gcc, glibc, binutils
  - Add ptest ptest support to elfutils, m4, gettext
  - Fixes for many ptest test failures
  - testimage: consider QB_DEFAULT_FSTYPE
  - oe-selftest: implement console keepalive output
  - Support for LTP / LTP compliance
  - Added core-image-sato-ptest-fast image to execute 'fast' subset of ptests
  - resulttool: Add log subcommand
  - resulttool: enable loading results directly from an http/https URL
  - resulttool: add manual test case configuration option
  - resulttool: Add option to dump all ptest logs
* Architecture / machine-specific enhancements:
  - New "qemuriscv64" emulated RISC-V 64-bit machine
  - qemu: Add ppc64 to QEMU_TARGETS
  - qemuarm64: Add QB_CPU_KVM to allow kvm acceleration
  - New tune file for ARM Cortex-A53-Cortex-A57
  - New tune file for arm1176jz-s CPU
  - meson.bbclass: Handle microblaze* mapping to cpu family
  - meson.bbclass: Make meson support aarch64_be.
  - libffi: added RISC-V support
  - icu: added armeb support
  - runqemu: added support for kvm on aarch64
  - beaglebone-yocto machine now set up to support booting images with runqemu
  - qemux86: make it possible to use higher tunes using 

Re: [yocto] Issues adding bare meta toolchain to yocto build

2019-10-23 Thread Richard Purdie
On Wed, 2019-10-23 at 11:23 +, Westermann, Oliver wrote:
> Hey,
> 
> I'm having issues adding a build for a bare metal target to my yocto
> toolchain. I've a NXP SoC with a M4 core and I would like to
> integrate the M4 binary build into yocto.
> My M4 binary has a CMAKE file that depends on ARMGCC_DIR being set to
> locate the toolchain and everything works fine locally.
> 
> I've create a recipe for the toolchain that is heavily inspired by a
> TI recipe for the gcc-arm-none-eabi (available here: 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/devtools/gcc-arm-none-eabi_7-2018-q2-update.bb?h=master
> ).
> I've made sure that GCC_ARM_NONE_TOOLCHAIN_RECIPE is set.
> 
> After calling bitbake -cpopulate-sysroot gcc-arm-none-eabi-native the
> image/${GCC_ARM_NONE_TOOLCHAIN_RECIPE} path contains the complete
> toolchain.
> 
> My M4 recipe looks like this (plus SUMMARY, LICENSE, SRC_URI, ...):
> 
> inherit pkgconfig cmake
> DEPENDS = "gcc-arm-none-eabi-native"
> 
> S = "${WORKDIR}/git "
> 
> EXTRA_OECMAKE = '-DCMAKE_TOOLCHAIN_FILE="../armgcc.cmake" \
>  -G "Unix Makefiles" \
>  -DCMAKE_BUILD_TYPE=release'
> 
> From my understanding depending on gcc-arm-none-eabi-native should
> result in the native toolchain being installed into the m4's recipe-
> sysroot-native folder.
> The sysroot-providers in the recipe-sysroot-native folder does list
> gcc-arm-none-eabi-native, but I don't get the files and therefore
> have no toolchain.
> 
> Any suggestions on what I'm doing wrong or how to debug this further?

Sounds like the sysroot filtering code doesn't know about this
directory and therefore doesn't pass it through to the recipe sysroot?

The recipe you link to is for an on target compiler, not one in the
sysroot.

I'm actually a little surprised you can't use our standard cross
compiler assuming this M4 core is on an ARM chip? It should be a case
of passing the right options to the compiler to target the M4?

Cheers,

Richard

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


Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.4.rc2)

2019-10-23 Thread richard . purdie
On Wed, 2019-10-23 at 08:00 +, Jain, Sangeeta wrote:
> Hello all,
> 
> This is the full report for 2.6.4 RC2:  
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
> 
> === Summary 
> No high milestone defects.  
> No new defect found in this cycle.
> The stap test case failure on beaglebone still exists in this release
> (BUG id:13273). 
> 
> === Bugs 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273
> 
> Thanks & Regards,
> Sangeeta Jain

Thanks Sangeeta and team!

Rather than respin the release we're thinking we should perhaps release
and then add the fix for the stap issue to the branch. The TSC will
make a decision on that, hopefully tomorrow. We're hoping to get the
warrior point release sorted ASAP but the remaining issue is proving
tricky to resolve.

Cheers,

Richard



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


Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.4.rc2)

2019-10-23 Thread akuster808
Jain,

Thanks for the report.


On 10/23/19 1:00 AM, Jain, Sangeeta wrote:
> Hello all,
>
> This is the full report for 2.6.4 RC2:  
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
>
> === Summary 
> No high milestone defects.  
> No new defect found in this cycle.
> The stap test case failure on beaglebone still exists in this release (BUG 
> id:13273). 
>
> === Bugs 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273

The fix for this is sitting in patchworks

https://patchwork.openembedded.org/patch/165649/

When I told Richard Thud was a go, I complete forgot about that change
not being merged.

- armin
>
> Thanks & Regards,
> Sangeeta Jain
>
>> -Original Message-
>> From: Poky Build User 
>> Sent: Friday, October 18, 2019 5:18 AM
>> To: yocto@yoctoproject.org
>> Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
>> ; Yeoh, Ee Peng ; Chan,
>> Aaron Chun Yew ; Ang, Chin Huat
>> ; richard.pur...@linuxfoundation.org;
>> akuster...@gmail.com; sjolley.yp...@gmail.com; Jain, Sangeeta
>> 
>> Subject: QA notification for completed autobuilder build (yocto-2.6.4.rc2)
>>
>>
>> A build flagged for QA (yocto-2.6.4.rc2) was completed on the autobuilder 
>> and is
>> available at:
>>
>>
>>https://autobuilder.yocto.io/pub/releases/yocto-2.6.4.rc2
>>
>>
>> Build hash information:
>>
>> bitbake: 6b045e074c6fea97d4e305a5a3c8bf82135d95eb
>> meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575
>> meta-intel: c200851435f39acd2fe4abbf7a05fbf617833964
>> meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5
>> oecore: cd7cf933b3235560ec71576d8f3836dff736a39f
>> poky: 51f6145f8f99a02df1dad937684f014b0172e72a
>>
>>
>>
>> This is an automated message from the Yocto Project Autobuilder
>> Git: git://git.yoctoproject.org/yocto-autobuilder2
>> Email: richard.pur...@linuxfoundation.org
>>
>>
>>


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


Re: [yocto] [wpe-webkit] Optimising imx6 performance for HTML5 using Cog + WPE WebKit

2019-10-23 Thread Carlos Alberto Lopez Perez
On 23/10/2019 13:27, Andy Pont wrote:
> Hello,
> 
> Broadening this out to the Freescale and Yocto mailing lists to see if
> any one has any answers…
> 
> We are using Cog and WPE Webkit on an i.MX6 Solo based board with a user
> interface that is based on HTML5, Javascript and CSS and are having some
> issues with fading and other canvas effects.  The board is running a
> Yocto image with the following in conf/local.conf:
> 
> PREFERRED_PROVIDER_virtual/wpebackend = "wpebackend-rdk"
> PACKAGECONFIG_pn-wpebackend-rdk = "imx6"
> 
> PACKAGECONFIG_append_pn-cairo = " glesv2 egl"
> PACKAGECONFIG_append_pn-wpewebkit = " 2dcanvas"
> 
> We start the browser with the following command line:
> 
> cog --enable-accelerated-2d-canvas=1 appui/index.html
> 

How the performance compares if you disable accelerated-2d-canvas?
It gets worse or its the same?

> Are there any other settings we should be using either in the Yocto
> build or when launching Cog as we are finding the CPU usage is >90%?
> 
> Is there a definitive way to show that all of the necessary drivers are
> loaded and Cog is making use of the GPU?
> 
> I have tried this with Cog 0.3.0 built with WPE WebKit 2.24.1 and Cog
> 0.4.0 built with WPE WebKit 2.26.1 and both give the same dissappointing
> results, as does running on the iMX6Q-SDP board I also have here.
> 

Usually on the web application side there are different things that can
be optimized to make it perform better on WPE.
I think it would be helpful to understand the problem if you can share a
demo of your web app where the performance problem can be easily reproduced.



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


Re: [yocto] [wpe-webkit] Optimising imx6 performance for HTML5 using Cog + WPE WebKit

2019-10-23 Thread Andy Pont

Carlos wrote...



 We start the browser with the following command line:

 cog --enable-accelerated-2d-canvas=1 appui/index.html



How the performance compares if you disable accelerated-2d-canvas?
It gets worse or its the same?
It is the same. I have been testing with http://fabricjs.com//animation 
and https://themaninblue.com/experiment/AnimationBenchmark/canvas/ and 
in all circumstances I see 10-12fps.



Usually on the web application side there are different things that can
be optimized to make it perform better on WPE.
I think it would be helpful to understand the problem if you can share a
demo of your web app where the performance problem can be easily reproduced.
The web app is responding to data being sent to it over a websocket 
connection from a backend application. I’ll see if we can create 
something that doesn’t rely on the websocket interface that can be run 
in the browser on its own.


-Andy.

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


[yocto] Optimising imx6 performance for HTML5 using Cog + WPE WebKit

2019-10-23 Thread Andy Pont

Hello,

Broadening this out to the Freescale and Yocto mailing lists to see if 
any one has any answers…


We are using Cog and WPE Webkit on an i.MX6 Solo based board with a user 
interface that is based on HTML5, Javascript and CSS and are having some 
issues with fading and other canvas effects.  The board is running a 
Yocto image with the following in conf/local.conf:


PREFERRED_PROVIDER_virtual/wpebackend = "wpebackend-rdk"
PACKAGECONFIG_pn-wpebackend-rdk = "imx6"

PACKAGECONFIG_append_pn-cairo = " glesv2 egl"
PACKAGECONFIG_append_pn-wpewebkit = " 2dcanvas"

We start the browser with the following command line:

cog --enable-accelerated-2d-canvas=1 appui/index.html

Are there any other settings we should be using either in the Yocto 
build or when launching Cog as we are finding the CPU usage is >90%?


Is there a definitive way to show that all of the necessary drivers are 
loaded and Cog is making use of the GPU?


I have tried this with Cog 0.3.0 built with WPE WebKit 2.24.1 and Cog 
0.4.0 built with WPE WebKit 2.26.1 and both give the same dissappointing 
results, as does running on the iMX6Q-SDP board I also have here.


-Andy.

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


[yocto] Issues adding bare meta toolchain to yocto build

2019-10-23 Thread Westermann, Oliver
Hey,

I'm having issues adding a build for a bare metal target to my yocto toolchain. 
I've a NXP SoC with a M4 core and I would like to integrate the M4 binary build 
into yocto.
My M4 binary has a CMAKE file that depends on ARMGCC_DIR being set to locate 
the toolchain and everything works fine locally.

I've create a recipe for the toolchain that is heavily inspired by a TI recipe 
for the gcc-arm-none-eabi (available here: 
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/devtools/gcc-arm-none-eabi_7-2018-q2-update.bb?h=master).
I've made sure that GCC_ARM_NONE_TOOLCHAIN_RECIPE is set.

After calling bitbake -cpopulate-sysroot gcc-arm-none-eabi-native the 
image/${GCC_ARM_NONE_TOOLCHAIN_RECIPE} path contains the complete toolchain.

My M4 recipe looks like this (plus SUMMARY, LICENSE, SRC_URI, ...):

inherit pkgconfig cmake
DEPENDS = "gcc-arm-none-eabi-native"

S = "${WORKDIR}/git "

EXTRA_OECMAKE = '-DCMAKE_TOOLCHAIN_FILE="../armgcc.cmake" \
 -G "Unix Makefiles" \
 -DCMAKE_BUILD_TYPE=release'

>From my understanding depending on gcc-arm-none-eabi-native should result in 
>the native toolchain being installed into the m4's recipe-sysroot-native 
>folder.
The sysroot-providers in the recipe-sysroot-native folder does list 
gcc-arm-none-eabi-native, but I don't get the files and therefore have no 
toolchain.

Any suggestions on what I'm doing wrong or how to debug this further?

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


Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 1/2] i2c: cadence: do not clear bus_hold_flag in mrecv

2019-10-23 Thread Quanyang Wang

Hi Shubhrajyoti,

On 10/23/19 5:17 PM, Shubhrajyoti Datta wrote:

Hi ,


-Original Message-
From: Quanyang Wang 
Sent: Wednesday, October 23, 2019 2:24 PM
To: Michal Simek ; Bruce ;
Shubhrajyoti Datta 
Cc: linux-yocto@yoctoproject.org; git 
Subject: Re: [linux-yocto][kernel v5.2/standard/xlnx-soc][PATCH 1/2] i2c:
cadence: do not clear bus_hold_flag in mrecv

Hi,

On 10/14/19 2:07 PM, Michal Simek wrote:

On 13. 10. 19 15:33, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

When using i2c_smbus_read_byte_data to read one byte from a slave
device, because of the commit d358def70688
("i2c: cadence: Fix the hold bit setting"), the transaction becomes:

S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P
 ^
  CR_HOLD bit as 0

This will result that the read operation fails and will read "0xff"
from the slave device. In the SMBus protocol stipulates that it must
follow that command with a repeated START condition as below:

S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Data] NA P

So keep CR_HOLD bit to be 1 to make sure that the read operation
begins with a Sr (repeated START) but not a STOP followed by START.

Signed-off-by: Quanyang Wang 
---
   drivers/i2c/busses/i2c-cadence.c | 2 --
   1 file changed, 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-cadence.c
b/drivers/i2c/busses/i2c-cadence.c
index 6b011931e090..d9493914be15 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -626,8 +626,6 @@ static void cdns_i2c_mrecv(struct cdns_i2c *id)
 */
if ((id->recv_count > CDNS_I2C_FIFO_DEPTH)  || id->bus_hold_flag)
ctrl_reg |= CDNS_I2C_CR_HOLD;
-   else
-   ctrl_reg = ctrl_reg & ~CDNS_I2C_CR_HOLD;

cdns_i2c_writereg(ctrl_reg, CDNS_I2C_CR_OFFSET);



Shubhrajyoti: Can you please comment?

Any comment?

I am not finding code segment in the tree
I am checking

https://gitenterprise.xilinx.com/Linux/linux-xlnx/blob/master/drivers/i2c/busses/i2c-cadence.c

maybe you can try moving to the latest code.


And when SDK kernel applies with this patch "i2c: cadence: Fix the hold 
bit setting",


using i2c_smbus_read_byte_data to access ucd90120 
(drivers/hwmon/pmbus/ucd9000.c) in the board zc706 can reproduce this error.


Thanks,

Quanyang


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


Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 1/2] i2c: cadence: do not clear bus_hold_flag in mrecv

2019-10-23 Thread Quanyang Wang

Hi,

On 10/14/19 2:07 PM, Michal Simek wrote:

On 13. 10. 19 15:33, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

When using i2c_smbus_read_byte_data to read one byte from a
slave device, because of the commit d358def70688
("i2c: cadence: Fix the hold bit setting"), the transaction becomes:

S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P
^
 CR_HOLD bit as 0

This will result that the read operation fails and will read "0xff" from
the slave device. In the SMBus protocol stipulates that it must follow that
command with a repeated START condition as below:

S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Data] NA P

So keep CR_HOLD bit to be 1 to make sure that the read operation begins
with a Sr (repeated START) but not a STOP followed by START.

Signed-off-by: Quanyang Wang 
---
  drivers/i2c/busses/i2c-cadence.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 6b011931e090..d9493914be15 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -626,8 +626,6 @@ static void cdns_i2c_mrecv(struct cdns_i2c *id)
 */
if ((id->recv_count > CDNS_I2C_FIFO_DEPTH)  || id->bus_hold_flag)
ctrl_reg |= CDNS_I2C_CR_HOLD;
-   else
-   ctrl_reg = ctrl_reg & ~CDNS_I2C_CR_HOLD;
  
  	cdns_i2c_writereg(ctrl_reg, CDNS_I2C_CR_OFFSET);
  


Shubhrajyoti: Can you please comment?

Any comment?


M

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


[yocto] [psplash][PATCH] add SPDX License identifier

2019-10-23 Thread Yann CARDAILLAC
Signed-off-by: Yann CARDAILLAC 
---
 make-image-header.sh | 1 +
 psplash-bar-img.h| 1 +
 psplash-colors.h | 2 ++
 psplash-config.h | 2 ++
 psplash-console.c| 2 ++
 psplash-console.h| 2 ++
 psplash-fb.c | 2 ++
 psplash-fb.h | 2 ++
 psplash-hand-img.h   | 1 +
 psplash-poky-img.h   | 1 +
 psplash-write.c  | 2 ++
 psplash.c| 2 ++
 psplash.h| 2 ++
 radeon-font.h| 1 +
 14 files changed, 23 insertions(+)

diff --git a/make-image-header.sh b/make-image-header.sh
index d7cf67c..85c9219 100755
--- a/make-image-header.sh
+++ b/make-image-header.sh
@@ -1,4 +1,5 @@
 #!/bin/sh
+# SPDX-License-Identifier: GPL-2.0-only
 
 set -e
 
diff --git a/psplash-bar-img.h b/psplash-bar-img.h
index c1c7626..b12000e 100644
--- a/psplash-bar-img.h
+++ b/psplash-bar-img.h
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /* GdkPixbuf RGBA C-Source image dump 1-byte-run-length-encoded */
 
 #define BAR_IMG_ROWSTRIDE (920)
diff --git a/psplash-colors.h b/psplash-colors.h
index d701089..73d80a0 100644
--- a/psplash-colors.h
+++ b/psplash-colors.h
@@ -4,6 +4,8 @@
  *  Copyright (c) 2012 sleep(5) ltd
  *  Author: Tomas Frydrych 
  *
+ *  SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
  *  the Free Software Foundation; either version 2, or (at your option)
diff --git a/psplash-config.h b/psplash-config.h
index 82bb76d..56d6595 100644
--- a/psplash-config.h
+++ b/psplash-config.h
@@ -4,6 +4,8 @@
  *  Copyright (c) 2014 MenloSystems GmbH
  *  Author: Olaf Mandel 
  *
+ *  SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
  *  the Free Software Foundation; either version 2, or (at your option)
diff --git a/psplash-console.c b/psplash-console.c
index 055f5b0..b19384b 100644
--- a/psplash-console.c
+++ b/psplash-console.c
@@ -3,6 +3,8 @@
  *
  *  Copyright (c) 2006 Matthew Allum 
  *
+ *  SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
  *  the Free Software Foundation; either version 2, or (at your option)
diff --git a/psplash-console.h b/psplash-console.h
index c444d27..4fcca97 100644
--- a/psplash-console.h
+++ b/psplash-console.h
@@ -3,6 +3,8 @@
  *
  *  Copyright (c) 2006 Matthew Allum 
  *
+ *  SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
  *  the Free Software Foundation; either version 2, or (at your option)
diff --git a/psplash-fb.c b/psplash-fb.c
index c064d18..a3230da 100644
--- a/psplash-fb.c
+++ b/psplash-fb.c
@@ -3,6 +3,8 @@
  *
  *  Copyright (c) 2006 Matthew Allum 
  *
+ *  SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
  *  the Free Software Foundation; either version 2, or (at your option)
diff --git a/psplash-fb.h b/psplash-fb.h
index d0dce10..42b7fb0 100644
--- a/psplash-fb.h
+++ b/psplash-fb.h
@@ -3,6 +3,8 @@
  *
  *  Copyright (c) 2006 Matthew Allum 
  *
+ *  SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  This program is free software; you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
  *  the Free Software Foundation; either version 2, or (at your option)
diff --git a/psplash-hand-img.h b/psplash-hand-img.h
index a015e2c..e0a863c 100644
--- a/psplash-hand-img.h
+++ b/psplash-hand-img.h
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /* GdkPixbuf RGBA C-Source image dump 1-byte-run-length-encoded */
 
 #define HAND_IMG_ROWSTRIDE (400)
diff --git a/psplash-poky-img.h b/psplash-poky-img.h
index 76267e6..a617724 100644
--- a/psplash-poky-img.h
+++ b/psplash-poky-img.h
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /* GdkPixbuf RGBA C-Source image dump 1-byte-run-length-encoded */
 
 #define POKY_IMG_ROWSTRIDE (1708)
diff --git a/psplash-write.c b/psplash-write.c
index 3fdba95..f34af0e 100644
--- a/psplash-write.c
+++ b/psplash-write.c
@@ -3,6 +3,8 @@
  *
  *  Copyright (c) 2006 Matthew Allum 
  *
+ *  SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  Parts of this file based on 'usplash' copyright Matthew Garret.
  *
  *  This program is free software; you can redistribute it and/or modify
diff --git a/psplash.c b/psplash.c
index 992e199..b0b91aa 100644
--- a/psplash.c
+++ b/psplash.c
@@ -3,6 +3,8 @@
  *
  *  Copyright (c) 2006 Matthew Allum 
  *
+ *  SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  Parts of this file ( fifo handling ) 

[yocto] [psplash][PATCH] Adding SPDX license identifier to psplash

2019-10-23 Thread Yann CARDAILLAC
Hi,

If you have any advice please feel free to ask. 

I've put GPLV2 or later whenever it was mentioned and GPLV2 where nothing was 
saying otherwise. 

Also it's my first try with git send-email so some things can go wrong ahah.

Best regards,

Yann CARDAILLAC

Yann CARDAILLAC (1):
  add SPDX License identifier

 make-image-header.sh | 1 +
 psplash-bar-img.h| 1 +
 psplash-colors.h | 2 ++
 psplash-config.h | 2 ++
 psplash-console.c| 2 ++
 psplash-console.h| 2 ++
 psplash-fb.c | 2 ++
 psplash-fb.h | 2 ++
 psplash-hand-img.h   | 1 +
 psplash-poky-img.h   | 1 +
 psplash-write.c  | 2 ++
 psplash.c| 2 ++
 psplash.h| 2 ++
 radeon-font.h| 1 +
 14 files changed, 23 insertions(+)

-- 
2.7.4

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


Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.4.rc2)

2019-10-23 Thread Jain, Sangeeta
Hello all,

This is the full report for 2.6.4 RC2:  
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

=== Summary 
No high milestone defects.  
No new defect found in this cycle.
The stap test case failure on beaglebone still exists in this release (BUG 
id:13273). 

=== Bugs 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273

Thanks & Regards,
Sangeeta Jain

>-Original Message-
>From: Poky Build User 
>Sent: Friday, October 18, 2019 5:18 AM
>To: yocto@yoctoproject.org
>Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
>; Yeoh, Ee Peng ; Chan,
>Aaron Chun Yew ; Ang, Chin Huat
>; richard.pur...@linuxfoundation.org;
>akuster...@gmail.com; sjolley.yp...@gmail.com; Jain, Sangeeta
>
>Subject: QA notification for completed autobuilder build (yocto-2.6.4.rc2)
>
>
>A build flagged for QA (yocto-2.6.4.rc2) was completed on the autobuilder and 
>is
>available at:
>
>
>https://autobuilder.yocto.io/pub/releases/yocto-2.6.4.rc2
>
>
>Build hash information:
>
>bitbake: 6b045e074c6fea97d4e305a5a3c8bf82135d95eb
>meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575
>meta-intel: c200851435f39acd2fe4abbf7a05fbf617833964
>meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5
>oecore: cd7cf933b3235560ec71576d8f3836dff736a39f
>poky: 51f6145f8f99a02df1dad937684f014b0172e72a
>
>
>
>This is an automated message from the Yocto Project Autobuilder
>Git: git://git.yoctoproject.org/yocto-autobuilder2
>Email: richard.pur...@linuxfoundation.org
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] TFS Urls with Git in Recipes

2019-10-23 Thread Lohr, Christian [ext]
Hello,

I'm using the following:
Yocto Release 2.4 (Rocko), and Bitbake 1.9.x

My problem is the following url (actually the "%20" is the problem in bitbake):
ssh://tfs-my-company.org:22/tfs/OWN_Projects/FooBar%20500/_git/DummyApplicationForYocto

I can do a "git clone " without any problems. Now I wanted to create a 
Yocto recipe similar to this:

--
SUMMARY = "A demo application"
DESCRIPTION = "This application is just for demo purpose and should be seen as 
Hello World"
LICENSE = "CLOSED"
#LIC_FILES_CHKSUM = ""

PROJECT_URL = "tfs-my-company.org:22/tfs/OWN_Projects"
PROJECT_NAME = "FooBar%20500"

SRC_URI = 
"git://${PROJECT_URL}/${PROJECT_NAME}/_git/DummyApplicationForYocto;protocol=ssh"
SRCREV = "${AUTOREV}"
PV = "1.0+git${SRCPV}"

DEPENDS = "qtbase"


The "%20" sign will be replaced with a space " " in some cases:
When I try to run "bitbake dummyapp", the following happens:
"FooBar%20500" will be transformed to "FooBar 500"


git -c core.fsyncobjectfiles=0 ls-remote ssh:// 
tfs-my-company.org:22/tfs/OWN_Projects/FooBar 500/_git/DummyApplicationForYocto 
 failed with exit code 128, output:
remote: Command git-upload-pack '/tfs/OWN_Projects/FooBar' is not in expected 
format.
fatal: Could not read from remote repository.

Is it possible to prevent this because if it would leave the "%20" the command 
would work.

Kind regards,

Christian Lohr

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