Re: [yocto] Yocto Dev Day at ELC 2017

[Andrea Galbusera]

On Fri, Mar 3, 2017 at 1:41 AM, Steve Burt  wrote:

> The slides are on the wiki:
> https://wiki.yoctoproject.org/wiki/DevDay_US_2017
>
> Hope this helps.
>

Thanks for the link, Steve: appreciated!


>
> On Thu, Mar 2, 2017 at 2:22 AM, Andrea Galbusera  wrote:
>
>> Hi,
>>
>> I was expecting to find some material from the Dev Day at ELC at [1] as
>> usual. Was it published somewhere else than the usual page?
>>
>> [1] https://www.yoctoproject.org/tools-resources/presentations
>>
>> --
>> ___
>> 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] any rumblings about a newer YP powerpc reference board than mpc8315e-rdb?

[Leon Woestenberg]

Hi,

I didn't check availability, but p2020rdb is it's successor (and similar, 2010).
 
Regards, Leon




> On 3 Mar 2017, at 14:51, Robert P. J. Day  wrote:
> 
>> On Fri, 3 Mar 2017, Burton, Ross wrote:
>> 
>> On 3 March 2017 at 13:24, Robert P. J. Day  wrote:
>>it seems of limited value for YP to have a powerpc reference
>>  board, mpc8315e-rdb, that is essentially impossible to
>>  procure. is there any effort being made to look around for a
>>  newer powerpc reference board that people could actually buy?
>> 
>> Do you have any suggestions?
> 
>  not at the moment ... perhaps the powerpc or freescale folks can
> weigh in. i'm not a powerpc expert, but it does seem pointless to have
> a reference board that no one can get.
> 
> rday
> 
> -- 
> 
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
>http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
> -- 
> ___
> 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] Systemd recipe breaks resolvconf

[Khem Raj]

On Sat, Mar 4, 2017 at 5:33 AM, Martin Townsend  wrote:
> Hi,
>
> I've just tracked down a problem with resolvconf not working on my
> board and it was due to the systemd recipe creating the resolv.conf
> link and patching etc.conf. Here's the snippet (I've taken it from
> krogoth but it is still there in morty).
>
> if ! ${@bb.utils.contains('PACKAGECONFIG', 'resolved', 'true',
> 'false', d)}; then
> # if resolved is disabled, it won't handle the link of resolv.conf, so
> # set it up ourselves
> ln -s ../run/resolv.conf ${D}${sysconfdir}/resolv.conf
> echo 'L! ${sysconfdir}/resolv.conf - - - - ../run/resolv.conf'
>>>${D}${exec_prefix}/lib/tmpfiles.d/etc.conf
> echo 'f /run/resolv.conf 0644 root root'
>>>${D}${exec_prefix}/lib/tmpfiles.d/systemd.conf
> fi
>
> As systemd's resolved is not enabled by default the above is
> happening.  The problem is that it breaks resolvconf which setsup
> /etc/resolv.conf to link to /etc/resolvconf/run/resolv.conf and
> doesn't seem to work when it's not.
>
> I've put an ugly hack in a systemd append that undoes the changes
> above and resolvconf works fine.
>
> Not sure what the best way to fix this, the if statement above should
> say is if ! resolved && image doesn't contain resolvconf but I don't
> think you can do this in do_install.  A DISTRO_FEATURE of resolvconf
> could be added to state that you are going to manage the DNS resolver
> configuration.  The other option is to remove the above if statement.
> Should systemd be setting up /etc/resolv.conf if resolved is not used?
> If you not going to use resolved then you are probably going to use
> something else. Or is this because systemd stops resolv.conf from
> being created? but wouldn't that only happen if you disable SysV Init
> altogether?

somehow the resolv.conf creation needs to get into tmpfiles.d when systemd
is enabled, thats what it tries to do here. If it conflicts with
resolveconf then
lets see if resolveconf can deal with new paths may be with symlinks or so.

>
> I can create a bug report if you think this is a genuine problem.
>
> Cheers,
> Martin.
> --
> ___
> 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] [PATCH] yocto-docs: Various formatting/clarification adjustments to BSP Guide

[Robert P. J. Day]

