date:20140410

From: Denys Dmytriyenko 

* Use fbdev video driver for xserver-xorg
* Recommend installing device tree DTB files into rootfs /boot directory
* Switch back to uImage kernel format from zImage, as U-boot was not updated
  - default has changed to zImage in newer U-boot 2013.10+, but we use 2013.07
* Correct copy/paste typo in serial console

Signed-off-by: Denys Dmytriyenko 
---
 meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
b/meta-yocto-bsp/conf/machine/beaglebone.conf
index f2ef0cf..4263715 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
@@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 XSERVER ?= "xserver-xorg \
xf86-input-evdev \
xf86-input-mouse \
-   xf86-video-omapfb \
+   xf86-video-fbdev \
xf86-input-keyboard"
 
-# Ship all kernel modules by default
-MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
+MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"
 
 EXTRA_IMAGEDEPENDS += "u-boot"
 
@@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
 IMAGE_FSTYPES += "tar.bz2 jffs2"
 EXTRA_IMAGECMD_jffs2 = "-lnp "
 
-SERIAL_CONSOLE = "115200 ttyO2"
+SERIAL_CONSOLE = "115200 ttyO0"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_VERSION_linux-yocto ?= "3.14%"
 
-KERNEL_IMAGETYPE = "zImage"
+KERNEL_IMAGETYPE = "uImage"
 KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
+KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
 
 SPL_BINARY = "MLO"
 UBOOT_SUFFIX = "img"
-- 
1.9.1

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

[yocto] [meta-yocto][PATCH 2/2] README.hardware: update with Texas Instruments Beaglebone instructions

From: Denys Dmytriyenko 

Replaces outdated Beagleboard instructions with Beaglebone Black (and White).

Signed-off-by: Denys Dmytriyenko 
---
 README.hardware | 78 +
 1 file changed, 78 insertions(+)

diff --git a/README.hardware b/README.hardware
index 68e1dd2..37fdab0 100644
--- a/README.hardware
+++ b/README.hardware
@@ -46,6 +46,7 @@ Hardware Reference Boards
 
 The following boards are supported by the meta-yocto-bsp layer:
 
+  * Texas Instruments Beaglebone (beaglebone)
   * Freescale MPC8315E-RDB (mpc8315e-rdb)
 
 For more information see the board's section below. The appropriate MACHINE
@@ -179,6 +180,83 @@ USB Device:
   
http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blob_plain;f=doc/usbkey.txt;hb=HEAD
 
 
+Texas Instruments Beaglebone (beaglebone)
+=
+
+The Beaglebone is an ARM Cortex-A8 development board with USB, Ethernet, 2D/3D
+accelerated graphics, audio, serial, JTAG, and SD/MMC. The Black adds a faster
+CPU, more RAM, eMMC flash and a micro HDMI port. The beaglebone MACHINE is
+tested on the following platforms:
+
+  o Beaglebone Black A6
+  o Beaglebone A6 (the original "White" model)
+
+The Beaglebone Black has eMMC, while the White does not. Pressing the USER/BOOT
+button when powering on will temporarily change the boot order. But for the 
sake
+of simplicity, these instructions assume you have erased the eMMC on the Black,
+so its boot behavior matches that of the White and boots off of SD card. To do
+this, issue the following commands from the u-boot prompt:
+
+# mmc dev 1
+# mmc erase 0 512
+
+To further tailor these instructions for your board, please refer to the
+documentation at http://www.beagleboard.org/bone and 
http://www.beagleboard.org/black
+
+From a Linux system with access to the image files perform the following steps
+as root, replacing mmcblk0* with the SD card device on your machine (such as 
sdc
+if used via a usb card reader):
+
+  1. Partition and format an SD card:
+ # fdisk -lu /dev/mmcblk0
+
+ Disk /dev/mmcblk0: 3951 MB, 3951034368 bytes
+ 255 heads, 63 sectors/track, 480 cylinders, total 7716864 sectors
+ Units = sectors of 1 * 512 = 512 bytes
+
+ Device Boot  Start End  Blocks  Id System
+ /dev/mmcblk0p1   *  63  144584   72261   c Win95 FAT32 
(LBA)
+ /dev/mmcblk0p2  144585  465884  160650  83 Linux
+
+ # mkfs.vfat -F 16 -n "boot" /dev/mmcblk0p1
+ # mke2fs -j -L "root" /dev/mmcblk0p2
+
+  The following assumes the SD card partitions 1 and 2 are mounted at
+  /media/boot and /media/root respectively. Removing the card and reinserting
+  it will do just that on most modern Linux desktop environments.
+
+  The files referenced below are made available after the build in
+  build/tmp/deploy/images.
+
+  2. Install the boot loaders
+ # cp MLO-beaglebone /media/boot/MLO
+ # cp u-boot-beaglebone.img /media/boot/u-boot.img
+
+  3. Install the root filesystem
+ # tar x -C /media/root -f core-image-$IMAGE_TYPE-beaglebone.tar.bz2
+
+  4. If using core-image-base or core-image-sato images, the SD card is ready
+ and rootfs already contains the kernel, modules and device tree (DTB)
+ files necessary to be booted with U-boot's default configuration, so
+ skip directly to step 8.
+ For core-image-minimal, proceed through next steps.
+
+  5. If using core-image-minimal rootfs, install the modules
+ # tar x -C /media/root -f modules-beaglebone.tgz
+
+  6. If using core-image-minimal rootfs, install the kernel uImage into /boot
+ directory of rootfs
+ # cp uImage-beaglebone.bin /media/root/boot/uImage
+
+  7. If using core-image-minimal rootfs, also install device tree (DTB) files
+ into /boot directory of rootfs
+ # cp uImage-am335x-bone.dtb /media/root/boot/am335x-bone.dtb
+ # cp uImage-am335x-boneblack.dtb /media/root/boot/am335x-boneblack.dtb
+
+  8. Unmount the SD partitions, insert the SD card into the Beaglebone, and
+ boot the Beaglebone
+
+
 Freescale MPC8315E-RDB (mpc8315e-rdb)
 =
 
-- 
1.9.1

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

Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback

2014-04-10 Thread Meenakumari Shedole

Hi All.

By using all latest version packages, Vaapi able to set the foreign window but 
there is random changes between Application and VaapiSink in SetWindowId, Play 
and Stop state.

Below are few of the different behaviors.

