date:20161102

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

2016-11-02 Thread 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}

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

2016-11-02 Thread 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

2016-11-02 Thread 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] How do I used Yocto to build an sdcard image for my Raspberry Pi 3 Model B?

2016-11-02 Thread 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] How do I used Yocto to build an sdcard image for my Raspberry Pi 3 Model B?

2016-11-02 Thread 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] [meta-raspberrypi3] Failed to build gstreamer1.0-plugins-bad with minimal configuration

2016-11-02 Thread 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

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

2016-11-02 Thread 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] Yocto 2.2 Morty supported Linux Distros

2016-11-02 Thread 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] how to copy a tar file to Root file system

2016-11-02 Thread 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 
>:
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

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

2016-11-02 Thread 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

2016-11-02 Thread 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

2016-11-02 Thread 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 
>:
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

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

2016-11-02 Thread 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] Yocto 2.2 Morty supported Linux Distros

2016-11-02 Thread 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

2016-11-02 Thread 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] [sstate-cache] using sstate-cache in parallel builds

2016-11-02 Thread 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

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

2016-11-02 Thread 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] LXC container: opkg_install_cmd: Cannot install package cmocka

2016-11-02 Thread Dinh Nguyen (dinhn)

Thanks — Got it.

—Dinh

From: dinhn >
Date: Wednesday, November 2, 2016 at 6:20 AM
To: "yocto@yoctoproject.org" 
>
Cc: dinhn >
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] [sstate-cache] using sstate-cache in parallel builds

2016-11-02 Thread 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

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

2016-11-02 Thread 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

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

2016-11-02 Thread 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] How to create an user bsp based on a other meta bsp layer?

2016-11-02 Thread 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] Yocto 2.2 Morty supported Linux Distros

2016-11-02 Thread 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] [meta-raspberrypi][PATCH 1/1] linux-raspberrypi: remove not needed bundle_initramfs_append()

2016-11-02 Thread 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

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

2016-11-02 Thread 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

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

2016-11-02 Thread 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

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

2016-11-02 Thread 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

Re: [yocto] Tcl SIGCHLD lost process error

2016-11-02 Thread Mircea Gliga


Does anyone has this issue also ?
Any input ?

Thanks

On 28/10/16 15:36, Valentina Skorpion wrote:

   Hello everyone,

 I have been using yocto jethro in order to build my custom Linux 
distribution for several devices ( qemuarm , sama5d4, etc) . I have 
used the linux-yocto 4.1.5 kernel version and latest version packages. 
After upgrading to yocto krogoth I have used a newer version of linux 
kernel ( version 4.7.2 ) and newer version packages. I had some tcl 
scripts which worked fine before but now  the following error has been 
triggered:
error waiting for process to exit : child process lost is sigchld 
ignored or trapped? )


 This error is being triggered when tcl *exec *function is 
executed. Even simpler commands such as "exec ls" triggers the same 
error (the command is not executed).


 I have tried to reproduce the error on yocto krogoth with older 