Collection of aesthetic/formatting/clarification fixes to BSP Guide,
including:

* Adjust some directory names to have trailing slash
* Reword some paragraphs for clarity
* Add s inside s for consistency

and other minor tweaks.

Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 4d0ace0..d189ee0 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -956,28 +956,28 @@
 Instructions on how to boot 
the BSP build from
 the BSP layer.
 Instructions on how to boot 
the binary images
-contained in the 
binary directory,
+contained in the 
binary/ directory,
 if present.
 Information on any known bugs 
or issues that users
 should know about when either building or 
booting the BSP
 binaries.
 
 README.sources 
File:
-You must include a 
README.sources in the
-
meta-bsp_name directory.
-This file specifies exactly where you can find the 
sources used to
-generate the binary images contained in the
-binary directory, if present.
+If your BSP layer includes a 
binary/ directory
+with at least one binary image, then it must also 
include a top-level
+README.sources file that 
explains exactly
+where you can find the sources used to generate 
those binary images.
 
 Layer Configuration 
File:
-You must include a 
conf/layer.conf in the
+You must include a 
conf/layer.conf file in the
 
meta-bsp_name directory.
 This file identifies the 
meta-bsp_name
 BSP layer as a layer to the build 
system.
 Machine Configuration 
File:
 You must include one or more
-
conf/machine/bsp_name.conf
-files in the 
meta-bsp_name directory.
+
conf/machine/machine.conf
+machine definition files in the
+
meta-bsp_name directory.
 These configuration files define machine targets 
that can be built
 using the BSP layer.
 Multiple machine configuration files define 
variations of machine
@@ -989,12 +989,22 @@
 hardware.
 If you do have very different targets, you should 
create separate
 BSP layers for each target.
-It is completely possible for a developer to 
structure the
-working repository as a conglomeration of 
unrelated BSP
-files, and to possibly generate BSPs targeted for 
release
-from that directory using scripts or some other 
mechanism
-(e.g. meta-yocto-bsp layer).
-Such considerations are outside the scope of this 
document.
+
+  
+It is completely possible for a developer to 
structure the
+working repository as a conglomeration of 
unrelated BSP
+files, and to possibly generate BSPs targeted 
for release
+from that directory using scripts or some 
other mechanism
+(e.g. meta-yocto-bsp 
layer).
+Such considerations are outside the scope of 
this document.
+  
+  
+In any event, the 
meta-yocto-bsp layer should be
+considered a special case as it defines the 
family of Yocto Project
+reference boards, which necessarily cover the 
set of supported
+architectures.
+  
+
 
 
 
@@ -1025,16 +1035,20 @@
 purposes, you should put the images and artifacts 
within a
 binary/ subdirectory located 
in 

[yocto] Systemd recipe breaks resolvconf

[Martin Townsend]

Hi,

I've just tracked down a problem with resolvconf not working on my
board and it was due to the systemd recipe creating the resolv.conf
link and patching etc.conf. Here's the snippet (I've taken it from
krogoth but it is still there in morty).

if ! ${@bb.utils.contains('PACKAGECONFIG', 'resolved', 'true',
'false', d)}; then
# if resolved is disabled, it won't handle the link of resolv.conf, so
# set it up ourselves
ln -s ../run/resolv.conf ${D}${sysconfdir}/resolv.conf
echo 'L! ${sysconfdir}/resolv.conf - - - - ../run/resolv.conf'
>>${D}${exec_prefix}/lib/tmpfiles.d/etc.conf
echo 'f /run/resolv.conf 0644 root root'
>>${D}${exec_prefix}/lib/tmpfiles.d/systemd.conf
fi

As systemd's resolved is not enabled by default the above is
happening.  The problem is that it breaks resolvconf which setsup
/etc/resolv.conf to link to /etc/resolvconf/run/resolv.conf and
doesn't seem to work when it's not.

I've put an ugly hack in a systemd append that undoes the changes
above and resolvconf works fine.

