Re: [yocto] [meta-raspberrypi][PATCH] u-boot: Simplify boot script

[Paul Barker]

On Wed,  2 Nov 2016 00:49:11 +1100
Jonathan Liu  wrote:

> device_tree_address=0x100 is set in config.txt so the firmware will
> load a patched device tree blob to 0x100 before passing control to
> U-Boot. The U-Boot script will then read the command line arguments
> generated by the firmware from the device tree and boot the kernel
> with the command line arguments and the loaded device tree.
> 
> This allows things like MAC address, board revision and serial number
> to be correctly configured and options in config.txt to be used.
> 
> Signed-off-by: Jonathan Liu 
> ---
>  recipes-bsp/bootfiles/rpi-config_git.bb| 5 +
>  recipes-bsp/rpi-u-boot-scr/files/boot.cmd  | 3 +++
>  recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd  | 6 --
>  recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd | 6 --
>  recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd | 6 --
>  recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd | 6 --
>  6 files changed, 8 insertions(+), 24 deletions(-)
>  create mode 100644 recipes-bsp/rpi-u-boot-scr/files/boot.cmd
>  delete mode 100644
> recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd delete mode
> 100644 recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd delete
> mode 100644 recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd
> delete mode 100644
> recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd
> 
> diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb
> b/recipes-bsp/bootfiles/rpi-config_git.bb index f610718..2f4d25c
> 100644 --- a/recipes-bsp/bootfiles/rpi-config_git.bb
> +++ b/recipes-bsp/bootfiles/rpi-config_git.bb
> @@ -76,6 +76,11 @@ do_deploy() {
>  echo "dispmanx_offline=1"
> >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt fi
>  
> +# U-Boot Device Tree support
> +if [ "${KERNEL_IMAGETYPE}" = "uImage" ]; then
> +sed -i '/#device_tree_address/ c\device_tree_address=0x100'
> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> +fi
> +
>  # SPI bus support
>  if [ -n "${ENABLE_SPI_BUS}" ] || [ "${PITFT}" = "1" ]; then
>  echo "# Enable SPI bus"
> >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt diff --git
> >>a/recipes-bsp/rpi-u-boot-scr/files/boot.cmd
> >>b/recipes-bsp/rpi-u-boot-scr/files/boot.cmd
> new file mode 100644
> index 000..3f7e3b6
> --- /dev/null
> +++ b/recipes-bsp/rpi-u-boot-scr/files/boot.cmd
> @@ -0,0 +1,3 @@
> +fdt addr ${fdt_addr_r} && fdt get value bootargs /chosen bootargs
> +fatload mmc 0:1 ${kernel_addr_r} uImage
> +bootm ${kernel_addr_r} - ${fdt_addr_r}
> diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd
> b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd deleted file
> mode 100644 index c86c758..000
> --- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -setenv fdtfile bcm2708-rpi-b.dtb
> -setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0
> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd' -mmc dev 0
> -fatload mmc 0:1 ${kernel_addr_r} uImage
> -fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
> -bootm ${kernel_addr_r} - ${fdt_addr_r}
> diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd
> b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd deleted file
> mode 100644 index c86c758..000
> --- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -setenv fdtfile bcm2708-rpi-b.dtb
> -setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0
> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd' -mmc dev 0
> -fatload mmc 0:1 ${kernel_addr_r} uImage
> -fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
> -bootm ${kernel_addr_r} - ${fdt_addr_r}
> diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd
> b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd deleted file
> mode 100644 index aa4ea64..000
> --- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -setenv fdtfile bcm2709-rpi-2-b.dtb
> -setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0
> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd' -mmc dev 0
> -fatload mmc 0:1 ${kernel_addr_r} uImage
> -fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
> -bootm ${kernel_addr_r} - ${fdt_addr_r}
> diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd
> b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd deleted file
> mode 100644 index 2950856..000
> --- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -setenv fdtfile bcm2710-rpi-3-b.dtb
> -setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0
> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd' -mmc dev 0
> -fatload mmc 0:1 ${kernel_addr_r} uImage
> -fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
> -bootm ${kernel_addr_r} - ${fdt_addr_r}

Looks like I missed the RaspberryPi Device Tree documentation
(https://www.raspberrypi.org/documentation/configuration/device-tree.md)
when putting my patches togethe

Re: [yocto] [meta-raspberrypi][PATCH] u-boot: Fix appending to RDEPENDS

[Paul Barker]

On Wed,  2 Nov 2016 00:46:47 +1100
Jonathan Liu  wrote:

> The += operator should not be used in combination with overrides as it
> will clear any existing values in the variable.
> 
> Example:
> FOO = "bar"
> FOO_rpi += "baz"
> 
> The above example would result in FOO being equal to " baz" instead of
> "bar baz".
> 
> The bbappend is changed to use a wildcard instead of a specific
> version to simplify updating U-Boot.
> 
> Signed-off-by: Jonathan Liu 
> ---
>  recipes-bsp/u-boot/u-boot_%.bbappend   | 1 +
>  recipes-bsp/u-boot/u-boot_2016.03.bbappend | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  create mode 100644 recipes-bsp/u-boot/u-boot_%.bbappend
>  delete mode 100644 recipes-bsp/u-boot/u-boot_2016.03.bbappend
> 
> diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend
> b/recipes-bsp/u-boot/u-boot_%.bbappend new file mode 100644
> index 000..3781666
> --- /dev/null
> +++ b/recipes-bsp/u-boot/u-boot_%.bbappend
> @@ -0,0 +1 @@
> +RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
> diff --git a/recipes-bsp/u-boot/u-boot_2016.03.bbappend
> b/recipes-bsp/u-boot/u-boot_2016.03.bbappend deleted file mode 100644
> index 35dfc37..000
> --- a/recipes-bsp/u-boot/u-boot_2016.03.bbappend
> +++ /dev/null
> @@ -1 +0,0 @@
> -RDEPENDS_${PN}_rpi += "rpi-u-boot-scr"

Looks good. Thanks for picking this up!

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

[yocto] [meta-raspberrypi][PATCH 0/1] linux-raspberrypi: remove not needed bundle_initramfs_append()

[piotr.lewicki]

This append is not needed anymore and it breaks the build for the people that 
use initramfs, because the path to
mkknlimg is wrong.

Resending again because it did not make into the master.

piotr.lewicki (1):
  linux-raspberrypi: remove not needed bundle_initramfs_append()

 recipes-kernel/linux/linux-raspberrypi.inc | 13 -
 1 file changed, 13 deletions(-)

-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH 1/1] linux-raspberrypi: remove not needed bundle_initramfs_append()

[piotr.lewicki]

---
 recipes-kernel/linux/linux-raspberrypi.inc | 13 -
 1 file changed, 13 deletions(-)

diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
b/recipes-kernel/linux/linux-raspberrypi.inc
index 6184402..98229d9 100644
--- a/recipes-kernel/linux/linux-raspberrypi.inc
+++ b/recipes-kernel/linux/linux-raspberrypi.inc
@@ -54,16 +54,3 @@ do_deploy_append() {
 fi
 echo "${CMDLINE}${PITFT_PARAMS}" > 
${DEPLOYDIR}/bcm2835-bootfiles/cmdline.txt
 }
-
-do_bundle_initramfs_append() {
-if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; then
-if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
-if test -n "${KERNEL_DEVICETREE}"; then
-# Add RPi bootloader trailer to kernel image to enable 
DeviceTree support
-for type in ${KERNEL_IMAGETYPES} ; do
-${STAGING_BINDIR_NATIVE}/mkknlimg --dtok 
${KERNEL_OUTPUT_DIR}/$type.initramfs ${KERNEL_OUTPUT_DIR}/$type.initramfs
-done
-fi
-fi
-fi
-}
-- 
2.7.4

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

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

[Joshua Lock]

On Tue, 2016-11-01 at 17:11 +, Burton, Ross wrote:
> 
> > > On 1 November 2016 at 17:05, Bas Mevissen 
wrote:
> > What are the criteria to call a distro supported?
> > 
> 
> > > The short version is that it's a distro that doesn't change too much,
is still supported, and we have builders on
autobuilder.yoctoproject.org running that distro.
> 
> The Centos mismatch is annoying, can you please file a bug?
> 

We previously had CentOS-7.* which was changed to CentOSLinux-7 in
meta-yocto ce1fe45e9a18a82e2b95ea7e0b088ba595c6.

What's going on here? Are CentOS really changing the value of their
Distributor ID for a released version?
Or is the issue here that they aren't using consistent values for
Distributor ID and its equivalent across /etc/lsb-release, /etc/redhat-
release, /etc/os-release and other potential sources?

Can someone with a CentOS 7 box pastebin their /etc/lsb-release,
/etc/redhat-release and /etc/os-release?

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

[yocto] How to create an user bsp based on a other meta bsp layer?

[S . Jaritz]

Hej

I want to create an own meta-bsp package for my custom mainboard based on 
an ATMEL SAMA5D35 SoC. For that I checked the documentation 
http://www.yoctoproject.org/docs/2.2/bsp-guide/bsp-guide.html#using-the-yocto-projects-bsp-tools
.

For me it is not clear how to create a bsp package based on the meta-atmel 
package. My goal is:

1.) use the SAMA5D35 SoC -> MACHINE ??= "sama5d3xek"
2.) append the device tree by adding: "mySAMA.dts" and "mySAMAmb.dtsi" 
(they use the dts files like #include "sama5d3.dtsi" from meta-atmel)
3.) adding my own defconfig for the kernel build
4.) change the configuration "at91bootstrap" which comes with the 
meta-atmel
5.) add some own SW packages

