we need to create (and maintain) stable release branches for meta-rpb, e.g. jethro and krogoth, on top of master..

It seems optee doesn't work.

log: https://paste.ubuntu.com/p/6Yf9F9ZzB9/

ERROR: Nothing RPROVIDES 'python-pyserial' (but /home/dl9pf/layerindexeval/tmp.GVNk7lptmM/layers-under-test/meta-96boards/recipes-bsp/burn-boot/burn-boot_git.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'python-pyserial' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['python-pyserial']

Not in README nor LAYERDEPENDS .

The error message is:
"Computing transaction...error: Can't install chromium-wayland-53.0.2785.143-r0@aarch64: no package provides libEGL.so()(64bit)"
or
"Computing transaction...error: Can't install weston-1.11.0-r0@aarch64: no package provides libwayland-egl.so()(64bit)"
etc.

The reason is that mali userland driver is single libMali.so and a number of symlinks pointing at it (libEGL.so.1.4, libEGL.so.1, libEGL.so, libGLESv1_CM.so*, libGLESv2.so*, libgbm.so*, libwayland-egl.so).
And rpm doesn't add "()(64bit)" to symlinks:

$ rpm -q --provides -p mali450-userland-r6p0-01rel0.hikey.rpm
warning: mali450-userland-r6p0-01rel0.hikey.rpm: Header V4 DSA/SHA1 Signature, key ID 30ef670f: NOKEY
elf(buildid) = e855e0c0d17cd37358dbebd2f2670cf770356cb4
libMali.so()(64bit)
libegl
libegl1
libgbm
libgles1
libgles2
libglesv1-cm1
libglesv2-2
mali450-userland = r6p0-01rel0
$ rpm -q --requires -p chromium-wayland-53.0.2785.143-r0.aarch64.rpm
warning: chromium-wayland-53.0.2785.143-r0.aarch64.rpm: Header V4 DSA/SHA1 Signature, key ID fa46f02c: NOKEY
/bin/sh
ld-linux-aarch64.so.1()(64bit)
ld-linux-aarch64.so.1(GLIBC_2.17)(64bit)
libEGL.so()(64bit)

An example log in jenkins (morty based build, multilib enabled):
https://ci.linaro.org/view/All/job/lhg-oe-build/MACHINE=hikey,label=lhg/111/consoleText

the python script to flash the board in recovery mode and the partition tables aren't shipped.

It isn't a big deal, we can use pre-built one from other builds but it will be better for end users to get everything in a single place.

I'm trying to build rpb-weston-image with https://github.com/96boards/oe-rpb-manifest.git master branch, but encounter many errors related to graphics libraries dependencies, following is the error log

ERROR: weston-3.0.0-r0 do_package_qa: QA Issue: /usr/bin/weston-simple-egl contained in package weston-examples requires libEGL.so()(64bit), but no providers found in RDEPENDS_weston-examples? [file-rdeps]
ERROR: weston-3.0.0-r0 do_package_qa: QA Issue: /usr/lib64/libweston-3/gl-renderer.so contained in package libweston-3 requires libEGL.so()(64bit), but no providers found in RDEPENDS_libweston-3? [file-rdeps]
ERROR: weston-3.0.0-r0 do_package_qa: QA Issue: /usr/lib64/libweston-3/gl-renderer.so contained in package libweston-3 requires libGLESv2.so()(64bit), but no providers found in RDEPENDS_libweston-3? [file-rdeps]
ERROR: weston-3.0.0-r0 do_package_qa: QA Issue: /usr/lib64/libweston-3/wayland-backend.so contained in package libweston-3 requires libwayland-egl.so()(64bit), but no providers found in RDEPENDS_libweston-3? [file-rdeps]
ERROR: weston-3.0.0-r0 do_package_qa: QA Issue: /usr/lib64/libweston-3/drm-backend.so contained in package libweston-3 requires libgbm.so()(64bit), but no providers found in RDEPENDS_libweston-3? [file-rdeps]
ERROR: weston-3.0.0-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: weston-3.0.0-r0 do_package_qa: Function failed: do_package_qa

But the libraries do exist:

./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/kmscube/git-r0/recipe-sysroot/usr/lib64/libwayland-egl.so
./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/cogl-1.0/1.22.2-r0/recipe-sysroot/usr/lib64/libwayland-egl.so
./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/gstreamer1.0-plugins-bad/1.12.3-r0/recipe-sysroot/usr/lib64/libwayland-egl.so
./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/libsdl2/2.0.7-r0/recipe-sysroot/usr/lib64/libwayland-egl.so
./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/weston/3.0.0-r0/recipe-sysroot/usr/lib64/libwayland-egl.so
./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/ffmpeg/3.3.4-r0/recipe-sysroot/usr/lib64/libwayland-egl.so
./build-rpb-wayland/tmp-rpb_wayland-glibc/work/aarch64-linaro-linux/clutter-1.0/1.26.2-r0/recipe-sysroot/usr/lib64/libwayland-egl.so
./build-rpb-wayland/tmp-rpb_wayland-glibc/sysroots-components/hikey/mali450-userland/usr/lib64/libwayland-egl.so

Does anyone encounter the same issue or know how to fix it? Any suggestions would be appreciated.

Per comments on #141
[...]
hmm. this looks a bit hacky.. if the config files are specific to hikey they should be in SRC_URI only for hikey. or maybe we should use COMPATIBLE_MACHINE. either way this doesn't look good on non Hikey platforms..
[...]
and
[...]
Side note, SRC_URI won't work, it will leave cfg empty and will fail in grub-mkimage. So if we want to fix the machine specific bits, COMPATIBLE_MACHINE might be the right approach.
[...]

https://developer.arm.com/products/software/mali-drivers/user-space has only one variant of the r7p0 driver for linux:
mali-450_r7p0-01rel0_linux_1arm64.tar.gz
So in the 32-bit build (when ${VER} is "hf") do_fetch fails when trying to download non-existing mali-450_r7p0-01rel0_linux_1arm${VER}.tar.gz

For r6p0 there are two variants:
mali450r6p001rel0linux1arm64tar.gz
mali450r6p001rel0linux1armhftar.gz

As a quick fix I've tried resurrecting recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb, and adding
COMPATIBLE_MACHINE = "(hikey|hikey-32)" - to the r6p0 recipe
and
COMPATIBLE_MACHINE = "hikey$" - to the r7p0 recipe.
This seemed to fix the issue with the hikey-32 build.

For optee-client.bb, is PACKAGE_ARCH = "${MACHINE_ARCH}" needed? Both optee-os_git.bb and optee-test_git.bb have it. Without it, optee_client build files go to build-rpb-wayland/tmp-rpb_wayland-glibc/aarch64-oe-linux instead of build-rpb-wayland/tmp-rpb_wayland-glibc/hikey-oe-linux, where both optee_os and optee_test are located.

https://github.com/96boards/meta-96boards/blob/master/recipes-kernel/linux/linux-96boards/0005-drivers-gpu-arm-utgard-Fix-build-issue.patch#L14

I am using OdroidC1plus board. I am facing same licensing issue in build.
Can anyone explain in which cases this change is allowed ? I don't want to trap in licensing issue for production build.

https://github.com/96boards/meta-96boards/blob/master/conf/machine/hikey.conf#L31

We ship linux-firmware, which is ~50% of the image size. We need to clean up the machine config and include only the required firmwares for HiKey.

I have boot up this recipe in hikey, but the HDMI is not working ,I have changed several Display, but still not work, I find the dmesg
732471] [drm:drm_sysfs_connector_add] ERROR failed to register connector device: -2
[ 1.814349] hi6210-hdmi-audio 0.hi6210_hdmi_card: ASoC: CPU DAI f7118000.hi6210_i2s not registered
[ 1.823408] hi6210-hdmi-audio 0.hi6210_hdmi_card: snd_soc_register_card failed (-517)
[ 1.964030] wlcore: ERROR could not get configuration binary ti-connectivity/wl18xx-conf.bin: -2