versions of linux kernel. On linux-yocto 4.4 the same error appeared.  
On linux-yocto 4.1.5 with some outdated packages (with older version, 
only Tcl had the same version in all test cases) the exec function 
runned fine (as I have mentioned before). To reproduce the error in 
this case, SIGCHLD had to be trapped outside tclsh (with trap command 
: trap "" CHLD), but even then, the command inside exec was executed 
and only after that the mentioned error was triggered (similar to this 
issue: 
http://www.rkeene.org/projects/tcl/tcl.fossil/info/2982713f ).


 It seemed at a package (on which depends Tcl) traps or ignores 
the SIGCHLD.  After some research, a similar issue has been reported ( 
https://sourceware.org/bugzilla/show_bug.cgi?id=19861 ). In a newer 
glibc version, fork functionality could not use IFUNC resolver so it 
would trigger in tcl the SIGCHLD error. A patch has been applied to 
glib pt-fork.c ( 
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blobdiff;f=nptl/pt-fork.c;h=db9b61d9aa172c7886b6ed3decb355a3aa4c9036;hp=b65d6b4eddc0c17a39825a9cd30d0dc3fb5b141f;hb=f06f3f05b48c72e2c9b0fa78671f94fd22d67da8;hpb=7838d298d895f65247fb6b498db03a4336fc0506 
) in order to fix the issue and now works fine.



 Has somebody encountered this issue too? Has anyone used this 
patch to fix the problem or used another fix? Thanks!









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

Re: [yocto] esdk without using Poky?

2016-11-02 Thread Gary Thomas


On 2016-11-02 03:25, Paul Eggleton wrote:

On Wed, 02 Nov 2016 03:02:11 Gary Thomas wrote:

On 2016-11-02 02:44, Paul Eggleton wrote:

On Wed, 02 Nov 2016 02:37:57 Gary Thomas wrote:

On 2016-11-01 21:33, Paul Eggleton wrote:

On Tue, 01 Nov 2016 13:36:57 Gary Thomas wrote:

On 2016-10-31 23:06, Paul Eggleton wrote:

FYI the eSDK will use whatever you set in DISTRO - you have your own
distribution, but I assume you are still referencing poky - perhaps as
an
include from your distro configuration? At least meta-poky must be in
your
bblayers.conf, otherwise I don't think you'd be getting this error.

Regardless of that, there is a bug here somewhere. What do you have
under
layers/ in the generated SDK? Are you setting TEMPLATECONF anywhere?


I don't have meta-poky, nor any mention of poky, in any of my layers.
I'm still relying on the poky GIT tree, but that's for historical
reasons
(started long before the OE-core split).


I think that's where the problem lies. You may not realise it, but the
TEMPLATECONF environment variable is being set simply by using the poky
repository, since there is a .templateconf directory at its root that
sets
it to "meta-poky/conf" if it isn't already set. This isn't a problem
during normal operation since meta-poky/conf exists there - you'll just
be using poky's template local.conf and bblayers.conf rather than any
other. When you generate the eSDK though, meta-poky won't be copied into
the eSDK because that layer is not in your bblayers.conf and thus you
get
the error.

I will have to try and figure a way around this. In the mean time you
should be able to change the saved value in
/conf/templateconf.cfg to "meta/conf" to work around the
issue,
but it'll come back if you create a new build directory unless you set
TEMPLATECONF in the external environment before running
oe-init-build-env.


I'm still confused.  There is no mention of meta-poky, or of the $DISTRO

'poky' anywhere in my /conf:
   gthomas@europa:p8701_2016-10-22$ cat conf/templateconf.cfg
   meta-rainier-am335x-p8701/conf
   gthomas@europa:p8701_2016-10-22$ grep -i poky conf/*
   conf/bblayers.conf:  /local/poky-cutting-edge/meta \
   conf/bblayers.conf:  /local/poky-cutting-edge/meta-oe \
   conf/bblayers.conf:  /local/poky-cutting-edge/meta-amltd \
   conf/bblayers.conf:
   /local/poky-cutting-edge/meta-rainier-am335x-p8701 \

conf/bblayers.conf:  /local/poky-cutting-edge/meta-ti \

   conf/bblayers.conf:  /local/poky-cutting-edge/meta-webserver \


It turns out I was mistaken. The templateconf.cfg in your build directory
has no bearing on what the value ends up being in the eSDK because that
file isn't copied over - instead it is created from scratch. I am working
on a proper fix now.


Thanks.  I tried overriding this on the machine where I want to
install the eSDK (not the same as where I built it) like this:
   gthomas@zeus:~$ TEMPLATECONF=meta-rainier-am335x-p8701/conf
/work/tmp/amltd-glibc-x86_64-arm-toolchain-ext-2.2+snapshot.sh

Sadly, it still failed the same way.


Right, that's because the environment is filtered by the SDK installer, so
that won't make it through into the environment used during installation.


I've tested your patches for this (from the OE-core mailing list)
and I can now build and use the eSDK for my board :-)

I do have a couple observations/questions:

* I added my missing tool with this line in my local.conf
 TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru"
  Why did this cause many of the nativesdk tools to have to be rebuilt?
 NOTE: Tasks Summary: Attempted 2423 tasks of which 2043 didn't need to be 
rerun and all succeeded.

* When I built 'nativesdk-ti-cgt-pru', I got a number of scary looking errors - 
here are a few:
ERROR: nativesdk-ti-cgt-pru-2.1.1-r0 do_configure: Taskhash mismatch eb0229a8c364c4c399fc2e84f4dfaf91 versus 
b5d16aa43836f3832200af39aba5b796 for 
virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-cgt-pru_2.1.1.bb.do_configure
ERROR: Taskhash mismatch eb0229a8c364c4c399fc2e84f4dfaf91 versus b5d16aa43836f3832200af39aba5b796 for 
virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-cgt-pru_2.1.1.bb.do_configure
ERROR: nativesdk-ti-cgt-pru-2.1.1-r0 do_compile: Taskhash mismatch bc0d6bb3a62f58875962d4ccf1b60dd9 versus 
9e207a5a6aa53512135b5ea3a0610bf3 for 
virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-cgt-pru_2.1.1.bb.do_compile


* When I installed the eSDK on a machine other than where I
  built it, I also got a lot (865) of messages like these:

WARNING: The quilt-native:do_configure sig is computed to be 315b89079a159e1d4e43d3199c487bdb, but the sig is locked to 
a9909bdcc4c81106eb42c21bb0d760fc in SIGGEN_LOCKEDSIGS_t-x86-64
The quilt-native:do_compile sig is computed to be be128011cc1f47157898f513dc4e9bbb, but the sig is locked to 
fa83446de41fe9e7c2c49c2745438a8d in SIGGEN_LOCKEDSIGS_t-x86-64
The quilt-native:do_install sig is computed to be

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

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

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

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

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

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

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

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

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

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

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

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

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

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

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

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

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

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

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

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

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

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

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

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

Re: [yocto] Tcl SIGCHLD lost process error

Re: [yocto] esdk without using Poky?

29 matches

Site Navigation

Mail list logo

Footer information