* with gstreamer1.0-omx_1.18%.bbappend it won't even parse with
dunfell and older
* and since
36c3c2e7ca
which renamed gstreamer1.0-omx_1.14%.bbappend to gstreamer1.0-omx_1.16%.bbappend it didn't
parse with zeus and older
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
This warning is gcc specific and causes build failures when building
with clang, lets therefore remove it when build is using clang compiler
Signed-off-by: Khem Raj <raj.khem@gmail.com>
With stock u-boot v2020.01 which we use from poky CM3 module won't boot.
We need to apply this patch in order to have platform again working.
Add it only for cm3 to not break anything else.
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
This patch is now backported into 5.4 stable
commit bc79abf4afea97d5ce682aa2bd1095fb74400916
so it should have been
deleted, otherwise its causing build/patch failures now as expected
Signed-off-by: Khem Raj <raj.khem@gmail.com>
rpi kernel spits out additional errors in kernel logs which should be
ignored, there is no easy way to extend parselogs testcase other than
inheriting it into another testcase and use that testcase instead
Signed-off-by: Khem Raj <raj.khem@gmail.com>
libcamera middleware has supported many pipelines for video frames capturing.
So defined the packageconfig, to enable the rpi pipeline and to capture frames
using the rpi camera sensor.
Signed-off-by: Madhavan Krishnan <madhavan.krishnan@linaro.org>
This helps in getting right headers, we have made a choice to let
userland provide KHR/khrplatform.h when using it instead of mesa-gl
which could have been another provider, xserver-xorg's glx
implementation depends on virtual/libgl which in case of rpi-without-vc4
driver is provided by mesa-gl, as a result, compilation fails since no
one is providing this header in this case.
Fixes errors like
usr/include/GL/glext.h:56:10: fatal error: KHR/khrplatform.h: No such file or directory
| 56 | #include <KHR/khrplatform.h>
| | ^~~~~~~~~~~~~~~~~~~
Fixes issue #391
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Needs some fixes from newer 5.4 kernel, e.g.:
1b940bbc5c55 Linux 5.4.56
df35e878d0a5 perf bench: Share some global variables to fix build with gcc 10
702d1b287fd2 perf env: Do not return pointers to local variables
73d2d6b421df perf tests bp_account: Make global variable static
to fix:
LINK perf/1.0-r9/perf-1.0/perf
perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/10.1.0/ld: error: perf/1.0-r9/perf-1.0/plugins/libtraceevent-dynamic-list:2:15: invalid character
perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/10.1.0/ld: error: perf/1.0-r9/perf-1.0/plugins/libtraceevent-dynamic-list:2:15: syntax error, unexpected end of file, expecting ';'
perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/10.1.0/ld: fatal error: unable to parse dynamic-list script file perf/1.0-r9/perf-1.0/plugins/libtraceevent-dynamic-list
collect2: error: ld returned 1 exit status
Makefile.perf:609: recipe for target 'perf/1.0-r9/perf-1.0/perf' failed
make[2]: *** [perf/1.0-r9/perf-1.0/perf] Error 1
make[2]: *** Waiting for unfinished jobs....
perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/10.1.0/ld: error: perf/1.0-r9/perf-1.0/plugins/libtraceevent-dynamic-list:2:15: invalid character
perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/10.1.0/ld: error: perf/1.0-r9/perf-1.0/plugins/libtraceevent-dynamic-list:2:15: syntax error, unexpected end of file, expecting ';'
perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi/../../libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/10.1.0/ld: fatal error: unable to parse dynamic-list script file perf/1.0-r9/perf-1.0/plugins/libtraceevent-dynamic-list
collect2: error: ld returned 1 exit status
error: command 'arm-oe-linux-gnueabi-gcc' failed with exit status 1
cp: cannot stat 'perf/1.0-r9/perf-1.0/python_ext_build/lib/perf*.so': No such file or directory
Makefile.perf:571: recipe for target 'perf/1.0-r9/perf-1.0/python/perf.so' failed
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
If the variable is not defined, bitbake will fail:
[...]
Task 'depends' should be specified in the form 'packagename:task'
[...]
This is because not expanding the variable leaves an invalid entry.
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
The raspberry pi 4 variant has a BCM2711 chip, however it still
uses the same boot files as the BCM2835 used in previous generations.
This change generalizes the naming of the directory generated in the
$DEPLOY_DIR to avoid the implication that the files are only
meant for the BCM2835.
Signed-off-by: Jeff Ithier <ithijme@gmail.com>
Add DEPLOYPAYLOAD, similar to the existing FATPAYLOAD, to enable
adding files to the boot partition from the image deploy directory.
Files such as hypervisor binaries may not be present (and in fact
unwanted) within the root filesystem, so FATPAYLOAD is not sufficient.
DEPLOYPAYLOAD is implemented with support for file renaming from the
source file in the image deploy directory to the filename written into
the boot image. DEPLOYPAYLOAD is a space-separated list of entries for
additions, each of which can optionally be colon-separated:
<image deploy directory file>:<destination filename>
If the colon separator is omitted, the source deploy directory filename
is used as the destination filename.
The support for specifying the destination filename is used for
including Xen, which produces a machine-specific file in the image
deploy directory, and is written to the image partition with its
expected filename: xen.
Files that are to be included from the image deploy directory will
be produced by tasks that the do_image_rpi_sdimg[depends] must list,
so enable adding entries to that via a new variable:
RPI_SDIMG_EXTRA_DEPENDS.
These changes enable retiring a Xen-specific Raspberry Pi SD card
bbclass from meta-virtualization and have been tested on the
Raspberry Pi 4.
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com>
Current configuration (16MHz) is made for the PiCAN2 board that uses 16MHz crystal. This setting allows for use of Waveshare RS485 CAN HAT that has 8MHz crystal soldered (although according to Waveshare there is also a 12MHz crystal version of the board).
Signed-off-by: Jakub Luzny <jakub@luzny.cz>
The u-boot-env is provided by u-boot recipe and not by libubootenv, so
right recipe to append is the u-boot.
Adding the rpi-u-boot-scr in DEPENDS variable is wrong because it is
forcing rpi-u-boot-scr to be a dependency, but it'll fail if I have
another recipe that provides bootscript, once both recipes provide the
same file. The default value of u-boot-default-script is rpi-u-boot-scr,
so right way is to use u-boot-default-script and change the
PREFERRED_PROVIDER_u-boot-default-script if needed.
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
Currently ENABLE_CAN adds mcp2525-can0 to the dtoverlay.
ENABLE_DUAL_CAN was added to also add mcp2515-can1 to the dtoverlay.
This will allow a user to enable dual CAN when using a hat like the
PiCAN 2 Duo board.
Signed-off-by: Colin McAllister <colinmca242@gmail.com>
The device tree only supports a single CAN interface. This prevents
compatiblity with dual-CAN boards like the PiCAN2 Duo.
The mcp2515-can1 device tree blob for overlay was added to RPI_KERNEL_DEVICETREE_OVERLAYS in order to support dual-CAN hats.
Signed-off-by: Colin McAllister <colinmca242@gmail.com>
As per the example in the bsp-guide, and the qemu and other machine
configs. Assists when running virtualized, where serial console
device can differ.
Signed-off-by: Christopher Clark <christopher.w.clark@gmail.com>