Not sure what the best way to fix this, the if statement above should
say is if ! resolved && image doesn't contain resolvconf but I don't
think you can do this in do_install.  A DISTRO_FEATURE of resolvconf
could be added to state that you are going to manage the DNS resolver
configuration.  The other option is to remove the above if statement.
Should systemd be setting up /etc/resolv.conf if resolved is not used?
If you not going to use resolved then you are probably going to use
something else. Or is this because systemd stops resolv.conf from
being created? but wouldn't that only happen if you disable SysV Init
altogether?

I can create a bug report if you think this is a genuine problem.

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

[yocto] standards for YP documentation markup?

[Robert P. J. Day]

  more nitpicky pedantry ... i mentioned this once upon a long time
ago, but i thought i'd revisit it. there is a fair bit of
inconsistency in the docbook markup in the YP docs such that, even
though the end-product looks reasonable, the markup kind of bounces
around all over the place and, in future, would cause all sorts of
hilarity if one wanted to redefine the rendering.

  for instance, there are a number of terms that are apparently
supposed to be rendered in italics at the moment, such as filenames,
variable names, command names and so on. but even though docbook
supports explicit markup using:

  
  
  

and so on, if you check the BSP guide,  is being used all
over the place for all of the above; examples:

You use the yocto-bsp create sub-command to create
LICENSE_FLAGS_WHITELIST, the build stops and

and so on. sure, it all looks good right now, but if someone wanted to
make a trivial change to the rendering of, say, just commands, well,
oh dear ...

  other nitpickery i noticed in that same doc is inconsistency of
defining notes depending on whether they have more than one paragraph.
if there's just one para, it's very common to see:

  
blah blah
woof woof
  

OTOH, if it's a multi-para note, you see:

  

  ... para 1 ...


  ... para 2 ...

  

but look closely at the final rendering and you'll see that the use of
 clearly changes the final rendering in terms of line spacing.
and, occasionally, even a single-para note in the guide uses
 so it's not even consistently inconsistent. :-)

  anyway, yes, it's all picky, but it would be useful to have a short
guide on standard for YP docs markup so that, if someone starts a new
one, it can at least follow some guidelines.

  thoughts?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

[yocto] occasional confusion in bsp guide, mixing BSP layer name and machine name

[Robert P. J. Day]

  as i claw my through the bsp guide, i notice the occasional
confusion between referring to the BSP layer itself and a machine
supported by that layer.

  a couple times, i've found references to the alleged machine
configuration file "conf/bsp_name.conf" (which i'm changing to
"conf/machine.conf"). and in section 1.4, i read the snippet:

/ start

Following is a specific example to help you better understand the
process. Consider an example that customizes a recipe by adding a
BSP-specific configuration file named interfaces to the
init-ifupdown_1.0.bb recipe for machine "xyz" where the BSP layer also
supports several other machines. Do the following:

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

  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

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

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

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

/ end

so we have a section that ostensibly describes the BSP layer
"meta-xyz", but first refers specifically to the machine "xyz" (even
though the layer is described as supporting multiple machines), and
further extends the directory structure with the machine name
"xyz-machine-one". is it just me, or is that confusing and
contradictory?

  sure, it's excruciatingly pedantic, but is there a doc-wide standard
