[linux-yocto] [PATCH 3/3] [kernel-cache] smp: Separate smp into 32 and 64 bit versions to avoid kernel warnings

2017-06-30 Thread Alejandro Hernandez 
When selecting SMP, some dependencies are needed, in the case
of a 32 bit build CONFIG_X86_BIGSMP=y is required, but adding that
to a 64 bit build causes warnings to be shown since X86_BIGSMP
requires X86_32 [n] itself, which can only be true for a 32 bit build.

This patch creates a 64 bit version of smp (smp_64), avoiding the
dependecy issues.

[YOCTO #11742]

Signed-off-by: Alejandro Hernandez 
---
 cfg/smp.scc| 2 +-
 cfg/smp_64.cfg | 5 +
 cfg/smp_64.scc | 4 
 cfg/x86_64.scc | 2 +-
 4 files changed, 11 insertions(+), 2 deletions(-)
 create mode 100644 cfg/smp_64.cfg
 create mode 100644 cfg/smp_64.scc

diff --git a/cfg/smp.scc b/cfg/smp.scc
index f697ce59..bf1e9bf6 100644
--- a/cfg/smp.scc
+++ b/cfg/smp.scc
@@ -1,4 +1,4 @@
-define KFEATURE_DESCRIPTION "Enable SMP"
+define KFEATURE_DESCRIPTION "Enable SMP for 32 bit builds"
 define KFEATURE_COMPATIBILITY all
 
 kconf hardware smp.cfg
diff --git a/cfg/smp_64.cfg b/cfg/smp_64.cfg
new file mode 100644
index ..22047746
--- /dev/null
+++ b/cfg/smp_64.cfg
@@ -0,0 +1,5 @@
+CONFIG_SMP=y
+CONFIG_SCHED_SMT=y
+# Increase default NR_CPUS from 8 to 64 so that platform with
+# more than 8 processors can be all activated at boot time
+CONFIG_NR_CPUS=64
diff --git a/cfg/smp_64.scc b/cfg/smp_64.scc
new file mode 100644
index ..e8b54e39
--- /dev/null
+++ b/cfg/smp_64.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "Enable SMP for 64 bit builds"
+define KFEATURE_COMPATIBILITY all
+
+kconf hardware smp_64.cfg
diff --git a/cfg/x86_64.scc b/cfg/x86_64.scc
index e792ac3b..9e9af11b 100644
--- a/cfg/x86_64.scc
+++ b/cfg/x86_64.scc
@@ -1,4 +1,4 @@
 include x86_base.scc
-include smp.scc
+include smp_64.scc
 include timer/hz_1000.scc
 kconf hardware x86_64.cfg
-- 
2.12.0

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

[linux-yocto] [PATCH 2/3] [kernel-cache] bsp/mohonpeak: smp gets added by default, remove unnecessary include

2017-06-30 Thread Alejandro Hernandez 
mohonpeak.scc and mohonpeak32.scc are based on x86.scc and x86_64.scc
which already include smp.scc, so remove the unnecessary include.

[YOCTO #11743]

Signed-off-by: Alejandro Hernandez 
---
 bsp/mohonpeak/mohonpeak.scc   | 3 ---
 bsp/mohonpeak/mohonpeak32.scc | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/bsp/mohonpeak/mohonpeak.scc b/bsp/mohonpeak/mohonpeak.scc
index dff0a897..f0634de4 100644
--- a/bsp/mohonpeak/mohonpeak.scc
+++ b/bsp/mohonpeak/mohonpeak.scc
@@ -23,8 +23,5 @@ include features/crypto/crypto.scc
 
 include cfg/efi.scc
 
-# Add smp support
-include cfg/smp.scc
-
 # Enable GCC inlining
 include features/inline/inline.scc
diff --git a/bsp/mohonpeak/mohonpeak32.scc b/bsp/mohonpeak/mohonpeak32.scc
index 56731863..b6a94adb 100644
--- a/bsp/mohonpeak/mohonpeak32.scc
+++ b/bsp/mohonpeak/mohonpeak32.scc
@@ -19,8 +19,5 @@ include features/crypto/crypto.scc
 
 include cfg/efi.scc
 
-#Add smp support
-include cfg/smp.scc
-
 #Enable GCC inlining
 include features/inline/inline.scc
-- 
2.12.0

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

[linux-yocto] [PATCH 1/3] [kernel-cache] bsp/rangeley: smp gets added by default, remove unnecessary include

2017-06-30 Thread Alejandro Hernandez 
rangeley.scc and rangeley32.scc are based on x86.scc and x86_64.scc
which already include smp.scc, so remove the unnecessary include.

[YOCTO #11743]

Signed-off-by: Alejandro Hernandez 
---
 bsp/rangeley/rangeley.scc   | 3 ---
 bsp/rangeley/rangeley32.scc | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/bsp/rangeley/rangeley.scc b/bsp/rangeley/rangeley.scc
index 381fb032..322cb997 100644
--- a/bsp/rangeley/rangeley.scc
+++ b/bsp/rangeley/rangeley.scc
@@ -18,8 +18,5 @@ include features/crypto/crypto.scc
 
 include cfg/efi.scc
 
-#Add smp support
-include cfg/smp.scc
-
 #Enable GCC inlining
 include features/inline/inline.scc
diff --git a/bsp/rangeley/rangeley32.scc b/bsp/rangeley/rangeley32.scc
index 65035894..0172895c 100644
--- a/bsp/rangeley/rangeley32.scc
+++ b/bsp/rangeley/rangeley32.scc
@@ -18,8 +18,5 @@ include features/crypto/crypto.scc
 
 include cfg/efi.scc
 
-#Add smp support
-include cfg/smp.scc
-
 #Enable GCC inlining
 include features/inline/inline.scc
-- 
2.12.0

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

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

2017-06-30 Thread Michael Ho 
Hi Darcy,

Thank you for the feedback. Actually, depending on what exactly you mean by user
supplied script, this patch set for the concept already supports that.

I'm not sure if my attachments got skewered by the mailing list or not but if
you can see my patch 
"0009-recipes-cdepends-test-example-recipe-framework-for-u.patch",
you can see an example implementation and what needs to be done to introduce a
custom compatibility checker.

This patch set provides the hooks for Bitbake and recipes to communicate about
the compatible dependency checker it needs to use. In essence, the recipes point
Bitbake to a python module that it can load from any meta-layer lib folder and
run a predefined function, passing the directories of the compatibility reports
(the latest from the freshly built recipe, and the older from the sstate cache
of the child recipe) which are also defined by the recipes. This python function
can then do whatever it wants with the compatibility data it has access to (i.e.
call a custom user script to look at the report information) and return
"incompatible" or "compatible" to control the RunQueue. Bitbake will rebuild if
incompatible is returned, and not rebuild if compatible is returned. It can also
return a different value which Bitbake will interpret as a compatibility error
(e.g. binary delivery recipe that will be incompatible so you want to crash the
build instead of detecting the error at runtime).

Therefore, the recipes themselves define all the compatibility report
information and how to do the comparison, allowing for "user supplied hook
scripts" which can be defined at any meta-layer level.

In the case you're hinting towards, you would need to implement the following
which can already hook into these patches:
1. a report generation function for the kernel recipe to output the data you
   need to compare - i.e. a compatibility report (a directory of files) that
   consists of the file checksums of the kernel headers stored in a text file
   and the PV of the recipe stored in another text file - to do so the kernel
   recipe merely needs to inherit compatible-depends-report and add a function
   that outputs these report files and add this function to the prefuncs of the
   task do_compatibility_report.
2. A python function to compare the different versions of the report format
   suggested in (1).
3. Modifying the child recipes to add the kernel to CDEPENDS and point Bitbake
   to the python function by setting the variable CDEPENDS_TOOL_xxx for the
   kernel provider.

If you look at the patch 0009, you'll see the example is fairly simple but
similar to what I explained above. The python function added to the lib folder
is the actual compatibility comparison function and more can be easily
introduced in any meta-layer to match the compatibility checking situation. (If
interested, I can share another example compatibility checker that uses the PV
of a recipe to do rebuild decisions).

Happy to answer in more detail if you require, just let me know.

Thank you.

Kind regards,
Michael Ho

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung - Linux Software Integration
Lise-Meitner-Str. 14
89081 Ulm

Tel.: +49 731 3780 4071
Mobil: +49 152 5498 0471
Fax: +49-731-37804-001
Mail: michael...@bmw-carit.de
Web: http://www.bmw-carit.de

BMW Car IT GmbH
Gechäftsführer: Kai-Uwe Balszuweit und Alexis Trolin
Sitz und Registergericht: München HRB 134810


From: Darcy Watkins 
Sent: 30 June 2017 17:01
To: Michael Ho
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] RFC: Backwards compatibility checking sstate-cache
  

Hi,


It would also be nice to add some sort of hook script support where user 
supplied hook script performs a check and returns either a "yes it's OK" or a 
"no have to rebuild it" status.
 And then tie that into the dependency logic.


I have unusual use case where I need to have a dependency on changes to the 
kernel version, but not necessarily something triggered after every kernel 
rebuild.   The package I'm building will trigger OpenSSL and a whole whack of  
stuff each time it rebuilds.


It depends on the kernel version and the headers, but shouldn't need to depend 
on every patch or kconfig change that happens.



___



Regards,
 
Darcy
 
Darcy Watkins ::  Senior Staff Engineer, Firmware
 
SIERRA WIRELESS
Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1  604 231 1100
13811 Wireless Way  :: Richmond, BC Canada V6V 3A4
[M4]
dwatk...@sierrawireless.com :: www.sierrawireless.com :: 
www.inmotiontechnology.com
 
  

On Jun 30, 2017, at 2:53 AM, Michael Ho  wrote:

 
Hi, at BMW Car IT we are working on an experimental feature to improve sstate
cache hits and we are looking for comments on the approach who might have some
insights to the problem and seeing if anyone is interested in the feature

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

2017-06-30 Thread Darcy Watkins 
Hi,

It would also be nice to add some sort of hook script support where user 
supplied hook script performs a check and returns either a "yes it's OK" or a 
"no have to rebuild it" status.
 And then tie that into the dependency logic.

I have unusual use case where I need to have a dependency on changes to the 
kernel version, but not necessarily something triggered after every kernel 
rebuild.   The package I'm building will trigger OpenSSL and a whole whack of 
stuff each time it rebuilds.

It depends on the kernel version and the headers, but shouldn't need to depend 
on every patch or kconfig change that happens.


___

Regards,

Darcy

Darcy Watkins ::  Senior Staff Engineer, Firmware

SIERRA WIRELESS
Direct  +1 604 233 7989   ::  Fax  +1 604 231 
1109  ::  Main  +1 604 231 
1100
13811 Wireless Way  :: Richmond, BC Canada V6V 3A4
[M4]
dwatk...@sierrawireless.com :: 
www.sierrawireless.com :: 
www.inmotiontechnology.com


On Jun 30, 2017, at 2:53 AM, Michael Ho 
> wrote:

Hi, at BMW Car IT we are working on an experimental feature to improve sstate
cache hits and we are looking for comments on the approach who might have some
insights to the problem and seeing if anyone is interested in the feature for
mainline.

The sstate-cache of a recipe is tied closely to its build dependencies, as the
signature generated for a task includes all parent task's signatures as part of
the signature information. This means that when changes occur in the parent
recipes, even if insignificant, all children recipes that have valid sstate
cache must invalidate their sstate cache objects.

What this patchset does is propose to add another optional variable to recipes,
CDEPENDS, which acts like DEPENDS for all RunQueue purposes but for signature
generation it excludes any parent tasks that come from dependencies listed in
it. This is to break the signature change domino effect.

This patchset also proposes modifying RunQueue to then be able to run a
compatibility checker during task execution phase for recipes and tasks that use
CDEPENDS and allow for deciding to re-execute a task despite being covered by
sstate-cache.

The patchset is based on the jethro branch for the poky repository, as this is
the branch that we are using.  If the general idea sounds good, we can consider
porting it to master.

Included is an patch that adds an example recipe and compatibility checker,
where compatibility is based on the file checksums of the parent recipes
packages. An example recipe, cdepends-test1, generates a compatibility report
containing the file checksums of all files that it packages and which file paths
they are at. Another recipe, cdepends-test2, can then strip this compatibility
report to the minimal files it needs to be consistent and can compare the latest
checksums it used to configure/compile/install with and if they have changed,
trigger a rebuild. If not, the previous version restored from sstate-cache is
used.

We are still experimenting with the usages of this, including the use of having
abi-compliance-checker to compare the ABI of shared libraries as a compatibility
checker during RunQueue and using the results to avoid rebuilding child recipes
when the .so files they depend on are still compatible. Example use cases of
this are allowing recipes which provide multiple shared libraries to change a
single .so file without rebuilding all its children that depend on the other
shared libraries but not the one that changed.

We're aware of the SIGGEN_EXCLUDERECIPES_ABISAFE feature but feel it didn't meet
the feature requirements of what this compatibility checker callback is doing,
although maybe when porting to master we could refactor to make better use of
the work already done there. The current implementation is a bit hacky but
comments would be appreciated in regards to if the concept is feasible and if
people are interested in making use of it and their use cases.

Kind regards,
Michael Ho

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung - Linux Software Integration
Lise-Meitner-Str. 14
89081 Ulm

Tel.: +49 731 3780 4071
Mobil: +49 152 5498 0471
Fax: +49-731-37804-001
Mail: michael...@bmw-carit.de
Web: http://www.bmw-carit.de

BMW Car IT GmbH
Gechäftsführer: Kai-Uwe Balszuweit und Alexis Trolin
Sitz und Registergericht: München HRB 134810

<0001-cache.py-add-support-for-CDEPENDS.patch>
<0002-siggen.py-add-support-for-CDEPENDS.patch>
<0003-runqueue.py-add-support-for-CDEPENDS.patch>
<0004-taskdata.py-add-support-for-CDEPENDS.patch>
<0005-rm_work.bbclass-add-exception-for-do_cache_compatibi.patch>

[yocto] QA cycle report for 2.1.3 rc2

2017-06-30 Thread Cruz, Libertad 
Hello All,



Here is the report for the 2.1.3 rc2 full point release test cycle.

Full Report : 
https://wiki.yoctoproject.org/wiki/WW26_-_2017-30-06_-_Full_Pass_2.1.3_rc2



=== Summary 

The QA cycle for release 2.1.3 rc2 is complete for this release cycle the 
testing team focused on re-executing only test cases that failed on 2.1.3 rc1  
and checking the image integrity on the auto builder.



 Details 

QA Hints



The 2.1.3 rc2 ran smoothly being able to verify the following bugs present on 
previous run 2.1.3 rc1



11644[Yocto 2.1.3] missing toolchian sdk for armv5e

11646[krogoth] WIC image does not load in graphical 
environment

11658[krogoth] testimage multiple errors and 
skipped test present in WIC image (Minnowmax64/NUC)

11659[krogoth] genericx86 fails to boot after 
install from USB on MMAX32



you may view a  full report of the existing bugs for 2.1.3 rc1 link: 
https://wiki.yoctoproject.org/wiki/WW24_-_2017-14-06_-_Full_Pass_2.1.3_rc1#Bugs_Found_during_QA_Test





No new bugs were found for this test cycle but there are some that are present 
11659 [krogoth] genericx86 fails to boot after install from USB on MMAX32[1]  
this bug has a fix but was not integrated on 2.1.3 rc2.

Bugs



   * M+ bugs

- 11659 [krogoth] genericx86 fails to boot after install from USB 
on MMAX32[1]

- 10694 - rpm does not detect file clashes on do_rootfs [2]





Full Bug Report : 
https://wiki.yoctoproject.org/wiki/WW24_-_2017-14-06_-_Full_Pass_2.1.3_rc1#Bugs_Found_during_QA_Test





 Links =



1.https://bugzilla.yoctoproject.org/show_bug.cgi?id=11659 
 [1]

2.https://bugzilla.yoctoproject.org/show_bug.cgi?id=10694 
 [2]



Regards

Libertad G.

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

[yocto] [ANNOUNCEMENT] Milestone 1 for Yocto Project 2.4 now available.

2017-06-30 Thread Tracy Graydon 
The first milestone release for Yocto Project 2.4 is available for download now.

Download:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.4_M1/

eclipse-poky-mars 92aa0e79e8b01c56f0670af3cd8296ec68b43350
eclipse-poky-neon 83e0083ef3a71e10039ace7d18057dddc154408b
meta-qt3 f33b73a9563f2dfdfd0ee37b61d65d90197a456f
meta-qt4 033509ebc1eb0d13290a7a3f0c2772ed58712c34
poky 6964efddd31c479386d1643c1025bc102710392f

Test report:

https://wiki.yoctoproject.org/wiki/WW25_-_2017-06-22_-_Full_Test_Cycle_2.4_M1_rc1

Thank you.

Tracy Graydon
Yocto Project
Build and Release
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW26’17 EOW

2017-06-30 Thread Jolley, Stephen K 
Current Dev Position: Preparing for YP 2.4 M2

Next Deadline: YP 2.4 M2 Cut off is July 17, 2017



SWAT team rotation: Stephano -> Maxin on June 30, 2017.

SWAT team rotation: Maxin -> Cal on July 7, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team



Key Status/Updates:

·YP 2.4 M1 is due to be released.

·YP 2.1.3 rc2 (krogoth) is in QA, mainly to provide checks on the new 
autobuilder cluster publishing capabilities.  It is mostly complete see: 
https://wiki.yoctoproject.org/wiki/2.1_QA_Status#Summary_Report

·YP 2.2.2 (Morty) continues to have issues with sanity tests failing 
for mips/aarch64 preventing a building making it to QA.

·We’ve merged changes which deviate us more significantly from the LSB 
than we have in the past. Since LSB is in maintenance mode and not targeted to 
Embedded/IoT usages this seems appropriate and the differences are documented 
in README.lsb.

·General patches are merging but triage of patches failing various 
tests is still the limiting factor on things merging.

·Bugzilla cleanup is ongoing however assistance on cleanup of bugs, 
particularly the older languishing ones would be much appreciated. This is 
having a positive effect on the bug tracking metrics (see the link below).



Planned upcoming dot releases:

YP 2.1.3 Cut off May 22, 2017 - In QA now.

YP 2.1.3 Release by June 3, 2017

YP 2.2.2 Cut off June 5, 2017 - See status above, working for an rc2.

YP 2.2.2 Release by June, 16 2017

YP 2.3.1 Cut off May 30, 2017 - Running late, but rc1 should go into QA after 
YP 2.1.3, and YP 2.2.2 are done.

YP 2.3.1 Release by June 9, 2017

YP 2.3.2 Cut off Aug 7, 2017

YP 2.3.2 Release by Aug. 18, 2017



Key YP 2.4 Dates are:

YP 2.4 M2 Cut off is July 17, 2017

YP 2.4 M2 Release by July 28, 2017

YP 2.4 M3 Cut off is Aug. 21, 2017

YP 2.4 M3 Release by Sept. 1, 2017

YP 2.4 M4 (Final) Cut off is Sept. 18, 2017

YP 2.4 M4 (Final) Release by Oct. 20, 2017



Tracking Metrics:

WDD 2508 (last week 2602)

(https://wiki.yoctoproject.org/charts/combo.html)



Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Features



[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:stephen.k.jol...@intel.com

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

[yocto] How to find out the rdepends of certain package

2017-06-30 Thread John Rama 
Hi, experts

I'm facing following problem, when building a image.


The following packages have unmet dependencies:
 openssh-dev : Depends: openssh (= 7.1p2-r0.0) but it is not going to be 
installed
   Recommends: openssh-misc-dev but it is not installable
   Recommends: shadow-sysroot-dev but it is not installable
   Recommends: libcrypto-dev but it is not installable
   Recommends: openssh-sshd-dev but it is not installable
   Recommends: update-alternatives-opkg-dev but it is not 
installable
   Recommends: openssh-scp-dev but it is not installable
   Recommends: openssh-ssh-dev but it is not installable
   Recommends: openssh-sftp-server-dev but it is not installable
   Recommends: openssh-keygen-dev but it is not installable
   Recommends: openssh-sftp-dev but it is not installable
E: Unable to correct problems, you have held broken packages.


I know this can be resolved by adding "openssh" to the IMAGE_INSTALL_append 
list.

But, I'm very curious which recipes try to use openssh-dev, or
which package depends on openssh-dev.

1. I just greped entire recipe tree with "openssh-dev", but there is no hit.
2. Run bitbake -g  option to generate the *-depends.dot file,
   then grepped with "openssh-dev", two hits. 
 
   package-depends.dot:31228:"openssh-staticdev" -> "openssh-dev" [style=dashed]
   pn-depends.dot:4474:"openssh" -> "openssh-dev" [style=dashed]

  However, these are not used by using the similiar method of #1 and #2.

Is there any good way to find out why openssh-dev is in the installed package 
list ?

John


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

Re: [yocto] [meta-raspberrypi] How to add a own dts file and patch the dts makefile

2017-06-30 Thread Andrea Galbusera 
Hi,

On Fri, Jun 30, 2017 at 3:35 PM,  wrote:

> Hej
>
> It's friday and I have some time to play a bit around. I like to build a
> simple test-adapter using a RPi. I want to connect some of the 40GPIO pins
> with a custom mainboard. For that I like to define the pin behaviour by an
> own dts file.
>
> I created my own dts file (testboard.dts) + a simple patch for
> "arch/arm/boot/dts/Makefile" to add the file.
>
> For adding them into the build-process I am append the kernel build
> (linux-raspberrypi%.bbappend).
>
> Now I have problems bringing them together, because the name of the
> git/source links changes (git -> linux-raspberrypi2-standard-build/source
> ). Maybe some one has an idea?
>
> I put the listings of the files below:
>
> ## linux-raspberrypi%.bbappend ##
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> SRC_URI += "file://testboard.dts;subdir=linux-raspberrypi2-standard-
> build/source/arch/arm/boot/dts \
> file://0001-add-testboard-to-makefile.patch \
> "
>

Why aren't you just crafting a patch that does both things? I mean adding
the .dts and changing Makefile in the same patch.


> PACKAGE_ARCH = "raspberrypi2"
>
> KERNEL_DEVICETREE += "testboard.dtb"
> #
>
> ## 0001-add-testboard-to-makefile.patch ##
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
>
> @@ -1,4 +1,8 @@
>  ifeq ($(CONFIG_OF),y)
> +
> +# my own dts files
> +dtb-$(CONFIG_ARCH_BCM2835) += \
> +testboard.dts
>
>  dtb-$(CONFIG_ARCH_BCM2835) += \
>  bcm2708-rpi-b.dtb \
> #
>
> ## testboard.dts ##
> /dts-v1/;
> #include "bcm2836.dtsi"
> #include "bcm2835-rpi.dtsi"
> #include "bcm283x-rpi-smsc9514.dtsi"
> #include "bcm283x-rpi-usb-host.dtsi"
>
> / {
> compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
> model = "RPi test";
>
> memory {
> reg = <0 0x4000>;
> };
>
> leds {
> act {
> gpios = < 47 0>;
> };
>
> pwr {
> label = "PWR";
> gpios = < 35 0>;
> default-state = "keep";
> linux,default-trigger = "default-on";
> };
> };
>
> };
>
>  {
> pinctrl-0 = <  _alt0>;
>
> /* I2S interface */
> i2s_alt0: i2s_alt0 {
> brcm,pins = <18 19 20 21>;
> brcm,function = ;
> status = "disabled";
> };
>
> cord0: cord0 {
> brcm,pins = <5 6 25>;
> brcm,function = ;
> status = "okay";
> };
>
> };
>
>  {
> hpd-gpios = < 46 GPIO_ACTIVE_LOW>;
> status = "disabled";
> };
> #
>
> For that I put a question on stackoverflow:
> https://stackoverflow.com/questions/44702426/how-to-
> setup-an-own-device-tree-for-a-raspberrypi-in-yocto
>
> Regards form Germany!
>
> Stefan
>
> 
> ESA Elektroschaltanlagen Grimma GmbH
> Broner Ring 30
> 04668 Grimma
> Telefon: +49 3437 9211 181 <+49%203437%209211181>
> Telefax: +49 3437 9211 26 <+49%203437%20921126>
> E-Mail: s.jar...@esa-grimma.de
> Internet: www.esa-grimma.de
>
>
> Geschäftsführer:
> Dipl.-Ing. Jörg Gaitzsch
> Jörg Reinker
>
> Sitz der Gesellschaft: Grimma
> Ust.-ID: DE 141784437
> Amtsgericht: Leipzig, HRB 5159
> Steuernummer: 238/108/00755
>
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
> erhalten
> haben, informieren Sie bitte sofort den Absender und löschen Sie diese
> Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
> Mail
> ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If you
> are
> not the intended recipient (or have received this e-mail in error) please
> notify the sender immediately and destroy this e-mail. Any unauthorized
> copying, disclosure or distribution of the material in this e-mail is
> strictly
> forbidden.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] How to add a own dts file and patch the dts makefile

2017-06-30 Thread S . Jaritz 
Hej

It's friday and I have some time to play a bit around. I like to build a 
simple test-adapter using a RPi. I want to connect some of the 40GPIO pins 
with a custom mainboard. For that I like to define the pin behaviour by an 
own dts file.

I created my own dts file (testboard.dts) + a simple patch for 
"arch/arm/boot/dts/Makefile" to add the file.

For adding them into the build-process I am append the kernel build 
(linux-raspberrypi%.bbappend).

Now I have problems bringing them together, because the name of the 
git/source links changes (git -> linux-raspberrypi2-standard-build/source 
). Maybe some one has an idea?

I put the listings of the files below:

## linux-raspberrypi%.bbappend ##
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://testboard.dts
;subdir=linux-raspberrypi2-standard-build/source/arch/arm/boot/dts \
file://0001-add-testboard-to-makefile.patch \
"
PACKAGE_ARCH = "raspberrypi2"

KERNEL_DEVICETREE += "testboard.dtb"
#

## 0001-add-testboard-to-makefile.patch ##
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile

@@ -1,4 +1,8 @@
 ifeq ($(CONFIG_OF),y)
+
+# my own dts files
+dtb-$(CONFIG_ARCH_BCM2835) += \
+   testboard.dts
 
 dtb-$(CONFIG_ARCH_BCM2835) += \
bcm2708-rpi-b.dtb \
#

## testboard.dts ##
/dts-v1/;
#include "bcm2836.dtsi"
#include "bcm2835-rpi.dtsi"
#include "bcm283x-rpi-smsc9514.dtsi"
#include "bcm283x-rpi-usb-host.dtsi"

/ {
compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
model = "RPi test";

memory {
reg = <0 0x4000>;
};

leds {
act {
gpios = < 47 0>;
};

pwr {
label = "PWR";
gpios = < 35 0>;
default-state = "keep";
linux,default-trigger = "default-on";
};
};

};

 {
pinctrl-0 = <  _alt0>;

/* I2S interface */
i2s_alt0: i2s_alt0 {
brcm,pins = <18 19 20 21>;
brcm,function = ;
status = "disabled";
};

cord0: cord0 {
brcm,pins = <5 6 25>;
brcm,function = ;
status = "okay";
};

};

 {
hpd-gpios = < 46 GPIO_ACTIVE_LOW>;
status = "disabled";
};
#

For that I put a question on stackoverflow:
https://stackoverflow.com/questions/44702426/how-to-setup-an-own-device-tree-for-a-raspberrypi-in-yocto

Regards form Germany!

Stefan


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 181
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich 
erhalten 
haben, informieren Sie bitte sofort den Absender und löschen Sie diese 
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser 
Mail 
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you 
are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is 
strictly 
forbidden.-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] rpi-base: wic: generate entries for u-boot

2017-06-30 Thread Andrei Gherzan 
On Thu, Jun 29, 2017 at 9:01 PM, Andrea Galbusera  wrote:

> This commit allow wic generated images to work when we want u-boot to
> load the kernel image.
>
> Augment IMAGE_BOOT_FILES with the proper entries when KERNEL_IMAGETYPE
> is "uImage". More specifically add u-boot image and boot.scr to deployed
> files
> and give the proper name to the kernel image accordingly.
>
> Signed-off-by: Andrea Galbusera 
> ---
>  conf/machine/include/rpi-base.inc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/conf/machine/include/rpi-base.inc b/conf/machine/include/rpi-
> base.inc
> index 4a0ea2a..71bb071 100644
> --- a/conf/machine/include/rpi-base.inc
> +++ b/conf/machine/include/rpi-base.inc
> @@ -83,7 +83,9 @@ def make_dtb_boot_files(d):
>
>  IMAGE_BOOT_FILES ?= "bcm2835-bootfiles/* \
>   ${@make_dtb_boot_files(d)} \
> - ${KERNEL_IMAGETYPE};${SDIMG_KERNELIMAGE} \
> + ${@bb.utils.contains('KERNEL_IMAGETYPE', 'uImage',
> '${KERNEL_IMAGETYPE}', '${KERNEL_IMAGETYPE};${SDIMG_KERNELIMAGE}', d)} \
> + ${@bb.utils.contains('KERNEL_IMAGETYPE', 'uImage',
> 'u-boot.bin;${SDIMG_KERNELIMAGE}', '', d)} \
> + ${@bb.utils.contains('KERNEL_IMAGETYPE', 'uImage',
> 'boot.scr;boot.scr', '', d)} \
>   "
>
>  # The kernel image is installed into the FAT32 boot partition and does
> not need
>