a.  To play 1080p media, First SetWindowID, Play and Stop. ( It works with 
foreign window)
b.  To play 1080p media, Second time only Play and Stop. (It won't work) and 
crash the daemon.
c.  start the daemon and app
d.  This time again SetWindowID, Play and Stop. (It works with foreign window)
e.  Only Play and Stop.( it works and won't crash the daemon also)
f.   Next time again setWindowID, Play and Stop. (it won't works)
g.  Next again to SetWindowID, Play and Stop.(it works)

Some times when I use only Play and Stop it open it's own window and start to 
play.

Regards
Meenakumari Shedole

From: Meenakumari Shedole
Sent: Friday, April 04, 2014 4:19 PM
To: Beauchesne, Gwenole; yocto@yoctoproject.org
Cc: Dipesh Karmakar
Subject: RE: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback

Thanks for your resposne Gwenole.

I downloaded updated gstreamer-vaapi-0.5.8 and GStreamer-0.10.36 with other 
dependency plaugins and va deriver but after manually install no luck to 
execute vaapisink.

can you please suggest, vaapi dependencies and their version to build.

Regards
Meena.

From: Beauchesne, Gwenole [gwenole.beauche...@intel.com]
Sent: Thursday, April 03, 2014 8:22 PM
To: Meenakumari Shedole; yocto@yoctoproject.org
Cc: Dipesh Karmakar
Subject: RE: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback

Hi,

> I have checked vaapisink source, it seems its supporting overlay on foreign X
> window.
> https://gitorious.org/vaapi/gstreamer-
> vaapi/source/643d35e87a67376af9cd89cd868666368b105ac3:gst/vaapisink/gs
> tvaapisink.c
> static gboolean gst_vaapisink_implements_interface_supported();
> static gboolean gst_vaapisink_ensure_window_xid();

The version you mention looks very old. I have integrated a fix from another 
user, who has been successfully using gstreamer-vaapi with GStreamer 0.10 in a 
scenario you describe (vaapisink + foreign window). Please update your 
gstreamer-vaapi version to at least 0.5.8. Or, the current git master tree. 
Other branches are not maintained any more. The fix I have in mind was f8666e2.

Regards,
Gwenole.

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Friday, March 28, 2014 4:42 PM
> To: Meenakumari Shedole
> Cc: yocto@yoctoproject.org; Dipesh Karmakar
> Subject: Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4
> playback
>
> On 28 March 2014 06:05, Meenakumari Shedole 
> wrote:
> > 1. playbin2 + avi/3gp is working properly because of xvimagesink is used
> interally.
> > 2. playbin2 + mp4 is not taking vaapi sink, we need to manually set video-
> sink=vaapisink.
> >Also we are getting arbitrary crash while setting the qml video window id
> to the vaapi sink.
> >So we are not getting any single pipe to play mp4/avi/3gp stuff.
>
> The important question is what recipe are you using to get the vaapi
> elements?
>
> What happens if you use vaapisink with AVI/3GP?  You should still get some
> acceleration.
>
> Note that especially when using vaapi sink you need to wait for the sink to
> create the window and then reparent it, you can't provide your own X
> window to vaapisink.  This is the usual cause for breakage.  Do testing with
> gst-launch before attempting to use your own application.
>
> Ross
>
>
> ::DISCLAIMER::
> --
> --
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive late or
> incomplete, or may contain viruses in transmission. The e mail and its
> contents (with or without referred errors) shall therefore not attach any
> liability on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the views or opinions of HCL or its
> affiliates. Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and / or publication of this message without the
> prior written consent of authorized representative of HCL is strictly
> prohibited. If you have received this email in error please delete it and 
> notify
> the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
>
> --
> --
-- 
___

Re: [yocto] Dogfooding and usability testing Toaster

On Wednesday 09 April 2014 16:39:38 Chris Larson wrote:
> On Wed, Apr 9, 2014 at 4:33 PM, Rudolf Streif 
wrote:
> > That is exciting. I just ran with it and started a build with toaster in
> > 
> > the background. A couple of observations from the get-go:
> >- South 0.8.4 is also needed in addition to Django. The Toaster Wiki
> >[1] does not say that but the Contribute to Toaster page [2] does.
> >- You need to run 'sudo pip install ...' for Django and South
> >otherwise the installation fails with 'permission denied' for
> >/usr/lib/python2.7
> >- Clicking on "Show me the manual" in the Toaster UI directs to [3]
> >which requires a log in
> >- Is it possible to relocate/rename the toaster.sqlite database via
> >configuration setting? If so, could I use the same database for
> >different
> >build environments?
> 
> Side note: you can use pip install --user ... rather than sudo pip, to
> install it to your user site-packages directory under ~/.local, which won't
> impact the rest of the system.

I'd like to see this documented using virtualenv [1] to install the additional 
packages - it's so much cleaner than any other solution.

Cheers,
Paul

[1] For those who aren't familiar with virtualenv:
http://simononsoftware.com/virtualenv-tutorial/

-- 

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

Re: [yocto] Dogfooding and usability testing Toaster

2014-04-10 Thread Barros Pena, Belen

On 09/04/2014 21:52, "Philip Balister"  wrote:

>On 04/09/2014 03:43 AM, Barros Pena, Belen wrote:
>> Hi all,
>> 
>> I am looking into collecting feedback on the first version of Toaster
>> 
>> https://www.yoctoproject.org/blogs/belenbarrospena/2014/eye-candy
>> 
>> which will be out with Yocto Project 1.6. There are 2 things I'd like to
>> do:
>> 
>> 1) Dogfooding
>> 
>> Once the release is out, it would be great to have people trying Toaster
>> for real work stuff, and telling us how it went. I am of course
>> particularly keen on hearing about what's wrong, so feel free to vent
>>your
>> frustrations with the thing.
>> 
>> 2) (More formal) usability testing
>> 
>> I am also looking into validating the Toaster interface in more
>> conventional ways, which means usability testing. This is done in
>> 30-minute sessions run remotely using screen sharing software, although
>>we
>> can also do it in person if you are going to ELC or the OEDAM. During
>> those 30 minutes you will be asked to do some stuff with Toaster and to
>> speak your mind a lot. I will also ask for your permission to record the
>> session, which you can of course refuse.
>
>Belen, can you add this to the OEDAM wiki page? We should have a good
>variety of people there to give feedback.

Good point. It also gave me the excuse to request an account for the wiki.
Will do as soon as I get login details.

Thanks!

Belén

>
>Philip
>
>> 
>> If you would like to volunteer for this (which is useful and important
>> stuff), get in touch with me (I am belen in IRC, or email me). I would
>> normally give out something in return for your time, but things are
>>tight
>> right now, so I'm afraid all you'll get on this occasion is a
>>heartwarming
>> thank you.
>> 
>> Cheers
>> 
>> Belén
>> 

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

Re: [yocto] PREFERRED_PROVIDER entry in local.conf

2014-04-10 Thread Romain

Hi, any clue ?

Thanks and Regards
Romain

On 8 April 2014 18:10, Romain  wrote:

> Hello all,
>
> While building an image I get those notes, and I would like to lock down
> the providers for sshd and jpeg :
> NOTE: multiple providers are available for runtime sshd (openssh, dropbear)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match sshd
> NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg
>
> I tried a few syntax in the local.conf, but none of them seem to work :
> PREFERRED_PROVIDER_virtual/sshd = "ssh-server-openssh"
> PREFERRED_PROVIDER_sshd = "ssh-server-openssh"
> PREFERRED_PROVIDER_sshd = "openssh"
> PREFERRED_PROVIDER_openssh = "sshd"
>
> Thanks !
> Romain
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Dogfooding and usability testing Toaster

2014-04-10 Thread Barros Pena, Belen

On 10/04/2014 11:14, "Paul Eggleton"  wrote:

>On Wednesday 09 April 2014 16:39:38 Chris Larson wrote:
>> On Wed, Apr 9, 2014 at 4:33 PM, Rudolf Streif
>wrote:
>> > That is exciting. I just ran with it and started a build with toaster
>>in
>> > 
>> > the background. A couple of observations from the get-go:
>> >- South 0.8.4 is also needed in addition to Django. The Toaster
>>Wiki
>> >[1] does not say that but the Contribute to Toaster page [2] does.
>> >- You need to run 'sudo pip install ...' for Django and South
>> >otherwise the installation fails with 'permission denied' for
>> >/usr/lib/python2.7

Thanks for this. We'll make sure to update the wiki.


>> >- Clicking on "Show me the manual" in the Toaster UI directs to [3]
>> >which requires a log in

Ah, yes: the manual is not ready yet, so its web page is not published.
That's why you are being asked to log in. It should be ready by release
time.

>> >- Is it possible to relocate/rename the toaster.sqlite database via
>> >configuration setting? If so, could I use the same database for
>> >different
>> >build environments?

I believe you can, although Alex Damien is the one who can explain the
details. The information here:

https://wiki.yoctoproject.org/wiki/Toaster#Setting_up_a_Toaster_Instance_on
_a_Remote_Host

might also answer some questions.

>> 
>> Side note: you can use pip install --user ... rather than sudo pip, to
>> install it to your user site-packages directory under ~/.local, which
>>won't
>> impact the rest of the system.
>
>I'd like to see this documented using virtualenv [1] to install the
>additional 
>packages - it's so much cleaner than any other solution.

Good point. I'll look into getting that going.

Belén

>
>Cheers,
>Paul
>
>[1] For those who aren't familiar with virtualenv:
>http://simononsoftware.com/virtualenv-tutorial/
>
>-- 
>
>Paul Eggleton
>Intel Open Source Technology Centre
>-- 
>___
>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] PREFERRED_PROVIDER entry in local.conf

2014-04-10 Thread Gaurang Shastri

Dear Romain,

Did you try writing in "meta/conf/distro/include/default-providers.inc "
like below:

==
PREFERRED_PROVIDER_virtual/sshd ?= "openssh"
PREFERRED_PROVIDER_virtual/jpeg ?= "jpeg"
==

//Gaurang Shastri


On Thu, Apr 10, 2014 at 3:51 PM, Romain  wrote:

> Hi, any clue ?
>
> Thanks and Regards
> Romain
>
> On 8 April 2014 18:10, Romain  wrote:
>
>> Hello all,
>>
>> While building an image I get those notes, and I would like to lock down
>> the providers for sshd and jpeg :
>> NOTE: multiple providers are available for runtime sshd (openssh,
>> dropbear)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match sshd
>> NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo)
>> NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg
>>
>> I tried a few syntax in the local.conf, but none of them seem to work :
>> PREFERRED_PROVIDER_virtual/sshd = "ssh-server-openssh"
>> PREFERRED_PROVIDER_sshd = "ssh-server-openssh"
>> PREFERRED_PROVIDER_sshd = "openssh"
>> PREFERRED_PROVIDER_openssh = "sshd"
>>
>> Thanks !
>> Romain
>>
>
>
> --
> ___
> 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] copying media files to qemux86

2014-04-10 Thread Bhushan S

Hi Cristian,

I meant passing the --enable- to ./configure.
# cd gst-plugins-base
# ./configure --enable-audiotestsrc --enable-videotestsrc ..

Regards,
--bhushan



On Tue, Apr 8, 2014 at 11:14 PM, Iorga, Cristian
wrote:

>  Hello,
>
> Sorry, what exactly to enable in ./configure?
>
> Regards,
>
> Cristian
>
>
>
>
>
> *From:* Bhushan S [mailto:bhushan...@gmail.com]
> *Sent:* Tuesday, April 8, 2014 2:48 PM
>
> *To:* Iorga, Cristian
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] copying media files to qemux86
>
>
>
> Hello Cristian,
>
>
>
> Had a similar doubt as described by Paul in Bug 
> 5589
> .
>
> Basically i wanted the "audiotestsrc" and "videotestsrc" plugins from
> gst-plugins-base and even though *-base was configured with those options,
>
> I still didn't see it in gst-inspect on qemux86.
>
> only after I added it to "CORE_IMAGE_EXTRA_INSTALL" i got it in the final
> image.
>
>
>
> Normal understanding was to enable it while ./configure and that should
> work. Am I missing something here ?
>
>
>
> Regards,
>
> --bhushan
>
>
>
>
>
> On Fri, Apr 4, 2014 at 7:20 PM, Iorga, Cristian 
> wrote:
>
>   Hello,
>
> What kind of troubles with gst-plugins-base?
>
> See YB5589: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5589
>
> Maybe there is a hint in there, and the meta gst package will help..
>
> /Cristian
>
>
>
> *From:* Bhushan S [mailto:bhushan...@gmail.com]
> *Sent:* Friday, April 4, 2014 1:35 PM
> *To:* Iorga, Cristian
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] copying media files to qemux86
>
>
>
> Yes Cristian.
>
> My earlier attempt with scp was unsuccessful (probably lack of ssh
> support).
>
>
>
> Currently I'm stuck with enabling gst-plugins-ugly package and plugins
> from gst-plugins-base package
>
>
>
>
>
> On Wed, Apr 2, 2014 at 5:44 PM, Iorga, Cristian 
> wrote:
>
>   Hello,
>
>
>
> By  media files, you mean music or video files?
>
> If so, depending on the image (if it has ssh support), you can copy into
> /home/root using scp after you boot the image.
>
> I have use this to test mp3 playback, for example with some audio files.
>
>
>
> Regards,
>
> Cristian Iorga
>
> YP
>
> Intel Corporation
>
>
>
> *From:* yocto-boun...@yoctoproject.org [mailto:
> yocto-boun...@yoctoproject.org] *On Behalf Of *Bhushan Shirsath
> *Sent:* Wednesday, April 2, 2014 2:07 PM
> *To:* yocto@yoctoproject.org
> *Subject:* [yocto] copying media files to qemux86
>
>
>
> Hi,
>
>
>
> I'm able to successfully launch "runqemu qemux86".
>
> Now i intend to test the media libs built using Yocto on qemu currently.
>
> Is it possible to transfer/copy media files to qemux86 emulator ?
>
>
>
> I tried copying files to tmp/sysroots/qemux86/ but it didn't work.
>
>
>
> Thanks,
>
> --bhushan
>
>
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PREFERRED_PROVIDER entry in local.conf