To match the same version/hash used by the Debian RPBs, we need to update the EDK2 support for HiKey, and also include support for Grub2, since the hardcoded boot command line was removed (it's now looking for sdcard/boot/efi/boot/bootaa64.efi, available as part of the first disk partition - vfat).

EDK2 version used by the Debian builds:
https://github.com/96boards-hikey/edk2.git - 76c7cfcc22c7448638acb6f904088b2ff3f79f63
https://github.com/96boards-hikey/arm-trusted-firmware.git - c006778cf5c97bd9ecc929620cb71c1b11a29480
https://github.com/96boards-hikey/OpenPlatformPkg.git - branch -> hikey-aosp

Uefi-tools is current latest, as it requires an additional patch for it to work with OpenPlatformPkg.

We should not run weston under the root user. To fix this issue, we need to create a separate weston group. Make sure that the new group can access the input devices and DRM driver.

I compiled the rpb-desktop-image for Hikey960. The image boots up fine but my bluetooth doesn't work. What is the reason for this? Am I missing something or is there any issue with the driver or some missing files? Help would be really appreciated.

0.4 is missing some key fixes that are in 0.7.

Linux 4.4 kernel compilation fails with below error on HiKey build

| DEBUG: Executing shell function do_compile
| NOTE: make -j 16 -j 16 Image CC=aarch64-oe-linux-gcc -fuse-ld=bfd LD=aarch64-oe-linux-ld.bfd
| GEN ./Makefile
| scripts/kconfig/conf --silentoldconfig Kconfig
| CHK include/config/kernel.release
| GEN ./Makefile
| CHK include/generated/uapi/linux/version.h
| CHK include/generated/utsrelease.h
| Using /mnt/home/knagabhirava/Siva/RPBbuild/build-rpb-wayland/tmp-rpb_wayland-glibc/work-shared/hikey/kernel-source as source for kernel
| HOSTCC scripts/extract-cert
| /mnt/home/knagabhirava/Siva/RPBbuild/build-rpb-wayland/tmp-rpb_wayland-glibc/work-shared/hikey/kernel-source/scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
| #include <openssl/bio.h>
| ^
| compilation terminated.
| make[3]: *** [scripts/extract-cert] Error 1
| make[2]: *** [scripts] Error 2
| make[1]: *** [sub-make] Error 2
| make: *** [__sub-make] Error 2

I am not able to ping, error:socket: Permission denied

I tried to flash latest images and I didn't get GRUB. After some testing back and forth, using l-loader from Debian builds worked. The one we build and ship in OE RPB looks broken.

Hi,

Today I tested running a poplar board using the thud branch of the oe-rpb-manifest but I am getting a lot of errors during the linux-poplar build due to usage of gcc8,

example of error:

drivers/msp/pvr/drv_pvr_intf.c:255:56: error: argument to 'sizeof' in 'strncpy' call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer-memaccess]

