[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, October 7, 2014 8:00 AM US Pacific Time

[Jolley, Stephen K]

Tuesday, October 7, 2014 8:00 AM US Pacific Time



Agenda:



* Opens collection - 5 min (Stephen)

* Yocto Project status - 5 min (Stephen/team)

https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.7_Status

https://wiki.yoctoproject.org/wiki/Yocto_1.7_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_1.7_Features

* SWAT team rotation: Beth -> Paul

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

* Opens - 10 min

* Team Sharing - 10 min





We encourage people attending the meeting to logon the Yocto Project IRC 
chancel during the meeting (optional):



Yocto IRC: http://webchat.freenode.net/?channels=#yocto

IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html



Conference Details:

Company:   WIND RIVER SYS

Ready-Access Number: 8007302996/9139049836

Access Code: 2705751


For International numbers see: 
https://www.yoctoproject.org/tools-resources/community/weekly-technical-call


Thanks,

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

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

Re: [yocto] yocto 1.6 - beaglebone black - cape manager

[Denys Dmytriyenko]

On Mon, Oct 06, 2014 at 02:57:08PM -0600, Gary Thomas wrote:
> On 2014-10-06 13:43, Denys Dmytriyenko wrote:
> >On Thu, Sep 04, 2014 at 07:02:13PM -0300, Diego Sueiro wrote:
> >>>I'm build yocto 1.6, My hardware is beaglebone black I successfull
> >>>build system image. But I can't see cape manager.
> >>>I need them to use SPI - enable spidev -
> >>>http://elinux.org/BeagleBone_Black_Enable_SPIDEV .
> >>>What do i do to build yocto with a cape manager?
> >>
> >>As far as I know, you have to use meta-beagleboard
> >> (almost 1 year without
> >>any new commit) as your BSP layer to get capemanager support with Yocto.
> >>Take a look here
> >>.
> >>The kernel version is 3.8.
> >>
> >>Here we have good news of having capemanager support on mainline:
> >>http://beagleboard.org/blog/2014-08-27-device-tree-overlay-support-lands-upstream/
> >>
> >>Here you have a beaglebord.org linux repo with capemanager support:
> >>https://github.com/beagleboard
> >>I don't know if there is any WIP to get this kernel compiled by Yocto/OE.
> >
> >Hi,
> >
> >[I was asked to provide additional comments to this topic - I'm the 
> >maintainer
> >of meta-ti and the author of BeagleBone Black support in meta-yocto-bsp]
> >
> >I see that Diego has pretty much covered all the basics above. I'll just add
> >few clarifications and details...
> >
> >
> >There are few different OE/Yocto BSPs for BeagleBone Black:
> >
> >1. meta-yocto-bsp provides "reference" BSPs for each of the supported
> >architectures. One for ARM (BeagleBone Black), one for MIPS, PPC and x86.
> >The keyword is "reference", as it is based on the mainline kernel/bootloader
> >and does not support any advanced features or anything not in the upstream
> >mainline kernel - e.g. no capes, no power management, no hardware
> >acceleration, no 3D, no PRU, etc. The purpose of this BSP is to have some
> >basic out-of-box experience for the select hardware platforms within Poky to
> >evaluate the Yocto Project and OpenEmbedded framework, but not the specific
> >hardware platforms. For proper and more comprehensive HW support users are
> >directed to the corresponding official BSPs - meta-intel, meta-ti, meta-fsl
> >(ARM, PPC), meta-amd, etc. etc.
> >
> >2. meta-ti is the official Texas Instruments BSP that provides the latest WIP
> >"staging" kernel and bootloader with most of the advanced features and
> >peripheral support for the wider range of latest TI platforms, including
> >BeagleBone Black. Most of the work in the "staging" area is being upstreamed,
> >so it eventually appears in the mainline kernel and u-boot. It doesn't 
> >support
> >capes on BBB, at least not yet - see below.
> >
> >3. meta-beagleboard (now defunct) was a split-off from meta-ti few years ago
> >to concentrate on the development of the BeagleBoard and BeagleBone 
> >specifics,
> >such as capes. At the time it was based on 3.8 kernel and had large patchsets
> >to add device tree overlays and cape management, among other things. 
> >Although,
> >meta-beagleboard seems to be dead now, the work on the devtree overlays and
> >cape manager has continued, thanks to Pantelis Antoniou - see the blog post 
> >on
> >beagleboard.org, linked by Diego above.
> >
> >
> >The plan always was for meta-ti and meta-beagleboard to meet upstream, hence
> >meta-ti will eventually have all the necessary pieces to support capes, once
> >it lands upstream. Meanwhile, TI now concentrates on supporting all the other
> >advanced features and upstreaming everything to mainline.
> >
> >BTW, the kernel repo from Robert Nelson (the last link from Diego above) is
> >now based on the TI "staging" kernel, i.e. the one provided by meta-ti, plus
> >some additional patches not yet accepted upstream. I might look into adding a
> >recipe to meta-ti to pull in that tree, but haven't decided yet...
> 
> Which, if any, of these choices is suitable for accelerated graphics?
> Which device(s) will that choice support?  HDMI, LCD cape, ???
> Can accelerated graphics, e.g. SGX, be supported by QT5?  If so, what
> additional magic needs to be done?

If you are asking about BeagleBone Black specifically, then meta-ti does 
provide accelerated GLES 3D graphics for SGX over HDMI. On other devices, 
built-in LCD is also supported, but not LCD cape, due to reasons above.
SGX is basically supported on Qt5, but there are some pieces missing, for 
which there is work either in progress or planned - for more details I'd 
recommend moving the discussion to meta-ti or meta-arago lists.

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

Re: [yocto] yocto 1.6 - beaglebone black - cape manager

[Gary Thomas]

On 2014-10-06 13:43, Denys Dmytriyenko wrote:

On Thu, Sep 04, 2014 at 07:02:13PM -0300, Diego Sueiro wrote:

I'm build yocto 1.6, My hardware is beaglebone black I successfull
build system image. But I can't see cape manager.
I need them to use SPI - enable spidev -
http://elinux.org/BeagleBone_Black_Enable_SPIDEV .
What do i do to build yocto with a cape manager?


As far as I know, you have to use meta-beagleboard
 (almost 1 year without
any new commit) as your BSP layer to get capemanager support with Yocto.
Take a look here
.
The kernel version is 3.8.

Here we have good news of having capemanager support on mainline:
http://beagleboard.org/blog/2014-08-27-device-tree-overlay-support-lands-upstream/

Here you have a beaglebord.org linux repo with capemanager support:
https://github.com/beagleboard
I don't know if there is any WIP to get this kernel compiled by Yocto/OE.


Hi,

[I was asked to provide additional comments to this topic - I'm the maintainer
of meta-ti and the author of BeagleBone Black support in meta-yocto-bsp]

I see that Diego has pretty much covered all the basics above. I'll just add
few clarifications and details...


There are few different OE/Yocto BSPs for BeagleBone Black:

1. meta-yocto-bsp provides "reference" BSPs for each of the supported
architectures. One for ARM (BeagleBone Black), one for MIPS, PPC and x86.
The keyword is "reference", as it is based on the mainline kernel/bootloader
and does not support any advanced features or anything not in the upstream
mainline kernel - e.g. no capes, no power management, no hardware
acceleration, no 3D, no PRU, etc. The purpose of this BSP is to have some
basic out-of-box experience for the select hardware platforms within Poky to
evaluate the Yocto Project and OpenEmbedded framework, but not the specific
hardware platforms. For proper and more comprehensive HW support users are
directed to the corresponding official BSPs - meta-intel, meta-ti, meta-fsl
(ARM, PPC), meta-amd, etc. etc.

2. meta-ti is the official Texas Instruments BSP that provides the latest WIP
"staging" kernel and bootloader with most of the advanced features and
peripheral support for the wider range of latest TI platforms, including
BeagleBone Black. Most of the work in the "staging" area is being upstreamed,
so it eventually appears in the mainline kernel and u-boot. It doesn't support
capes on BBB, at least not yet - see below.

3. meta-beagleboard (now defunct) was a split-off from meta-ti few years ago
to concentrate on the development of the BeagleBoard and BeagleBone specifics,
such as capes. At the time it was based on 3.8 kernel and had large patchsets
to add device tree overlays and cape management, among other things. Although,
meta-beagleboard seems to be dead now, the work on the devtree overlays and
cape manager has continued, thanks to Pantelis Antoniou - see the blog post on
beagleboard.org, linked by Diego above.


The plan always was for meta-ti and meta-beagleboard to meet upstream, hence
meta-ti will eventually have all the necessary pieces to support capes, once
it lands upstream. Meanwhile, TI now concentrates on supporting all the other
advanced features and upstreaming everything to mainline.

BTW, the kernel repo from Robert Nelson (the last link from Diego above) is
now based on the TI "staging" kernel, i.e. the one provided by meta-ti, plus
some additional patches not yet accepted upstream. I might look into adding a
recipe to meta-ti to pull in that tree, but haven't decided yet...


Which, if any, of these choices is suitable for accelerated graphics?
Which device(s) will that choice support?  HDMI, LCD cape, ???
Can accelerated graphics, e.g. SGX, be supported by QT5?  If so, what
additional magic needs to be done?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] yocto 1.6 - beaglebone black - cape manager