On Thursday 10 April 2014 16:55:15 Gaurang Shastri wrote:
> Did you try writing in "meta/conf/distro/include/default-providers.inc "
> like below:
> 
> ==
> PREFERRED_PROVIDER_virtual/sshd ?= "openssh"
> PREFERRED_PROVIDER_virtual/jpeg ?= "jpeg"
> ==

You shouldn't modify this file directly - modifications should go into your 
custom distro config. In any case, the above is not going to do anything 
because there isn't any such target as virtual/sshd or virtual/jpeg.

Cheers,
Paul

-- 

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

Re: [yocto] PREFERRED_PROVIDER entry in local.conf

Hi Romain,

On Tuesday 08 April 2014 18:10:11 Romain wrote:
> While building an image I get those notes, and I would like to lock down
> the providers for sshd and jpeg :
> NOTE: multiple providers are available for runtime sshd (openssh, dropbear)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match sshd
> NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg
> 
> I tried a few syntax in the local.conf, but none of them seem to work :
> PREFERRED_PROVIDER_virtual/sshd = "ssh-server-openssh"
> PREFERRED_PROVIDER_sshd = "ssh-server-openssh"
> PREFERRED_PROVIDER_sshd = "openssh"
> PREFERRED_PROVIDER_openssh = "sshd"

Of these, only PREFERRED_PROVIDER_sshd = "openssh" would be expected to work. 
However, testing it locally I think there is a problem here; I'll do some more 
investigation. 

That said, one workaround would be to find where you have "sshd" in RDEPENDS or 
IMAGE_INSTALL and just use the specific name (openssh-sshd) in there instead. 
(I'm assuming this is in one of your layers or modifications since we don't 
have runtime dependencies on "sshd" in the core itself.)

Cheers,
Paul

-- 

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

Re: [yocto] [meta-yocto][PATCH 1/2] beaglebone.conf: configuration updates

Hi Denys,

With this patch applied and the updated README I can boot a Beaglebone
Black (rev A6) with a default yocto image/config (I've used
core-image-sato-sdk FWIW). Everything seems fine, I ran a bunch of tests
on the image, except for X - it doesn't start :(.
I've built with fbdev and omapfb too.

X log for fbdev: 
http://pastebin.com/sqNc35U0

for omapfb:
http://pastebin.com/fMkzMW8U

Is there anything else that needs to changed/added? I could add a
xorg.conf on the image too, but then it beats the point...

Cheers,
Stefan


On Thu, 2014-04-10 at 04:02 -0400, Denys Dmytriyenko wrote:
> From: Denys Dmytriyenko 
> 
> * Use fbdev video driver for xserver-xorg
> * Recommend installing device tree DTB files into rootfs /boot directory
> * Switch back to uImage kernel format from zImage, as U-boot was not updated
>   - default has changed to zImage in newer U-boot 2013.10+, but we use 2013.07
> * Correct copy/paste typo in serial console
> 
> Signed-off-by: Denys Dmytriyenko 
> ---
>  meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
> b/meta-yocto-bsp/conf/machine/beaglebone.conf
> index f2ef0cf..4263715 100644
> --- a/meta-yocto-bsp/conf/machine/beaglebone.conf
> +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
> @@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
>  XSERVER ?= "xserver-xorg \
> xf86-input-evdev \
> xf86-input-mouse \
> -   xf86-video-omapfb \
> +   xf86-video-fbdev \
> xf86-input-keyboard"
>  
> -# Ship all kernel modules by default
> -MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"
>  
>  EXTRA_IMAGEDEPENDS += "u-boot"
>  
> @@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
>  IMAGE_FSTYPES += "tar.bz2 jffs2"
>  EXTRA_IMAGECMD_jffs2 = "-lnp "
>  
> -SERIAL_CONSOLE = "115200 ttyO2"
> +SERIAL_CONSOLE = "115200 ttyO0"
>  
>  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>  PREFERRED_VERSION_linux-yocto ?= "3.14%"
>  
> -KERNEL_IMAGETYPE = "zImage"
> +KERNEL_IMAGETYPE = "uImage"
>  KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
> +KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
>  
>  SPL_BINARY = "MLO"
>  UBOOT_SUFFIX = "img"
> -- 
> 1.9.1
> 

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

Re: [yocto] [meta-yocto][PATCH 1/2] beaglebone.conf: configuration updates




On Thu, 2014-04-10 at 13:36 +, Stanacar, StefanX wrote:
> Hi Denys,
> 
> With this patch applied and the updated README I can boot a Beaglebone
> Black (rev A6) with a default yocto image/config (I've used
> core-image-sato-sdk FWIW). Everything seems fine, I ran a bunch of tests
> on the image, except for X - it doesn't start :(.
> I've built with fbdev and omapfb too.
> 
> X log for fbdev: 
> http://pastebin.com/sqNc35U0
> 
> for omapfb:
> http://pastebin.com/fMkzMW8U
> 
> Is there anything else that needs to changed/added? I could add a
> xorg.conf on the image too, but then it beats the point...
> 

What I was trying to say is that we are missing a .bbappend for
xserver-xf86-config that adds the right xorg.conf (either for fbdev or
omapfb). I'll try to come up with one.

Cheers,
Stefan

> Cheers,
> Stefan
> 
> 
> On Thu, 2014-04-10 at 04:02 -0400, Denys Dmytriyenko wrote:
> > From: Denys Dmytriyenko 
> > 
> > * Use fbdev video driver for xserver-xorg
> > * Recommend installing device tree DTB files into rootfs /boot directory
> > * Switch back to uImage kernel format from zImage, as U-boot was not updated
> >   - default has changed to zImage in newer U-boot 2013.10+, but we use 
> > 2013.07
> > * Correct copy/paste typo in serial console
> > 
> > Signed-off-by: Denys Dmytriyenko 
> > ---
> >  meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
> > b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > index f2ef0cf..4263715 100644
> > --- a/meta-yocto-bsp/conf/machine/beaglebone.conf
> > +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > @@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
> >  XSERVER ?= "xserver-xorg \
> > xf86-input-evdev \
> > xf86-input-mouse \
> > -   xf86-video-omapfb \
> > +   xf86-video-fbdev \
> > xf86-input-keyboard"
> >  
> > -# Ship all kernel modules by default
> > -MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> > +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"
> >  
> >  EXTRA_IMAGEDEPENDS += "u-boot"
> >  
> > @@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
> >  IMAGE_FSTYPES += "tar.bz2 jffs2"
> >  EXTRA_IMAGECMD_jffs2 = "-lnp "
> >  
> > -SERIAL_CONSOLE = "115200 ttyO2"
> > +SERIAL_CONSOLE = "115200 ttyO0"
> >  
> >  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> >  PREFERRED_VERSION_linux-yocto ?= "3.14%"
> >  
> > -KERNEL_IMAGETYPE = "zImage"
> > +KERNEL_IMAGETYPE = "uImage"
> >  KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
> > +KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
> >  
> >  SPL_BINARY = "MLO"
> >  UBOOT_SUFFIX = "img"
> > -- 
> > 1.9.1
> > 
> 

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

Re: [yocto] PREFERRED_PROVIDER entry in local.conf

2014-04-10 Thread Romain

Hi Paul,

I am now using "openssh-sshd" in IMAGE_INSTALL and it solved the problem.
For jpeg unfortunately it can't be solved like this because others recipes
depends on jpeg. I think the PREFERRED_PROVIDER is the only solution to
choose between jpeg and libjpeg-turbo.

Cheers,
Romain


On 10 April 2014 14:31, Paul Eggleton wrote:
>
> Of these, only PREFERRED_PROVIDER_sshd = "openssh" would be expected to
> work.
> However, testing it locally I think there is a problem here; I'll do some
> more
> investigation.
>
> That said, one workaround would be to find where you have "sshd" in
> RDEPENDS or
> IMAGE_INSTALL and just use the specific name (openssh-sshd) in there
> instead.
> (I'm assuming this is in one of your layers or modifications since we don't
> have runtime dependencies on "sshd" in the core itself.)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PREFERRED_PROVIDER entry in local.conf

2014-04-10 Thread Paul Barker

On 10 April 2014 15:53, Romain  wrote:
> Hi Paul,
>
> I am now using "openssh-sshd" in IMAGE_INSTALL and it solved the problem.
> For jpeg unfortunately it can't be solved like this because others recipes
> depends on jpeg. I think the PREFERRED_PROVIDER is the only solution to
> choose between jpeg and libjpeg-turbo.
>

I've had these in my local.conf and working for a long time:

PREFERRED_PROVIDER_jpeg = "jpeg"
PREFERRED_PROVIDER_jpeg-native = "jpeg-native"