Merged to master. Thanks.

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

[yocto] RFC: Backwards compatibility checking sstate-cache

2017-06-30 Thread Michael Ho 
Hi, at BMW Car IT we are working on an experimental feature to improve sstate
cache hits and we are looking for comments on the approach who might have some
insights to the problem and seeing if anyone is interested in the feature for
mainline.

The sstate-cache of a recipe is tied closely to its build dependencies, as the
signature generated for a task includes all parent task's signatures as part of
the signature information. This means that when changes occur in the parent
recipes, even if insignificant, all children recipes that have valid sstate
cache must invalidate their sstate cache objects.

What this patchset does is propose to add another optional variable to recipes,
CDEPENDS, which acts like DEPENDS for all RunQueue purposes but for signature
generation it excludes any parent tasks that come from dependencies listed in
it. This is to break the signature change domino effect.

This patchset also proposes modifying RunQueue to then be able to run a
compatibility checker during task execution phase for recipes and tasks that use
CDEPENDS and allow for deciding to re-execute a task despite being covered by
sstate-cache.

The patchset is based on the jethro branch for the poky repository, as this is
the branch that we are using.  If the general idea sounds good, we can consider
porting it to master.

Included is an patch that adds an example recipe and compatibility checker,
where compatibility is based on the file checksums of the parent recipes
packages. An example recipe, cdepends-test1, generates a compatibility report
containing the file checksums of all files that it packages and which file paths
they are at. Another recipe, cdepends-test2, can then strip this compatibility
report to the minimal files it needs to be consistent and can compare the latest
checksums it used to configure/compile/install with and if they have changed,
trigger a rebuild. If not, the previous version restored from sstate-cache is
used.

