Re: [yocto] Yocto Dev Day at ELC 2017
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?
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
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
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 the
[yocto] Systemd recipe breaks resolvconf
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?
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
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
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
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
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 +++ b/recipes-graphics/userland/userland/0003-wayland-Add-Wayland-example.patch @@ -1,7 +1,7 @@ -From 8a4b3ea902b