Have you tried these?

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PREFERRED_PROVIDER entry in local.conf

On Thursday 10 April 2014 15:53:12 Romain wrote:
> On 10 April 2014 14:31, Paul Eggleton wrote:
> > Of these, only PREFERRED_PROVIDER_sshd = "openssh" would be expected to
> > work. However, testing it locally I think there is a problem here; I'll do
> > some more investigation.
> > 
> > That said, one workaround would be to find where you have "sshd" in
> > RDEPENDS or IMAGE_INSTALL and just use the specific name (openssh-sshd) in
> > there instead. (I'm assuming this is in one of your layers or modifications
> > since we don't have runtime dependencies on "sshd" in the core itself.)
>
> I am now using "openssh-sshd" in IMAGE_INSTALL and it solved the problem.

OK great. FYI I've filed the following bug for this issue:

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

> For jpeg unfortunately it can't be solved like this because others recipes
> depends on jpeg. I think the PREFERRED_PROVIDER is the only solution to
> choose between jpeg and libjpeg-turbo.

So for jpeg, PREFERRED_PROVIDER_jpeg will work, since that is a build-time 
dependency / provider situation which is definitely working.

Cheers,
Paul

-- 

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

[yocto] How to include kernel module without including the kernel in the rootfs?

I just added a custom kernel module to my build, and now my rootfs
includes a copy of my kernel (thus making it too large to fit in my
pinhole sized root partition).

Is there any way to prevent the kernel from being included in the
rootfs?  Do modutils require a kernel image in order to function
properly?

My recipe contains

inherit module

So I'm expecting that the module class does magic that results in the
kernel getting installed.

Is there a flag I can set to say "Don't do that?".

Thanks.

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

Re: [yocto] [meta-yocto][PATCH 1/2] beaglebone.conf: configuration updates




On Thu, 2014-04-10 at 14:14 +, Stanacar, StefanX wrote:
> 
> 
> On Thu, 2014-04-10 at 13:36 +, Stanacar, StefanX wrote:
> > Hi Denys,
> > 
> > With this patch applied and the updated README I can boot a Beaglebone
> > Black (rev A6) with a default yocto image/config (I've used
> > core-image-sato-sdk FWIW). Everything seems fine, I ran a bunch of tests
> > on the image, except for X - it doesn't start :(.
> > I've built with fbdev and omapfb too.
> > 
> > X log for fbdev: 
> > http://pastebin.com/sqNc35U0
> > 
> > for omapfb:
> > http://pastebin.com/fMkzMW8U
> > 
> > Is there anything else that needs to changed/added? I could add a
> > xorg.conf on the image too, but then it beats the point...
> > 
> 
> What I was trying to say is that we are missing a .bbappend for
> xserver-xf86-config that adds the right xorg.conf (either for fbdev or
> omapfb). I'll try to come up with one.


Okay ignore that it didn't helped, I think I know what's missing.. I
need the latest SRCREV_meta for kernel.

Cheers,
Stefan


> Cheers,
> Stefan
> 
> > Cheers,
> > Stefan
> > 
> > 
> > On Thu, 2014-04-10 at 04:02 -0400, Denys Dmytriyenko wrote:
> > > From: Denys Dmytriyenko 
> > > 
> > > * Use fbdev video driver for xserver-xorg
> > > * Recommend installing device tree DTB files into rootfs /boot directory
> > > * Switch back to uImage kernel format from zImage, as U-boot was not 
> > > updated
> > >   - default has changed to zImage in newer U-boot 2013.10+, but we use 
> > > 2013.07
> > > * Correct copy/paste typo in serial console
> > > 
> > > Signed-off-by: Denys Dmytriyenko 
> > > ---
> > >  meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
> > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
> > > b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > index f2ef0cf..4263715 100644
> > > --- a/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > @@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
> > >  XSERVER ?= "xserver-xorg \
> > > xf86-input-evdev \
> > > xf86-input-mouse \
> > > -   xf86-video-omapfb \
> > > +   xf86-video-fbdev \
> > > xf86-input-keyboard"
> > >  
> > > -# Ship all kernel modules by default
> > > -MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> > > +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"
> > >  
> > >  EXTRA_IMAGEDEPENDS += "u-boot"
> > >  
> > > @@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
> > >  IMAGE_FSTYPES += "tar.bz2 jffs2"
> > >  EXTRA_IMAGECMD_jffs2 = "-lnp "
> > >  
> > > -SERIAL_CONSOLE = "115200 ttyO2"
> > > +SERIAL_CONSOLE = "115200 ttyO0"
> > >  
> > >  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> > >  PREFERRED_VERSION_linux-yocto ?= "3.14%"
> > >  
> > > -KERNEL_IMAGETYPE = "zImage"
> > > +KERNEL_IMAGETYPE = "uImage"
> > >  KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
> > > +KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
> > >  
> > >  SPL_BINARY = "MLO"
> > >  UBOOT_SUFFIX = "img"
> > > -- 
> > > 1.9.1
> > > 
> > 
> 

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

Re: [yocto] [meta-yocto][PATCH 1/2] beaglebone.conf: configuration updates

2014-04-10 Thread Bruce Ashfield


On 14-04-10 11:27 AM, Stanacar, StefanX wrote:




On Thu, 2014-04-10 at 14:14 +, Stanacar, StefanX wrote:



On Thu, 2014-04-10 at 13:36 +, Stanacar, StefanX wrote:

Hi Denys,

With this patch applied and the updated README I can boot a Beaglebone
Black (rev A6) with a default yocto image/config (I've used
core-image-sato-sdk FWIW). Everything seems fine, I ran a bunch of tests
on the image, except for X - it doesn't start :(.
I've built with fbdev and omapfb too.

X log for fbdev:
http://pastebin.com/sqNc35U0

for omapfb:
http://pastebin.com/fMkzMW8U

Is there anything else that needs to changed/added? I could add a
xorg.conf on the image too, but then it beats the point...



What I was trying to say is that we are missing a .bbappend for
xserver-xf86-config that adds the right xorg.conf (either for fbdev or
omapfb). I'll try to come up with one.



Okay ignore that it didn't helped, I think I know what's missing.. I
need the latest SRCREV_meta for kernel.


Which I just sent (and which may have prompted your email), so try
the commits I just sent and see if it helps.

Bruce



Cheers,
Stefan



Cheers,
Stefan


Cheers,
Stefan


On Thu, 2014-04-10 at 04:02 -0400, Denys Dmytriyenko wrote:

From: Denys Dmytriyenko 

* Use fbdev video driver for xserver-xorg
* Recommend installing device tree DTB files into rootfs /boot directory
* Switch back to uImage kernel format from zImage, as U-boot was not updated
   - default has changed to zImage in newer U-boot 2013.10+, but we use 2013.07
* Correct copy/paste typo in serial console

Signed-off-by: Denys Dmytriyenko 
---
  meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
b/meta-yocto-bsp/conf/machine/beaglebone.conf
index f2ef0cf..4263715 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
@@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
  XSERVER ?= "xserver-xorg \
 xf86-input-evdev \
 xf86-input-mouse \
-   xf86-video-omapfb \
+   xf86-video-fbdev \
 xf86-input-keyboard"

-# Ship all kernel modules by default
-MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
+MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"

  EXTRA_IMAGEDEPENDS += "u-boot"

@@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
  IMAGE_FSTYPES += "tar.bz2 jffs2"
  EXTRA_IMAGECMD_jffs2 = "-lnp "

-SERIAL_CONSOLE = "115200 ttyO2"
+SERIAL_CONSOLE = "115200 ttyO0"

  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
  PREFERRED_VERSION_linux-yocto ?= "3.14%"

-KERNEL_IMAGETYPE = "zImage"
+KERNEL_IMAGETYPE = "uImage"
  KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
+KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"

  SPL_BINARY = "MLO"
  UBOOT_SUFFIX = "img"
--
1.9.1









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

Re: [yocto] How to include kernel module without including the kernel in the rootfs?

2014-04-10 Thread Bruce Ashfield


On 14-04-10 11:32 AM, Patrick Doyle wrote:

I just added a custom kernel module to my build, and now my rootfs
includes a copy of my kernel (thus making it too large to fit in my
pinhole sized root partition).

Is there any way to prevent the kernel from being included in the
rootfs?  Do modutils require a kernel image in order to function
properly?


Clear this in your kernel recipe:

# Allow machines to override this dependency if kernel image files are
# not wanted in images as standard
RDEPENDS_kernel-base ?= "kernel-image"

and you'll get no kernel image, and yes, modules will work.

Bruce



My recipe contains

inherit module

So I'm expecting that the module class does magic that results in the
kernel getting installed.

Is there a flag I can set to say "Don't do that?".

Thanks.

--wpd



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

[yocto] Why increment PRINC by 2?

The BSP guide gives the following helpful tip for installing a custom
/etc/network/interfaces file (see
https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#customizing-a-recipe-for-a-bsp
-- and thank you, BTW -- that addressed a specific problem I needed to
solve):

1. Edit the init-ifupdown_1.0.bbappend file so that it contains the following:

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
PRINC := "${@int(PRINC) + 2}"

The append file needs to be in the meta-xyz/recipes-core/init-ifupdown
directory.

2. Create and place the new interfaces configuration file in the BSP's
layer here:

meta-xyz/recipes-core/init-ifupdown/files/xyz/interfaces

In my continuing attempt to understand the mindset of Yocto
practitioners, I would appreciate any light folks can shed on this... it
opens up so many questions to me...

1) Why does FILESEXTRAPATHS exist? The documentation says, "You can
extend FILESPATH variable by using FILESEXTRAPATHS." Errr, can't one
extend FILESPATH with

