[yocto] mklibs in USER_CLASSES

[Taek Hyun Shin]

Hi,Somebody help met plz.I'm using Yocto Project 2.0I want to reduce my rootfs due to fast execute binaries.So, I did apply mklibs using USE_CLASSESBut, I got error message as follow: 208 No pic file found for /home/B110141/works/Yocto/build/tcc8021/tmp/sysroots/tcc8021/usr/lib//libgmp.so.10 ; copying 209 reducing libgobject-2.0.so.0 210 No pic file found for /home/B110141/works/Yocto/build/tcc8021/tmp/sysroots/tcc8021/usr/lib//libgobject-2.0.so.0 ; copying 211 reducing libgstreamer-1.0.so.0 212 No pic file found for /home/B110141/works/Yocto/build/tcc8021/tmp/sysroots/tcc8021/usr/lib//libgstreamer-1.0.so.0 ; copying 213 reducing libhogweed.so.4 214 No pic file found for /home/B110141/works/Yocto/build/tcc8021/tmp/sysroots/tcc8021/usr/lib//libhogweed.so.4 ; copying 215 reducing libinput.so.10 216 No pic file found for /home/B110141/works/Yocto/build/tcc8021/tmp/sysroots/tcc8021/usr/lib//libinput.so.10 ; copying 217 reducing libjpeg.so.9 218 No pic file found for /home/B110141/works/Yocto/build/tcc8021/tmp/sysroots/tcc8021/usr/lib//libjpeg.so.9 ; copying 219 reducing liblog.so 220 No pic file found for /home/B110141/works/Yocto/build/tcc8021/tmp/sysroots/tcc8021/usr/lib//liblog.so ; copying 221 reducing libm.so.6 222 No pic file found for /home/B110141/works/Yocto/build/tcc8021/tmp/sysroots/tcc8021/lib//libm.so.6 ; copying 223 reducing libmenuw.so.5 224 No pic file found for /home/B110141/works/Yocto/build/tcc8021/tmp/sysroots/tcc8021/usr/lib//libmenuw.so.5 ; copying 225 reducing libmount.so.1 226 No pic file found for /home/B110141/works/Yocto/build/tcc8021/tmp/sysroots/tcc8021/lib//libmount.so.1 ; copying 227 reducing libmtdev.so.1How can I create the pic file each librariesHelp me plz TT




Thanks & Best Regards,Wily Taekhyun Shin  Telechips Inc.R Center / Automotive Group / Linux Team / Research EngineerTel : +82-2-3443-6792(Ext. 390), M.P : +82-10-4376-5530, E-mail : ths...@telechips.comThis mail and attachments contain confidential information of Telechips Inc. which has its own authority. It is not allowed to disclose,transmit or use this confidential information to the third parties without the prior written consent of Telechips Inc. by any form or means. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents and destroy all copies of the original message. -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] esdk without using Poky?

[Gary Thomas]

On 2016-11-04 04:41, Paul Eggleton wrote:

On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote:

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 :-)


Great!


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?


So just FYI this will only work for the standard SDK, it's not the right way
to add these tools for the eSDK - in fact it may break the eSDK due to
bringing things into the native sysroot that shouldn't be there.

At the moment I think the only way to properly add this to the eSDK is to do
this:

SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot"

We don't document this, and it's a little awkward in any case. I'll work on
it.


I'll change my setup to use this.  Hopefully you can find a prettier way to
do it in the future and document how.




* 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-cg
t-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-c
gt-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-cg
t-pru_2.1.1.bb.do_compile


Where did you build this? Just in your normal build?


I got this when I built nativesdk-ti-cgt-pru directly from the command line.
The ti-cgt-pru-native package had already been built indirectly by pru-icss.



This kind of error indicates that a variable value is changing while bitbake
is running - often this is caused by date/time values in variables. Looking in
meta-ti I can't see anything that would cause this though. Was it only showing
up for nativesdk-ti-cgt-pru ?


* 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
85c8be820a93b84901dd7528eb61840e, but the sig is locked to
6caa366055ef06147ef64cbe7d83c608 in SIGGEN_LOCKEDSIGS_t-x86-64
The quilt-native:do_populate_sysroot sig is computed to be
5b0f52254aa8548fa406b806dae000cb, but the sig is locked to
d3cf7e526716d0286ce596c44c6b9936 in SIGGEN_LOCKEDSIGS_t-x86-64
The glibc:do_patch sig is computed to be 373272e62465460928320aa7643f9916,
but the sig is locked to 712620a3943887e11d9730013d1e07f0 in
SIGGEN_LOCKEDSIGS_t-armv7ahf-neon


Right. Are you using uninative? If not, you probably should (and I just sent a
patch to disable building the eSDK without it).


I'll give that a go and see if it helps.




All that said, it is now working for me, time to learn to use it!
Thanks for your help.  Feel free to add my Acked-by or Signed-off-by
to your patches if you wish.

Acked-by: Gary Thomas 
Signed-off-by: Gary Thomas 


Thanks!

Cheers,
Paul




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] esdk without using Poky?

[Paul Eggleton]

On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote:
> 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 :-)

Great!
 
> 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?

So just FYI this will only work for the standard SDK, it's not the right way 
to add these tools for the eSDK - in fact it may break the eSDK due to 
bringing things into the native sysroot that shouldn't be there.

At the moment I think the only way to properly add this to the eSDK is to do 
this:

SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot"

We don't document this, and it's a little awkward in any case. I'll work on 
it.

> * 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-cg
> t-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-c
> gt-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-cg
> t-pru_2.1.1.bb.do_compile

Where did you build this? Just in your normal build?

This kind of error indicates that a variable value is changing while bitbake 
is running - often this is caused by date/time values in variables. Looking in 
meta-ti I can't see anything that would cause this though. Was it only showing 
up for nativesdk-ti-cgt-pru ?

> * 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
> 85c8be820a93b84901dd7528eb61840e, but the sig is locked to
> 6caa366055ef06147ef64cbe7d83c608 in SIGGEN_LOCKEDSIGS_t-x86-64
> The quilt-native:do_populate_sysroot sig is computed to be
> 5b0f52254aa8548fa406b806dae000cb, but the sig is locked to
> d3cf7e526716d0286ce596c44c6b9936 in SIGGEN_LOCKEDSIGS_t-x86-64
> The glibc:do_patch sig is computed to be 373272e62465460928320aa7643f9916,
> but the sig is locked to 712620a3943887e11d9730013d1e07f0 in
> SIGGEN_LOCKEDSIGS_t-armv7ahf-neon

Right. Are you using uninative? If not, you probably should (and I just sent a 
patch to disable building the eSDK without it).

> All that said, it is now working for me, time to learn to use it!
> Thanks for your help.  Feel free to add my Acked-by or Signed-off-by
> to your patches if you wish.
> 
> Acked-by: Gary Thomas 
> Signed-off-by: Gary Thomas 

Thanks!

Cheers,
Paul

-- 

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

[yocto] [AUH] Upgrade status: 2016-11-04

[auh]

AUH finished upgrade batch the result patches/logs can be found at:
https://logs.yoctoproject.org/auh//20161102154900.tar.gz, next are the 
statistics:

Recipe upgrade statistics:

* Failed(do_compile): 12
libjpeg-turbo, 1.5.1, Maxin B. John 
wpa-supplicant, 2.6, Maxin B. John 
python-git, 2.1.0, Jose Lamego 
kexec-tools, 2.0.13, Alexander Kanavin 
icu, 58.1, Alexander Kanavin 
python-setuptools, 28.7.1, Jose Lamego 
gpgme, 1.7.1, Hongxu Jia 
less, 487, Robert Yang 
libpng, 1.6.26, Maxin B. John 
cogl-1.0, 1.22.2, Jussi Kukkonen 
texinfo, 6.3, Leonardo Sandoval 

libsamplerate0, 0.1.9, Tanu Kaskinen 
* Failed(do_configure): 9
gstreamer1.0-plugins-good, 1.10.0, Maxin B. John 
weston, 1.12.0, Jussi Kukkonen 
pinentry, 0.9.7, Armin Kuster 
gstreamer1.0-plugins-bad, 1.10.0, Maxin B. John 
vte, 0.46.0, Jussi Kukkonen 
xserver-xorg, 1.18.99.902, Jussi Kukkonen 
gstreamer1.0-rtsp-server, 1.10.0, Maxin B. John 
gstreamer1.0-plugins-base, 1.10.0, Maxin B. John 
libpcap, 1.8.1, Maxin B. John 
* Succeeded: 62
sqlite3, 3.15.0, Maxin B. John 
gnupg, 2.1.15, Hongxu Jia 
dbus-test, 1.10.12, Chen Qi 
ltp, 20160920, Dengke Du 
ofono, 1.19, Maxin B. John 
libarchive, 3.2.2, Alexander Kanavin 
lttng-modules, 2.8.3+gitAUTOINC+114e0e4afe, Richard Purdie 

orc, 0.4.26, Maxin B. John 
grep, 2.26, Chen Qi 
libxi, 1.7.8, Jussi Kukkonen 
iproute2, 4.8.0, Maxin B. John 
mc, 4.8.18, Maxin B. John 
swig, 3.0.10, Edwin Plauchu 
gawk, 4.1.4, Chen Qi 
shared-mime-info, 1.7, Jussi Kukkonen 
nspr, 4.13.1, Alexander Kanavin 
tzdata, 2016h, Robert Yang 
man-pages, 4.08, Hongxu Jia 
gstreamer1.0, 1.10.0, Maxin B. John 
libxrandr, 1.5.1, Jussi Kukkonen 
e2fsprogs, 1.43.3, Robert Yang 
wayland, 1.12.0, Jussi Kukkonen 
iw, 4.9, Maxin B. John 
curl, 7.51.0, Chen Qi 
sudo, 1.8.18p1, Chen Qi 
mpfr, 3.1.5, Richard Purdie 
dbus-glib, 0.108, Chen Qi 
diffutils, 3.5, Chen Qi 
btrfs-tools, 4.8.2, Alexander Kanavin 
acpid, 2.0.28, Maxin B. John 
slang, 2.3.1, Robert Yang 
harfbuzz, 1.3.3, Maxin B. John 
lighttpd, 1.4.43, Alexander Kanavin 
util-linux, 2.28.2, Chen Qi 
sysstat, 11.5.1, Chen Qi 
xkeyboard-config, 2.19, Jussi Kukkonen 
elfutils, 0.167, Hongxu Jia 
clutter-gtk-1.0, 1.8.2, Jussi Kukkonen 
python-pexpect, 4.2.1, Jose Lamego 
xf86-input-evdev, 2.10.4, Jussi Kukkonen 
clutter-gst-3.0, 3.0.20, Jussi Kukkonen 
python3-pygobject, 3.22.0, Edwin Plauchu 

pciutils, 3.5.2, Chen Qi 
vala, 0.34.2, Alexander Kanavin 
python-numpy, 1.11.2, Jose Lamego 
neon, 0.30.2, Maxin B. John 
ifupdown, 0.8.16, Maxin B. John 
nfs-utils, 1.3.4, Mariano Lopez 
bluez5, 5.43, Maxin B. John 
ethtool, 4.8, Maxin B. John 

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

[Paul Barker]

On Fri, 4 Nov 2016 08:55:05 +1100
Jonathan Liu  wrote:

> Hi Paul,
> 
> On 4 November 2016 at 07:57, 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}
> >>
> >> 
> >
> > This doesn't work for me.
> >
> > On RaspberryPi B+ I get no kernel messages during the boot. I do get a
> > login prompt though and the boot is successful.
> >
> > On RaspberryPi 3 I don't get anything after "Starting kernel ...".
> >
> > https://www.raspberrypi.org/documentation/configuration/device-tree.md
> > says:
> >
> > The base Device Trees are located alongside start.elf in the FAT
> > partition (/boot from Linux), named bcm2708-rpi-b.dtb,
> > bcm2708-rpi-b-plus.dtb, bcm2708-rpi-cm.dtb, and
> > bcm2709-rpi-2-b.dtb.
> >
> > In /boot I have:
> >
> > bcm2708-rpi-b.dtb
> > bcm2708-rpi-b-plus.dtb
> > bcm2709-rpi-2-b.dtb
> > bcm2710-rpi-3-b.dtb
> >
> > So my guess is that the RaspberryPi 3 isn't loading the right device
> > tree.
> >
> > Is this a problem with start.elf (which we need to report upstream) or
> > a problem with our DTB file names?
> >
> > I'd also say we probably have a problem with bootargs as it doesn't
> > print out kernel messages during boot.
> >
> > What's the benefit of using the device tree cobbled together by
> > start.elf instead of loading the DTB file ourselves?
> 
> As I mentioned in the commit:
> "This allows things like MAC address, board revision and serial number
> to be correctly configured and options in config.txt to be used."
> 
> So:
> - MAC address of ethernet shown by ifconfig
> - Output of cat /proc/cpuinfo
> 
> Looks like the config.txt option disables the board model auto
> detection so the device_tree= config.txt isn't automatically set
> properly. Probably the U-Boot binary needs to modified by mkknlimg
> --dtok instead of explicitly setting the device tree address in
> config.txt. Will look into this later if I have time.
> 

Ah ok, that makes sense.

I'll have a look if there's any way to check which DTB file start.elf is
picking up. 

I thought mkknlimg wasn't required any more though
(https://github.com/raspberrypi/tools/issues/58). I'm probably just
hitting up against the not-well-documented bits of the RaspberryPi boot
process.

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

[Jonathan Liu]

Hi Paul,

On 4 November 2016 at 07:57, 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}
>>
>> 
>
> This doesn't work for me.
>
> On RaspberryPi B+ I get no kernel messages during the boot. I do get a
> login prompt though and the boot is successful.
>
> On RaspberryPi 3 I don't get anything after "Starting kernel ...".
>
> https://www.raspberrypi.org/documentation/configuration/device-tree.md
> says:
>
> The base Device Trees are located alongside start.elf in the FAT
> partition (/boot from Linux), named bcm2708-rpi-b.dtb,
> bcm2708-rpi-b-plus.dtb, bcm2708-rpi-cm.dtb, and
> bcm2709-rpi-2-b.dtb.
>
> In /boot I have:
>
> bcm2708-rpi-b.dtb
> bcm2708-rpi-b-plus.dtb
> bcm2709-rpi-2-b.dtb
> bcm2710-rpi-3-b.dtb
>
> So my guess is that the RaspberryPi 3 isn't loading the right device
> tree.
>
> Is this a problem with start.elf (which we need to report upstream) or
> a problem with our DTB file names?
>
> I'd also say we probably have a problem with bootargs as it doesn't
> print out kernel messages during boot.
>
> What's the benefit of using the device tree cobbled together by
> start.elf instead of loading the DTB file ourselves?