I created a working meta-mySAMA layer. It has grown over the time into 
some kind of meta-bsp. Think it would be nice to round everthing up by 
creating an own meta-bsp - to make it beautiful.

Is there a tutorial for that? Or can someone explan the steps form using 
"yocto-bsp create mySAMA "?

Regads!

Stefan


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 176
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] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

[Ionel Badisor]

On 10/22/2016 07:21 PM, Karim ATIKI wrote:

Hi Paul,


the compile log file is attached with this mail.





*De :* Paul Barker 
*Envoyé :* samedi 22 octobre 2016 17:26
*À :* Karim ATIKI
*Cc :* yocto
*Objet :* Re: [yocto] [raspberrypi3][meta-qt5] Failed to build
meta-toolchain-qt5

On Sat, 22 Oct 2016 15:16:18 +
Karim ATIKI  wrote:


Actually, it looks like the issue comes from gstreamer1.0-plugins-bad
recipe.


This function, graphics_get_display_size, comes from libbcm_host
which seems to be present in sysroot.


In log.doconfigure i found:


checking for bcm_host_init in -lbcm_host... yes
checking bcm_host.h usability... yes
checking bcm_host.h presence... yes
checking for bcm_host.h... yes

So it seems that it found the necessary library.


However, in the logfile of the compile error, there is no
"-lbcm_host" dependency at all.


Any idea to solve it ?



Could you post more of the compile log? It would be good to see the
full set of arguments being used for compiling/linking.

Thanks,
Paul




I stumble upon this issue before. My solution was to add
LDFLAGS += " -lbcm_host"
In a bbappend to gstreamer1.0-plugins-bad_%.bbappend in my layer




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

Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

[Karim ATIKI]

Hi Ionel,


I filed a bug-report for this concern.

Thanks for your feedback, I'll try it this afternoon..


Karim.



De : Ionel Badisor 
Envoyé : mercredi 2 novembre 2016 12:03
À : Karim ATIKI; Paul Barker
Cc : yocto
Objet : Re: [yocto] [raspberrypi3][meta-qt5] Failed to build meta-toolchain-qt5

On 10/22/2016 07:21 PM, Karim ATIKI wrote:
> Hi Paul,
>
>
> the compile log file is attached with this mail.
>
>
>
>
> 
> *De :* Paul Barker 
> *Envoyé :* samedi 22 octobre 2016 17:26
> *À :* Karim ATIKI
> *Cc :* yocto
> *Objet :* Re: [yocto] [raspberrypi3][meta-qt5] Failed to build
> meta-toolchain-qt5
>
> On Sat, 22 Oct 2016 15:16:18 +
> Karim ATIKI  wrote:
>
>> Actually, it looks like the issue comes from gstreamer1.0-plugins-bad
>> recipe.
>>
>>
>> This function, graphics_get_display_size, comes from libbcm_host
>> which seems to be present in sysroot.
>>
>>
>> In log.doconfigure i found:
>>
>>
>> checking for bcm_host_init in -lbcm_host... yes
>> checking bcm_host.h usability... yes
>> checking bcm_host.h presence... yes
>> checking for bcm_host.h... yes
>>
>> So it seems that it found the necessary library.
>>
>>
>> However, in the logfile of the compile error, there is no
>> "-lbcm_host" dependency at all.
>>
>>
>> Any idea to solve it ?
>>
>
> Could you post more of the compile log? It would be good to see the
> full set of arguments being used for compiling/linking.
>
> Thanks,
> Paul
>
>

I stumble upon this issue before. My solution was to add
LDFLAGS += " -lbcm_host"
In a bbappend to gstreamer1.0-plugins-bad_%.bbappend in my layer




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

[yocto] LXC container: opkg_install_cmd: Cannot install package cmocka

[Dinh Nguyen (dinhn)]

Folks,

I am trying to bring the cmocka recipe our IOX SDK Yocto. Cmocka is a fork for 
Googles cmockery unit testing framework to fix bugs.

I am able to compile and build IPK packages for cmocka without any issue.
But during creating the LXC container which including the cmocka,  
opkg_install_cmd can install and configure other recipes  but can’t install 
package cmocka as shown below in the “red”

There is no details info on why it can’t install the package or what is the 
problem. Have anyone encountered this issue and how to solve it? Many thanks in 
advance.
…
Configuring libmodbus5.
Configuring initscripts.
Configuring libboost-graph1.56.0.
Configuring boost-serialization.
Configuring libboost-program-options1.56.0.
Configuring opkg-collateral.
Configuring boost-test.
Configuring libzlog1.2.
Configuring poky-feed-config-opkg.
Configuring libboost-filesystem1.56.0.
Configuring base-passwd.
Configuring packagegroup-core-boot.
Configuring libboost-signals1.56.0.
Configuring libz1.
Configuring libboost-iostreams1.56.0.
Configuring boost.
Configuring libjansson4.
Configuring libuv1.
Collected errors:
 * opkg_install_cmd: Cannot install package cmocka.

DEBUG: Python function do_rootfs finished
ERROR: Function failed: do_rootfs

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