FILESPATH = "blah:" + $FILESPATH

or
FILESPATH_prepend = "blah:"

I see that the documentation for FILESPATH specifically states:

"Do not hand-edit the FILESPATH variable. If you want the build system
to look in directories other than the defaults, extend the FILESPATH
variable by using the FILESEXTRAPATHS variable."

but that doesn't help me understand why this method is preferred for
extending FILESPATH.

2) Why does PRINC exist? The documentation says that PRINC "causes
the PR variable of .bbappend files to dynamically increment" and that
"This increment minimizes the impact of layer ordering." I guess that
means that the init-ifupdown_1.0.bb file has some revision (which I
think is "1.0") and that, when my .bbappend file is appended to it,
causes the recipe to effectively be "3.0". Why do I care? If there
is an "init-ifupdown_5.0.bb" file someplace in my search path, won't I
get that one anyway? How does this minimize the impact of layer
ordering?

Oh yeah, and why increment by 2? Why not 1, or pi?

I guess I only had 2 questions... but 1,000,000 subquestions :-)

Thanks for any tips you can give me.

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

Re: [yocto] [meta-yocto][PATCH 1/2] beaglebone.conf: configuration updates

On Thu, Apr 10, 2014 at 03:27:43PM +, Stanacar, StefanX wrote:
> 
> 
> 
> On Thu, 2014-04-10 at 14:14 +, Stanacar, StefanX wrote:
> > 
> > 
> > On Thu, 2014-04-10 at 13:36 +, Stanacar, StefanX wrote:
> > > Hi Denys,
> > > 
> > > With this patch applied and the updated README I can boot a Beaglebone
> > > Black (rev A6) with a default yocto image/config (I've used
> > > core-image-sato-sdk FWIW). Everything seems fine, I ran a bunch of tests
> > > on the image, except for X - it doesn't start :(.
> > > I've built with fbdev and omapfb too.
> > > 
> > > X log for fbdev: 
> > > http://pastebin.com/sqNc35U0
> > > 
> > > for omapfb:
> > > http://pastebin.com/fMkzMW8U
> > > 
> > > Is there anything else that needs to changed/added? I could add a
> > > xorg.conf on the image too, but then it beats the point...
> > > 
> > 
> > What I was trying to say is that we are missing a .bbappend for
> > xserver-xf86-config that adds the right xorg.conf (either for fbdev or
> > omapfb). I'll try to come up with one.
> 
> 
> Okay ignore that it didn't helped, I think I know what's missing.. I
> need the latest SRCREV_meta for kernel.

Sorry for the delay - yes, couple tweaks are needed from BSP as well.


> > > On Thu, 2014-04-10 at 04:02 -0400, Denys Dmytriyenko wrote:
> > > > From: Denys Dmytriyenko 
> > > > 
> > > > * Use fbdev video driver for xserver-xorg
> > > > * Recommend installing device tree DTB files into rootfs /boot directory
> > > > * Switch back to uImage kernel format from zImage, as U-boot was not 
> > > > updated
> > > >   - default has changed to zImage in newer U-boot 2013.10+, but we use 
> > > > 2013.07
> > > > * Correct copy/paste typo in serial console
> > > > 
> > > > Signed-off-by: Denys Dmytriyenko 
> > > > ---
> > > >  meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
> > > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
> > > > b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > index f2ef0cf..4263715 100644
> > > > --- a/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > @@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
> > > >  XSERVER ?= "xserver-xorg \
> > > > xf86-input-evdev \
> > > > xf86-input-mouse \
> > > > -   xf86-video-omapfb \
> > > > +   xf86-video-fbdev \
> > > > xf86-input-keyboard"
> > > >  
> > > > -# Ship all kernel modules by default
> > > > -MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> > > > +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"
> > > >  
> > > >  EXTRA_IMAGEDEPENDS += "u-boot"
> > > >  
> > > > @@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
> > > >  IMAGE_FSTYPES += "tar.bz2 jffs2"
> > > >  EXTRA_IMAGECMD_jffs2 = "-lnp "
> > > >  
> > > > -SERIAL_CONSOLE = "115200 ttyO2"
> > > > +SERIAL_CONSOLE = "115200 ttyO0"
> > > >  
> > > >  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> > > >  PREFERRED_VERSION_linux-yocto ?= "3.14%"
> > > >  
> > > > -KERNEL_IMAGETYPE = "zImage"
> > > > +KERNEL_IMAGETYPE = "uImage"
> > > >  KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
> > > > +KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
> > > >  
> > > >  SPL_BINARY = "MLO"
> > > >  UBOOT_SUFFIX = "img"
> > > > -- 
> > > > 1.9.1
> > > > 
> > > 
> > 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Why increment PRINC by 2?

On Thu, Apr 10, 2014 at 11:55:08AM -0400, Patrick Doyle wrote:
> The BSP guide gives the following helpful tip for installing a custom
> /etc/network/interfaces file (see
> https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#customizing-a-recipe-for-a-bsp
> -- and thank you, BTW -- that addressed a specific problem I needed to
> solve):
> 
> 1. Edit the init-ifupdown_1.0.bbappend file so that it contains the following:
> 
>  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>  PRINC := "${@int(PRINC) + 2}"
> 
> 
> The append file needs to be in the meta-xyz/recipes-core/init-ifupdown
> directory.
> 
> 2. Create and place the new interfaces configuration file in the BSP's
> layer here:
> 
>  meta-xyz/recipes-core/init-ifupdown/files/xyz/interfaces
> 
> In my continuing attempt to understand the mindset of Yocto
> practitioners, I would appreciate any light folks can shed on this... it
> opens up so many questions to me...
> 
> 1) Why does FILESEXTRAPATHS exist?  The documentation says, "You can
> extend FILESPATH variable by using FILESEXTRAPATHS."  Errr, can't one
> extend FILESPATH with
> 
> FILESPATH = "blah:" + $FILESPATH
> 
> or
> FILESPATH_prepend = "blah:"
> 
> I see that the documentation for FILESPATH specifically states:
> 
> "Do not hand-edit the FILESPATH variable. If you want the build system
> to look in directories other than the defaults, extend the FILESPATH
> variable by using the FILESEXTRAPATHS variable."
> 
> but that doesn't help me understand why this method is preferred for
> extending FILESPATH.
> 
> 2) Why does PRINC exist?  The documentation says that PRINC "causes
> the PR variable of .bbappend files to dynamically increment" and that
> "This increment minimizes the impact of layer ordering."  I guess that
> means that the init-ifupdown_1.0.bb file has some revision (which I
> think is "1.0") and that, when my .bbappend file is appended to it,
> causes the recipe to effectively be "3.0".  Why do I care?  If there
> is an "init-ifupdown_5.0.bb" file someplace in my search path, won't I
> get that one anyway?  How does this minimize the impact of layer
> ordering?

That is PV (package version) you are thinking of. But PRINC increments PR 
(package revision).

PR is not used in the recipe names, but rather in resulting binary packages. 
So your init-ifupdown_1.0.bb/bbappend will result in a binary package of 
init-ifupdown_1.0-r0_.ipk/rpm

That portion -r0 will be incremented, becoming -r2 or the original+2 (can be 
any number)

PV usually corresponds to changes in the sources, while PR corresponds to 
changes in the recipe. If a recipe is composed from multiple parts (.inc file 
or .bbappend) you may want to distinguish that.

As an alternative, some distro chose to append a more meaningful suffix to PR 
instead of just incrementing PR. I.e. our Arago distro appends "-aragoX" where 
X is the number of revisions we made in our distro on top of the main recipe. 
The end result of the package version will be "3.5-r6-arago2". It means the 
sources for the package are of version 3.5, the main recipe was updated 6 
times and there were also 2 more recipe bbappend updates by the distro...

It's a common practice in Linux Distro world - Ubuntu uses the same principle, 
when updating packages inherited from Debian, e.g. bash_4.1-2ubuntu3_i386.deb

-- 
Denys


> Oh yeah, and why increment by 2?  Why not 1, or pi?
> 
> I guess I only had 2 questions... but 1,000,000 subquestions :-)
> 
> Thanks for any tips you can give me.
> 
> --wpd
> -- 
> ___
> 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] [meta-yocto][PATCH 1/2] beaglebone.conf: configuration updates




On Thu, 2014-04-10 at 11:58 -0400, Denys Dmytriyenko wrote:
> On Thu, Apr 10, 2014 at 03:27:43PM +, Stanacar, StefanX wrote:
> > 
> > 
> > 
> > On Thu, 2014-04-10 at 14:14 +, Stanacar, StefanX wrote:
> > > 
> > > 
> > > On Thu, 2014-04-10 at 13:36 +, Stanacar, StefanX wrote:
> > > > Hi Denys,
> > > > 
> > > > With this patch applied and the updated README I can boot a Beaglebone
> > > > Black (rev A6) with a default yocto image/config (I've used
> > > > core-image-sato-sdk FWIW). Everything seems fine, I ran a bunch of tests
> > > > on the image, except for X - it doesn't start :(.
> > > > I've built with fbdev and omapfb too.
> > > > 
> > > > X log for fbdev: 
> > > > http://pastebin.com/sqNc35U0
> > > > 
> > > > for omapfb:
> > > > http://pastebin.com/fMkzMW8U
> > > > 
> > > > Is there anything else that needs to changed/added? I could add a
> > > > xorg.conf on the image too, but then it beats the point...
> > > > 
> > > 
> > > What I was trying to say is that we are missing a .bbappend for
> > > xserver-xf86-config that adds the right xorg.conf (either for fbdev or
> > > omapfb). I'll try to come up with one.
> > 
> > 
> > Okay ignore that it didn't helped, I think I know what's missing.. I
> > need the latest SRCREV_meta for kernel.
> 
> Sorry for the delay - yes, couple tweaks are needed from BSP as well.

