96boards / meta-96boards Goto Github PK
View Code? Open in Web Editor NEWOpenEmbedded BSP Layer for the 96boards.org boards
License: MIT License
OpenEmbedded BSP Layer for the 96boards.org boards
License: MIT License
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.
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.%"
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.
[...]
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
we need to create (and maintain) stable release branches for meta-rpb, e.g. jethro and krogoth, on top of master..
I am not able to ping, error:socket: Permission denied
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.
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.
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.
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
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.
It seems optee doesn't work.
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.
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.
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
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.
0.4 is missing some key fixes that are in 0.7.
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
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 .
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.