[yocto] [sstate-cache] using sstate-cache in parallel builds

[Chris Z.]

Hi,

Is it secure to use in parallel sstate-cache for building images for
different target machines ?

Br,
Chris Z.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] LXC container: opkg_install_cmd: Cannot install package cmocka

[Dinh Nguyen (dinhn)]

Thanks — Got it.

—Dinh

From: dinhn mailto:di...@cisco.com>>
Date: Wednesday, November 2, 2016 at 6:20 AM
To: "yocto@yoctoproject.org" 
mailto:yocto@yoctoproject.org>>
Cc: dinhn mailto:di...@cisco.com>>
Subject: LXC container: opkg_install_cmd: Cannot install package cmocka


Folks,

I am trying to bring the cmocka recipe our IOX SDK Yocto. Cmocka is a fork for 
Googles cmockery unit testing framework to fix bugs.

I am able to compile and build IPK packages for cmocka without any issue.
But during creating the LXC container which including the cmocka,  
opkg_install_cmd can install and configure other recipes  but can’t install 
package cmocka as shown below in the “red”

There is no details info on why it can’t install the package or what is the 
problem. Have anyone encountered this issue and how to solve it? Many thanks in 
advance.
…
Configuring libmodbus5.
Configuring initscripts.
Configuring libboost-graph1.56.0.
Configuring boost-serialization.
Configuring libboost-program-options1.56.0.
Configuring opkg-collateral.
Configuring boost-test.
Configuring libzlog1.2.
Configuring poky-feed-config-opkg.
Configuring libboost-filesystem1.56.0.
Configuring base-passwd.
Configuring packagegroup-core-boot.
Configuring libboost-signals1.56.0.
Configuring libz1.
Configuring libboost-iostreams1.56.0.
Configuring boost.
Configuring libjansson4.
Configuring libuv1.
Collected errors:
 * opkg_install_cmd: Cannot install package cmocka.

DEBUG: Python function do_rootfs finished
ERROR: Function failed: do_rootfs

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

[yocto] First release meta-arduino layer for the Arduino Yún

[Beth 'pidge' Flanagan]

Hi all,

A few weeks ago at ELCE, Paul Barker and I decided to create a layer
for the Arduino Yún. We are now releasing the 0.1 version for Morty to
the wider community. Patches welcome of course.

-b



Hello,

We are pleased to announce the 0.1 release of our meta-arduino layer
for the Yocto Porject 2.2 "Morty" release.

It is available for download at:

https://www.toganlabs.com/downloads/bsp/meta-arduino/0.1/meta-arduino-0
.1-morty-2.2.tar.bz

or via github at:

https://github.com/toganlabs/meta-arduino


Name: https://www.toganlabs.com/downloads/bsp/meta-arduino/0.1/meta-ard
uino-0.1-morty-2.2.tar.bz
Hash: 20c65dee2d091f4f5797c869720ad339aca96f49
Tag: 0.1-morty
md5sum: 882fa547011fad0530978f4496ca2f3f
sha256sum:
cc0a72a4e90b6423e7cc1cb93f47f742d001b2276640d5577170dbb3a3eff2a3

This OpenEmbedded BSP layer supports the Arduino Yún board and is based
on previous work from OpenWRT.

Future support is planned for the Arduino Industrial 101 board and the
Arduino Yún Shield.

Maintainers:

Beth 'pidge' Flanagan pi...@toganlabs.com
Paul Barker p...@paulbarker.me.uk
Primary repository: https://github.com/toganlabs/meta-arduino

Please send any questions and patches to the yocto@yoctoproject.org
mailing list with "[meta-arduino]" 
in the subject.

We are not associated with Arduino LLC in any way. This is solely a
community supported alternative to the LininoOS OpenWRT based solution.
Support requests and bug reports should go directly to the maintainers
and not the nice folks at Arduino.

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

Re: [yocto] [sstate-cache] using sstate-cache in parallel builds

[Burton, Ross]

On 2 November 2016 at 13:36, Chris Z.  wrote:

> Is it secure to use in parallel sstate-cache for building images for
> different target machines ?
>

Short answer: yes.

The hashes will be different so there's no risk of conflicting files for
the target, so it's only native recipes that may conflict.  The worst case
situation here in two parallel builds is that they'll both build the same
recipe and put it into sstate, there isn't any risk of corruption.

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

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

[Daniel.]

2016-11-01 21:35 GMT-02:00 Khem Raj :

>
> On Nov 1, 2016, at 4:22 PM, Burton, Ross  wrote:
>
>
> On 1 November 2016 at 22:20, Daniel.  wrote:
>
>> Just as a note, I've been using archlinux for about a year and have never
>> faced "distro related problems", except when the gcc6 comes out. Anyway I'm
>> using daisy in my work. I think that making old releases supported by X
>> distro doesn't make any sense...
>>
>
> The supported list of distros is just the list of distros that are known
> to work, and if something breaks then we'll notice and fix it.  If you want
> to use arch and face the periodic problems such as new toolchain meaning
> you can't build gcc-cross, then go for it.
>
>
> Another option perhaps is to use a debian stable container with docker (
> https://hub.docker.com/r/cbrake/oe-build/)
> and you can use your favorite distro for stuff you usually do and at same
> time let OE/YP build on  a known/supported distro e.g.
> Its a bit of mind shift but I am happily using it, while my distro stays
> bleeding edge arch.
>
> e.g. see
>
> http://bec-systems.com/site/1281/using-docker-for-oeyocto-builds
>
>
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
I'm planning to move to ubuntu 16.04 as I have in home, since I'm something
like tired of reading the words "not supported" .. but I have a lot of work
to do before I can format my machine there... So, it will be arch :)

I was just notifying that I have never had problems with arch being "not
supported". The packages needed there, and the ones that can't be found at
binary repos can be found at AUR, so, arch works just fine.

Regards,

-- 
*"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 2.2 Morty supported Linux Distros

[Burton, Ross]

On 2 November 2016 at 14:21, Daniel.  wrote:

> I'm planning to move to ubuntu 16.04 as I have in home, since I'm
> something like tired of reading the words "not supported" .. but I have a
> lot of work to do before I can format my machine there... So, it will be
> arch :)
>

Ubuntu 16.04 is supported, the documentation is wrong and will be fixed.
Arch is not, and never will be.

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

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

[Bas Mevissen]

On 02/11/16 11:05, Joshua Lock wrote:


Can someone with a CentOS 7 box pastebin their /etc/lsb-release,
/etc/redhat-release and /etc/os-release?



/etc/lsb-release not available


At launch (1406):

/etc/redhat-release (link to /etc/centos-release):
CentOS Linux release 7.2.1406 (Core)

/etc/os-release:
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/";
BUG_REPORT_URL="https://bugs.centos.org/";



Currently (1511):

/etc/redhat-release (link to /etc/centos-release):
CentOS Linux release 7.2.1511 (Core)

/etc/os-release:
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/";
BUG_REPORT_URL="https://bugs.centos.org/";

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

So it seems to me that things have not changed in an unexpected way.

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

Re: [yocto] how to copy a tar file to Root file system

[Swapna.Gurumani]

Hi Danile,
Thank you so much for your help. My .bb file now looks like as attached. Did 
your tar file have .a and .so?? I am getting errors because of them. Can I 
force the do_package_qa to skip?
Thanks,
Regards
Swapna