We are still experimenting with the usages of this, including the use of having
abi-compliance-checker to compare the ABI of shared libraries as a compatibility
checker during RunQueue and using the results to avoid rebuilding child recipes
when the .so files they depend on are still compatible. Example use cases of
this are allowing recipes which provide multiple shared libraries to change a
single .so file without rebuilding all its children that depend on the other
shared libraries but not the one that changed.

We're aware of the SIGGEN_EXCLUDERECIPES_ABISAFE feature but feel it didn't meet
the feature requirements of what this compatibility checker callback is doing,
although maybe when porting to master we could refactor to make better use of
the work already done there. The current implementation is a bit hacky but
comments would be appreciated in regards to if the concept is feasible and if
people are interested in making use of it and their use cases.

Kind regards,
Michael Ho

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung - Linux Software Integration
Lise-Meitner-Str. 14
89081 Ulm

Tel.: +49 731 3780 4071
Mobil: +49 152 5498 0471
Fax: +49-731-37804-001
Mail: michael...@bmw-carit.de
Web: http://www.bmw-carit.de

BMW Car IT GmbH
Gechäftsführer: Kai-Uwe Balszuweit und Alexis Trolin
Sitz und Registergericht: München HRB 134810

From 0afcfc5bde251e96a434c345b4e0e4db895feeae Mon Sep 17 00:00:00 2001
From: Michael Ho 
Date: Fri, 30 Jun 2017 06:52:12 +0200
Subject: [PATCH 1/9] cache.py: add support for CDEPENDS
To: yocto@yoctoproject.org