As I mentioned in the commit:
"This allows things like MAC address, board revision and serial number
to be correctly configured and options in config.txt to be used."

So:
- MAC address of ethernet shown by ifconfig
- Output of cat /proc/cpuinfo

Looks like the config.txt option disables the board model auto
detection so the device_tree= config.txt isn't automatically set
properly. Probably the U-Boot binary needs to modified by mkknlimg
--dtok instead of explicitly setting the device tree address in
config.txt. Will look into this later if I have time.

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

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

[Khem Raj]

here is reworked patch
https://github.com/kraj/meta-raspberrypi/commit/468e28084a4d41e71fc0fde53b43033cd19ef9d5.patch
 


try it again

> On Nov 3, 2016, at 2:27 PM, Karim ATIKI  wrote:
> 
> Hi Khem,
> 
> I just tried to rebuild gstreamer1.0-plugins-bad from a clean checkout with 
> your patch.
> At first glance, it's working.
> 
> "bitbake gstreamer1.0-plugins-bad" succeeded but with a QA Warning:
> 
> gstreamer1.0-plugins-bad-1.8.3-r0 do_configure: QA Issue: 
> gstreamer1.0-plugins-bad: invalid PACKAGECONFIG: "dispmanx 
> [invalid-packageconfig]
> 
> Karim
> 
> 
> 
> De : yocto-boun...@yoctoproject.org  
> > de 
> la part de Khem Raj >
> Envoyé : jeudi 3 novembre 2016 21:57
> À : yocto@yoctoproject.org 
> Objet : [yocto] [meta-raspberrypi][PATCH V2] 
> gstreamer1.0-plugins-bad_%.bbappend: Set PACKAGECONFIG_GL for RPi
> 
> Enable dispmanx support if using bcm driver
> 
> Signed-off-by: Khem Raj >
> ---
> Changes from V1->V2:
> - Remove spurious "
> - Rearrange code
> - Remove duplicate packageconfig for dispmanx
> 
>  .../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..7292f90 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 enable dispmanx not when using VC4 driver
> +
> +PACKAGECONFIG_append_rpi = "${@bb.utils.contains('MACHINE_FEATURES', 
> 'vc4graphics', '', ' dispmanx', d)}"
> +
> +PACKAGECONFIG_GL_rpi = "egl gles2"
> +
> +PACKAGECONFIG_append_rpi = " hls libmms faad"
> +
> +PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,userland"
> --
> 2.10.2
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto 
> 
> yocto Info Page 
> lists.yoctoproject.org 
> Discussion of all things about the Yocto Project. Read our Community 
> Guidelines or learn more about how to participate in other community 
> discussions.



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 V2] gstreamer1.0-plugins-bad_%.bbappend: Set PACKAGECONFIG_GL for RPi

[Karim ATIKI]

Hi Khem,


I just tried to rebuild gstreamer1.0-plugins-bad from a clean checkout with 
your patch.

At first glance, it's working.


"bitbake gstreamer1.0-plugins-bad" succeeded but with a QA Warning:


gstreamer1.0-plugins-bad-1.8.3-r0 do_configure: QA Issue: 
gstreamer1.0-plugins-bad: invalid PACKAGECONFIG: "dispmanx 
[invalid-packageconfig]


Karim




De : yocto-boun...@yoctoproject.org  de la part 
de Khem Raj 
Envoyé : jeudi 3 novembre 2016 21:57
À : yocto@yoctoproject.org
Objet : [yocto] [meta-raspberrypi][PATCH V2] 
gstreamer1.0-plugins-bad_%.bbappend: Set PACKAGECONFIG_GL for RPi

Enable dispmanx support if using bcm driver

Signed-off-by: Khem Raj 
---
Changes from V1->V2:
- Remove spurious "
- Rearrange code
- Remove duplicate packageconfig for dispmanx

 .../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..7292f90 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 enable dispmanx not when using VC4 driver
+
+PACKAGECONFIG_append_rpi = "${@bb.utils.contains('MACHINE_FEATURES', 
'vc4graphics', '', ' dispmanx', d)}"
+
+PACKAGECONFIG_GL_rpi = "egl gles2"
+
+PACKAGECONFIG_append_rpi = " hls libmms faad"
+
+PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,userland"
--
2.10.2

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
yocto Info Page
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.



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

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}
>
> 

This doesn't work for me.

On RaspberryPi B+ I get no kernel messages during the boot. I do get a
login prompt though and the boot is successful.

On RaspberryPi 3 I don't get anything after "Starting kernel ...".

https://www.raspberrypi.org/documentation/configuration/device-tree.md
says:

The base Device Trees are located alongside start.elf in the FAT
partition (/boot from Linux), named bcm2708-rpi-b.dtb,
bcm2708-rpi-b-plus.dtb, bcm2708-rpi-cm.dtb, and
bcm2709-rpi-2-b.dtb.

In /boot I have:

bcm2708-rpi-b.dtb
bcm2708-rpi-b-plus.dtb
bcm2709-rpi-2-b.dtb
bcm2710-rpi-3-b.dtb

So my guess is that the RaspberryPi 3 isn't loading the right device
tree.

Is this a problem with start.elf (which we need to report upstream) or
a problem with our DTB file names?

I'd also say we probably have a problem with bootargs as it doesn't
print out kernel messages during boot.

What's the benefit of using the device tree cobbled together by
start.elf instead of loading the DTB file ourselves?

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

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

[Khem Raj]

Enable dispmanx support if using bcm driver

Signed-off-by: Khem Raj 
---
Changes from V1->V2:
- Remove spurious "
- Rearrange code
- Remove duplicate packageconfig for dispmanx

 .../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..7292f90 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 enable dispmanx not when using VC4 driver
+
+PACKAGECONFIG_append_rpi = "${@bb.utils.contains('MACHINE_FEATURES', 
'vc4graphics', '', ' dispmanx', d)}"
+
+PACKAGECONFIG_GL_rpi = "egl gles2"
+
+PACKAGECONFIG_append_rpi = " hls libmms faad"
+
+PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,userland"
-- 
2.10.2

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

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

[Paul Eggleton]

On Wed, 02 Nov 2016 20:17:11 swapna.gurum...@microchip.com wrote:
> > 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?

There are various QA checks on the output (as you've no doubt seen) - some of
those require examining binaries such as the checks on rpaths, and that
requires running objdump.

> > * 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?

That error has nothing to do with the S value - as I mentioned, S may not
matter in this case, but it might as well be correct if you're setting it at
all.

You resolved this issue in the end, but for future reference there is a guide
on how to deal with various QA errors/warnings here:

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-errors-and-warnings
 
> > * 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]
 