From: Daniel. [mailto:danielhi...@gmail.com]
Sent: Tuesday, November 01, 2016 1:18 PM
To: Paul Eggleton 
Cc: Swapna Gurumani - C40450 ; 
yocto@yoctoproject.org
Subject: Re: [yocto] how to copy a tar file to Root file system

I have an example of a recipe exploding a tar here: 
https://gist.github.com/gkos/02eccb8e1e02312327aa6db6cdc9d501
The tar is used as a source. So the bitbake explodes it to ${WORKDIR} and I 
simply copy it to /opt
I hope that this helps :)
Regards,

2016-11-01 18:00 GMT-02:00 Paul Eggleton 
mailto:paul.eggle...@linux.intel.com>>:
On Tue, 01 Nov 2016 18:45:02 
swapna.gurum...@microchip.com wrote:
> Every step I take close, I take 2 back :(
> My bb now looks like the one attached. I had to add each folder for
> FILES_${PN} contrary to your advice otherwise I got the following error:
> ERROR: crank-1.0-r2 do_package: QA Issue: crank: Files/directories were
> installed but not shipped in any package: /opt
>   /opt/crank
> Please set FILES such that these items are packaged. Alternatively if they
> are unneeded, avoid installing them or delete them within do_install.
> crank: 2 installed and not shipped files. [installed-vs-shipped]
>
>
>
> I am now getting the following error:
> ERROR: crank-1.0-r2 do_install: Function failed: do_install (log file is
> located at
> /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-neon
> -poky-linux-gnueabi/crank/1.0-r2/temp/log.do_install.26457) ERROR: Logfile
> of failure stored in:
> /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-neon
> -poky-linux-gnueabi/crank/1.0-r2/temp/log.do_install.26457
> Log data follows:
> | DEBUG: Executing shell function do_install
> | cp: cannot stat
> | '/home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-n
> | eon-poky-linux-gnueabi/crank/1.0-r2/crank': No such file or directory
> | WARNING:
> | /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-ne
> | on-poky-linux-gnueabi/crank/1.0-r2/temp/run.do_install.26457:1 exit 1 from
> | 'cp -a --no-preserve=ownership
> | /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-ne
> | on-poky-linux-gnueabi/crank/1.0-r2/crank
> | /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-ne
> | on-poky-linux-gnueabi/crank/1.0-r2/image/opt/' ERROR: Function failed:
> | do_install (log file is located at
> | /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-ne
> | on-poky-linux-gnueabi/crank/1.0-r2/temp/log.do_install.26457)
> ERROR: Task 1082
> (/home/swapna/workspace/work/yocto/meta-atmel/qt5-layer/recipes-qt/apps/cra
> nk_1.0.bb, do_install) failed with exit code '1' NOTE: 
> Tasks Summary:
> Attempted 3806 tasks of which 3805 didn't need to be rerun and 1 failed. No
> currently running tasks (3034 of 4662)
>
> Summary: 1 task failed:
>
> /home/swapna/workspace/work/yocto/meta-atmel/qt5-layer/recipes-qt/apps/cran
> k_1.0.bb, do_install Summary: There was 1 WARNING message 
> shown.
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
>
>
> Also if I look into the
> /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-neon-
> poky-linux-gnueabi/crank/1.0-r2 It is empty.

There's something strange going on here, because the path you have just given
is ${WORKDIR} - and that shouldn't be able to be empty at this point. If
nothing else there should be a "temp" directory under it containing logs if
*any* tasks have run. Surely you have skipped out some steps between when it
was working and now? I notice the tarball name changed - did you regenerate it
or just rename it?

In any case, when debugging situations like this it helps to make a fresh
start - run "bitbake -c clean crank" (you don't need -c cleansstate because
being stuck at do_install you haven't got to any real sstate tasks yet). Then
methodically run through each task - when do_unpack ran what got unpacked into
${WORKDIR}? If that's as expected, what got put into ${D} (which is the
"image" subdirectory under ${WORKDIR})? Does what's in ${D} match up with the
layout you expect to be on the target? At any time you can use
"bitbake -e crank | less" to inspect the value of variables. You can also see
exactly what commands got run within the task by looking at the run.do_* files
under "temp" in the workdir.

Also:

* That third line "install -m ..." you now have in do_install won't work and
in any case isn't necessary since you are already copying that with the cp
command.

* Based on what you've said earlier, your S value cannot be correct - it may
not matter, but it might as well be fixed anyway. If the tarball unpacks a
"crank" subdirectory then it should be set to 

Re: [yocto] how to copy a tar file to Root file system

[Burton, Ross]

On 2 November 2016 at 20:00,  wrote:

> Thank you so much for your help. My .bb file now looks like as attached.
> Did your tar file have .a and .so?? I am getting errors because of them.
> Can I force the do_package_qa to skip?
>
>
You might find this document useful:
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries

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

Re: [yocto] how to copy a tar file to Root file system

[Swapna.Gurumani]

> 
> Also if I look into the
> /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf
> -neon-
> poky-linux-gnueabi/crank/1.0-r2 It is empty.

There's something strange going on here, because the path you have just given 
is ${WORKDIR} - and that shouldn't be able to be empty at this point. If 
nothing else there should be a "temp" directory under it containing logs if
*any* tasks have run. Surely you have skipped out some steps between when it 
was working and now? I notice the tarball name changed - did you regenerate it 
or just rename it?

Answer>> I renamed it. For some reason it was. But now its populated with lot 
of stuff including the crank folder, temp, image etc..


In any case, when debugging situations like this it helps to make a fresh start 
- run "bitbake -c clean crank" (you don't need -c cleansstate because being 
stuck at do_install you haven't got to any real sstate tasks yet). Then 
methodically run through each task - when do_unpack ran what got unpacked into 
${WORKDIR}? If that's as expected, what got put into ${D} (which is the "image" 
subdirectory under ${WORKDIR})? Does what's in ${D} match up with the layout 
you expect to be on the target? At any time you can use "bitbake -e crank | 
less" to inspect the value of variables. You can also see exactly what commands 
got run within the task by looking at the run.do_* files under "temp" in the 
workdir.
 
ANSWER >> All this looks good. The run.do* files don't show much. Although, why 
am I seeing stuff like:
NOTE: arm-poky-linux-gnueabi-objdump -p 
/home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-neon-poky-linux-gnueabi/crank/1.0-r0/packages-split/crank/opt/crank/linux-sama5d-armle-fbdev-obj/lib/luagretest.so

In log.do_package_qa?


* Based on what you've said earlier, your S value cannot be correct - it may 
not matter, but it might as well be fixed anyway. If the tarball unpacks a 
"crank" subdirectory then it should be set to "${WORKDIR}/crank".

ANSWER >> I get the same error no matter what the S is set to:
non -staticdev package contains static .a library: crank path 
'work/cortexa5hf-neon-poky-linux-gnueabi/crank/1.0-r0/packages-split/crank/opt/crank/linux-sama5d-armle-fbdev-obj/lib/libssgf.a'
 [staticdev]


WHY am I getting this error?


* Setting DEPENDS isn't really doing you any good - DEPENDS is for build-time 
dependencies. You're only unpacking a tarball, you don't need any build-time 
dependencies to speak of. If you have runtime dependencies then set them in 
RDEPENDS_${PN} since that's where runtime dependencies need to be set.

ANSWER>> without that line, I get the following error:

WARNING: crank-1.0-r0 do_package_qa: QA Issue: crank rdepends on tslib, but it 
isn't a build dependency, missing tslib in DEPENDS or PACKAGECONFIG? 
[build-deps]
WARNING: crank-1.0-r0 do_package_qa: QA Issue: crank rdepends on libasound, but 
it isn't a build dependency, missing alsa-lib in DEPENDS or PACKAGECONFIG? 
[build-deps]


* As another responder pointed out, the inherit of pkgconfig isn't needed - you 
don't need pkg-config for anything being done here.
Again, same error with or without this. Or even if I use " inherit bin_package"



Cheers,
Paul

-- 

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

Re: [yocto] how to copy a tar file to Root file system

[Swapna.Gurumani]

Thank you to Paul Eggleton, Daniel and Ross Burton.
I was able to solve by miseries by adding the following line to my miseries:

FILES_${PN}-staticdev = "/opt/crank/linux-sama5d-armle-fbdev-obj/lib/*.a"

Ref:
http://stackoverflow.com/questions/28792597/how-to-add-a-new-library-using-yocto
Regards

Swapna
From: Daniel. [mailto:danielhi...@gmail.com]
Sent: Tuesday, November 01, 2016 1:18 PM
To: Paul Eggleton 
Cc: Swapna Gurumani - C40450 ; 
yocto@yoctoproject.org
Subject: Re: [yocto] how to copy a tar file to Root file system

I have an example of a recipe exploding a tar here: 
https://gist.github.com/gkos/02eccb8e1e02312327aa6db6cdc9d501
The tar is used as a source. So the bitbake explodes it to ${WORKDIR} and I 
simply copy it to /opt
I hope that this helps :)
Regards,