I've rebuit with latest SRCREV_meta and indeed X starts fine now,
thanks.

Cheers,
Stefan

> 
> 
> > > > On Thu, 2014-04-10 at 04:02 -0400, Denys Dmytriyenko wrote:
> > > > > From: Denys Dmytriyenko 
> > > > > 
> > > > > * Use fbdev video driver for xserver-xorg
> > > > > * Recommend installing device tree DTB files into rootfs /boot 
> > > > > directory
> > > > > * Switch back to uImage kernel format from zImage, as U-boot was not 
> > > > > updated
> > > > >   - default has changed to zImage in newer U-boot 2013.10+, but we 
> > > > > use 2013.07
> > > > > * Correct copy/paste typo in serial console
> > > > > 
> > > > > Signed-off-by: Denys Dmytriyenko 
> > > > > ---
> > > > >  meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
> > > > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
> > > > > b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > > index f2ef0cf..4263715 100644
> > > > > --- a/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > > +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > > @@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
> > > > >  XSERVER ?= "xserver-xorg \
> > > > > xf86-input-evdev \
> > > > > xf86-input-mouse \
> > > > > -   xf86-video-omapfb \
> > > > > +   xf86-video-fbdev \
> > > > > xf86-input-keyboard"
> > > > >  
> > > > > -# Ship all kernel modules by default
> > > > > -MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> > > > > +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"
> > > > >  
> > > > >  EXTRA_IMAGEDEPENDS += "u-boot"
> > > > >  
> > > > > @@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
> > > > >  IMAGE_FSTYPES += "tar.bz2 jffs2"
> > > > >  EXTRA_IMAGECMD_jffs2 = "-lnp "
> > > > >  
> > > > > -SERIAL_CONSOLE = "115200 ttyO2"
> > > > > +SERIAL_CONSOLE = "115200 ttyO0"
> > > > >  
> > > > >  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> > > > >  PREFERRED_VERSION_linux-yocto ?= "3.14%"
> > > > >  
> > > > > -KERNEL_IMAGETYPE = "zImage"
> > > > > +KERNEL_IMAGETYPE = "uImage"
> > > > >  KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
> > > > > +KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
> > > > >  
> > > > >  SPL_BINARY = "MLO"
> > > > >  UBOOT_SUFFIX = "img"
> > > > > -- 
> > > > > 1.9.1
> > > > > 
> > > > 
> > > 
> > 

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

Re: [yocto] Why increment PRINC by 2?

On Thu, Apr 10, 2014 at 12:23:31PM -0400, Denys Dmytriyenko wrote:
> On Thu, Apr 10, 2014 at 11:55:08AM -0400, Patrick Doyle wrote:
> > The BSP guide gives the following helpful tip for installing a custom
> > /etc/network/interfaces file (see
> > https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#customizing-a-recipe-for-a-bsp
> > -- and thank you, BTW -- that addressed a specific problem I needed to
> > solve):
> > 
> > 1. Edit the init-ifupdown_1.0.bbappend file so that it contains the 
> > following:
> > 
> >  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> >  PRINC := "${@int(PRINC) + 2}"
> > 
> > 
> > The append file needs to be in the meta-xyz/recipes-core/init-ifupdown
> > directory.
> > 
> > 2. Create and place the new interfaces configuration file in the BSP's
> > layer here:
> > 
> >  meta-xyz/recipes-core/init-ifupdown/files/xyz/interfaces
> > 
> > In my continuing attempt to understand the mindset of Yocto
> > practitioners, I would appreciate any light folks can shed on this... it
> > opens up so many questions to me...
> > 
> > 1) Why does FILESEXTRAPATHS exist?  The documentation says, "You can
> > extend FILESPATH variable by using FILESEXTRAPATHS."  Errr, can't one
> > extend FILESPATH with
> > 
> > FILESPATH = "blah:" + $FILESPATH
> > 
> > or
> > FILESPATH_prepend = "blah:"
> > 
> > I see that the documentation for FILESPATH specifically states:
> > 
> > "Do not hand-edit the FILESPATH variable. If you want the build system
> > to look in directories other than the defaults, extend the FILESPATH
> > variable by using the FILESEXTRAPATHS variable."
> > 
> > but that doesn't help me understand why this method is preferred for
> > extending FILESPATH.
> > 
> > 2) Why does PRINC exist?  The documentation says that PRINC "causes
> > the PR variable of .bbappend files to dynamically increment" and that
> > "This increment minimizes the impact of layer ordering."  I guess that
> > means that the init-ifupdown_1.0.bb file has some revision (which I
> > think is "1.0") and that, when my .bbappend file is appended to it,
> > causes the recipe to effectively be "3.0".  Why do I care?  If there
> > is an "init-ifupdown_5.0.bb" file someplace in my search path, won't I
> > get that one anyway?  How does this minimize the impact of layer
> > ordering?
> 
> That is PV (package version) you are thinking of. But PRINC increments PR 
> (package revision).
> 
> PR is not used in the recipe names, but rather in resulting binary packages. 
> So your init-ifupdown_1.0.bb/bbappend will result in a binary package of 
> init-ifupdown_1.0-r0_.ipk/rpm
> 
> That portion -r0 will be incremented, becoming -r2 or the original+2 (can be 
> any number)
> 
> PV usually corresponds to changes in the sources, while PR corresponds to 
> changes in the recipe. If a recipe is composed from multiple parts (.inc file 
> or .bbappend) you may want to distinguish that.
> 
> As an alternative, some distro chose to append a more meaningful suffix to PR 
> instead of just incrementing PR. I.e. our Arago distro appends "-aragoX" 
> where 
> X is the number of revisions we made in our distro on top of the main recipe. 
> The end result of the package version will be "3.5-r6-arago2". It means the 
> sources for the package are of version 3.5, the main recipe was updated 6 
> times and there were also 2 more recipe bbappend updates by the distro...
> 
> It's a common practice in Linux Distro world - Ubuntu uses the same 
> principle, 
> when updating packages inherited from Debian, e.g. bash_4.1-2ubuntu3_i386.deb

Ah, and forgot to mention the new way of dealing with PR increments:
https://wiki.yoctoproject.org/wiki/PR_Service


> > Oh yeah, and why increment by 2?  Why not 1, or pi?
> > 
> > I guess I only had 2 questions... but 1,000,000 subquestions :-)
> > 
> > Thanks for any tips you can give me.
> > 
> > --wpd
> > -- 
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-yocto][PATCH 1/2] beaglebone.conf: configuration updates

On Thu, Apr 10, 2014 at 04:35:51PM +, Stanacar, StefanX wrote:
> 
> 
> 
> On Thu, 2014-04-10 at 11:58 -0400, Denys Dmytriyenko wrote:
> > On Thu, Apr 10, 2014 at 03:27:43PM +, Stanacar, StefanX wrote:
> > > 
> > > 
> > > 
> > > On Thu, 2014-04-10 at 14:14 +, Stanacar, StefanX wrote:
> > > > 
> > > > 
> > > > On Thu, 2014-04-10 at 13:36 +, Stanacar, StefanX wrote:
> > > > > Hi Denys,
> > > > > 
> > > > > With this patch applied and the updated README I can boot a Beaglebone
> > > > > Black (rev A6) with a default yocto image/config (I've used
> > > > > core-image-sato-sdk FWIW). Everything seems fine, I ran a bunch of 
> > > > > tests
> > > > > on the image, except for X - it doesn't start :(.
> > > > > I've built with fbdev and omapfb too.
> > > > > 
> > > > > X log for fbdev: 
> > > > > http://pastebin.com/sqNc35U0
> > > > > 
> > > > > for omapfb:
> > > > > http://pastebin.com/fMkzMW8U
> > > > > 
> > > > > Is there anything else that needs to changed/added? I could add a
> > > > > xorg.conf on the image too, but then it beats the point...
> > > > > 
> > > > 
> > > > What I was trying to say is that we are missing a .bbappend for
> > > > xserver-xf86-config that adds the right xorg.conf (either for fbdev or
> > > > omapfb). I'll try to come up with one.
> > > 
> > > 
> > > Okay ignore that it didn't helped, I think I know what's missing.. I
> > > need the latest SRCREV_meta for kernel.
> > 
> > Sorry for the delay - yes, couple tweaks are needed from BSP as well.
> 
> I've rebuit with latest SRCREV_meta and indeed X starts fine now,
> thanks.

Great, thanks for verifying it!

-- 
Denys