I tried fixing a couple of them but new errors kept appearing.

Is this something someone else has experienced and know if there are any plans to update the linux-poplar fork. I suspect not as it has been pretty dead for 2 years.

I am trying to re-run the build with:

GCCVERSION = "7.%"

When I have meta-96boards in layermix and try to build for qemux86 it ends up with these horrendous errors

It could be that one recipe provides something the other doesn't and should. The following provider and runtime provider differences may be helpful.
/mnt/a/oe/sources/openembedded-core/meta/recipes-bsp/grub/grub-efi_2.02.bb has unique provides:

/mnt/a/oe/sources/openembedded-core/meta/recipes-bsp/grub/grub-efi_2.02.bb has unique rprovides:
  grub-efi-doc
  grub-efi-locale
  grub-efi-dbg
  ^grub-efi-locale-.*
  grub-efi-staticdev
  grub-efi-dev
/mnt/a/oe/sources/meta-96boards/recipes-bsp/grub/grub_git.bb has unique provides:
  grub
/mnt/a/oe/sources/meta-96boards/recipes-bsp/grub/grub_git.bb has unique rprovides:
  grub-dbg
  grub-doc
  grub-staticdev
  grub
  grub-dev
  grub-locale
  ^grub-locale-.*
ERROR: Multiple versions of grub are due to be built (/mnt/a/oe/sources/meta-96boards/recipes-bsp/grub/grub_git.bb /mnt/a/oe/sources/openembedded-core/meta/recipes-bsp/grub/grub_2.02.bb). Only one version of a given PN should be built in any given build. You likely need t
o set PREFERRED_VERSION_grub to select the correct version or don't depend on multiple versions.

So the question is

is this recipe still relevant ?
whats missing in OE-Core recipe ?
Can the differences be reconciled and upstreamed ?

AARCH64 seems to be fully supported in the version of grub thats provided by OE-Core