2016-11-01 18:00 GMT-02:00 Paul Eggleton 
mailto:paul.eggle...@linux.intel.com>>:
On Tue, 01 Nov 2016 18:45:02 
swapna.gurum...@microchip.com wrote:
> Every step I take close, I take 2 back :(
> My bb now looks like the one attached. I had to add each folder for
> FILES_${PN} contrary to your advice otherwise I got the following error:
> ERROR: crank-1.0-r2 do_package: QA Issue: crank: Files/directories were
> installed but not shipped in any package: /opt
>   /opt/crank
> Please set FILES such that these items are packaged. Alternatively if they
> are unneeded, avoid installing them or delete them within do_install.
> crank: 2 installed and not shipped files. [installed-vs-shipped]
>
>
>
> I am now getting the following error:
> ERROR: crank-1.0-r2 do_install: Function failed: do_install (log file is
> located at
> /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-neon
> -poky-linux-gnueabi/crank/1.0-r2/temp/log.do_install.26457) ERROR: Logfile
> of failure stored in:
> /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-neon
> -poky-linux-gnueabi/crank/1.0-r2/temp/log.do_install.26457
> Log data follows:
> | DEBUG: Executing shell function do_install
> | cp: cannot stat
> | '/home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-n
> | eon-poky-linux-gnueabi/crank/1.0-r2/crank': No such file or directory
> | WARNING:
> | /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-ne
> | on-poky-linux-gnueabi/crank/1.0-r2/temp/run.do_install.26457:1 exit 1 from
> | 'cp -a --no-preserve=ownership
> | /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-ne
> | on-poky-linux-gnueabi/crank/1.0-r2/crank
> | /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-ne
> | on-poky-linux-gnueabi/crank/1.0-r2/image/opt/' ERROR: Function failed:
> | do_install (log file is located at
> | /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-ne
> | on-poky-linux-gnueabi/crank/1.0-r2/temp/log.do_install.26457)
> ERROR: Task 1082
> (/home/swapna/workspace/work/yocto/meta-atmel/qt5-layer/recipes-qt/apps/cra
> nk_1.0.bb, do_install) failed with exit code '1' NOTE: 
> Tasks Summary:
> Attempted 3806 tasks of which 3805 didn't need to be rerun and 1 failed. No
> currently running tasks (3034 of 4662)
>
> Summary: 1 task failed:
>
> /home/swapna/workspace/work/yocto/meta-atmel/qt5-layer/recipes-qt/apps/cran
> k_1.0.bb, do_install Summary: There was 1 WARNING message 
> shown.
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
>
>
> Also if I look into the
> /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-neon-
> poky-linux-gnueabi/crank/1.0-r2 It is empty.

There's something strange going on here, because the path you have just given
is ${WORKDIR} - and that shouldn't be able to be empty at this point. If
nothing else there should be a "temp" directory under it containing logs if
*any* tasks have run. Surely you have skipped out some steps between when it
was working and now? I notice the tarball name changed - did you regenerate it
or just rename it?

In any case, when debugging situations like this it helps to make a fresh
start - run "bitbake -c clean crank" (you don't need -c cleansstate because
being stuck at do_install you haven't got to any real sstate tasks yet). Then
methodically run through each task - when do_unpack ran what got unpacked into
${WORKDIR}? If that's as expected, what got put into ${D} (which is the
"image" subdirectory under ${WORKDIR})? Does what's in ${D} match up with the
layout you expect to be on the target? At any time you can use
"bitbake -e crank | less" to inspect the value of variables. You can also see
exactly what commands got run within the task by looking at the run.do_* files
under "temp" in the workdir.

Also:

* That third line "install -m ..." you now have in do_install won't work and
in any case isn't necessary since you are already copying that with the cp
command.

* Based on what you've said earlier, your S value cannot be correct - it may
not matter, but it might as well be 

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

[Joshua Lock]

On Wed, 2016-11-02 at 17:41 +0100, Bas Mevissen wrote:
> On 02/11/16 11:05, Joshua Lock wrote:
> 
> > 
> > Can someone with a CentOS 7 box pastebin their /etc/lsb-release,
> > /etc/redhat-release and /etc/os-release?
> > 
> 
> /etc/lsb-release not available
> 
> 
> At launch (1406):
> 
> /etc/redhat-release (link to /etc/centos-release):
> CentOS Linux release 7.2.1406 (Core)
> 
> /etc/os-release:
> NAME="CentOS Linux"
> VERSION="7 (Core)"
> ID="centos"
> ID_LIKE="rhel fedora"
> VERSION_ID="7"
> PRETTY_NAME="CentOS Linux 7 (Core)"
> ANSI_COLOR="0;31"
> CPE_NAME="cpe:/o:centos:centos:7"
> HOME_URL="https://www.centos.org/";
> BUG_REPORT_URL="https://bugs.centos.org/";
> 
> 
> 
> Currently (1511):
> 
> /etc/redhat-release (link to /etc/centos-release):
> CentOS Linux release 7.2.1511 (Core)
> 
> /etc/os-release:
> NAME="CentOS Linux"
> VERSION="7 (Core)"
> ID="centos"
> ID_LIKE="rhel fedora"
> VERSION_ID="7"
> PRETTY_NAME="CentOS Linux 7 (Core)"
> ANSI_COLOR="0;31"
> CPE_NAME="cpe:/o:centos:centos:7"
> HOME_URL="https://www.centos.org/";
> BUG_REPORT_URL="https://bugs.centos.org/";
> 
> CENTOS_MANTISBT_PROJECT="CentOS-7"
> CENTOS_MANTISBT_PROJECT_VERSION="7"
> REDHAT_SUPPORT_PRODUCT="centos"
> REDHAT_SUPPORT_PRODUCT_VERSION="7"
> 
> So it seems to me that things have not changed in an unexpected way.

Thank you! Any chance you can share the output of `lsb_release -ir`
also?

Regards,

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

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

[Trevor Woerner]

On 11/01/2016 11:27 AM, Burton, Ross wrote:
Scott, can you update the list at 
http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#detailed-supported-distros 
so that it reflects the list in the code:


SANITY_TESTED_DISTROS ?= " \
poky-1.8 \n \
poky-2.0 \n \
poky-2.1 \n \
poky-2.2 \n \
Ubuntu-14.04 \n \
Ubuntu-14.10 \n \
Ubuntu-15.04 \n \
Ubuntu-15.10 \n \
Ubuntu-16.04 \n \
Fedora-22 \n \
Fedora-23 \n \
Fedora-24 \n \
CentOSLinux-7.* \n \
Debian-8.* \n \
openSUSE-13.2 \n \
SUSELINUX-42.1 \n \
"


The website also needs to list openSUSE 42.1 (Leap). Thanks!
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi3] Failed to build gstreamer1.0-plugins-bad with minimal configuration