[Denys Dmytriyenko]

On Thu, Sep 04, 2014 at 07:02:13PM -0300, Diego Sueiro wrote:
> > I'm build yocto 1.6, My hardware is beaglebone black I successfull
> > build system image. But I can't see cape manager.
> > I need them to use SPI - enable spidev -
> > http://elinux.org/BeagleBone_Black_Enable_SPIDEV .
> > What do i do to build yocto with a cape manager?
> 
> As far as I know, you have to use meta-beagleboard
>  (almost 1 year without
> any new commit) as your BSP layer to get capemanager support with Yocto.
> Take a look here
> .
> The kernel version is 3.8.
> 
> Here we have good news of having capemanager support on mainline:
> http://beagleboard.org/blog/2014-08-27-device-tree-overlay-support-lands-upstream/
> 
> Here you have a beaglebord.org linux repo with capemanager support:
> https://github.com/beagleboard
> I don't know if there is any WIP to get this kernel compiled by Yocto/OE.

Hi,

[I was asked to provide additional comments to this topic - I'm the maintainer 
of meta-ti and the author of BeagleBone Black support in meta-yocto-bsp]

I see that Diego has pretty much covered all the basics above. I'll just add 
few clarifications and details...


There are few different OE/Yocto BSPs for BeagleBone Black:

1. meta-yocto-bsp provides "reference" BSPs for each of the supported 
architectures. One for ARM (BeagleBone Black), one for MIPS, PPC and x86.
The keyword is "reference", as it is based on the mainline kernel/bootloader 
and does not support any advanced features or anything not in the upstream 
mainline kernel - e.g. no capes, no power management, no hardware 
acceleration, no 3D, no PRU, etc. The purpose of this BSP is to have some 
basic out-of-box experience for the select hardware platforms within Poky to 
evaluate the Yocto Project and OpenEmbedded framework, but not the specific 
hardware platforms. For proper and more comprehensive HW support users are 
directed to the corresponding official BSPs - meta-intel, meta-ti, meta-fsl 
(ARM, PPC), meta-amd, etc. etc.

2. meta-ti is the official Texas Instruments BSP that provides the latest WIP 
"staging" kernel and bootloader with most of the advanced features and 
peripheral support for the wider range of latest TI platforms, including 
BeagleBone Black. Most of the work in the "staging" area is being upstreamed, 
so it eventually appears in the mainline kernel and u-boot. It doesn't support 
capes on BBB, at least not yet - see below.

3. meta-beagleboard (now defunct) was a split-off from meta-ti few years ago 
to concentrate on the development of the BeagleBoard and BeagleBone specifics, 
such as capes. At the time it was based on 3.8 kernel and had large patchsets 
to add device tree overlays and cape management, among other things. Although, 
meta-beagleboard seems to be dead now, the work on the devtree overlays and 
cape manager has continued, thanks to Pantelis Antoniou - see the blog post on 
beagleboard.org, linked by Diego above.


The plan always was for meta-ti and meta-beagleboard to meet upstream, hence 
meta-ti will eventually have all the necessary pieces to support capes, once 
it lands upstream. Meanwhile, TI now concentrates on supporting all the other 
advanced features and upstreaming everything to mainline.

BTW, the kernel repo from Robert Nelson (the last link from Diego above) is 
now based on the TI "staging" kernel, i.e. the one provided by meta-ti, plus 
some additional patches not yet accepted upstream. I might look into adding a 
recipe to meta-ti to pull in that tree, but haven't decided yet...


If there are any questions remain, please find me on meta-ti mailing list at 
meta...@yoctoproject.org. Thanks.

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

Re: [yocto] Issues removing RRECOMMENDS packages with BAD_RECOMMENDATIONS

[Burton, Ross]

On 29 September 2014 12:43, Carr, Chris (GE Intelligent Platforms)
 wrote:
> Basically the BAD_RECOMMENDATIONS that I have defined is not 
> removing/preventing
> the installation of the RRECOMMENDS packages. This is using opkg as the 
> package
> manager.

Would you mind briefly switching to the RPM package manager and seeing
if that changes what gets installed?

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

Re: [yocto] Recommended Hardware for building

[Oliver Novakovic]

Thanks a lot for all of the information so far. This will give me a good
starting point on configuring a build server or PC.

 

Basically, the image itself is very basic, but it does include the
complete QT5 release including QTWebkit which seems to be the most
demanding to build.

The rest are smaller support packages for connectivity and a QML based
HMI.

 

Thanks again,

Oliver

 

