Hello
While using Linaro 'meta-linaro-toolchain' layer with own definition
of AArch64 machine (not using Linaro's meta-aarch64) I have noticed
seemingly incorrect use of LINKER_HASH_STYLE variable.
In the current master and morty branches (I have not checked others
yet), all meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-*.inc
files contain following lines:
EXTRA_OECONF_BASE = "\
--disable-bootstrap \
--disable-libmudflap \
--with-system-zlib \
--with-linker-hash-style=${LINKER_HASH_STYLE} \
--enable-linker-build-id \
--with-ppl=no \
--with-cloog=no \
In my case, during the build, meta/recipes-devtools/gcc/gcc-cross.inc
gets included and breaks the libgcc qa checks by incorrectly
redefining hash style to SysV (snippet below, this was introduced in
morty):
# While we want the 'gnu' hash style, we explicitly set it to sysv here to
# ensure that any recipe which doesn't obey our LDFLAGS (which also set it to
# gnu) will hit a QA failure.
LINKER_HASH_STYLE ?= "sysv"
So, per my understanding, instead of directly using LINKER_HASH_STYLE,
Linaro GCC build shall parse LDFLAGS and get correct hash style there.
Of course, it may be also hardcoded or otherwise avoided but from the
comment above it seems that Yocto engineers explicitly insist on
LDFLAGS checking :)
Would this approach (use of LDFLAGS instead of LINKER_HASH_STYLE) be
acceptable for meta-linaro?
Best regards,
Artem Mygaiev
Hi folks,
I have two CES blockers with the master branch of https://github.com/ndechesne/meta-qcom
1. The build it defaulting to uni-proc. What change is required to enable all the cores.
2. Issuing reboot in a terminal window will not cause the device to reboot. A power cycle is required after issuing "reboot" from console.
Regards,
Joel Winarske (prior QC Senior Staff Engineer)
Senior Embedded Software Engineer
INRIX
(206) 512-6779
> Op 6 sep. 2016, om 20:42 heeft Denys Dmytriyenko <denis(a)denix.org> het volgende geschreven:
>
> Koen, Fathi, et al,
>
> Any chance to get EXTRA_OEMAKE to not hardcode ARM64 flags?
>
> https://git.linaro.org/openembedded/meta-linaro.git/blob/HEAD:/meta-optee/r…
It’s not planned, but we wouldn’t say no to patches :)
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
Greetings,
Have to call it "v3" as I've sent a different patch with "v2" earlier.
This is a reworked version of "[PATCH] mali-userland-drm: add support for mali450 binaries for hikey":
- the __anonymous() function (inspired by mesa.inc) removed, as I doubt that it adds value in this case, and
am not sure it handles the package names correctly.
- recipe file name changed. Tried to minimize the use of non-default values where possible.
All in all, it now looks more similar to [1].
- using the mesa_%.bbappend looks unavoidable for me, and it should match the files included into the driver
tarball (from SRC_URI), so the mesa_%.bbappend has been added to this patch.
- more comments added.
Regarding the PACKAGE_ARCH = "${MACHINE_ARCH}", the driver is indeed specific for HiKey (would not fit
other boards with mali450), but I don't know the details.
Thanks,
Andrey
[1] https://github.com/ARM-software/meta-mali/blob/master/recipes-graphics/mali…
From: Andrey Konovalov <andrey.konovalov(a)linaro.org>
Date: Wed, 8 Jun 2016 00:07:21 +0300
Subject: [PATCH 1/4] Add public Mali450 driver for wayland
Signed-off-by: Andrey Konovalov <andrey.konovalov(a)linaro.org>
---
.../mali-userland/mali450-userland_r6p0_01rel0.bb | 55 ++++++++++++++++++++++
recipes-graphics/mesa/mesa_%.bbappend | 11 +++++
2 files changed, 66 insertions(+)
create mode 100644 recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb
create mode 100644 recipes-graphics/mesa/mesa_%.bbappend
diff --git a/recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb b/recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb
new file mode 100644
index 0000000..63bcf51
--- /dev/null
+++ b/recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb
@@ -0,0 +1,55 @@
+SUMMARY = "Mali450 libraries (drm backend)"
+
+LICENSE = "Proprietary"
+LIC_FILES_CHKSUM = "file://${WORKDIR}/END_USER_LICENCE_AGREEMENT.txt;md5=3918cc9836ad038c5a090a0280233eea"
+
+SRC_URI[md5sum] = "36f39e86ccfe5a6a4cb2090865c339ba"
+SRC_URI[sha256sum] = "dd136931cdbb309c0ce30297c06f7c6b0a48450f51acbbbc10529d341977f728"
+
+PROVIDES += "virtual/egl virtual/libgles1 virtual/libgles2 virtual/libdrm"
+
+DEPENDS = "virtual/mesa"
+
+BACKEND="drm"
+
+SRC_URI = " http://malideveloper.arm.com/downloads/drivers/binary/utgard/r6p0-01rel0/ma…"
+
+S = "${WORKDIR}/wayland-drm"
+
+# The SRC is just a set of binaries to install - nothing to configure and to
+# compile
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+do_install() {
+ install -m 755 -d ${D}/${libdir}
+ install ${S}/libMali.so ${D}/${libdir}
+ ln -sf libMali.so ${D}/${libdir}/libEGL.so.1.4
+ ln -sf libEGL.so.1.4 ${D}/${libdir}/libEGL.so.1
+ ln -sf libEGL.so.1 ${D}/${libdir}/libEGL.so
+ ln -sf libMali.so ${D}/${libdir}/libGLESv1_CM.so.1.1
+ ln -sf libGLESv1_CM.so.1.1 ${D}/${libdir}/libGLESv1_CM.so.1
+ ln -sf libGLESv1_CM.so.1 ${D}/${libdir}/libGLESv1_CM.so
+ ln -sf libMali.so ${D}/${libdir}/libGLESv2.so.2.0
+ ln -sf libGLESv2.so.2.0 ${D}/${libdir}/libGLESv2.so.2
+ ln -sf libGLESv2.so.2 ${D}/${libdir}/libGLESv2.so
+ ln -sf libMali.so ${D}/${libdir}/libgbm.so.1
+ ln -sf libgbm.so.1 ${D}/${libdir}/libgbm.so
+ ln -sf libMali.so ${D}/${libdir}/libwayland-egl.so
+}
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+# The mali-450 driver tarball has only *.so files, so all the packages
+# except the ${PN} one would be empty
+PACKAGES = "${PN}"
+FILES_${PN} += "${libdir}/*.so* "
+
+INSANE_SKIP_${PN} = "ldflags dev-so"
+
+# To get the egl/gles headers and the packageconfig files (missing from this
+# mali-450 driver tarball) we have to build mesa, and to handle the conflicts
+# due to both mali450-userland, and mesa providing the same libraries.
+RREPLACES_${PN} = "libegl libegl1 libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
+RPROVIDES_${PN} = "libegl libegl1 libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
+RCONFLICTS_${PN} = "libegl libegl1 libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
diff --git a/recipes-graphics/mesa/mesa_%.bbappend b/recipes-graphics/mesa/mesa_%.bbappend
new file mode 100644
index 0000000..3020b2b
--- /dev/null
+++ b/recipes-graphics/mesa/mesa_%.bbappend
@@ -0,0 +1,11 @@
+# Remove the *.so libraries - the ones provided by mali-450 driver are to
+# be used for HiKey
+do_install_append() {
+ rm -f ${D}/${libdir}/libEGL.so*
+ rm -f ${D}/${libdir}/libGLESv1_CM.so*
+ rm -f ${D}/${libdir}/libGLESv2.so*
+ rm -f ${D}/${libdir}/libgbm.so*
+ rm -f ${D}/${libdir}/libwayland-egl.so*
+}
+
+PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl"
--
1.9.1