[Khem Raj]

Can you test this patch here


https://github.com/kraj/meta-raspberrypi/commit/73be88cec27bb3b9d52d7782bd82c60395626abd.patch

and let me know if it fixes your issue ?


On Tue, Nov 1, 2016 at 11:51 AM, Karim ATIKI  wrote:
> Hi Paul,
>
>
> Thanks for your feedback.
>
> Unfortunately I was suspecting such a problem.
>
>
> Regarding the config below, is it possible to install the
> "dispmanx"component to activate EGL ?
>
>
> What recipe provides dispmanx ?
>
>
> Karim
>
>
>
>
>
> 
> De : Paul Barker 
> Envoyé : samedi 29 octobre 2016 23:13
> À : Karim ATIKI
> Cc : yocto
> Objet : Re: [yocto] [meta-raspberrypi3] Failed to build
> gstreamer1.0-plugins-bad with minimal configuration
>
> On Fri, 28 Oct 2016 05:56:07 +
> Karim ATIKI  wrote:
>
>> Hi Paul,
>>
>>
>> Thanks a lot for your feedback and analysis.
>>
>> I think it sohuld compile without X11 and Wayland as it's a very
>> common configuration
>>
>> for RaspberryPi being used with Qt5.x applications.
>>
>>
>> Do you think it's bug related to Gstreamer1.0 configuration ?
>>
>>
>>
>> Karim
>>
>
> The do_configure log for gstreamer1.0-plugins-bad does contain:
>
> configure: WARNING: X or Wayland is required for OpenGL support
>
> configure.ac in gst-plugins-bad-1.8.3 contains:
>
> dnl EGL
> if test "x$HAVE_EGL" = "xno"; then
>   if test "x$HAVE_GL" = "xno"; then
> AC_MSG_WARN([Building requires either EGL or GLX for OpenGL
> support])
>   fi
> else
>   if test "x$NEED_EGL" != "xno"; then
> if test "x$HAVE_WINDOW_WAYLAND" = "xyes" -o "x$HAVE_WINDOW_X11" =
> "xyes" -o "x$HAVE_WINDOW_DISPMANX" = "xyes"; then
>   GL_LIBS="$GL_LIBS -lEGL $EGL_LIBS"
>   GL_CFLAGS="$GL_CFLAGS $EGL_CFLAGS"
>   USE_EGL=yes
> fi
>   fi
> fi
> ;;
>
> In config.status EGL_LIBS contains "-lbcm_host -lvcos
> -lvchiq_arm", however GL_LIBS only contains "-lGLESv2". So I'd say
> EGL_LIBS is not being included in to GL_LIBS because
> HAVE_WINDOW_WAYLAND, HAVE_WINDOW_X11 and HAVE_WINDOW_DISPMAX are all
> false.
>
> GL_LIBS is used in gst-libs/gst/gl/Makefile.am so that's the variable
> the libraries should be listed in.
>
> I'd say that's an upstream issue - it really looks like it's demanding
> X or Wayland to be enabled for OpenGL to work. I'd suggest raising the
> issue upsteream.
>
> Thanks,
> Paul Barker
>
> --
> ___
> 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] How do I used Yocto to build an sdcard image for my Raspberry Pi 3 Model B?

[Thomas A. F. Thorne MEng AUS MIET]

I was starting to look at using Yocto  as
a system for building software images for the Raspberry Pi 3 Model B
that I have. I wanted to try using Yocto as there are some projects at
my office that may begin using it in the future. One of the nice points
is that all the setup of cross compilers for your target system is
handled by a Yocto layer. There is already a Yocto layer for the
Raspberry Pi
(meta-raspberrypi
) and a
custom meta-rpi  layer someone has
put together with a few more example images.

I need to either cross-compile kernel modules or use Yocto as I have
special drivers I wish to add to the Pi. These are already compiled and
working on my Ubuntu PC and I hoped using Yocto might make it easy to
cross compile these and any other updates in the future.

My difficulty is that the SD Card image talked about in
the meta-raspberrypi documentation
 and
several tutorials, never gets generated, even on successful builds.


Tutorials Mentioning The Use Of |dd| & An .sdimg File

  * Build a Raspberry Pi 2 Minimal Image with The Yocto Project


  * Building Raspberry Pi Systems with Yocto

  * 12MB Minimal Image for Raspberry Pi using the Yocto Project


  * Poky Raspberry Pi SD Card Image



Commonly Seen Error

None of the builds I have made so far generate .sdimg files. When I try
to add the |sdcard| or |sdcard_image-rpi| image types to IMAGE_FSTYPES I
get messages such as:

|ERROR:
/home/thomasthorne/work/yocto-rpi/meta-raspberrypi/recipes-core/images/rpi-test-image.bb:
No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdcard_image-rpi' -
possibly invalid type name or missing support class |


Main Questions

/How do I generate the SD card image for my Pi from Yocto?/

Do I need to format the SD card manually and copy over the contents bit
by bit?

Why do all these tutorials suggest it would be as simple as a
single |dd| command? I guess something changed in the last couple of
years and they are all out of date.


This was also posted at
http://raspberrypi.stackexchange.com/questions/57155/how-do-i-used-yocto-to-build-an-sdcard-image-for-my-raspberry-pi-3-model-b
before I realised it is probably more of a Yocto question than a
Raspberry Pi one. 

I will be very grateful of any help or advice you can offer.  Even an
explanation of when the generation of SD card images was dropped from
the Yocto Project would be very helpful. 

Regards,

-- 
Thomas A. F. Thorne MEng. AUS MIET
*Software Engineer*

*NET2EDGE*

Tel: +44 3450 130 030 
Email: thomas.tho...@net2edge.com 
Web: http://www.Net2Edge.com/ 

Net2Edge Limited is a company registered in England & Wales (Company No.
2438435, VAT No. GB 537553821) Passfield Oak, Liphook, Hampshire, GU30
7RL. This email transmission is confidential and intended solely for the
person or organisation to whom it is addressed. If you are not the
intended recipient, you must not copy, distribute or disseminate the
information, or take any action in reliance of it. Any views expressed
in this message are those of the individual sender, except where the
sender specifically states them to be the views of any organisation or
employer. If you have received this message in error, do not open any
attachment but please notify the sender (above) and delete this message
from your system. Please rely on your own virus check. Although all
outbound mail is checked for viruses, no responsibility is taken by the
sender for any damage rising out of any bug or virus infection.



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

