Re: [yocto] [Openembedded-architecture] [OE-core] OpenEmbedded Stand at FOSDEM
On Thu, 26 Jan 2017 22:39:17 +0100 Andreas Müller wrote: > On Thu, Jan 5, 2017 at 4:30 PM, Philip Balister > wrote: > > On 01/03/2017 08:13 PM, Andreas Müller wrote: > >> On Tue, Jan 3, 2017 at 4:32 PM, Philip Balister > >> wrote: > >>> Every year since 2007, OpenEmbedded has a stand at FOSDEM > >>> (http://www.fosdem.org) > >>> > >>> From the first year: > >>> > >>> https://www.flickr.com/photos/32615155@N00/405229708/in/album-72157594561002629/ > >>> > >>> Belen and I are sort of organizing this, but both of us are also > >>> involved in devrooms, so we will need a lot of help manning the > >>> stand and getting some demos together. > >>> > >>> Demos should try and show how the project makes embedded work > >>> easier, by showing tools and/or cool examples of devices using > >>> Linux built with OpenEmbedded. In previous years, we've shown > >>> toaster with data collected from demos on the table. Collections > >>> of devices running images built from the same recipe and > >>> interesting products using Linux by OpenEmbedded. > >>> > >>> I'm happy to try and organize demos and staffing, but I could > >>> really use some help this year, so if you are in a position to > >>> tak ethe lead on operating the stand, that would be a huge help > >>> to me and the rest of the project. > >>> > >>> Thanks, > >>> > >>> Philip > Nobody? > > Andreas There's 3 of us from Togán Labs who'll be able to help out manning the stand. I know I can do all day Saturday and up to about 4pm on Sunday and I'm happy to be at the stand all day (with the obvious caffeine breaks!). Let me know if you need help setting things up and what time you need people to turn up on Saturday morning. If you need anything printing then send it to me. I can bring 2x 4-way UK power strips plus 2x EU->UK power adaptors for our gear. I've got 2 laptops plus a few embedded devices. I don't have any EU power strips though. I've updated the wiki page. Thanks, Paul -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Where to find help for yocto application and and system development
Hello, I'm beginning with Yocto. I would like to know where to find general help (like a forum, or mailing lists) for my Yocto-related technical problems. Right now I have problems just integrating a library into my build. Later I will also do system development. If this helps, a further description of my most urgent problem: I want to integrate the tr-50 library, available on github: https://github.com/inhedron/libtr50 It is managed via autotools. I built a new project subdirectory in my custom layer for the lib. I built a basic recipe (with some tool) which, in principle should somehow recognize the autotools and build the project then. I changed the SCR_URI to the local .tar.gz file. But when I build, it comes down to this: make: *** No rule to make target 'install'. Stop. I don't know if and which parameters I should change in the recipe. Another problem is that the lib needs openssl-dev. I can't find how to include openssl-dev into the Yocto build. Looking forward for your answers, best regards, Jakob -- Jakob Hasse Software Developement E: jakob.ha...@smart-home-technology.ch T: +41 44 552 02 66 Smart Home Technology GmbH www.smart-home-technology.ch -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where to find help for yocto application and and system development
Hi Jakob, welcome on-board. The Yocto community expects you to re-use the available documentation and online resources (or even offline resources like books) on Yocto or OpenEmbedded. Then if things remains unclear you can ask questions here on the mailing list and on IRC channels yocto. Your question (and probably a lot of subsequent things you learn on the way) can be answered by the documentation and existing resources. I would recommend to read the documentation, then find an existing recipe that uses "autotools" and another that DEPENDS on openssl. There are a lot of resources online: http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe https://www.yoctoproject.org/tools-resources/community/irc Regards, Leon. On Fri, Jan 27, 2017 at 12:43 PM, Jakob Hasse < jakob.ha...@smart-home-technology.ch> wrote: > Hello, > > I'm beginning with Yocto. > I would like to know where to find general help (like a forum, or mailing > lists) for my Yocto-related technical problems. > Right now I have problems just integrating a library into my build. Later > I will also do system development. > > If this helps, a further description of my most urgent problem: > > I want to integrate the tr-50 library, available on github: > > https://github.com/inhedron/libtr50 > > It is managed via autotools. > I built a new project subdirectory in my custom layer for the lib. > I built a basic recipe (with some tool) which, in principle should somehow > recognize the autotools and build the project then. I changed the SCR_URI > to the local .tar.gz file. But when I build, it comes down to this: > make: *** No rule to make target 'install'. Stop. > I don't know if and which parameters I should change in the recipe. > Another problem is that the lib needs openssl-dev. I can't find how to > include openssl-dev into the Yocto build. > > Looking forward for your answers, best regards, > Jakob > > -- > Jakob Hasse > Software Developement > > E: jakob.ha...@smart-home-technology.ch > T: +41 44 552 02 66 > > Smart Home Technology GmbH > www.smart-home-technology.ch > > -- > ___ > 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-rockchip][PATCH 2/7] machine: Add machine file for the rk3288 linux Boards
Hey, Could you: - Make one patch per new machine file and not one patch for all new added machine - Add a clear @DESCRIPTION for each board, see an example here: https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/conf/machine/firefly-rk3288.conf - Write a clear and an understandable commit message for your new patches @Trevor: What do you think about this rk-linux.inc ? I don't like this, either its name and what it contains. That's it for now. Thanks for your patches 2017-01-19 15:04 GMT+01:00 Jacob Chen : > Evb-rk3288 is the offical evaluate board, add it to help myself develop. > > Fennec-rk3288 and Tinker-rk3288 is rk3288 based SBCs. > . > Tinker Boards: > http://www.cnx-software.com/2017/01/05/asus-tinker-board- > is-a-raspberry-pi-3-alternative-based-on-rockchip-rk3288-processor/ > > Signed-off-by: Jacob Chen > --- > conf/machine/evb-rk3288.conf | 12 > conf/machine/fennec-rk3288.conf | 12 > conf/machine/include/rk-linux.inc | 20 > conf/machine/tinker-rk3288.conf | 13 + > 4 files changed, 57 insertions(+) > create mode 100644 conf/machine/evb-rk3288.conf > create mode 100644 conf/machine/fennec-rk3288.conf > create mode 100644 conf/machine/include/rk-linux.inc > create mode 100644 conf/machine/tinker-rk3288.conf > > diff --git a/conf/machine/evb-rk3288.conf b/conf/machine/evb-rk3288.conf > new file mode 100644 > index 000..88a5f78 > --- /dev/null > +++ b/conf/machine/evb-rk3288.conf > @@ -0,0 +1,12 @@ > +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd > +# Released under the MIT license (see COPYING.MIT for the terms) > + > +#@TYPE: Machine > +#@NAME: EVB 3288 > + > +include conf/machine/include/rk3288.inc > +include conf/machine/include/rk-linux.inc > + > +KERNEL_DEVICETREE = "rk3288-evb-act8846.dtb" > + > +UBOOT_MACHINE = "evb-rk3288_defconfig" > diff --git a/conf/machine/fennec-rk3288.conf b/conf/machine/fennec-rk3288. > conf > new file mode 100644 > index 000..a85045f > --- /dev/null > +++ b/conf/machine/fennec-rk3288.conf > @@ -0,0 +1,12 @@ > +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd > +# Released under the MIT license (see COPYING.MIT for the terms) > + > +#@TYPE: Machine > +#@NAME: FENNEC RK3288 > + > +include conf/machine/include/rk3288.inc > +include conf/machine/include/rk-linux.inc > + > +KERNEL_DEVICETREE = "rk3288-fennec.dtb" > + > +UBOOT_MACHINE = "fennec-rk3288_defconfig" > diff --git a/conf/machine/include/rk-linux.inc b/conf/machine/include/rk- > linux.inc > new file mode 100644 > index 000..6abaa0d > --- /dev/null > +++ b/conf/machine/include/rk-linux.inc > @@ -0,0 +1,20 @@ > +# Rockchip BSP default settings > + > +PREFERRED_PROVIDER_virtual/egl = "mali-userspace" > +PREFERRED_PROVIDER_virtual/libgles1 = "mali-userspace" > +PREFERRED_PROVIDER_virtual/libgles2 = "mali-userspace" > +PREFERRED_PROVIDER_virtual/libopencl = "mali-userspace" > + > +# Workaround: libmali.so provided by rk having no SONAME field in it > +# so add it to fix rdepends problems > +ASSUME_SHLIBS += "libEGL.so:mali-userspace" > +ASSUME_SHLIBS += "libGLESv1_CM.so:mali-userspace" > +ASSUME_SHLIBS += "libGLESv2.so:mali-userspace" > +ASSUME_SHLIBS += "libOpenCL.so:mali-userspace" > +ASSUME_SHLIBS += "libgbm.so:mali-userspace" > +ASSUME_SHLIBS += "libwayland-egl.so:mali-userspace" > + > +PREFERRED_PROVIDER_virtual/kernel = "linux-rockchip" > +PREFERRED_PROVIDER_virtual/bootloader = "u-boot-rockchip" > + > +IMAGE_CLASSES += "rockchip-next-image" > diff --git a/conf/machine/tinker-rk3288.conf b/conf/machine/tinker-rk3288. > conf > new file mode 100644 > index 000..0464133 > --- /dev/null > +++ b/conf/machine/tinker-rk3288.conf > @@ -0,0 +1,13 @@ > +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd > +# Released under the MIT license (see COPYING.MIT for the terms) > + > +#@TYPE: Machine > +#@NAME: Tinker RK3288 > +#@DESCRIPTION: ASUS Tinker Board is a Raspberry Pi 3 Alternative based on > Rockchip RK3288 Processor. > + > +include conf/machine/include/rk3288.inc > +include conf/machine/include/rk-linux.inc > + > +KERNEL_DEVICETREE = "rk3288-miniarm.dtb" > + > +UBOOT_MACHINE = "miniarm-rk3288_defconfig" > -- > 2.7.4 > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 4/7] recipes-graphics: Add support for mali-userspace
Hi all,
Correct me if I am wrong, but these are generic mali userpace binaries ?
meta-rockchip is a bsp meta layer, it should only contains files and
recipes to make rockchip board working or things specific to the rockchip
board. For me these recipes are completly generic and might be re-used for
another platform with another SoC.
I don't want this in meta-rockchip. There is no a layer called meta-mali or
something ?
@Trevor: Feel free to comment, the point of view of the second maintainer
is always welcome
Thanks,
Romain
2017-01-19 15:04 GMT+01:00 Jacob Chen :
> Add support for mali userspace which are binaries that can be run
> with weston and X11.
>
> Signed-off-by: Jacob Chen
> ---
> recipes-graphics/mali-userspace/mali-userspace.inc | 57
> ++
> .../mali-userspace/mali-userspace_t76x.bb | 18 +++
> recipes-graphics/mesa/mesa_%.bbappend | 9
> 3 files changed, 84 insertions(+)
> create mode 100644 recipes-graphics/mali-userspace/mali-userspace.inc
> create mode 100644 recipes-graphics/mali-userspace/mali-userspace_t76x.bb
> create mode 100644 recipes-graphics/mesa/mesa_%.bbappend
>
> diff --git a/recipes-graphics/mali-userspace/mali-userspace.inc
> b/recipes-graphics/mali-userspace/mali-userspace.inc
> new file mode 100644
> index 000..d40f583
> --- /dev/null
> +++ b/recipes-graphics/mali-userspace/mali-userspace.inc
> @@ -0,0 +1,57 @@
> +SUMMARY = "Userspace mali driver for Midgard-T76x"
> +DESCRIPTION = "Userspace mali driver for Midgard-T76x"
> +LICENSE = "CLOSED"
> +SECTION = "libs"
> +
> +DEPENDS = "libdrm"
> +DEPENDS += "${@bb.utils.contains("DISTRO_FEATURES", "wayland", " mesa",
> " ", d)}"
> +
> +PROVIDES += "virtual/egl virtual/libgles1 virtual/libgles2
> virtual/libopencl libgbm"
> +PROVIDES += "${@bb.utils.contains("DISTRO_FEATURES", "wayland", "
> virtual/libwayland-egl", " ", d)}"
> +
> +S = "${WORKDIR}"
> +
> +SRC_URI = "git://github.com/rockchip-linux/libmali.git;branch=rockchip;"
> +SRCREV_pn-${PN} = "${AUTOREV}"
> +
> +INSANE_SKIP_${PN} = "already-stripped ldflags dev-so"
> +
> +INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
> +INHIBIT_PACKAGE_STRIP = "1"
> +
> +USE_X11 = "${@bb.utils.contains("DISTRO_FEATURES", "x11", "yes", "no",
> d)}"
> +USE_WL = "${@bb.utils.contains("DISTRO_FEATURES", "wayland", "yes",
> "no", d)}"
> +
> +do_configure[noexec] = "1"
> +do_compile[noexec] = "1"
> +
> +do_install () {
> + # Create MALI manifest
> + install -m 755 -d ${D}/${libdir}
> + if [ "${USE_X11}" = "yes" ]; then
> + install ${S}/x11/libmali.so ${D}/${libdir}
> + elif [ "${USE_WL}" = "yes" ]; then
> + install ${S}/wayland/libmali.so ${D}/${libdir}
> + fi
> +
> + ln -sf libmali.so ${D}/${libdir}/libEGL.so
> + ln -sf libmali.so ${D}/${libdir}/libGLESv1_CM.so
> + ln -sf libmali.so ${D}/${libdir}/libGLESv2.so
> + ln -sf libmali.so ${D}/${libdir}/libOpenCL.so
> + ln -sf libmali.so ${D}/${libdir}/libgbm.so
> +
> + if [ "${USE_WL}" = "yes" ]; then
> + ln -sf libmali.so ${D}/${libdir}/libwayland-egl.so
> + fi
> +}
> +
> +PACKAGES = "${PN}"
> +FILES_${PN} += "${libdir}/*.so"
> +
> +RREPLACES_${PN} = "libegl libgles1 libglesv1-cm1 libgles2 libglesv2-2
> libgbm"
> +RPROVIDES_${PN} = "libegl libgles1 libglesv1-cm1 libgles2 libglesv2-2
> libgbm"
> +RCONFLICTS_${PN} = "libegl libgles1 libglesv1-cm1 libgles2 libglesv2-2
> libgbm"
> +
> +# Workaround: libmali.so provided by rk having no SONAME field in it
> +# so add it to fix rdepends problems
> +RPROVIDES_${PN} += "libwayland-egl.so libgbm.so libGLESv1_CM.so
> libGLESv2.so libEGL.so libOpenCL.so"
> diff --git a/recipes-graphics/mali-userspace/mali-userspace_t76x.bb
> b/recipes-graphics/mali-userspace/mali-userspace_t76x.bb
> new file mode 100644
> index 000..3281ac0
> --- /dev/null
> +++ b/recipes-graphics/mali-userspace/mali-userspace_t76x.bb
> @@ -0,0 +1,18 @@
> +require mali-userspace.inc
> +
> +TYPE = "midgard"
> +SW_VER = "r13p0"
> +HW_VER = "r0p0"
> +
> +LIB_PATH = "arm-linux-gnueabihf"
> +
> +MALI_X11 = "libmali-${TYPE}-${SW_VER}-${HW_VER}.so"
> +MALI_WAYLAND = "libmali-${TYPE}-${SW_VER}-${HW_VER}-wayland.so"
> +
> +do_install_prepend () {
> + mkdir -p x11
> + cp git/lib/${LIB_PATH}/${MALI_X11} x11/libmali.so
> +
> + mkdir -p wayland
> + cp git/lib/${LIB_PATH}/${MALI_WAYLAND} wayland/libmali.so
> +}
> diff --git a/recipes-graphics/mesa/mesa_%.bbappend
> b/recipes-graphics/mesa/mesa_%.bbappend
> new file mode 100644
> index 000..d9cab75
> --- /dev/null
> +++ b/recipes-graphics/mesa/mesa_%.bbappend
> @@ -0,0 +1,9 @@
> +PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl
> virtual/libwayland-egl"
> +
> +do_install_append () {
> +rm -f ${D}/${libdir}/libEGL*
> +rm -f ${D}/${libdir}/libGLESv1_CM.*
> +rm -f ${D}/${libdir}/libGLESv2.*
> +rm -f ${D}/${libdir}/libgbm*
> +rm -f ${D}/${libdir}/libwayland-egl*
> +}
> --
> 2.7.4
>
>
Re: [yocto] [PATCH 5/7] recipes-bsp: add u-boot-rockchip support
Hi all, 2017-01-19 11:09 GMT+01:00 Jacob Chen : > Rockchip next-dev U-boot is the next generation of rockchip u-boot, will > also be an upstream tracking branch. > At present, this branch is just a rebased upstream u-boot. > > Signed-off-by: Jacob Chen > --- > recipes-bsp/u-boot/u-boot-rockchip_next.bb | 17 + > 1 file changed, 17 insertions(+) > create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_next.bb > > diff --git a/recipes-bsp/u-boot/u-boot-rockchip_next.bb > b/recipes-bsp/u-boot/u-boot-rockchip_next.bb > new file mode 100644 > index 000..30d16b0 > --- /dev/null > +++ b/recipes-bsp/u-boot/u-boot-rockchip_next.bb > @@ -0,0 +1,17 @@ > +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd > +# Released under the MIT license (see COPYING.MIT for the terms) > + > +require recipes-bsp/u-boot/u-boot.inc > + > +DESCRIPTION = "Rockchip next-dev U-Boot" > +LICENSE = "GPLv2+" > +LIC_FILES_CHKSUM = "file://Licenses/README;md5= > a2c678cfd4a4d97135585cad908541c6" > +COMPATIBLE_MACHINE = "(rk3288)" > So... in this case why not simply use u-boot mainline ? Most of rk3288-based boards are very well supported with http://git.denx.de/?p=u-boot/u-boot-rockchip.git .. Do you need something specific that it is not supported yet by u-boot mainline ? My philosophy is simple: When the SoC and the board is correctly supported by a project on upstream, we use the mainline version of this project (ex: the linux kernel, u-boot, etc). When that's not the case, we can write a specific recipe for a vendor version. This is the case for example for the kernel vendor "linux-rockchip" ( https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/recipes-kernel/linux/linux-rockchip_3.0.bb?id=0f7f53c00e7787d5e4843752721a1690169f4ffd), that's basically the kernel vendor 3.0.36 for the radxa rock here because that's the kernel which supports the most features and I/O (compared to the mainline kernel for this SoC or this board). Thanks, Romain -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where to find help for yocto application and and system development
Hello Leon,
Thank you for the answer!
I read the documentation, it doesn't really give me more than general
hints what to try (or maybe I read at the wrong place). I also read in
"Embedded Linux Project Using Yocto Project Cookbook". I know that
bitbake should use autotools somehow. I set up my directories exactly
like the other projects which work without any issues. The other
project, however, are simple executables.
What is unclear to me:
To what shall SCR_URI point? The git repo? Downloaded .tar.gz file? The
source dir copied into the project directory besided the recipe)? I
tried all these ways already, each bringing up a different error, basically.
Do I need to change do_install() or does the makefile handles it? If I
interpret the documentation and the book correctly, I don't need to do
anything more in the recipe...
When I want to fetch from git, it complains about the SRCREF not being
set. So I tried to set it to the most recent commit of the repo in the
recipe file, but it gave another error. I also tried to "append" it
somehow to the git URI which didn't work either.
Note that I need to include the development version of openssl, not
openssl itself (on Ubuntu host you do something like apt install
openssl-dev).
The recipe is appended, if it helps:
# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in order to
be fully functional.
# (Feel free to remove these comments when editing.)
#
# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best
guesses - it is
# your responsibility to verify that the values are complete and correct.
LICENSE = "Unknown"
LIC_FILES_CHKSUM = "file://COPYING;md5=c8ee358fdf91d887aa014c8712e8c22d"
SRC_URI[md5sum] = "da7315f9bc22ff4c24a1cef404b4f3a8"
# No information for SRC_URI yet (only an external source tree was
specified)
SRC_URI =
"/usr/local/dey-2.0/sources/meta-training/recipes-examples/tr-50/tr-50-0.1/"
#SRC_URI =
"git://https://github.com/inhedron/libtr50.git;rev=aedc45c4e9a9a9a3aa301616ad03f07b903d9a81";
#SRC_URI = "file:///home/jakob/Downloads/libtr50-0.1.0.tar.gz"
#SRCREF = "aedc45c4e9a9a9a3aa301616ad03f07b903d9a81"
DEPENDS = "openssl "
# NOTE: if this software is not capable of being built in a separate
build directory
# from the source, you should replace autotools with autotools-brokensep
in the
# inherit line
inherit autotools
# Specify any options you want to pass to the configure script using
EXTRA_OECONF:
EXTRA_OECONF = " --with-examples"
#do_install(){
#eo_runmake install DESTDIR=${D} PREFIX=${D}
#}
Thanks in advance for any answers!
All the best,
Jakob
On 27.01.2017 14:39, Leon Woestenberg wrote:
Hi Jakob,
welcome on-board.
The Yocto community expects you to re-use the available documentation
and online resources (or even offline resources like books) on Yocto
or OpenEmbedded. Then if things remains unclear you can ask questions
here on the mailing list and on IRC channels yocto.
Your question (and probably a lot of subsequent things you learn on
the way) can be answered by the documentation and existing resources.
I would recommend to read the documentation, then find an existing
recipe that uses "autotools" and another that DEPENDS on openssl.
There are a lot of resources online:
http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe
https://www.yoctoproject.org/tools-resources/community/irc
Regards,
Leon.
On Fri, Jan 27, 2017 at 12:43 PM, Jakob Hasse
> wrote:
Hello,
I'm beginning with Yocto.
I would like to know where to find general help (like a forum, or
mailing lists) for my Yocto-related technical problems.
Right now I have problems just integrating a library into my
build. Later I will also do system development.
If this helps, a further description of my most urgent problem:
I want to integrate the tr-50 library, available on github:
https://github.com/inhedron/libtr50
It is managed via autotools.
I built a new project subdirectory in my custom layer for the lib.
I built a basic recipe (with some tool) which, in principle should
somehow recognize the autotools and build the project then. I
changed the SCR_URI to the local .tar.gz file. But when I build,
it comes down to this:
make: *** No rule to make target 'install'. Stop.
I don't know if and which parameters I should change in the recipe.
Another problem is that the lib needs openssl-dev. I can't find
how to include openssl-dev into the Yocto build.
Looking forward for your answers, best regards,
Jakob
--
Jakob Hasse
Software Developement
E: jakob.ha...@smart-home-technology.ch
T: +41 44 552 02 66
Smart Home Technology GmbH
www.smart-home-technology.ch
Re: [yocto] [meta-rockchip][PATCH 6/7] rk3288.inc: add some variables
Hi all, It remembers me a discussion that I wanted to have with Trevor: do we want specific TUNES (like these ones) in the machines files ? it is distro specific ? I think that we might use "simple tune" like cortexa17 and let the possibility to the user to select neon or hf or vfpv4 for example. You could imagine a case where you write a machine file into another layer that inherits from a machine file (which is in meta-rockchip) and overrides DEFAULTTUNE for example. Also Jacob, seriously split your commits :) . One commit per feature with a clear message to describe your changes please. Thanks, Romain 2017-01-19 15:04 GMT+01:00 Jacob Chen : > change tune to cortexa17hf-neon: > Using the soft floating point abi is incompatible with some binary > libaries. > > Set preferred mali version to t76x. > > Add APPEND which will be used in extlinux.conf. > > Add SOC_FAMILY to help add chip specific changes. > > Add SPL_BINARY to support build u-boot spl > > Signed-off-by: Jacob Chen > --- > conf/machine/include/rk3288.inc | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/conf/machine/include/rk3288.inc > b/conf/machine/include/rk3288.inc > index e6c19a2..9e7804a 100644 > --- a/conf/machine/include/rk3288.inc > +++ b/conf/machine/include/rk3288.inc > @@ -1,10 +1,18 @@ > # Copyright (C) 2015 Romain Perier > # Released under the MIT license (see COPYING.MIT for the terms) > > +SOC_FAMILY = "rk3288" > + > require conf/machine/include/tune-cortexa17.inc > +require conf/machine/include/soc-family.inc > > -DEFAULTTUNE="cortexa17-neon" > +DEFAULTTUNE="cortexa17hf-neon" > PREFERRED_PROVIDER_virtual/kernel = "linux" > SERIAL_CONSOLES = "115200;ttyS2" > +SPL_BINARY = "u-boot-spl-dtb.bin" > KERNEL_IMAGETYPE = "zImage" > KBUILD_DEFCONFIG = "multi_v7_defconfig" > + > +PREFERRED_VERSION_mali-userspace = "t76x" > + > +APPEND = "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk2p7 > rootfstype=ext4 init=/sbin/init" > -- > 2.7.4 > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 6/7] rk3288.inc: add some variables
Also "Add some variables"... does not mean anything to me :) 2017-01-27 16:01 GMT+01:00 Romain Perier : > Hi all, > > It remembers me a discussion that I wanted to have with Trevor: do we > want specific TUNES (like these ones) in the machines files ? it is distro > specific ? > I think that we might use "simple tune" like cortexa17 and let the > possibility to the user to select neon or hf or vfpv4 for example. You > could imagine a case where you write a machine file into another layer that > inherits from a machine file (which is in meta-rockchip) and overrides > DEFAULTTUNE for example. > > Also Jacob, seriously split your commits :) . One commit per feature with > a clear message to describe your changes please. > > Thanks, > Romain > > > 2017-01-19 15:04 GMT+01:00 Jacob Chen : > >> change tune to cortexa17hf-neon: >> Using the soft floating point abi is incompatible with some binary >> libaries. >> >> Set preferred mali version to t76x. >> >> Add APPEND which will be used in extlinux.conf. >> >> Add SOC_FAMILY to help add chip specific changes. >> >> Add SPL_BINARY to support build u-boot spl >> >> Signed-off-by: Jacob Chen >> --- >> conf/machine/include/rk3288.inc | 10 +- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/conf/machine/include/rk3288.inc >> b/conf/machine/include/rk3288.inc >> index e6c19a2..9e7804a 100644 >> --- a/conf/machine/include/rk3288.inc >> +++ b/conf/machine/include/rk3288.inc >> @@ -1,10 +1,18 @@ >> # Copyright (C) 2015 Romain Perier >> # Released under the MIT license (see COPYING.MIT for the terms) >> >> +SOC_FAMILY = "rk3288" >> + >> require conf/machine/include/tune-cortexa17.inc >> +require conf/machine/include/soc-family.inc >> >> -DEFAULTTUNE="cortexa17-neon" >> +DEFAULTTUNE="cortexa17hf-neon" >> PREFERRED_PROVIDER_virtual/kernel = "linux" >> SERIAL_CONSOLES = "115200;ttyS2" >> +SPL_BINARY = "u-boot-spl-dtb.bin" >> KERNEL_IMAGETYPE = "zImage" >> KBUILD_DEFCONFIG = "multi_v7_defconfig" >> + >> +PREFERRED_VERSION_mali-userspace = "t76x" >> + >> +APPEND = "console=tty1 console=ttyS2,115200n8 rw root=/dev/mmcblk2p7 >> rootfstype=ext4 init=/sbin/init" >> -- >> 2.7.4 >> >> > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] kernel-yocto: Update source tree with kgit-meta
On 2017-01-26 03:38 AM, David Vincent wrote:
kgit-meta processes a file called meta-series to update the source tree
(create, merge branches, ...). This fixes the merging of feature
branches using the new merge command of yocto-kernel-tools.
I have this queued, with some modifications. I as traveling this week,
so it'll be early next week before this goes out for merge.
cheers,
Bruce
Signed-off-by: David Vincent
---
meta/classes/kernel-yocto.bbclass | 13 +
1 file changed, 13 insertions(+)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 5cfd8aff50..b37ac01a84 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -162,6 +162,19 @@ do_kernel_metadata() {
bbfatal_log "Could not generate configuration queue for
${KMACHINE}."
fi
fi
+
+ # Update git repository by running kgit-meta
+ cd ${S}
+
+ check_git_config
+ meta_dir=$(kgit --meta)
+ if [ -f "${meta_dir}/meta-series" ]; then
+ kgit-meta ${meta_dir}/meta-series
+ if [ $? -ne 0 ]; then
+ bberror "Could not apply metadata for ${KMACHINE}."
+ bbfatal_log "Failures can be resolved in the linux source
directory ${S})"
+ fi
+ fi
}
do_patch() {
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where to find help for yocto application and and system development
Hi Jakob,
It's a bit trial & error with Yocto to be fair.
We use it quite extensively in our LuneOS project. There are quite some
layers available with example recipes as well that you could look into
for inspiration :)
I think 2 important things to note for you:
SRC_URI can point to a git repo, tar.gz etc
When you point to a git repo you need to include SRCREV (with V not
F!!).
When you point to a .tar.gz for example you need to add:
SRC_URI[md5sum] = "mymd5sum"
SRC_URI[sha256sum] = "mysha256sum"
For example see:
For using git:
https://github.com/webOS-ports/meta-webos-ports/blob/b0ca23f27d2496209656b037b113417b0af25480/meta-luneos/recipes-nemomobile/voicecall/voicecall_git.bb#L13
For using a .tar.xz with autotools:
https://github.com/webOS-ports/meta-webos-ports/blob/b0ca23f27d2496209656b037b113417b0af25480/meta-luneos/recipes-support/pidgin/pidgin-sipe_1.21.1.bb
I hope this helps a bit at least.
Herman
On 2017-01-27 15:51, Jakob Hasse wrote:
Hello Leon,
Thank you for the answer!
I read the documentation, it doesn't really give me more than general
hints what to try (or maybe I read at the wrong place). I also read in
"Embedded Linux Project Using Yocto Project Cookbook". I know that
bitbake should use autotools somehow. I set up my directories exactly
like the other projects which work without any issues. The other
project, however, are simple executables.
What is unclear to me:
To what shall SCR_URI point? The git repo? Downloaded .tar.gz file?
The source dir copied into the project directory besided the recipe)?
I tried all these ways already, each bringing up a different error,
basically.
Do I need to change do_install() or does the makefile handles it? If I
interpret the documentation and the book correctly, I don't need to do
anything more in the recipe...
When I want to fetch from git, it complains about the SRCREF not being
set. So I tried to set it to the most recent commit of the repo in the
recipe file, but it gave another error. I also tried to "append" it
somehow to the git URI which didn't work either.
Note that I need to include the development version of openssl, not
openssl itself (on Ubuntu host you do something like apt install
openssl-dev).
The recipe is appended, if it helps:
# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in order
to be fully functional.
# (Feel free to remove these comments when editing.)
#
# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best
guesses - it is
# your responsibility to verify that the values are complete and
correct.
LICENSE = "Unknown"
LIC_FILES_CHKSUM =
"file://COPYING;md5=c8ee358fdf91d887aa014c8712e8c22d" [5]
SRC_URI[md5sum] = "da7315f9bc22ff4c24a1cef404b4f3a8"
# No information for SRC_URI yet (only an external source tree was
specified)
SRC_URI =
"/usr/local/dey-2.0/sources/meta-training/recipes-examples/tr-50/tr-50-0.1/"
#SRC_URI =
"git://https://github.com/inhedron/libtr50.git;rev=aedc45c4e9a9a9a3aa301616ad03f07b903d9a81";
#SRC_URI = "file:///home/jakob/Downloads/libtr50-0.1.0.tar.gz" [6]
#SRCREF = "aedc45c4e9a9a9a3aa301616ad03f07b903d9a81"
DEPENDS = "openssl "
# NOTE: if this software is not capable of being built in a separate
build directory
# from the source, you should replace autotools with
autotools-brokensep in the
# inherit line
inherit autotools
# Specify any options you want to pass to the configure script using
EXTRA_OECONF:
EXTRA_OECONF = " --with-examples"
#do_install(){
#eo_runmake install DESTDIR=${D} PREFIX=${D}
#}
Thanks in advance for any answers!
All the best,
Jakob
On 27.01.2017 14:39, Leon Woestenberg wrote:
Hi Jakob,
welcome on-board.
The Yocto community expects you to re-use the available
documentation and online resources (or even offline resources like
books) on Yocto or OpenEmbedded. Then if things remains unclear you
can ask questions here on the mailing list and on IRC channels
yocto.
Your question (and probably a lot of subsequent things you learn on
the way) can be answered by the documentation and existing
resources.
I would recommend to read the documentation, then find an existing
recipe that uses "autotools" and another that DEPENDS on openssl.
There are a lot of resources online:
http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe
https://www.yoctoproject.org/tools-resources/community/irc
Regards,
Leon.
On Fri, Jan 27, 2017 at 12:43 PM, Jakob Hasse
wrote:
Hello,
I'm beginning with Yocto.
I would like to know where to find general help (like a forum, or
mailing lists) for my Yocto-related technical problems.
Right now I have problems just integrating a library into my
build. Later I will also do system development.
If this helps, a further description of my most urgent problem:
I want to integrate the tr-50 library, available on github:
https://github.com/inhedron/libtr50 [1]
It is managed via autotools.
I built a new project subdirectory i
Re: [yocto] [PATCH 1/7] recipes-kernel: linux-rockchip: Add new recipe for 4.4
Hi all,
supposing that this patch series is for meta-rockchip (next time add a
prefix meta-rockchip, as it is explained in the README)
2017-01-19 11:09 GMT+01:00 Jacob Chen :
> Rockchip 4.4 kernel is currently the latest version of the rockchip
> offical kernel,
> will be an upstream tracking branch.
> We regularly release the kernel through github.
> It support all rockchip 64-bit chips and a few 32-bit chips.
>
Could you be more precise ? if some SoCs are better supported by this
kernel instead the mainline kernel, we can consider to accept this recipe
and use it for a set of boards.
>
> Signed-off-by: Jacob Chen
> ---
> recipes-kernel/linux/linux-rockchip_4.4.bb | 20
> 1 file changed, 20 insertions(+)
> create mode 100644 recipes-kernel/linux/linux-rockchip_4.4.bb
>
> diff --git a/recipes-kernel/linux/linux-rockchip_4.4.bb
> b/recipes-kernel/linux/linux-rockchip_4.4.bb
> new file mode 100644
> index 000..ca3674e
> --- /dev/null
> +++ b/recipes-kernel/linux/linux-rockchip_4.4.bb
> @@ -0,0 +1,20 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +require recipes-kernel/linux/linux-yocto.inc
> +
> +SRC_URI = "git://github.com/rockchip-linux/kernel.git;branch=release-4.4
> ;"
> +
> +SRCREV = "${AUTOREV}"
> +LINUX_VERSION = "4.4.41"
> +# Override local version in order to use the one generated by linux build
> system
> +# And not "yocto-standard"
> +LINUX_VERSION_EXTENSION = ""
> +PR = "r1"
> +PV = "${LINUX_VERSION}"
> +
> +# Include only supported boards for now
> +COMPATIBLE_MACHINE = "(rk3288)"
>
+deltask kernel_configme
>
> +KBUILD_DEFCONFIG = "rockchip_linux_defconfig"
>
>
I think that you can move this to a machine file... (for the board that use
linux-rockchip)
Thanks,
Romain
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 3/7] machine: firefly: use linux-rockchip by default
Hi all, 1. Add more details to your commits 2. As I said in a previous patch, I don't like this... rk-linux.inc , the name of the file is not clear at all... and I don't like its content for now. 3. There is really a small differences between a kernel mainline and your kernel rk3288 nowadays... Do you have a working VPU in your kernel ? perhaps that it might be interesting for this... (if I remember, it's not supported in upstream) Thanks, Romain 2017-01-19 15:40 GMT+01:00 Eddie Cai : > Hi > > 2017-01-19 18:09 GMT+08:00 Jacob Chen : > > This is the kernel vendor that supports all hw components for this board, > > so we use it by default. > The title and commit message didn't match the your content. Linux > rockchip should refer to http://github.com/linux-rockchip. > firefly-rk3288.conf already using http://github.com/linux-rockchip > > > > Signed-off-by: Jacob Chen > > --- > > conf/machine/firefly-rk3288.conf | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/conf/machine/firefly-rk3288.conf > b/conf/machine/firefly-rk3288.conf > > index 8fa005d..47e63e1 100644 > > --- a/conf/machine/firefly-rk3288.conf > > +++ b/conf/machine/firefly-rk3288.conf > > @@ -7,4 +7,8 @@ > > #http://www.t-firefly.com/en/ > > > > include conf/machine/include/rk3288.inc > > +include conf/machine/include/rk-linux.inc > > + > > KERNEL_DEVICETREE = "rk3288-firefly.dtb" > > + > > +UBOOT_MACHINE = "firefly-rk3288_defconfig" > > -- > > 2.7.4 > > > > -- > > ___ > > 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
[yocto] Change default OS in YOCTO poky distro
Hello All, I have few question regarding Yocto poky distribution, it may be very silly question but if somebody could help to clear my doubts it will be very useful. Q1. What is the default OS in Yocto Poky build. Q1. What Steps I need to do in case I want to have some different OS(Android) or Type 1 Hypervisor on my Yocot Poky distro, which layers I need to add or remove from default Yocto Poky distro Thanks and Regards -- *Nitish Jha* -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Change default OS in YOCTO poky distro
On 1/27/17 6:59 AM, nitish jha wrote: > Hello All, > > I have few question regarding Yocto poky distribution, it may be very > silly question but if somebody could help to clear my doubts it will be > very useful. > > Q1. What is the default OS in Yocto Poky build. Yocto tools and infra helps you to generate a Linux based OS > > Q1. What Steps I need to do in case I want to have some different > OS(Android) or Type 1 Hypervisor on my Yocot Poky distro, which layers I > need to add or remove from default Yocto Poky distro > you have bunch of options look into meta-virtualization http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization > > Thanks and Regards > > -- > *Nitish Jha* > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 2/7] machine: Add machine file for the rk3288 linux Boards
On Fri, Jan 27, 2017 at 9:37 AM, Romain Perier wrote: > Could you: > - Make one patch per new machine file and not one patch for all new added > machine Agreed. Are all of these machines actual devices? The evb one doesn't sound real. Are all of these machines released and available for purchase? I've heard of the tinkerboard (although I can't seem to find one I can actually buy) but I haven't heard of the fennec. > - Add a clear @DESCRIPTION for each board, see an example here: > https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/conf/machine/firefly-rk3288.conf > - Write a clear and an understandable commit message for your new patches > > @Trevor: What do you think about this rk-linux.inc ? I don't like this, > either its name and what it contains. First off, I think it's really great to see people contributing to meta-rockchip! :-) This entire set of patches seems to be adding "official" support for the rockchip devices; in other words, these recipes will help you to create builds that use the official rockchip sources. That is great. But I think a good BSP gives a user all the possibilities but then leaves the final decision up to them. So I agree with Romain, I think the name could use more work. It would be nice if this set of patches included something in the name that let the user know these build from official sources. Then the user could decide whether they want to use the official rockchip sources, or whether they want to build from upstream. So I'm not opposed to the idea of adding recipes for official sources, I'd like like to see them added in a way that leaves the decision with the user. > That's it for now. > Thanks for your patches +1 :-) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Delivery Status Notification (Failure)
Jacob, gmail bounced this message back from the "jacob-c...@rock-chips.com" email address since the mail handler for rock-chips.com said the "jacob-chen" user does not exist. We can't accept a Signed-off-by line that doesn't point to a valid email address. Please adjust your Signed-off-by line to point to a real email address. Best regards, Trevor On Fri, Jan 27, 2017 at 2:41 PM, Mail Delivery Subsystem < mailer-dae...@googlemail.com> wrote: > [image: Error Icon] > Message not delivered > There was a problem delivering your message to *jacob-c...@rock-chips.com*. > See the technical details below, or try resending in a few minutes. > The response from the remote server was: > > 550 jacob-c...@rock-chips.com:user not exist > > Final-Recipient: rfc822; jacob-c...@rock-chips.com > Action: failed > Status: 5.0.0 > Remote-MTA: dns; mxwcom.263xmail.com. (38.83.106.84, the server for the > domain rock-chips.com.) > Diagnostic-Code: smtp; 550 jacob-c...@rock-chips.com:user not exist > Last-Attempt-Date: Fri, 27 Jan 2017 11:41:36 -0800 (PST) > > > -- Forwarded message -- > From: Trevor Woerner > To: Romain Perier > Cc: Jacob Chen , "yocto@yoctoproject.org" < > yocto@yoctoproject.org>, Eddie Cai , Jacob Chen > > Date: Fri, 27 Jan 2017 14:41:32 -0500 > Subject: Re: [meta-rockchip][PATCH 2/7] machine: Add machine file for the > rk3288 linux Boards > On Fri, Jan 27, 2017 at 9:37 AM, Romain Perier > wrote: > > Could you: > > - Make one patch per new machine file and not one patch for all new added > > machine > > Agreed. > > Are all of these machines actual devices? The evb one doesn't sound real. > > Are all of these machines released and available for purchase? I've > heard of the tinkerboard (although I can't seem to find one I can > actually buy) but I haven't heard of the fennec. > > > - Add a clear @DESCRIPTION for each board, see an example here: > > https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/ > tree/conf/machine/firefly-rk3288.conf > > - Write a clear and an understandable commit message for your new patches > > > > @Trevor: What do you think about this rk-linux.inc ? I don't like this, > > either its name and what it contains. > > First off, I think it's really great to see people contributing to > meta-rockchip! :-) > > This entire set of patches seems to be adding "official" support for > the rockchip devices; in other words, these recipes will help you to > create builds that use the official rockchip sources. That is great. > But I think a good BSP gives a user all the possibilities but then > leaves the final decision up to them. > > So I agree with Romain, I think the name could use more work. It would > be nice if this set of patches included something in the name that let > the user know these build from official sources. Then the user could > decide whether they want to use the official rockchip sources, or > whether they want to build from upstream. So I'm not opposed to the > idea of adding recipes for official sources, I'd like like to see them > added in a way that leaves the decision with the user. > > > > > That's it for now. > > Thanks for your patches > > +1 :-) > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 2/7] machine: Add machine file for the rk3288 linux Boards
On 1/27/17 11:41 AM, Trevor Woerner wrote: > On Fri, Jan 27, 2017 at 9:37 AM, Romain Perier > wrote: >> Could you: >> - Make one patch per new machine file and not one patch for all new added >> machine > > Agreed. > > Are all of these machines actual devices? The evb one doesn't sound real. > > Are all of these machines released and available for purchase? I've > heard of the tinkerboard (although I can't seem to find one I can > actually buy) but I haven't heard of the fennec. > >> - Add a clear @DESCRIPTION for each board, see an example here: >> https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/tree/conf/machine/firefly-rk3288.conf >> - Write a clear and an understandable commit message for your new patches >> >> @Trevor: What do you think about this rk-linux.inc ? I don't like this, >> either its name and what it contains. > > First off, I think it's really great to see people contributing to > meta-rockchip! :-) > > This entire set of patches seems to be adding "official" support for > the rockchip devices; in other words, these recipes will help you to > create builds that use the official rockchip sources. That is great. > But I think a good BSP gives a user all the possibilities but then > leaves the final decision up to them. > > So I agree with Romain, I think the name could use more work. It would > be nice if this set of patches included something in the name that let > the user know these build from official sources. Then the user could > decide whether they want to use the official rockchip sources, or > whether they want to build from upstream. So I'm not opposed to the > idea of adding recipes for official sources, I'd like like to see them > added in a way that leaves the decision with the user. Usually convention is -mainline.bb in some BSP layer. In somecases community layers are maintained in repo of their own. > > > >> That's it for now. >> Thanks for your patches > > +1 :-) > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 6/7] rk3288.inc: add some variables
Hi Romain, On Fri, Jan 27, 2017 at 10:01 AM, Romain Perier wrote: > Hi all, > > It remembers me a discussion that I wanted to have with Trevor: do we want > specific TUNES (like these ones) in the machines files ? it is distro > specific ? Awesome! I'm happy to see we're both thinking along the same lines! That was exactly the same thought I had too :-) I even had a couple private conversations with some other BSP maintainers I know to ask them about this, and I spent some time surveying other BSP layers to see what other people are doing. Unfortunately there's no consensus, which means that there is no absolute right or wrong. I personally do feel that a good BSP layer should not be providing a DEFAULTTUNE, this decision should be up to the user and/or a DISTRO layer. In practice, however, this topic is complicated (especially in the ARM world) by the existence of the binaries for things like MALI (accelerated graphics). Other devices could potentially have binary blobs for various other reasons. BSPs which provide support for aarch64 devices are lucky because they can skirt this entire issue; aarch64 implies hard float, so the default tunes are always going to enable hard float and therefore work with binaries. 32-bit BSPs are going to have this problem. Looking at other BSP layers many specify a DEFAULTTUNE: - meta-raspberrypi - meta-xilinx - meta-gumstix - meta-intel - meta-odroid (akuster) - meta-freescale - meta-sunxi Most of these DEFAULTTUNE suggestions, however, are found in conf/machine/include/.inc files, not in conf/machine/.bb files directly. Looking closely, however, in many cases a BSP layer might have configurations for many different devices, only some of which have DEFAULTTUNEs (this is true for meta-sunxi, for example). BSP layers that I can find that don't have DEFAULTTUNES are: - meta-qcom - meta-beaglebone (koen) - meta-exynos - meta-ettus In meta-beaglebone's case, it requires conf/machine/include/ti33x.inc (which comes from meta-ti), that file then has a "DEFAULTTUNE ?=" but it could be argued that meta-ti is a chip layer and not a BSP layer. At the very least, it should not be something that is provided with an equals sign, it should be specified in a BSP layer with ?=. Also, the general consensus is that a DEFAULTTUNE should not be given in a machine file directly. Most BSP layers have a "chip include file" in which a DEFAULTTUNE is given. Many layers don't include DEFAULTTUNE but have notes in their README files that explain this to the user and give suggestions for what they might put in their conf/local.conf files. meta-sunxi, for example, doesn't give DEFAULTTUNEs for all their machine files, but they do provide recipes for mali. They handle this in the mali recipe by checking to see if the user has enabled hf. If the user is trying to use mali but hasn't enabled hf then that recipe will error out and let the user know they have to enable hf if they want mali or they have to not try to use mali if they prefer to use soft-float. I think that's a good way of handling this situation (see meta-sunxi/recipes-graphics/libgles/sunxi-mali_git.bb). There is some debate on whether a default tune should point to a specific chip (e.g. cortexa17) or whether it should only specify an ABI (e.g. armv7a). Overwhelmingly in the ARM BSPs specific chips are used. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-rockchip][PATCH 4/7] recipes-graphics: Add support for mali-userspace
On Fri, Jan 27, 2017 at 9:41 AM, Romain Perier wrote: > Hi all, > > Correct me if I am wrong, but these are generic mali userpace binaries ? > meta-rockchip is a bsp meta layer, it should only contains files and recipes > to make rockchip board working or things specific to the rockchip board. For > me these recipes are completly generic and might be re-used for another > platform with another SoC. > > I don't want this in meta-rockchip. There is no a layer called meta-mali or > something ? > > @Trevor: Feel free to comment, the point of view of the second maintainer is > always welcome :-) I was just about to point out that there is no meta-mali, and that most BSP layers do include their own recipes for mali (meta-sunxi, meta-96boards, meta-xilinx) but, googling around, there is in fact a meta-mali provided my ARM itself: https://github.com/ARM-software/meta-mali . So I guess we could go either way. Although I haven't looked at what's specifically provided in meta-mali to know if it would be useful or not. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] pkg_postinst shell?
Hello Yocto. I am debugging my recipe, which uses pkg_postinst but does not seem to work as expected. It runs fine without $D detection. However, if I try to run it at first boot (skipping with exit 1 if $D is not empty), the board boot seems to hang. I think error (syntax error, etc.?) happening when it is run on the board, but package manager. I doubt it is caused by non-existence of '#!/bin/sh' in my script but I am not sure since I am still trying the builds again and again. i) Regarding the posttest script execution, is there log available so that I can look into (instead of writing out log file by myself from within my script)? I do not seem to find it in temp folder of my recipes's working directory. ii) Is '#!/bin/sh' always necessary? iii) What happens with pkg_postinst_PN_append? If it is defined without pkg_postinst_PN, it still works and executed? If i) is true what about '#!/bin/sh' in this case? If you have qucik suggestions, it is a great help. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