That message is slightly misleading - in this case it really is just a runtime
dependency (since you're not building anything) and you should be able to
resolve it by setting RDEPENDS_${PN} rather than DEPENDS.

> > * 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"

Again, this isn't related to those errors, pkg-config just isn't necessary
for what this recipe does. 

FYI, bin_package is more suited to packages whose layout is already prepared
for the target (e.g. if you had an rpm or deb file) - you could have used it
here, but I'm not entirely sure it would have made things much easier given
the issues you ran into.

Cheers,
Paul

-- 

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

[yocto] [yocto-autobuilder][PATCH] buildset-config.meta-intel/nightly-meta-intel.conf

[Graydon, Tracy]

Update nightly-meta-intel.conf with the most recent release branches.

Signed-off-by: Graydon, Tracy 
---
 buildset-config.meta-intel/nightly-meta-intel.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/buildset-config.meta-intel/nightly-meta-intel.conf 
b/buildset-config.meta-intel/nightly-meta-intel.conf
index 3db11f5..557bb67 100644
--- a/buildset-config.meta-intel/nightly-meta-intel.conf
+++ b/buildset-config.meta-intel/nightly-meta-intel.conf
@@ -19,7 +19,7 @@ props: [{'release_me':{'prop_type':'ChoiceStringParameter',
'name': 'release_me',
'label':' Generate a release?:'}},
 {'poky_name':{'prop_type':'ChoiceStringParameter',
-   'choices': ['', 'jethro', 
'fido','dizzy','daisy','dora','dylan','danny','denzil','edison','bernard'],
+   'choices': ['', 'pyro', 'morty', 'krogoth', 'jethro', 
'fido','dizzy','daisy','dora','dylan','danny','denzil','edison','bernard'],
'name': 'poky_name',
'label':' Name of the poky release.For further 
info on release names see https://wiki.yoctoproject.org/wiki/Releases;> Releases  '}},
 {'is_milestone':{'prop_type':'ChoiceStringParameter',
-- 
2.7.0

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

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

[Andre McCurdy]

On Wed, Nov 2, 2016 at 11:29 PM, Khem Raj  wrote:
> 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

Comment seems to be truncated?

> +
> +PACKAGECONFIG[dispmanx] = "--enable-dispmanx,--disable-dispmanx,userland"

Typical style is to put PACKAGECONFIG[foo] lines after defining PACKAGECONFIG.

> +PACKAGECONFIG_append_rpi = " "${@bb.utils.contains("MACHINE_FEATURES", 
> "vc4graphics", "", "dispmanx", d)}"

Typo, extra "

> +
> +PACKAGECONFIG_GL_rpi = "egl gles2"
> +PACKAGECONFIG_append_rpi = " hls libmms faad dispmanx"

Appending dispmanx is conditional on MACHINE_FEATURES 3 lines above.
It probably shouldn't be unconditional here.

> +
> --
> 2.10.2
>
> --
> ___
> 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] Shallow git clones?

[Khem Raj]

> On Nov 3, 2016, at 6:06 AM, Gary Thomas  wrote:
> 
> I recall seeing some discussion in the past about using shallow
> GIT clones when importing repositories?  Is this ever going to
> happen?
> 
> The reason I ask is that I routinely save the GIT tarballs and
> some of them are obscenely obese :-(  The worst of the bunch
> is the device firmware for the RaspberryPi (as of today):
>  -rw-rw-r-- 1 gthomas gthomas 6321877646 Nov  3 12:13 
> git2_github.com.raspberrypi.firmware.git.tar.gz
> 
> This particular tar file increased by more than 300MB since
> the last time I downloaded it (only 2016-09-13!)  I routinely
> slosh these files across the oceans (sometimes using tin cans
> and strings it seems) and this can be very tedious.  Is there
> anything that can be done to make these files a bit more manageable?

while shallow clones is a comprehensive solution and we should probably slot it 
for 2.3 release
the above recipe should stop using git fetcher and convert to using tarballs
since this git repo hosts binaries, it will bloat with every time they push
stuff into it. Someone should teach these RPi folks to not abuse github.

> 
> Note: the RaspberryPi files are not the only offenders.  Take
> a look at the really big ones on my download mirror (~1GB or larger):
>  912558047 Jun  3  2015 git2_git.yoctoproject.org.linux-yocto-3.14.git.tar.gz
>  916869431 Sep 18 16:54 git2_git.yoctoproject.org.linux-yocto-4.4.git.tar.gz
>  917066415 Mar  8  2011 chrome-11.0.686.0.tar.bz2
>  929710560 Jun  5  2014 git2_git.yoctoproject.org.linux-yocto-3.10.git.tar.gz
>  975438005 May 14  2015 git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz
>  997340641 Jan  4  2013 
> git2_dev.omapzoom.org.pub.scm.integration.kernel-ubuntu.git.tar.gz
> 1013093794 Jul 22  2011 chrome-14.0.825.0.tar.bz2
> 1097457194 Jul  9  2015 git2_github.com.Itseez.opencv.git.tar.gz
> 1101241868 Jul 15 15:44 git2_git.freescale.com.ppc.sdk.linux.git.tar.gz
> 1167801376 Oct 24  2013 
> git2_git.kernel.org.pub.scm.linux.kernel.git.stable.linux-stable.git.tar.gz
> 1192994858 Nov 24  2014 git2_github.com.Freescale.linux-mainline.git.tar.gz
> 1399737300 Mar 30  2010 
> git_git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-2.6.git.tar.gz
> 1455878541 Feb 22  2016 git2_github.com.Freescale.linux-fslc.git.tar.gz
> 1637597724 Aug 11 09:45 git2_git.freescale.com.imx.linux-2.6-imx.git.tar.gz
> 1785320074 Aug 15  2012 git2_github.com.mirrors.gcc.git.tar.gz
> 1787717120 Oct 11 10:28 
> git2_git.ti.com.ti-linux-kernel.ti-linux-kernel.git.tar.gz
> 2070939344 Nov  3 12:11 git2_github.com.raspberrypi.linux.git.tar.gz
> 2478557202 Aug 10 11:47 git2_github.com.boundarydevices.linux-imx6.git.tar.gz
> 2525826872 Jul 12 16:42 git2_github.com.gcc-mirror.gcc.tar.gz
> 6321877646 Nov  3 12:13 git2_github.com.raspberrypi.firmware.git.tar.gz
> 
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



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

Re: [yocto] Invalid configuration from end user prevents continuing

[Khem Raj]

> On Nov 2, 2016, at 11:21 PM, Andrew Stuart  
> wrote:
> 
> Hello
> 
> I'm trying to get yocto to run from a hard disk.  It's not finishing the boot 
> process. Research suggests that there is some problem around the rootfs.
> 
> Here is a screenshot of where the boot is stuck (also attached to this email)
> 
> http://imgur.com/a/pf9Cy 
> 
> grub.cfg looks like this:
> 
> serial --speed=115200 --word=8 --parity=no --stop=1
> terminal_input --append  serial
> terminal_output --append serial
> set timeout=1
> GRUB_TIMEOUT=1
> menuentry 'yocto' {
> linux /boot/yocto_bzImage root=/dev/xvda1 rw console=ttyS0,115200

You might need to change this to whatever kernel thinks about the root disk 
device
may be its added as /dev/sdaX or /dev/hdaX


> }
> 
> To make this system boot, I did the following:
> 1: boot ubuntu
> 2: delete everything except the /boot directory from ubuntu’s root partition
> 3: mount the rootfs image that was generated by yocto
> 4: copy all files from the mounted rootfs image onto the hard drive root 
> partition
> 5: replace the grub.cfg with the one shown above.
> 
> It should work I imagine…..
> 
> I guess that an invalid configuration from me is preventing it continuing.  
> Trouble is I am not sure what I have configured wrong.
> 
> I'm not sure what I can do to take a next step in resolving this.  Does 
> anyone have any suggestions? thanks.
> 
> thanks
> 
> 
> 
> 
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



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

Re: [yocto] Guide to how to build a minimal system

[Khem Raj]

> On Nov 2, 2016, at 4:02 AM, Andrew Stuart  
> wrote:
> 
> I want to build a minimal Nginx system that does nothing else but serve 
> static files. Preferably with nothing else installed at all apart from 
> network configuration via /etc/network/interfaces. Perhaps also optionally 
> with ssh.
> 
> Ideally I would be able to provide the HTML files that make up the website 
> via an initramfs file.
> 
> I’d like this to run on x86-64 on KVM.
> 
> I’m looking for a guide that shows me the key steps to implement something 
> minimal like this.  Does such a guide exist?
> 
> I’ve watched several hours of Youtube videos on Yocto, I’ve read various 
> getting started guides and spent several hours installing and building.
> 
> Quite how to configure something down to minimal still is not clear.
> 
> Can someone guide me please as to where to find such docs?

You can start by building core-image-minimal which should be a bare bootable 
system. So in your own layer write a recipe for your image
and seed it with

require recipes-core/images/core-image-minimal.bb

and then add IMAGE_INSTALL += “nginx”

then build upwards to whatever you need.

> 
> One additional specific question - I can see that there is a web servers 
> layer, but how to only get the one webserver that I want (nginx) as opposed 
> to getting them all?
> 
> thanks
> 
> Andrew
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



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 remove/disable QtWebKit from building?

[Khem Raj]

> On Nov 2, 2016, at 7:18 AM, Anatoli Veselinov  
> wrote:
> 
> I have been searching about this but didn't found anything. I don't know if 
> what I'm asking is possible so let me explain.
> 
> My goal is to create a custom image for a target that it can run Qt 
> applications.
> I have the image ready, I also generated the Qt sdk (with populate_sdk) and I 
> already can cross-compile. Ok.
> 
> My question is, for future builds, how do I disable or remove some Qt modules 
> that I don't need?
> 
> I did:
> 
> PACKAGECONFIG_remove_pn-qttools = "qtwebkit"
> PACKAGECONFIG_remove_pn-qtquick1 = "qtwebkit"
> 
> but that doesn't disable qtwebkit to be built, I saw qtwebkit do_compile task 
> running and it takes a lot of time.

you need to remove it from qtbase as well.


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



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?

[Khem Raj]

> On Nov 3, 2016, at 4:57 AM, Thomas Thorne  wrote:
> 
> Presumably because I have in my local.conf:
> IMAGE_FSTYPES = "tar.xz ext3"
> 

yes thats the problem.


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

Re: [yocto] How to add libudev.h

[Fred Ollinger]

I belive this goes in your .bb file:

DEPENDS = " \
udev \
"

RDEPENDS_${PN} = " \
udev \
"

Also, you probably need the right flags for libudev.

Here are docs on that:

https://www.freedesktop.org/software/systemd/man/libudev.html

Of course, you need to tailor your build system to use these and incorporate 
this into your project.

I like automake so here's how to use pkgconfig with automake:

https://autotools.io/pkgconfig/pkg_check_modules.html

NOTE: systemd also provides libudev so if you have systemd, it's likely getting 
installed there and conflicts with udev, but I'm not sure, so you want to look 
into this as well. When I installed source for my debian jessie, I got systemd, 
and not udev sources. YMMV.

Frederick


From: yocto-boun...@yoctoproject.org  on behalf 
of mickael 
Sent: Thursday, November 3, 2016 4:55 AM
To: yocto@yoctoproject.org
Subject: [yocto]  How to add libudev.h

Hi all, i need to build a lib --> openZwave (on a imx6 card) libudev.h.
I have this error during the build :
/home/root/openzwave-1.4.164/cpp/hidapi/linux/hid.c:44:21: fatal error:
libudev.h: No such file or directory
I have tried to add udev to my local.conf but this not resolve the problem.
How i can add it to my build please ?
--
___
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] Shallow git clones?

[Christopher Larson]

On Thu, Nov 3, 2016 at 6:06 AM, Gary Thomas  wrote:

> I recall seeing some discussion in the past about using shallow
> GIT clones when importing repositories?  Is this ever going to
> happen?
>

Mentor has a bitbake patch series to support construction of and fetching
of shallow git tarballs. My goal is to get this merged for master, now that
morty has been branched, but ran into a unit test failure, so I’m working
on that, and on adding some new unit tests for it, before re-submission.
The current version is at https://github.com/kergoth/bitbake on the
shallow-external branch, if you’re curious.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Shallow git clones?

[Alexander Kanavin]

On 11/03/2016 03:06 PM, Gary Thomas wrote:

I recall seeing some discussion in the past about using shallow
GIT clones when importing repositories?  Is this ever going to
happen?

The reason I ask is that I routinely save the GIT tarballs and
some of them are obscenely obese :-(  The worst of the bunch
is the device firmware for the RaspberryPi (as of today):
  -rw-rw-r-- 1 gthomas gthomas 6321877646 Nov  3 12:13
git2_github.com.raspberrypi.firmware.git.tar.gz

This particular tar file increased by more than 300MB since
the last time I downloaded it (only 2016-09-13!)  I routinely
slosh these files across the oceans (sometimes using tin cans
and strings it seems) and this can be very tedious.  Is there
anything that can be done to make these files a bit more manageable?


Yes. You can investigate if the upstream produces tarball releases, and 
convince them to do it if they don't. Generally we prefer tarball 
downloads in oe-core for this exact reason, but it is not always possible.


Alex

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

[yocto] How to add libudev.h

[mickael]

Hi all, i need to build a lib --> openZwave (on a imx6 card) libudev.h.
I have this error during the build :
/home/root/openzwave-1.4.164/cpp/hidapi/linux/hid.c:44:21: fatal error:  
libudev.h: No such file or directory

I have tried to add udev to my local.conf but this not resolve the problem.
How i can add it to my build please ?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to disable a Qt module to be built?

[Anatoli V.]

I have been searching about this but didn't found anything. I don't know 
if what I'm asking is possible so let me explain.


My goal is to create a custom image for a target that it can run Qt 
applications.
I have the image ready, I also generated the Qt sdk (with populate_sdk) 
and I already can cross-compile. Ok.


My question is, for future builds, how do I disable or remove some Qt 
modules that I don't need?


I did:

PACKAGECONFIG_remove_pn-qttools = "qtwebkit"
PACKAGECONFIG_remove_pn-qtquick1 = "qtwebkit"

but that doesn't disable qtwebkit to be built, I saw qtwebkit do_compile 
task running and it takes a lot of time.


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

[yocto] How do I remove/disable QtWebKit from building?

[Anatoli Veselinov]

I have been searching about this but didn't found anything. I don't know 
if what I'm asking is possible so let me explain.


My goal is to create a custom image for a target that it can run Qt 
applications.
I have the image ready, I also generated the Qt sdk (with populate_sdk) 
and I already can cross-compile. Ok.


My question is, for future builds, how do I disable or remove some Qt 
modules that I don't need?


I did:

PACKAGECONFIG_remove_pn-qttools = "qtwebkit"
PACKAGECONFIG_remove_pn-qtquick1 = "qtwebkit"

but that doesn't disable qtwebkit to be built, I saw qtwebkit do_compile 
task running and it takes a lot of time.

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

[yocto] Guide to how to build a minimal system

[Andrew Stuart]

I want to build a minimal Nginx system that does nothing else but serve static 
files. Preferably with nothing else installed at all apart from network 
configuration via /etc/network/interfaces. Perhaps also optionally with ssh.

Ideally I would be able to provide the HTML files that make up the website via 
an initramfs file.

I’d like this to run on x86-64 on KVM.

I’m looking for a guide that shows me the key steps to implement something 
minimal like this.  Does such a guide exist?

I’ve watched several hours of Youtube videos on Yocto, I’ve read various 
getting started guides and spent several hours installing and building.

Quite how to configure something down to minimal still is not clear.

Can someone guide me please as to where to find such docs?

One additional specific question - I can see that there is a web servers layer, 
but how to only get the one webserver that I want (nginx) as opposed to getting 
them all?

thanks

Andrew

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

Re: [yocto] Shallow git clones?

[Bas Mevissen]

On 03/11/16 14:06, Gary Thomas wrote:

I recall seeing some discussion in the past about using shallow
GIT clones when importing repositories?  Is this ever going to
happen?

The reason I ask is that I routinely save the GIT tarballs and
some of them are obscenely obese :-(  The worst of the bunch
is the device firmware for the RaspberryPi (as of today):
  -rw-rw-r-- 1 gthomas gthomas 6321877646 Nov  3 12:13
git2_github.com.raspberrypi.firmware.git.tar.gz



On the OE-Core mailing list, there is currently a case of downloading 
600MB for gdb alone... I think this concern applies to Yocto and 
OpenEmbedded as a whole.


Cheers,

Bas.
--
___
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?

[Thomas Thorne]

May have solved the issue.  Thank you for your help.  

> What do you get from this?
>% bitbake rpi-test-image -e | grep ^IMAGE_FSTYPES

I get:
thomasthorne@thorne-ul-dt:~/work/rpi-layer/build$ bitbake rpi-test-image -e | 
grep ^IMAGE_FSTYPES
IMAGE_FSTYPES_DEBUGFS="tar.xz ext3"
IMAGE_FSTYPES="tar.xz ext3"

Presumably because I have in my local.conf:
IMAGE_FSTYPES = "tar.xz ext3"

If I update that to be "tar.xz ext3 sdimg" I get error messages such as:
$ bitbake rpi-test-image -e | grep ^IMAGE_FSTYPES
ERROR: 
/home/thomasthorne/work/yocto-rpi/meta-raspberrypi/recipes-core/images/rpi-test-image.bb:
 No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdimg' - possibly invalid type 
name or missing support class
ERROR: 
/home/thomasthorne/work/yocto-rpi/meta-raspberrypi/recipes-core/images/rpi-hwup-image.bb:
 No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdimg' - possibly invalid type 
name or missing support class
ERROR: 
/home/thomasthorne/work/yocto-rpi/meta-raspberrypi/recipes-core/images/rpi-basic-image.bb:
 No IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdimg' - possibly invalid type 
name or missing support class
ERROR: /home/thomasthorne/work/rpi-layer/meta-rpi/images/qt5-basic-image.bb: No 
IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdimg' - possibly invalid type name 
or missing support class
ERROR: /home/thomasthorne/work/rpi-layer/meta-rpi/images/console-image.bb: No 
IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdimg' - possibly invalid type name 
or missing support class
ERROR: Failed to parse recipe: 
/home/thomasthorne/work/yocto-rpi/meta-raspberrypi/recipes-core/images/rpi-hwup-image.bb
ERROR: /home/thomasthorne/work/rpi-layer/meta-rpi/images/audio-image.bb: No 
IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdimg' - possibly invalid type name 
or missing support class
ERROR: /home/thomasthorne/work/rpi-layer/meta-rpi/images/qt5-image.bb: No 
IMAGE_CMD defined for IMAGE_FSTYPES entry 'sdimg' - possibly invalid type name 
or missing support class

> If it doesn't say (at least)
>IMAGE_FSTYPES="tar.bz2 ext3 rpi-sdimg"
> then try making those settings in your local.conf

That might help.  I seem to now get:

$ bitbake rpi-test-image -e | grep ^IMAGE_FSTYPES
IMAGE_FSTYPES_DEBUGFS="tar.xz ext3 rpi-sdimg"
IMAGE_FSTYPES="tar.xz ext3 rpi-sdimg"

So the system is happy with the rpi-sdimg but not sdimg on its own.  

Now when I perform `$ bitbake rpi-test-image` I get a few warnings about 
license files and then the baking seems to fail with an error about "dd: failed 
to open '/rpi-test-image-raspberrypi3-20161103111232.rootfs.rpi-sdimg': 
Permission denied". That is documented as do_image_rpi_sdimg failed with 
oe-core in krogoth branch 
https://github.com/agherzan/meta-raspberrypi/issues/30 for the meta-raspberrypi 
layer.  That error is resolved on a krogoth specific branch for the 
meta-raspberrypi later.  Checking out that branch instead of master allows the 
SD card image creation to succeed.  I can now see sdimg files:

$ ls tmp/deploy/images/raspberrypi3/*.rpi-sdimg
tmp/deploy/images/raspberrypi3/rpi-test-image-raspberrypi3-20161103113408.rootfs.rpi-sdimg
tmp/deploy/images/raspberrypi3/rpi-test-image-raspberrypi3.rpi-sdimg

Once again thank you for your assistance.  

If you use the Raspberry Pi StackExchange site, please add your suggestion of 
including rpi-sdimg as an answer to 
http://raspberrypi.stackexchange.com/questions/57155/how-do-i-used-yocto-to-build-an-sdcard-image-for-my-raspberry-pi-3-model-b
  If you do not use that site then I will add an answer with an attribution to 
you & this list later today.  

Grateful Regards, 

Thomas A. F. Thorne  Software Engineer  Net2Edge

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

Re: [yocto] How to add libudev.h

[idealsim]

Ok, i will try to add dev-pkgs to my recipe here  
https://github.com/modjo756/meta-udoo-modjo/blob/krogoth-modjo/qt5-layer/recipes-qt/images/udoo-image-qt5.bb  
and add udev to my local.conf.

I let you know if it's work...
Mickael

Le Thu, 03 Nov 2016 14:03:04 +0100, Burton, Ross  a  
écrit:




On 3 November 2016 at 12:55, idealsim  wrote:

Thanks for your answer.
It seems that i didn't have DEPENDS = "udev".
How i can add it ?
   - to my local.conf
   or
   - to myImage.bb
Regards,


If you want to do compiling inside the image, the easy way is to just  
add dev-pkgs to IMAGE_FEATURES for the image recipe.  This gives you all  
of the >headers for everything installed, which will include the udev  
headers assuming that your image has udev.


Ross




--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to add libudev.h

[Gary Thomas]

On 2016-11-03 13:55, idealsim wrote:

Thanks for your answer.
It seems that i didn't have DEPENDS = "udev".
How i can add it ?
- to my local.conf
or
- to myImage.bb


I would add it to your recipe, then it should build under any circumstance.


Le Thu, 03 Nov 2016 13:29:57 +0100, Gary Thomas  a écrit:


On 2016-11-03 13:19, idealsim wrote:

Hi all, i need to build a lib --> openZwave (on a imx6 card) libudev.h.
I have this error during the build :
/home/root/openzwave-1.4.164/cpp/hidapi/linux/hid.c:44:21: fatal error: 
libudev.h: No such file or directory
I have tried to add udev to my local.conf but this not resolve the problem.
How i can add it to my build please ?


Did you try adding 'udev' to DEPENDS in your recipe?  That's
the way bitbake knows to provide such connections (i.e. how your
recipe can find the appropriate files during build)


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] Shallow git clones?

[Gary Thomas]

I recall seeing some discussion in the past about using shallow
GIT clones when importing repositories?  Is this ever going to
happen?

The reason I ask is that I routinely save the GIT tarballs and
some of them are obscenely obese :-(  The worst of the bunch
is the device firmware for the RaspberryPi (as of today):
  -rw-rw-r-- 1 gthomas gthomas 6321877646 Nov  3 12:13 
git2_github.com.raspberrypi.firmware.git.tar.gz

This particular tar file increased by more than 300MB since
the last time I downloaded it (only 2016-09-13!)  I routinely
slosh these files across the oceans (sometimes using tin cans
and strings it seems) and this can be very tedious.  Is there
anything that can be done to make these files a bit more manageable?

Note: the RaspberryPi files are not the only offenders.  Take
a look at the really big ones on my download mirror (~1GB or larger):
  912558047 Jun  3  2015 git2_git.yoctoproject.org.linux-yocto-3.14.git.tar.gz
  916869431 Sep 18 16:54 git2_git.yoctoproject.org.linux-yocto-4.4.git.tar.gz
  917066415 Mar  8  2011 chrome-11.0.686.0.tar.bz2
  929710560 Jun  5  2014 git2_git.yoctoproject.org.linux-yocto-3.10.git.tar.gz
  975438005 May 14  2015 git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz
  997340641 Jan  4  2013 
git2_dev.omapzoom.org.pub.scm.integration.kernel-ubuntu.git.tar.gz
 1013093794 Jul 22  2011 chrome-14.0.825.0.tar.bz2
 1097457194 Jul  9  2015 git2_github.com.Itseez.opencv.git.tar.gz
 1101241868 Jul 15 15:44 git2_git.freescale.com.ppc.sdk.linux.git.tar.gz
 1167801376 Oct 24  2013 
git2_git.kernel.org.pub.scm.linux.kernel.git.stable.linux-stable.git.tar.gz
 1192994858 Nov 24  2014 git2_github.com.Freescale.linux-mainline.git.tar.gz
 1399737300 Mar 30  2010 
git_git.kernel.org.pub.scm.linux.kernel.git.tmlind.linux-omap-2.6.git.tar.gz
 1455878541 Feb 22  2016 git2_github.com.Freescale.linux-fslc.git.tar.gz
 1637597724 Aug 11 09:45 git2_git.freescale.com.imx.linux-2.6-imx.git.tar.gz
 1785320074 Aug 15  2012 git2_github.com.mirrors.gcc.git.tar.gz
 1787717120 Oct 11 10:28 
git2_git.ti.com.ti-linux-kernel.ti-linux-kernel.git.tar.gz
 2070939344 Nov  3 12:11 git2_github.com.raspberrypi.linux.git.tar.gz
 2478557202 Aug 10 11:47 git2_github.com.boundarydevices.linux-imx6.git.tar.gz
 2525826872 Jul 12 16:42 git2_github.com.gcc-mirror.gcc.tar.gz
 6321877646 Nov  3 12:13 git2_github.com.raspberrypi.firmware.git.tar.gz

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] How to add libudev.h

[Burton, Ross]

On 3 November 2016 at 12:55, idealsim  wrote:

> Thanks for your answer.
> It seems that i didn't have DEPENDS = "udev".
> How i can add it ?
> - to my local.conf
> or
> - to myImage.bb
> Regards,
>

If you want to do compiling inside the image, the easy way is to just add
dev-pkgs to IMAGE_FEATURES for the image recipe.  This gives you all of the
headers for everything installed, which will include the udev headers
assuming that your image has udev.

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 03/11/16 11:34, Joshua Lock wrote:

Not to worry, I used a CentOS container to test this myself:

# lsb_release -ir
Distributor ID: CentOS
Release:7.2.1511



I got the same result.


The problem is that we check multiple sources for a distro's name,
favouring the output of lsb_release -ir.

If you have lsb_release available your system is reported as CentOS,
otherwise we fall back to reading os-release or redhat-release and get
CentOSLinux.



It appears that I got lsb_release on my CentOS host by installing the 
Google Chrome RPM, which required lsb >= 4.0.



I've filed a bug to track this issue:

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



Thanks, tracking it.

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

Re: [yocto] How to add libudev.h

[idealsim]

Thanks for your answer.
It seems that i didn't have DEPENDS = "udev".
How i can add it ?
- to my local.conf
or
- to myImage.bb
Regards,


Le Thu, 03 Nov 2016 13:29:57 +0100, Gary Thomas  a  
écrit:



On 2016-11-03 13:19, idealsim wrote:

Hi all, i need to build a lib --> openZwave (on a imx6 card) libudev.h.
I have this error during the build :
/home/root/openzwave-1.4.164/cpp/hidapi/linux/hid.c:44:21: fatal error:  
libudev.h: No such file or directory
I have tried to add udev to my local.conf but this not resolve the  
problem.

How i can add it to my build please ?


Did you try adding 'udev' to DEPENDS in your recipe?  That's
the way bitbake knows to provide such connections (i.e. how your
recipe can find the appropriate files during build)




--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to add libudev.h

[Gary Thomas]

On 2016-11-03 13:19, idealsim wrote:

Hi all, i need to build a lib --> openZwave (on a imx6 card) libudev.h.
I have this error during the build :
/home/root/openzwave-1.4.164/cpp/hidapi/linux/hid.c:44:21: fatal error: 
libudev.h: No such file or directory
I have tried to add udev to my local.conf but this not resolve the problem.
How i can add it to my build please ?


Did you try adding 'udev' to DEPENDS in your recipe?  That's
the way bitbake knows to provide such connections (i.e. how your
recipe can find the appropriate files during build)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] How to add libudev.h

[idealsim]

Hi all, i need to build a lib --> openZwave (on a imx6 card) libudev.h.
I have this error during the build :
/home/root/openzwave-1.4.164/cpp/hidapi/linux/hid.c:44:21: fatal error:  
libudev.h: No such file or directory

I have tried to add udev to my local.conf but this not resolve the problem.
How i can add it to my build please ?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Access Control List (ACL) permissions attributes not getting preserved in rootfs

[Kumar, Shrawan]

Hello Team ,

I am trying to set extended attributes using below post inst . I am able to 
preserve the setcap and smack attributes in the ext4 image. However, I am 
getting "Invalid argument " when I run getfacl/setfacl in qemu target . As said 
earlier all the 3 attributes are seen using devshell in the rootfs folder.

pkg_postinst_${PN}() {
  
setfacl -m u:user2:r-- $D${bindir}/helloworld
setcap cap_net_raw+ep  $D${bindir}/helloworld
chsmack -a "helloWorldAccessLabel" -e "helloWorldExecuteLabel" 
$D${bindir}/helloworld
 
}


When I was using " e2fsprogs_1.42.9.bb the POSIX caps and smack rules were not 
getting preserved but acl attributes were getting preserved now opposite is 
happening .


@Joshua/Team
Can somebody help here ? This is bit urgent and I have been struggling for 
quite some time.

Note :I have set the inode size to be 256 while creating the ext4 image.


Thanks and REgads
Shrawan



-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Kumar, Shrawan
Sent: Thursday, October 27, 2016 6:26 PM
To: Joshua G Lock; yocto@yoctoproject.org
Subject: Re: [yocto] Access Control List (ACL) permissions attributes not 
getting preserved in rootfs

Hello All,

Further update on this issue , migrated to "e2fsprogs_1.43.bb"  from 
"e2fsprogs_1.42.9.bb" . It is observed that the ACL permission set are visible 
on dev-shell  but when qemu is launched we get below error :

root@qemux86:#getfacl /usr/bin/helloworld
getfacl: /usr/bin/helloworld: Invalid argument


Also,
 
root@qemux86:# setfacl -m u:user2:r-- /usr/bin/helloworld 
   setfacl: /usr/bin/helloworld: Invalid argument




Thanks and Regards
Shrawan




-Original Message-
From: Joshua G Lock [mailto:joshua.g.l...@linux.intel.com]
Sent: Friday, August 12, 2016 7:22 PM
To: Kumar, Shrawan; yocto@yoctoproject.org
Subject: Re: [yocto] Access Control List (ACL) permissions attributes not 
getting preserved in rootfs

On Fri, 2016-08-12 at 12:33 +, Kumar, Shrawan wrote:
> Hello All,
>  
> I am  using  poky “ jethro”  , and  though  one of my recipe, I have 
> created user1 & user2 and then trying to set ACL rules  on 
> “helloworld” bin as below :
>  
>  
> do_install() {
>     install -d ${D}${bindir}
>     install -m 0700 helloworld ${D}${bindir}
>     install -d ${D}/lib/systemd/system
>     install -m 0700 hello.service 
> ${D}/lib/systemd/system/
>     chown    user1:group1 ${D}${bindir}/helloworld
>        setfacl -m u:user2:r-- ${D}${bindir}/helloworld }
>  
>  
> è When I see   on the devshell ( bitbake HelloWorld –c devshell)  :
> poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> minimal/1.0-r0/rootfs/usr/bin# getfacl helloworld    , I could see 
> that ACL permissions are set correctly as below :
> -    # file: helloworld
> -    # owner: user1
> -    # group: group1
> -    user::rwx
> -    user:user2:r--
> -    group::---
> -    mask::r--
> -    other::---
>  
> However, It does not seems to be getting preserved in rootfs. :
> /poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> minimal/1.0-r0/rootfs/usr/bin# getfacl helloworld # file: helloworld #
> owner: user1 # group: group1 user::rwx
> group::---
> other::---
>  
> quick help  here would be highly appreciated

This is due to the fact that we don't currently have a mechanism to preserve 
xattr through to image construction[1].

The largest barrier for doig so is that the package managers (certainly dpkg 
and rpm) don't have any support for xattrs in packages (an image is populated 
via the package manager).

To the best of my knowledge the only option for adding some xattr/ACL is to use 
a postinst[2] to set the attributes after the package has been installed.

Regards,

Joshua

1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9858
2. http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#new-
recipe-post-installation-scripts

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

[Gary Thomas]

On 2016-11-03 10:21, Thomas Thorne wrote:

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




No, files such as that not turning up is exactly what I am asking about.



thomasthorne@thorne-ul-dt:~/work/rpi-layer/build$ ls 
tmp/deploy/images/raspberrypi3/*.rpi-sdimg

ls: cannot access 'tmp/deploy/images/raspberrypi3/*.rpi-sdimg': No such file or 
directory

thomasthorne@thorne-ul-dt:~/work/rpi-layer/build$ ls 
tmp/deploy/images/raspberrypi2/*.rpi-sdimg

ls: cannot access 'tmp/deploy/images/raspberrypi2/*.rpi-sdimg': No such file or 
directory



I have tried building for Pi 2 and Pi 3.  rpi-test-image, rpi-basic-image, 
console-image, core-image-minimal,
core-image-full but none of them seem to have generated an SD image.  Plenty of 
other files I could put together but no
ready formed image to dd across.


What do you get from this?
  % bitbake rpi-test-image -e | grep ^IMAGE_FSTYPES

If it doesn't say (at least)
  IMAGE_FSTYPES="tar.bz2 ext3 rpi-sdimg"
then try making those settings in your local.conf

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
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?

[Thomas Thorne]

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

No, files such as that not turning up is exactly what I am asking about.

thomasthorne@thorne-ul-dt:~/work/rpi-layer/build$ ls 
tmp/deploy/images/raspberrypi3/*.rpi-sdimg
ls: cannot access 'tmp/deploy/images/raspberrypi3/*.rpi-sdimg': No such file or 
directory
thomasthorne@thorne-ul-dt:~/work/rpi-layer/build$ ls 
tmp/deploy/images/raspberrypi2/*.rpi-sdimg
ls: cannot access 'tmp/deploy/images/raspberrypi2/*.rpi-sdimg': No such file or 
directory

I have tried building for Pi 2 and Pi 3.  rpi-test-image, rpi-basic-image, 
console-image, core-image-minimal, core-image-full but none of them seem to 
have generated an SD image.  Plenty of other files I could put together but no 
ready formed image to dd across.

Thomas A. F. Thorne  Software Engineer  
Net2Edge
-- 
___
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 3 November 2016 at 09:57, Mike Looijmans  wrote:

> Would it be safe to store the sstate-cache for a bunch of builds into a
> single directory, with builds running in parallel contributing to that?
>
> Each build would be using a different set of layers, different machines,
> and building different images, but there would be a lot of common things
> (usually they all refer to the same OE branches).
>
> We use a build server to share out sstate-cache for various builds, but as
> projects are getting added, it's getting more complicated with projects
> using the sstate-caches of other projects. It would make things quite
> simple if all builds just pointed to the same sstate-cache directory, so
> they could share whatever they want.
>

Mine all share a single sstate cache, as that's pretty much the point.  If
you're targetting different machines then there's a pretty good chance
there's no overlap anyway.

sstate fetch is basically "does a file with this recipe+sha exist", so as
long as files are written atomically then there's no race conditions.
 sstate write is done atomically to a temporary file which then then mv'd
to the real filename, so the only race here is that two parallel bitbakes
doing exactly the same build configuration (ie, same hash) can both not
find anything in sstate, both rebuild, and both write to sstate.  As the
write is atomic, worst case is more work done than required.

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

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

[Joshua Lock]

On Wed, 2016-11-02 at 21:31 +, Joshua Lock wrote:
> 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?

Not to worry, I used a CentOS container to test this myself:

# lsb_release -ir
Distributor ID: CentOS
Release:7.2.1511

The problem is that we check multiple sources for a distro's name,
favouring the output of lsb_release -ir.

If you have lsb_release available your system is reported as CentOS,
otherwise we fall back to reading os-release or redhat-release and get
CentOSLinux.

I've filed a bug to track this issue:

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

Regards,

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

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

[Mike Looijmans]

On 02-11-16 15:17, Burton, Ross wrote:


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.


Could I take this one step further:

Would it be safe to store the sstate-cache for a bunch of builds into a single 
directory, with builds running in parallel contributing to that?


Each build would be using a different set of layers, different machines, and 
building different images, but there would be a lot of common things (usually 
they all refer to the same OE branches).


We use a build server to share out sstate-cache for various builds, but as 
projects are getting added, it's getting more complicated with projects using 
the sstate-caches of other projects. It would make things quite simple if all 
builds just pointed to the same sstate-cache directory, so they could share 
whatever they want.


Would that work? I'd think so, but never dared to actually make it so...


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
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