Re: [yocto] How do I used Yocto to build an sdcard image for my Raspberry Pi 3 Model B?

[Khem Raj]

Do you see an image with .rpi-sdimg in deploy/images/raspberrypi3

 % ls *.rpi-sdimg
rpi-hwup-image-raspberrypi3-20161103050832.rootfs.rpi-sdimg
rpi-hwup-image-raspberrypi3.rpi-sdimg@

Thats the one you should be able to dd

> On Nov 2, 2016, at 6:10 AM, Thomas A. F. Thorne MEng AUS MIET 
>  wrote:
> 
> I was starting to look at using Yocto  as a 
> system for building software images for the Raspberry Pi 3 Model B that I 
> have. I wanted to try using Yocto as there are some projects at my office 
> that may begin using it in the future. One of the nice points is that all the 
> setup of cross compilers for your target system is handled by a Yocto layer. 
> There is already a Yocto layer for the Raspberry Pi 
> (meta-raspberrypi
>  ) and a custom 
> meta-rpi  layer someone has put together 
> with a few more example images.
> 
> I need to either cross-compile kernel modules or use Yocto as I have special 
> drivers I wish to add to the Pi. These are already compiled and working on my 
> Ubuntu PC and I hoped using Yocto might make it easy to cross compile these 
> and any other updates in the future.
> 
> My difficulty is that the SD Card image talked about in the meta-raspberrypi 
> documentation 
>  and 
> several tutorials, never gets generated, even on successful builds.
> 
> Tutorials Mentioning The Use Of dd & An .sdimg File
> 
> Build a Raspberry Pi 2 Minimal Image with The Yocto Project 
> 
> Building Raspberry Pi Systems with Yocto 
> 
> 12MB Minimal Image for Raspberry Pi using the Yocto Project 
> 
> Poky Raspberry Pi SD Card Image 
> 
> Commonly Seen Error
> 
> None of the builds I have made so far generate .sdimg files. When I try to 
> add the sdcard or sdcard_image-rpi image types to IMAGE_FSTYPES I get 
> messages such as:
> 
> ERROR: 
> /home/thomasthorne/work/yocto-rpi/meta-raspberrypi/recipes-core/images/rpi-test-image.bb:
>  No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdcard_image-rpi' - possibly 
> invalid type name or missing support class
> Main Questions
> 
> How do I generate the SD card image for my Pi from Yocto?
> 
> Do I need to format the SD card manually and copy over the contents bit by 
> bit?
> 
> Why do all these tutorials suggest it would be as simple as a single dd 
> command? I guess something changed in the last couple of years and they are 
> all out of date.
> 
> 
> This was also posted at 
> http://raspberrypi.stackexchange.com/questions/57155/how-do-i-used-yocto-to-build-an-sdcard-image-for-my-raspberry-pi-3-model-b
>  
> before
>  I realised it is probably more of a Yocto question than a Raspberry Pi one.
> I will be very grateful of any help or advice you can offer.  Even an 
> explanation of when the generation of SD card images was dropped from the 
> Yocto Project would be very helpful.
> Regards,
> --
> Thomas A. F. Thorne MEng. AUS MIET
> Software Engineer
> 
> NET2EDGE
> 
> Tel: +44 3450 130 030 
> Email: thomas.tho...@net2edge.com 
> Web: http://www.Net2Edge.com/ 
> 
> Net2Edge Limited is a company registered in England & Wales (Company No. 
> 2438435, VAT No. GB 537553821) Passfield Oak, Liphook, Hampshire, GU30 7RL. 
> This email transmission is confidential and intended solely for the person or 
> organisation to whom it is addressed. If you are not the intended recipient, 
> you must not copy, distribute or disseminate the information, or take any 
> action in reliance of it. Any views expressed in this message are those of 
> the individual sender, except where the sender specifically states them to be 
> the views of any organisation or employer. If you have received this message 
> in error, do not open any attachment but please notify the sender (above) and 
> delete this message from your system. Please rely on your own virus check. 
> Although all outbound mail is checked for viruses, no responsibility is taken 
> by the sender for any damage rising out of any bug or virus infection.
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yoct

Re: [yocto] [meta-raspberrypi][PATCH 1/1] linux-raspberrypi: remove not needed bundle_initramfs_append()

[Khem Raj]

> On Nov 2, 2016, at 2:52 AM, piotr.lewicki  wrote:
> 
> ---
> recipes-kernel/linux/linux-raspberrypi.inc | 13 -
> 1 file changed, 13 deletions(-)
> 
> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
> b/recipes-kernel/linux/linux-raspberrypi.inc
> index 6184402..98229d9 100644
> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> @@ -54,16 +54,3 @@ do_deploy_append() {
> fi
> echo "${CMDLINE}${PITFT_PARAMS}" > 
> ${DEPLOYDIR}/bcm2835-bootfiles/cmdline.txt
> }
> -
> -do_bundle_initramfs_append() {
> -if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; 
> then
> -if test "x${KERNEL_IMAGETYPE}" != "xuImage" ; then
> -if test -n "${KERNEL_DEVICETREE}"; then
> -# Add RPi bootloader trailer to kernel image to enable 
> DeviceTree support
> -for type in ${KERNEL_IMAGETYPES} ; do
> -${STAGING_BINDIR_NATIVE}/mkknlimg --dtok 
> ${KERNEL_OUTPUT_DIR}/$type.initramfs ${KERNEL_OUTPUT_DIR}/$type.initramfs
> -done
> -fi
> -fi
> -fi
> -}

I have staged it form testing.



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] u-boot: Fix appending to RDEPENDS

[Khem Raj]

> On Nov 2, 2016, at 1:28 AM, Paul Barker  wrote:
> 
> On Wed,  2 Nov 2016 00:46:47 +1100
> Jonathan Liu  wrote:
> 
>> The += operator should not be used in combination with overrides as it
>> will clear any existing values in the variable.
>> 
>> Example:
>> FOO = "bar"
>> FOO_rpi += "baz"
>> 
>> The above example would result in FOO being equal to " baz" instead of
>> "bar baz".
>> 
>> The bbappend is changed to use a wildcard instead of a specific
>> version to simplify updating U-Boot.
>> 
>> Signed-off-by: Jonathan Liu 
>> ---
>> recipes-bsp/u-boot/u-boot_%.bbappend   | 1 +
>> recipes-bsp/u-boot/u-boot_2016.03.bbappend | 1 -
>> 2 files changed, 1 insertion(+), 1 deletion(-)
>> create mode 100644 recipes-bsp/u-boot/u-boot_%.bbappend
>> delete mode 100644 recipes-bsp/u-boot/u-boot_2016.03.bbappend
>> 
>> diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend
>> b/recipes-bsp/u-boot/u-boot_%.bbappend new file mode 100644
>> index 000..3781666
>> --- /dev/null
>> +++ b/recipes-bsp/u-boot/u-boot_%.bbappend
>> @@ -0,0 +1 @@
>> +RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
>> diff --git a/recipes-bsp/u-boot/u-boot_2016.03.bbappend
>> b/recipes-bsp/u-boot/u-boot_2016.03.bbappend deleted file mode 100644
>> index 35dfc37..000
>> --- a/recipes-bsp/u-boot/u-boot_2016.03.bbappend
>> +++ /dev/null
>> @@ -1 +0,0 @@
>> -RDEPENDS_${PN}_rpi += "rpi-u-boot-scr"
> 
> Looks good. Thanks for picking this up!