> > > > > On Thu, 2014-04-10 at 04:02 -0400, Denys Dmytriyenko wrote:
> > > > > > From: Denys Dmytriyenko 
> > > > > > 
> > > > > > * Use fbdev video driver for xserver-xorg
> > > > > > * Recommend installing device tree DTB files into rootfs /boot 
> > > > > > directory
> > > > > > * Switch back to uImage kernel format from zImage, as U-boot was 
> > > > > > not updated
> > > > > >   - default has changed to zImage in newer U-boot 2013.10+, but we 
> > > > > > use 2013.07
> > > > > > * Correct copy/paste typo in serial console
> > > > > > 
> > > > > > Signed-off-by: Denys Dmytriyenko 
> > > > > > ---
> > > > > >  meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
> > > > > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > > > > 
> > > > > > diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
> > > > > > b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > > > index f2ef0cf..4263715 100644
> > > > > > --- a/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > > > +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > > > @@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= 
> > > > > > "xserver-xorg"
> > > > > >  XSERVER ?= "xserver-xorg \
> > > > > > xf86-input-evdev \
> > > > > > xf86-input-mouse \
> > > > > > -   xf86-video-omapfb \
> > > > > > +   xf86-video-fbdev \
> > > > > > xf86-input-keyboard"
> > > > > >  
> > > > > > -# Ship all kernel modules by default
> > > > > > -MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> > > > > > +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"
> > > > > >  
> > > > > >  EXTRA_IMAGEDEPENDS += "u-boot"
> > > > > >  
> > > > > > @@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
> > > > > >  IMAGE_FSTYPES += "tar.bz2 jffs2"
> > > > > >  EXTRA_IMAGECMD_jffs2 = "-lnp "
> > > > > >  
> > > > > > -SERIAL_CONSOLE = "115200 ttyO2"
> > > > > > +SERIAL_CONSOLE = "115200 ttyO0"
> > > > > >  
> > > > > >  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> > > > > >  PREFERRED_VERSION_linux-yocto ?= "3.14%"
> > > > > >  
> > > > > > -KERNEL_IMAGETYPE = "zImage"
> > > > > > +KERNEL_IMAGETYPE = "uImage"
> > > > > >  KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
> > > > > > +KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
> > > > > >  
> > > > > >  SPL_BINARY = "MLO"
> > > > > >  UBOOT_SUFFIX = "img"
> > > > > > -- 
> > > > > > 1.9.1
> > > > > > 
> > > > > 
> > > > 
> > > 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to include kernel module without including the kernel in the rootfs?

Hi Bruce,
Thank you very much.  That did the trick.

--wpd


On Thu, Apr 10, 2014 at 11:35 AM, Bruce Ashfield
 wrote:
> On 14-04-10 11:32 AM, Patrick Doyle wrote:
>>
>> I just added a custom kernel module to my build, and now my rootfs
>> includes a copy of my kernel (thus making it too large to fit in my
>> pinhole sized root partition).
>>
>> Is there any way to prevent the kernel from being included in the
>> rootfs?  Do modutils require a kernel image in order to function
>> properly?
>
>
> Clear this in your kernel recipe:
>
> # Allow machines to override this dependency if kernel image files are
> # not wanted in images as standard
> RDEPENDS_kernel-base ?= "kernel-image"
>
> and you'll get no kernel image, and yes, modules will work.
>
> Bruce
>
>
>>
>> My recipe contains
>>
>> inherit module
>>
>> So I'm expecting that the module class does magic that results in the
>> kernel getting installed.
>>
>> Is there a flag I can set to say "Don't do that?".
>>
>> Thanks.
>>
>> --wpd
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PREFERRED_PROVIDER entry in local.conf

2014-04-10 Thread Romain

Thanks for filing the bug.

I confirm that adding the line in my local.conf fix the jpeg provider :
PREFERRED_PROVIDER_jpeg = "libjpeg-turbo"

Thanks for your help !
Romain
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-linaro][PATCH] external-linaro-toolchain: Fix for 32bit armhf build

2014-04-10 Thread Khem Raj

On Thu, Apr 10, 2014 at 12:49 AM, Kazuya Nishimura
 wrote:
> From: Kazuya Nishimura 
>
> Use ld-linux-armhf.so.3 if call convention hard.
> Fix QA issue errors by packaging approprieately.
> Add eglibc-locale_2.19.bbappend to fix QA issue error.
>   An empty directory is created while do_install.
>
> Signed-off-by: Kazuya Nishimura 
> ---
>  .../conf/distro/include/tcmode-external-linaro.inc |1 +
>  .../eglibc/eglibc-locale_2.19.bbappend |   23 
>  .../external-linaro-toolchain.bb   |   38
> 
>  3 files changed, 56 insertions(+), 6 deletions(-)
>  create mode 100755
> meta-linaro-toolchain/recipes-core/eglibc/eglibc-locale_2.19.bbappend
>
> diff --git
> a/meta-linaro-toolchain/conf/distro/include/tcmode-external-linaro.inc
> b/meta-linaro-toolchain/conf/distro/include/tcmode-external-linaro.inc
> index 1d9fd59..26d464c 100644
> --- a/meta-linaro-toolchain/conf/distro/include/tcmode-external-linaro.inc
> +++ b/meta-linaro-toolchain/conf/distro/include/tcmode-external-linaro.inc
> @@ -41,6 +41,7 @@ DISTRO_FEATURES_LIBC = "ipv4 ipv6 libc-backtrace
> libc-big-macros libc-bsd libc-c
>   libc-getlogin libc-idn libc-inet-anl libc-libm libc-libm-big \
>   libc-memusage libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn
> libc-streams libc-sunrpc \
>   libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp
> libc-posix-regexp-glibc \
> + libc-charsets libc-locales libc-locale-code \
>   libc-posix-wchar-io"
>
>  ENABLE_BINARY_LOCALE_GENERATION = "0"
> diff --git
> a/meta-linaro-toolchain/recipes-core/eglibc/eglibc-locale_2.19.bbappend
> b/meta-linaro-toolchain/recipes-core/eglibc/eglibc-locale_2.19.bbappend
> new file mode 100755
> index 000..3e91e74
> --- /dev/null
> +++ b/meta-linaro-toolchain/recipes-core/eglibc/eglibc-locale_2.19.bbappend
> @@ -0,0 +1,23 @@
> +do_install () {
> + mkdir -p ${D}${datadir}
> + if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then
> + mkdir -p ${D}${bindir}
> + cp -fpPR ${LOCALETREESRC}/${bindir}/* ${D}${bindir}
> + fi
> + if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then
> + mkdir -p ${D}${localedir}
> + cp -fpPR ${LOCALETREESRC}/${localedir}/* ${D}${localedir}
> + fi
> + if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then
> + mkdir -p ${D}${libdir}
> + cp -fpPR ${LOCALETREESRC}/${libdir}/gconv ${D}${libdir}
> + fi
> + if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then
> + cp -fpPR ${LOCALETREESRC}/${datadir}/i18n ${D}${datadir}
> + fi
> + if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then
> + cp -fpPR ${LOCALETREESRC}/${datadir}/locale ${D}${datadir}
> + fi
> + chown root.root -R ${D}
> + cp -fpPR ${LOCALETREESRC}/SUPPORTED ${WORKDIR}
> +}

why is chown needed here ?
secondly, this piece should go into OE-Core

> diff --git
> a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
> b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
> index 240d550..47fd4ca 100644
> ---
> a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
> +++
> b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
> @@ -41,6 +41,12 @@ PROVIDES += "\
>   libitm \
>   libitm-dev \
>   libitm-staticdev \
> + libasan \
> + libasan-dev \
> + libasan-staticdev \
> + libatomic \
> + libatomic-dev \
> + libatomic-staticdev \
>   virtual/linux-libc-headers \
>  "
>
> @@ -50,12 +56,11 @@ PR = "r2"
>  # https://launchpad.net/linaro-toolchain-binaries
>  SRC_URI = "file://SUPPORTED"
>
> +LDLINUX32 = "${@base_contains("TUNE_FEATURES", "callconvention-hard",
> "ld-linux-armhf.so.3", "ld-linux.so.3",d)}"
> +
>  do_install() {
>   install -d ${D}${base_libdir}
> - install -d ${D}${bindir}
> - install -d ${D}${sbindir}
>   install -d ${D}${libdir}
> - install -d ${D}${libexecdir}
>   install -d ${D}${datadir}
>   install -d ${D}${includedir}
>
> @@ -79,7 +84,7 @@ do_install() {
>   fi
>
>   # fix up the copied symlinks (they are still pointing to the multiarch
> directory)
> - linker_name="${@base_contains("TUNE_FEATURES", "aarch64",
> "ld-linux-aarch64.so.1", "ld-linux.so.3",d)}"
> + linker_name="${@base_contains("TUNE_FEATURES", "aarch64",
> "ld-linux-aarch64.so.1", "${LDLINUX32}",d)}"
>   ln -sf ld-${ELT_VER_LIBC}.so ${D}${base_libdir}/${linker_name}
>   ln -sf ../../lib/libnsl.so.1 ${D}${libdir}/libnsl.so
>   ln -sf ../../lib/librt.so.1 ${D}${libdir}/librt.so
> @@ -144,6 +149,12 @@ PACKAGES =+ "\
>   libitm \
>   libitm-dev \
>   libitm-staticdev \
> + libasan \
> + libasan-dev \
> + libasan-staticdev \
> + libatomic \
> + libatomic-dev \
> + libatomic-staticdev \
>  "
>
>  INSANE_SKIP_${PN}-dbg = "staticdev"
> @@ -282,14 +293,16 @@ FILES_libssp-staticdev = " \
>
>  FILES_libgfortran = "${base_libdir}/libgfortran.so.*"
>  FILES_libgfortran-dev = " \
> -  ${base_libdir}/libgfortran.so"
> +  ${base_libdir}/libgfortran.so \
> +  ${base_libdir}/libgfortran.spec"
>  FI

Re: [yocto] CGL compliance layer initiative

2014-04-10 Thread Diego Sueiro

Vali,

I'm excited to see CGL support for Yocto.
I'm going to test this layer as soon as possible.

One question, which branch of Yocto is it based on?

Regards,

--
*dS
Diego Sueiro
sent from mobile.
On Apr 9, 2014 11:05 AM, "Vali Cobelea"  wrote:

> OK Paul, that indeed makes sense, I really did not knew that preliminary
> versions of layers are accepted.
> I will discuss around here and if everything goes OK we will start the
> move in the "public" layer index.
> I also do agree with an all-together strategy, no matter for the layer
> state.
>
>
> Much appreciated,
> Vali
>
>
> On 04/09/2014 02:01 PM, Paul Eggleton wrote:
>
>> On Wednesday 09 April 2014 13:55:47 Vali Cobelea wrote:
>>
>>> On 04/09/2014 01:51 PM, Paul Eggleton wrote:
>>>
 On Tuesday 08 April 2014 18:34:08 Vali Cobelea wrote:

> Here at ENEA we decided to take the initiative regarding the CGL
> compliance when it comes to the Yocto Project.
> For this we started the work on a dedicated layer called 'meta-cgl'
>
> which can be accessed / cloned from here:
> http://git.enea.com/git/?p=linux/meta-cgl.git
> git clone g...@git.enea.com:linux/meta-cgl
>
> Have a look of the things we got there so far, please remember that
> there is still plenty of work to be done (layer architecture, CGL
> requirements coverage mode and so on).
> It is a little bit more than a stub layer, consider it a starting point
> for the direction we would like to have with this layer.
>
> Any input is much appreciated, lets keep the discussion by this email
> thread and see where it goes.
>
 I don't have anything to offer on the layer contents, but I would say in
 order to make it easy for people to find this layer I would strongly
 encourage you to>
 submit it to the OpenEmbedded layer index:
 http://layers.openembedded.org/layerindex/submit/

>>> Thank you for the input.
>>> We will keep the layer for a short period of time at the current
>>> location while getting other ideas regarding the content / architecture.
>>> The layer initiative will also be raised up in the board advisory
>>> meeting, in order to get even more input.
>>> After which we will make it easier to find, access and use for anyone,
>>> exactly as you suggested.
>>>
>> OK, as the maintainer it's totally up to you.
>>
>> I would say though generally that I'd like to see more people adding their
>> work-in-progress layers to the layer index, even if at some time later
>> they
>> will be moved elsewhere or absorbed into another layer - it just makes it
>> easier to point people to the layer index so they can find recipes that
>> have
>> already been written, rather than having to re-write them from scratch.
>>
>> Cheers,
>> Paul
>>
>>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] defconfig on daisy

2014-04-10 Thread Søren Holm

Hi

I have a linux-yocto_3.14.bbappend file in my local layer. Basically it just 
specifies the defconfig for the kernel.

The problem now is just that defconfig is not used for the specific kernel. 
It's copied into ${WORKDIR} but never used.

Have procedures on how to do this changed since dora - or is somthing broken?
 
-- 
Søren Holm
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Building python module after compiling in one recipe

2014-04-10 Thread Jens Lucius


Hi

I am trying to bitbake pjproject including the python module. I manged 
to write a working .bb recipe for the latest pjproject, which compiles 
and installes correctly. But I also want to build the python module.


The documentation of pjproject says about building the python module:

1. Build the PJSIP libraries first with the usual "./configure && make
   dep && make" commands.
2. Go to pjsip-apps/src/python directory.
3. Run *'sudo python ./setup.py install'* or just *'sudo make'*

So I guess with the working recipe I got part 1. I tried to do stepts 2 
and 3 by adding the following:


do_compile_append() {
export BUILD_SYS
export HOST_SYS
export STAGING_INCDIR
export STAGING_LIBDIR

cd ${S}/pjsip-apps/src/python
oe_runmake
}

which starts the building process but then terminates with:

| cc1: warning: include location "/usr/include/python2.7" is unsafe for 
cross-compilation [-Wpoison-system-directories]

| In file included from _pjsua.c:20:0:
| _pjsua.h:25:20: fatal error: Python.h: No such file or directory

So I guess it is trying to use the host python for building the module 
(which is obviously not correct).


So can I build them both in one recipe and how? And if built correctly 
how to install the modules?


Thanks for your help.



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

[yocto] polkit and consolekit

2014-04-10 Thread Trevor Woerner

consolekit has a dependency on polkit:

arm-oe-linux-gnueabi-gcc: error:
/SSD/build/distroless/tmp/qemuarm-eglibc/sysroots/qemuarm/usr/lib/libpolkit-gobject-1.so:
No such file or directory
ERROR: Function failed: do_compile (log file is located at
/SSD/build/distroless/tmp/qemuarm-eglibc/work/armv5te-oe-linux-gnueabi/consolekit/0.4.6-r0/temp/log.do_compile.18881)

Whereas consolekit is in openembedded-core, polkit is in meta-openembedded.

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

[yocto] Confusion about autotools

I am trying to write a recipe for a custom gstreamer plugin that
compiles fine (natively) with autotools.

I thought it would be as simple as writing a recipe that said something like:

inherit autotools

myplugin_do_fetch() {
commands_to_make_a_copy_of_my_source_code_in_build_tree;
}
EXPORT_FUNCTIONS do_fetch

(I am leaving out the boilerplate DESCRIPTION, LICENSE, etc...

But when I try to run my recipe, I get an error that ends like:

109: /home/wpd/.../run.do_fetch.1234 do_fetch: not found

and when I look at run.do_fetch, I see on line 109

do_fetch

I thought that do_fetch would be inherited from base.bbclass.  I look
in autotools.bbclass and I don't see a do_fetch function task defined
there.

So now I'm confused.  Since this isn't working the way I thought it
would, I figured it was time (once again -- and thanks for all of the
help so far!) to ask the list how I should do this.

For purely hysterical reasons, the gst plugin is in the same (bzr)
repository and my yocto build environment.  I was expecting to write a
"do_fetch()" task that would copy the source files into the
appropriate location in build tree.

I guess I could create a subdirectory of the recipe that contains a
bunch of symbolic links to each of the source files required to build
the plugin, and list them all as file:whatever in SRC_URI.  But that
feels hackish.

Once again, any tips to help over this hump (and help me make it to
the big important demo next week) would be welcome.

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

Re: [yocto] Confusion about autotools

2014-04-10 Thread Chris Larson

On Thu, Apr 10, 2014 at 4:43 PM, Patrick Doyle  wrote:

> I am trying to write a recipe for a custom gstreamer plugin that
> compiles fine (natively) with autotools.
>
> I thought it would be as simple as writing a recipe that said something
> like:
>
> inherit autotools
>
> myplugin_do_fetch() {
> commands_to_make_a_copy_of_my_source_code_in_build_tree;
> }
> EXPORT_FUNCTIONS do_fetch
>
> (I am leaving out the boilerplate DESCRIPTION, LICENSE, etc...
>
> But when I try to run my recipe, I get an error that ends like:
>
> 109: /home/wpd/.../run.do_fetch.1234 do_fetch: not found
>
> and when I look at run.do_fetch, I see on line 109
>
> do_fetch
>
> I thought that do_fetch would be inherited from base.bbclass.  I look
> in autotools.bbclass and I don't see a do_fetch function task defined
> there.
>

EXPORT_FUNCTIONS is an inheritance mechanism, to let you override a
function in a class you inherit but still be able to explicitly call the
function defined by that class. Unless you have a 'myplugin' class, nothing
will translate myplugin_do_fetch to do_fetch. If you want to override a
function like do_fetch in your recipe, just override that function, don't
prefix it.
-- 
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] Confusion about autotools

ok, that makes sense.  Trying to pattern match against too many
patterns, and not spending enough time understanding the underlying
technology.  Thank you for the explanation.

If you don't mind, I'll move on to my next question...

I now have a "do_fetch()" task that looks like this:

do_fetch () {
bberror "Hello World"
exit 1
}

Where would I see "Hello World" pop out?  I don't see it in the log file.

I do see in run.do_fetch a shell script that looks like:
...
do_fetch() {
bberror "Hello World"
exit 1

}

bberror() {
echo "ERROR: $*"

}

cd '/home/wpd/yocto/downloads'
do_fetch

That's cool... things are starting to make sense now.  Especially as I
see that "do_fetch()" is probably not the right task to overload.

But I do wonder what happened to my "Hello World" message.

--wpd


On Thu, Apr 10, 2014 at 7:50 PM, Chris Larson  wrote:
>
> On Thu, Apr 10, 2014 at 4:43 PM, Patrick Doyle  wrote:
>>
>> I am trying to write a recipe for a custom gstreamer plugin that
>> compiles fine (natively) with autotools.
>>
>> I thought it would be as simple as writing a recipe that said something
>> like:
>>
>> inherit autotools
>>
>> myplugin_do_fetch() {
>> commands_to_make_a_copy_of_my_source_code_in_build_tree;
>> }
>> EXPORT_FUNCTIONS do_fetch
>>
>> (I am leaving out the boilerplate DESCRIPTION, LICENSE, etc...
>>
>> But when I try to run my recipe, I get an error that ends like:
>>
>> 109: /home/wpd/.../run.do_fetch.1234 do_fetch: not found
>>
>> and when I look at run.do_fetch, I see on line 109
>>
>> do_fetch
>>
>> I thought that do_fetch would be inherited from base.bbclass.  I look
>> in autotools.bbclass and I don't see a do_fetch function task defined
>> there.
>
>
> EXPORT_FUNCTIONS is an inheritance mechanism, to let you override a function
> in a class you inherit but still be able to explicitly call the function
> defined by that class. Unless you have a 'myplugin' class, nothing will
> translate myplugin_do_fetch to do_fetch. If you want to override a function
> like do_fetch in your recipe, just override that function, don't prefix it.
> --
> 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] Confusion about autotools

2014-04-10 Thread Chris Larson

On Thu, Apr 10, 2014 at 5:12 PM, Patrick Doyle  wrote:

> ok, that makes sense.  Trying to pattern match against too many
> patterns, and not spending enough time understanding the underlying
> technology.  Thank you for the explanation.
>
> If you don't mind, I'll move on to my next question...
>
> I now have a "do_fetch()" task that looks like this:
>
> do_fetch () {
> bberror "Hello World"
> exit 1
> }
>
> Where would I see "Hello World" pop out?  I don't see it in the log file.
>

It should show up in the do_fetch log (not the cooker log), which lives
next to the run script. That said, it's possible you're hitting an issue
due to the base.bbclass fetch implementation being python, not shell.
-- 
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] Confusion about autotools