for names to be used for stuff like this? otherwise, i'll just make
something up to clean this up (assuming, of course, that it needs
cleaning and i'm not just hopelessly misreading all of this).

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

[yocto] [meta-raspberrypi][PATCH] linux-raspberrypi: Default to 4.9 kernel

[Khem Raj]

4.9 is now declared stable for raspberrypi

Signed-off-by: Khem Raj 
---
 conf/machine/include/rpi-default-versions.inc | 2 +-
 conf/machine/raspberrypi3-64.conf | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/conf/machine/include/rpi-default-versions.inc 
b/conf/machine/include/rpi-default-versions.inc
index 2007cc0..faa6b41 100644
--- a/conf/machine/include/rpi-default-versions.inc
+++ b/conf/machine/include/rpi-default-versions.inc
@@ -1,3 +1,3 @@
 # RaspberryPi BSP default versions
 
-PREFERRED_VERSION_linux-raspberrypi ??= "4.4.%"
+PREFERRED_VERSION_linux-raspberrypi ??= "4.9.%"
diff --git a/conf/machine/raspberrypi3-64.conf 
b/conf/machine/raspberrypi3-64.conf
index 0bf1397..ca10ed9 100644
--- a/conf/machine/raspberrypi3-64.conf
+++ b/conf/machine/raspberrypi3-64.conf
@@ -37,5 +37,3 @@ VC4_CMA_SIZE ?= "cma-256"
 
 UBOOT_MACHINE = "rpi_3_config"
 MACHINE_FEATURES_append = " vc4graphics"
-
-PREFERRED_VERSION_linux-raspberrypi ?= "4.9.%"
-- 
2.12.0

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

[yocto] [meta-raspberrypi][PATCH 2/2] firmware: Update to 20170215 release

[Khem Raj]

Signed-off-by: Khem Raj 
---
 recipes-bsp/common/firmware.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
index 8aea628..7487b49 100644
--- a/recipes-bsp/common/firmware.inc
+++ b/recipes-bsp/common/firmware.inc
@@ -1,10 +1,10 @@
-RPIFW_DATE ?= "20161215"
+RPIFW_DATE ?= "20170215"
 RPIFW_SRC_URI ?= 
"https://github.com/raspberrypi/firmware/archive/1.${RPIFW_DATE}.tar.gz;
 RPIFW_S ?= "${WORKDIR}/firmware-1.${RPIFW_DATE}"
 
 SRC_URI = "${RPIFW_SRC_URI}"
-SRC_URI[md5sum] = "ddd7645988360d7ef267b48c32293ad7"
-SRC_URI[sha256sum] = 
"bda18f2affb50053940fd88c3f3bec5af9a4b4ced753d01107a2b106cfb02d13"
+SRC_URI[md5sum] = "e0ce7be125ee567f7e804897e5eeff72"
+SRC_URI[sha256sum] = 
"98970367e26b7b618baf9feb1aafdd29a59e63145f5cae4e9a6596c71773cb04"
 
 PV = "${RPIFW_DATE}"
 
-- 
2.12.0

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

[yocto] [meta-raspberrypi][PATCH 1/2] userland: Update to latest

[Khem Raj]

Forward port the patches

Signed-off-by: Khem Raj 
---
 ...01-Allow-applications-to-set-next-resource-handle.patch |  6 +++---
 .../0002-wayland-Add-support-for-the-Wayland-winsys.patch  | 14 +++---
 .../userland/0003-wayland-Add-Wayland-example.patch|  6 +++---
 .../0004-wayland-egl-Add-bcm_host-to-dependencies.patch|  6 +++---
 ...erface-remove-faulty-assert-to-make-weston-happy-.patch |  6 +++---
 .../0006-zero-out-wl-buffers-in-egl_surface_free.patch |  6 +++---
 .../0007-initialize-front-back-wayland-buffers.patch   |  6 +++---
 .../userland/userland/0008-Remove-RPC_FLUSH.patch  |  6 +++---
 .../userland/userland/0009-fix-cmake-dependency-race.patch |  8 
 .../0010-Fix-for-framerate-with-nested-composition.patch   |  6 +++---
 .../userland/0011-build-shared-library-for-vchostif.patch  |  8 
 ...-implement-buffer-wrapping-interface-for-dispmanx.patch |  6 +++---
 .../0013-Implement-triple-buffering-for-wayland.patch  | 11 ---
 recipes-graphics/userland/userland_git.bb  |  2 +-
 14 files changed, 51 insertions(+), 46 deletions(-)

diff --git 
a/recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
 
b/recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
index 4f72845..d622157 100644
--- 
a/recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
+++ 
b/recipes-graphics/userland/userland/0001-Allow-applications-to-set-next-resource-handle.patch
@@ -1,7 +1,7 @@
-From 4b68419e58ef31e72abab688d0c7cc5db80efc13 Mon Sep 17 00:00:00 2001
+From f6540119d5b064361ffcb370373794932f97bfdd Mon Sep 17 00:00:00 2001
 From: Dom Cobley 
 Date: Tue, 9 Jul 2013 09:26:26 -0400
-Subject: [PATCH 01/12] Allow applications to set next resource handle
+Subject: [PATCH 01/13] Allow applications to set next resource handle
 
 This patch adds provisions in userland to
 let apps callers set the next rendereing dispmanx resource.
@@ -204,5 +204,5 @@ index 8a5734c..51b3580 100644
  
  FN(void, eglIntGetColorData_impl, (EGL_SURFACE_ID_T s, KHRN_IMAGE_FORMAT_T 
format, uint32_t width, uint32_t height, int32_t stride, uint32_t y_offset, 
void *data))
 -- 
-2.10.2
+2.12.0
 
diff --git 
a/recipes-graphics/userland/userland/0002-wayland-Add-support-for-the-Wayland-winsys.patch
 
b/recipes-graphics/userland/userland/0002-wayland-Add-support-for-the-Wayland-winsys.patch
index 6cc8ea8..324fa91 100644
--- 
a/recipes-graphics/userland/userland/0002-wayland-Add-support-for-the-Wayland-winsys.patch
+++ 
b/recipes-graphics/userland/userland/0002-wayland-Add-support-for-the-Wayland-winsys.patch
@@ -1,7 +1,7 @@
-From e3d2d0007e1c6c32ab7d9a28f1e399d42b511333 Mon Sep 17 00:00:00 2001
+From 5f9e011a6c15b3a05b3be412d7ba5c1077ececf1 Mon Sep 17 00:00:00 2001
 From: Tomeu Vizoso 
 Date: Tue, 1 Oct 2013 13:19:20 +0200
-Subject: [PATCH 02/12] wayland: Add support for the Wayland winsys
+Subject: [PATCH 02/13] wayland: Add support for the Wayland winsys
 
 * Adds EGL_WL_bind_wayland_display extension
 * Adds wayland-egl library
@@ -68,7 +68,7 @@ index 4a88665..5da71a9 100644
 +
 +*~
 diff --git a/CMakeLists.txt b/CMakeLists.txt
-index 98252c3..d6ae907 100644
+index cfc8ae5..673a5ad 100644
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
 @@ -24,6 +24,17 @@ include(makefiles/cmake/global_settings.cmake)
@@ -1542,7 +1542,7 @@ index 000..8bafc15
 +Libs: -L${libdir} -lwayland-egl
 +Cflags: -I${includedir}
 diff --git a/interface/vmcs_host/CMakeLists.txt 
b/interface/vmcs_host/CMakeLists.txt
-index 0b3adc9..f44d01f 100755
+index fde18da..6718215 100755
 --- a/interface/vmcs_host/CMakeLists.txt
 +++ b/interface/vmcs_host/CMakeLists.txt
 @@ -9,13 +9,24 @@ add_definitions(-fno-strict-aliasing)
@@ -1551,12 +1551,12 @@ index 0b3adc9..f44d01f 100755
  
 -add_library(vchostif
 -${VMCS_TARGET}/vcfilesys.c ${VMCS_TARGET}/vcmisc.c
--vc_vchi_gencmd.c vc_vchi_filesys.c
+-vc_vchi_gencmd.c vc_vchi_filesys.c vc_vchi_gpuserv.c
 -vc_vchi_tvservice.c vc_vchi_cecservice.c
 -vc_vchi_dispmanx.c vc_service_common.c)
 +set(VCHOSTIF_SOURCE
 +${VMCS_TARGET}/vcfilesys.c ${VMCS_TARGET}/vcmisc.c
-+vc_vchi_gencmd.c vc_vchi_filesys.c
++vc_vchi_gencmd.c vc_vchi_filesys.c vc_vchi_gpuserv.c
 +vc_vchi_tvservice.c vc_vchi_cecservice.c
 +vc_vchi_dispmanx.c vc_service_common.c)
  #${VMCS_TARGET}/vmcs_main.c
@@ -1885,5 +1885,5 @@ index 000..ad90d30
 +set(${_sources} ${${_sources}} PARENT_SCOPE)
 +endfunction()
 -- 
-2.10.2
+2.12.0
 
diff --git 
a/recipes-graphics/userland/userland/0003-wayland-Add-Wayland-example.patch 
b/recipes-graphics/userland/userland/0003-wayland-Add-Wayland-example.patch
index bbd9727..f888533 100644
--- a/recipes-graphics/userland/userland/0003-wayland-Add-Wayland-example.patch
+++