Modifies the bitbake recipe cache handling to now parse also the CDEPENDS
variable, the cdepends flag that can be set for tasks, and also the machine
architecture for the recipe target (since compatibility will be tied to the
machine type also).
---
 bitbake/lib/bb/cache.py | 29 +
 1 file changed, 29 insertions(+)

diff --git a/bitbake/lib/bb/cache.py b/bitbake/lib/bb/cache.py
index ab09b08..3596242 100644
--- a/bitbake/lib/bb/cache.py
+++ b/bitbake/lib/bb/cache.py
@@ -146,6 +146,9 @@ class CoreRecipeInfo(RecipeInfoCommon):
 self.fakerootenv  = self.getvar('FAKEROOTENV', metadata)
 self.fakerootdirs = self.getvar('FAKEROOTDIRS', metadata)
 self.fakerootnoenv= self.getvar('FAKEROOTNOENV', metadata)
+self.cdepends = self.depvar('CDEPENDS', metadata)
+self.task_cdepends= self.flaglist('cdepends', self.tasks, metadata, True)
+self.target_sys   = self.getvar('MULTIMACH_TARGET_SYS', metadata)
 
 @classmethod
 def init_cacheData(cls, cachedata):
@@ -172,6 +175,12 @@ class CoreRecipeInfo(RecipeInfoCommon):
 cachedata.rproviders = defaultdict(list)
 cachedata.packages_dynamic = defaultdict(list)
 
+cachedata.all_cdepends = []
+cachedata.compatible_deps = defaultdict(list)
+