I have staged it for testing


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] u-boot: Simplify boot script

[Khem Raj]

> On Nov 2, 2016, at 12:46 AM, Paul Barker  wrote:
> 
> On Wed,  2 Nov 2016 00:49:11 +1100
> Jonathan Liu  wrote:
> 
>> device_tree_address=0x100 is set in config.txt so the firmware will
>> load a patched device tree blob to 0x100 before passing control to
>> U-Boot. The U-Boot script will then read the command line arguments
>> generated by the firmware from the device tree and boot the kernel
>> with the command line arguments and the loaded device tree.
>> 
>> This allows things like MAC address, board revision and serial number
>> to be correctly configured and options in config.txt to be used.
>> 
>> Signed-off-by: Jonathan Liu 
>> ---
>> recipes-bsp/bootfiles/rpi-config_git.bb| 5 +
>> recipes-bsp/rpi-u-boot-scr/files/boot.cmd  | 3 +++
>> recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd  | 6 --
>> recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd | 6 --
>> recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd | 6 --
>> recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd | 6 --
>> 6 files changed, 8 insertions(+), 24 deletions(-)
>> create mode 100644 recipes-bsp/rpi-u-boot-scr/files/boot.cmd
>> delete mode 100644
>> recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd delete mode
>> 100644 recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd delete
>> mode 100644 recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd
>> delete mode 100644
>> recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd
>> 
>> diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb
>> b/recipes-bsp/bootfiles/rpi-config_git.bb index f610718..2f4d25c
>> 100644 --- a/recipes-bsp/bootfiles/rpi-config_git.bb
>> +++ b/recipes-bsp/bootfiles/rpi-config_git.bb
>> @@ -76,6 +76,11 @@ do_deploy() {
>> echo "dispmanx_offline=1"
 ${DEPLOYDIR}/bcm2835-bootfiles/config.txt fi
>> 
>> +# U-Boot Device Tree support
>> +if [ "${KERNEL_IMAGETYPE}" = "uImage" ]; then
>> +sed -i '/#device_tree_address/ c\device_tree_address=0x100'
>> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
>> +fi
>> +
>> # SPI bus support
>> if [ -n "${ENABLE_SPI_BUS}" ] || [ "${PITFT}" = "1" ]; then
>> echo "# Enable SPI bus"
 ${DEPLOYDIR}/bcm2835-bootfiles/config.txt diff --git
 a/recipes-bsp/rpi-u-boot-scr/files/boot.cmd
 b/recipes-bsp/rpi-u-boot-scr/files/boot.cmd
>> new file mode 100644
>> index 000..3f7e3b6
>> --- /dev/null
>> +++ b/recipes-bsp/rpi-u-boot-scr/files/boot.cmd
>> @@ -0,0 +1,3 @@
>> +fdt addr ${fdt_addr_r} && fdt get value bootargs /chosen bootargs
>> +fatload mmc 0:1 ${kernel_addr_r} uImage
>> +bootm ${kernel_addr_r} - ${fdt_addr_r}
>> diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd
>> b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd deleted file
>> mode 100644 index c86c758..000
>> --- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd
>> +++ /dev/null
>> @@ -1,6 +0,0 @@
>> -setenv fdtfile bcm2708-rpi-b.dtb
>> -setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0
>> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd' -mmc dev 0
>> -fatload mmc 0:1 ${kernel_addr_r} uImage
>> -fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
>> -bootm ${kernel_addr_r} - ${fdt_addr_r}
>> diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd
>> b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd deleted file
>> mode 100644 index c86c758..000
>> --- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd
>> +++ /dev/null
>> @@ -1,6 +0,0 @@
>> -setenv fdtfile bcm2708-rpi-b.dtb
>> -setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0
>> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd' -mmc dev 0
>> -fatload mmc 0:1 ${kernel_addr_r} uImage
>> -fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
>> -bootm ${kernel_addr_r} - ${fdt_addr_r}
>> diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd
>> b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd deleted file
>> mode 100644 index aa4ea64..000
>> --- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd
>> +++ /dev/null
>> @@ -1,6 +0,0 @@
>> -setenv fdtfile bcm2709-rpi-2-b.dtb
>> -setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0
>> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd' -mmc dev 0
>> -fatload mmc 0:1 ${kernel_addr_r} uImage
>> -fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
>> -bootm ${kernel_addr_r} - ${fdt_addr_r}
>> diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd
>> b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd deleted file
>> mode 100644 index 2950856..000
>> --- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd
>> +++ /dev/null
>> @@ -1,6 +0,0 @@
>> -setenv fdtfile bcm2710-rpi-3-b.dtb
>> -setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0
>> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd' -mmc dev 0
>> -fatload mmc 0:1 ${kernel_addr_r} uImage
>> -fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
>> -bootm ${kernel_addr_r} - ${fdt_addr_r}
> 
> Looks like I 

[yocto] [meta-raspberrypi][PATCH] linux-raspberrypi_4.8.bb: Upgrade to 4.8.6

[Khem Raj]

Signed-off-by: Khem Raj 
---
 recipes-kernel/linux/linux-raspberrypi_4.8.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
index 528cfef..4664249 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
@@ -1,8 +1,8 @@
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
 
-LINUX_VERSION ?= "4.8.4"
+LINUX_VERSION ?= "4.8.6"
 
-SRCREV = "d8f7c2da3d33ea4fb4f67411badad374b1160b44"
+SRCREV = "6abac13566786086cd912d87e4f1a922e2a391b2"
 SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.8.y \
 "
 require linux-raspberrypi.inc
-- 
2.10.2

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

[yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad_%.bbappend: Set PACKAGECONFIG_GL for RPi

[Khem Raj]

Enable dispmanx support if using bcm driver

Signed-off-by: Khem Raj 
---
 .../gstreamer/gstreamer1.0-plugins-bad_%.bbappend  | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend 
b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
index ab0280e..1097e65 100644
--- a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
+++ b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
@@ -1,2 +1,12 @@
-EXTRA_OECONF_append_rpi = " 
CPPFLAGS='-I${STAGING_DIR_TARGET}/usr/include/interface/vcos/pthreads \
-   
-I${STAGING_DIR_TARGET}/usr/include/interface/vmcs_host/linux'"
+EXTRA_OECONF_append_rpi = " 
CPPFLAGS='-I${STAGING_INCDIR}/interface/vcos/pthreads \
+   
-I${STAGING_INCDIR}/interface/vmcs_host/linux'"
+
+# if using bcm driver then enable dispmanx, other
+
+PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,userland"
+
+PACKAGECONFIG_append_rpi = " "${@bb.utils.contains("MACHINE_FEATURES", 
"vc4graphics", "", "dispmanx", d)}"
+
+PACKAGECONFIG_GL_rpi = "egl gles2"
+PACKAGECONFIG_append_rpi = " hls libmms faad dispmanx"
+
-- 
2.10.2

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