From: Bryan Evenson  [mailto:Bryan Evenson
] 
Sent: Freitag, 3. Oktober 2014 14:48
To: Martin Jansa ; Chris Tapp
; "oliver.novako...@alpine.de"

Cc: "yocto@yoctoproject.org" 
Subject: RE: [yocto] Recommended Hardware for building

 


Oliver, 

> -Original Message- 
> From: yocto-boun...@yoctoproject.org [mailto:yocto- 
> boun...@yoctoproject.org] On Behalf Of Martin Jansa 
> Sent: Thursday, October 02, 2014 3:09 PM 
> To: Chris Tapp 
> Cc: yocto@yoctoproject.org 
> Subject: Re: [yocto] Recommended Hardware for building 
> 
> On Thu, Oct 02, 2014 at 05:51:29PM +0100, Chris Tapp wrote: 
> > 
> > On 2 Oct 2014, at 11:04, Burton, Ross wrote: 
> > 
> > > On 2 October 2014 10:36, Oliver Novakovic 
> wrote: 
> > >> Can anyone recommend a reasonable performant hardware setup to 
> use ? 
> > >> 
> > >> What should be considered ? Are there any pitfalls ? What about 
> > >> bottlenecks in the build system ? 
> 
> you should start by saying what you're going to build, my experience
is quite 
> different when building "small" images like console-image or even
x11-image 
> and "big" images/feeds which contain whole qt5 stack, 3 webkits and 
> 2 chromium builds. 

Agreed, what you are building and what your goals are makes a difference
in what you need. I have a build machine setup that is mainly used to
verify everything builds correctly after committing changes. It's an
Intel i3-3220 with 8GB RAM. The autobuilder is setup on a Linux VM which
is given 4GB RAM and does not recognize the extra Hyper-threaded cores,
meaning it acts as a dual core machine. Rebuild of my console image
typically takes under 20 minutes, and most of that time is
packaging/install. After the initial build, there really isn't much for
my system that needs to get rebuilt between commits. 

So if you are looking for a build machine that is outside your normal
workflow, a $400 PC may be enough for you. If this machine is for your
development build and you have a have a lot of graphic applications that
you need to build, you may want something more in line with what other
people are suggesting. 

Regards, 
Bryan 

> 
> In general: bitbake will better utilize all available performance with
bigger 
> image (e.g. build time for console image won't change so much if you
go from 
> 8 cores to 24, but building e.g. just webkit alone will be more than
twice 
> faster on 24 cores). 
> 
> Regards, 
> 
> > >> Specifically: 
> > >> 
> > >> How many cores are recommended ? And how much cache is necessary 
> ? 
> > >> How much of the main memory does Yocto really use ? Is 32 GB 
> > >> sufficient or should I go for 64 ? 
> > >> 
> > >> Does it make sense to use two SSDs as Raid0 to get builds faster
? 
> > > 
> > > As much of everything as you can afford. :) The build isn't heavy 
> > > in any particular metric, so don't sacrifice RAM for SSDs for
example. 
> > > 
> > > RAID 0 over SSD would be nice and fast, but I prefer having a good
> > > amount of RAM and a tuned ext4 (no journal, long commit delay) so 
> > > data doesn't actually hit the disk as frequently. Keeping the
actual 
> > > build directories on a separate disk is good for performance and
not 
> > > causing data loss when you lose a disk. 
> > > 
> > > There are people that have 64GB in machines and then set TMPDIR to
a 
> > > tmpfs. Surprisingly this isn't that much faster (5% or so), but 
> > > it's a lot easier on the hardware and power consumption. 
> > 
> > My experience: 
> > 
> > I've got a quad core with hyper-threading (so 8 usable cores)
running at 
> about 3.8 GHz, 16GB of RAM and use multiple SSDs - one to hold the
meta 
> data, downloads and top level build areas (local.conf, etc) and have
the 
> TMPDIR on a second SSD (so, as Ross says, I don't get a surprise when
it 
> wears out!). 
> > 
> > I can build my images (basically an x11 image) in just under 60
minutes 
> (once all the files have been fetched). I run with BB_NUMBER_THREADS
and 
> PARALLEL_MAKE both set to 16 to make sure the cores are fully loaded
as 
> much as possible (other says that should be 8 and 8 to reduce
scheduling 
> overhead). 
> > 
> > During the build the system is CPU bound quite a bit of the time (so
more 
> cores should help), but there are significant periods where the build 
> dependency chain means this isn't the case and only two or three cores
are 
> active. Previously I recall comparing results with someone else and
finding 
> that having lots more cores (24, I think) didn't give a significant
improvement 
> in build time (certainly not for the 3x system build cost). 
> > 
> > I've never seen peak memory usage