1. yocto@lists.yoctoproject.org
  2. Messages
   Date   
[meta-rockchip][PATCH v3 0/3] kmeta BSP for nanopi-m4

Yann Dirson
 

From: Yann Dirson <yann@blade-group.com>

Changes from in v3:
- relocate the bsp files into files/ so we don't have to add linux-yocto/
to FILESEXTRAPATHS for all other kernels
- removed the "don't force KCONFIG_MODE to alldefconfig" (not needed fina=
lly,
and causing interferences in default setup)
- add "usbhost" to MACHINE_FEATURES to enable lsusb and friends
- better hardware coverage (though still no wifi/bt/audio, and buggy hdmi=
)

The Wifi/BT support requires firmware, to be properly packaged; BT
support itself is still buggy in mainline; audio jack requires a
couple of patches; HDMI requires at the very least a DTS patch, and
LibreELEC maintains a "latest and greatest" DRM patchset, but it can
conflicts with some patches in default kmeta.

Yann Dirson (3):
rockchip-defaults: don't force KCONFIG_MODE to alldefconfig
NanoPi-M4: let all variants use the same KMACHINE type
linux-yocto: add a NanoPi-M4 BSP

conf/machine/include/nanopi-m4.inc | 1 +
conf/machine/include/rockchip-defaults.inc | 1 -
.../linux/files/bsp/nanopi-m4-standard.scc | 7 +++
.../linux/files/bsp/nanopi-m4-tiny.scc | 7 +++
recipes-kernel/linux/files/bsp/nanopi-m4.cfg | 40 ++++++++++++++
recipes-kernel/linux/files/bsp/nanopi-m4.scc | 5 ++
recipes-kernel/linux/files/bsp/rk3399.cfg | 50 +++++++++++++++++
recipes-kernel/linux/files/bsp/rk3399.scc | 5 ++
recipes-kernel/linux/files/bsp/rockchip.cfg | 53 +++++++++++++++++++
recipes-kernel/linux/files/bsp/rockchip.scc | 6 +++
recipes-kernel/linux/linux-yocto%.bbappend | 6 +++
11 files changed, 180 insertions(+), 1 deletion(-)
create mode 100644 recipes-kernel/linux/files/bsp/nanopi-m4-standard.scc
create mode 100644 recipes-kernel/linux/files/bsp/nanopi-m4-tiny.scc
create mode 100644 recipes-kernel/linux/files/bsp/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/files/bsp/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/files/bsp/rk3399.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rk3399.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip.scc

--=20
2.30.2
[meta-rockchip][PATCH v3 1/3] NanoPi-M4: let all variants use the same KMACHINE type

Yann Dirson
 

From: Yann Dirson <yann@blade-group.com>

This will allow us to define a single set of kernel BSP for all
variants of the board (which only need to differ in u-boot dts).

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
conf/machine/include/nanopi-m4.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/na=
nopi-m4.inc
index 74cdae8..603160f 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -3,6 +3,7 @@
=20
require rk3399.inc
=20
+KMACHINE =3D "nanopi-m4"
KERNEL_DEVICETREE =3D "rockchip/rk3399-nanopi-m4.dtb"
=20
RK_BOOT_DEVICE =3D "mmcblk1"
--=20
2.30.2
Re: #yocto #sdk #cmake #yocto #sdk #cmake

Monsees, Steven C (US)
 

Thanks you...

-----Original Message-----
From: Khem Raj <raj.khem@gmail.com>
Sent: Thursday, April 22, 2021 11:23 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk #cmake

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access "Cybersecurity OneSpace Page" and report phishing by clicking the button "Report Phishing" on the Outlook toolbar.


take a look at
https://github.com/kraj/meta-clang/blob/master/recipes-core/meta/clang-environment.inc#L11-L19

perhaps that can be something you might find useful

On Thu, Apr 22, 2021 at 11:51 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



When setting up an SDK, (standard or extensible), build which will be using cmake, is there a proper way to pre-configure OEToolchainConfig.cmake for ones env/applications ?



Currently I build the SDK, install, and then manually edit...



Thanks,

Steve
Re: #bitbake Can't use 'bitbake -g <image-name> -u taskdep #bitbake

keydi <krzysztof.dudziak@...>
 

As for project here Poky operates on headless server. Developers use SSH to interact with Poky, to handle its input data, and to access build results. Must gtk3 be installed locally to Poky or will taskexp be able to connect to gtk3 operating on ssh client? As of time being Poky host has gtk not installed. Installation of gtk on Poky host will need approval of latter's administrator.
Re: Problems building hardknott for raspberri pi

Khem Raj
 



On Thu, Apr 22, 2021 at 11:13 PM Morten Bruun <morten.bruun@...> wrote:
On Fri, Apr 23, 2021 at 8:03 AM Khem Raj <raj.khem@...> wrote:
On Thu, Apr 22, 2021 at 10:54 PM Morten Bruun <morten.bruun@...> wrote:
>
> On Fri, Apr 23, 2021 at 7:30 AM Khem Raj <raj.khem@...> wrote:
>>
>> On Thu, Apr 22, 2021 at 10:22 PM Morten Bruun <morten.bruun@...> wrote:
>> >
>> > I'm upgrading to hardknott. The meta-raspberry layer does not have a hardknott branch, so I'm building with the master branch.
>> >
>>
>> I think meta-raspberrypi should branch before mesa-gl restructuring
>> initiated changes in meta-raspberrypi can you try with
>> meta-raspberrypi master@d1f191ed3018e0b130311e443f014e30d2f5ed97
>> and see if it works
>>
> Thanks for your quick reply. I tried to build with d1f191ed3018e0b130311e443f014e30d2f5ed97 which gives me this error instead:
>

never mind, I think we perhaps have is broken on master too. Are you
using DISABLE_VC4GRAPHICS = "1" ?


No, I'm not using DISABLE_VC4GRAPHICS - should I?

Then it should not be using Mesa-gl so it’s a bit confusing how you end up needing it 


/Morten
Re: Problems building hardknott for raspberri pi

Morten Bruun
 

On Fri, Apr 23, 2021 at 8:03 AM Khem Raj <raj.khem@...> wrote:
On Thu, Apr 22, 2021 at 10:54 PM Morten Bruun <morten.bruun@...> wrote:
>
> On Fri, Apr 23, 2021 at 7:30 AM Khem Raj <raj.khem@...> wrote:
>>
>> On Thu, Apr 22, 2021 at 10:22 PM Morten Bruun <morten.bruun@...> wrote:
>> >
>> > I'm upgrading to hardknott. The meta-raspberry layer does not have a hardknott branch, so I'm building with the master branch.
>> >
>>
>> I think meta-raspberrypi should branch before mesa-gl restructuring
>> initiated changes in meta-raspberrypi can you try with
>> meta-raspberrypi master@d1f191ed3018e0b130311e443f014e30d2f5ed97
>> and see if it works
>>
> Thanks for your quick reply. I tried to build with d1f191ed3018e0b130311e443f014e30d2f5ed97 which gives me this error instead:
>

never mind, I think we perhaps have is broken on master too. Are you
using DISABLE_VC4GRAPHICS = "1" ?


No, I'm not using DISABLE_VC4GRAPHICS - should I?

/Morten
Re: Problems building hardknott for raspberri pi

Khem Raj
 

On Thu, Apr 22, 2021 at 10:54 PM Morten Bruun <morten.bruun@apide.com> wrote:

On Fri, Apr 23, 2021 at 7:30 AM Khem Raj <raj.khem@gmail.com> wrote:

On Thu, Apr 22, 2021 at 10:22 PM Morten Bruun <morten.bruun@apide.com> wrote:

I'm upgrading to hardknott. The meta-raspberry layer does not have a hardknott branch, so I'm building with the master branch.
I think meta-raspberrypi should branch before mesa-gl restructuring
initiated changes in meta-raspberrypi can you try with
meta-raspberrypi master@d1f191ed3018e0b130311e443f014e30d2f5ed97
and see if it works
Thanks for your quick reply. I tried to build with d1f191ed3018e0b130311e443f014e30d2f5ed97 which gives me this error instead:
never mind, I think we perhaps have is broken on master too. Are you
using DISABLE_VC4GRAPHICS = "1" ?


ERROR: mesa-gl-2_21.0.1-r0 do_configure: meson failed
ERROR: mesa-gl-2_21.0.1-r0 do_configure: Execution of '/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301' failed with exit code 1:
The Meson build system
Version: 0.57.1
Source dir: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/mesa-21.0.1
Build dir: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/build
Build type: cross build
Program python3 found: YES (/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot-native/usr/bin/python3-native/python3)

../mesa-21.0.1/meson.build:21:0: ERROR: Options "swrast" are not in allowed choices: "auto, i915, i965, r100, r200, nouveau"

A full log can be found at /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/build/meson-logs/meson-log.txt
WARNING: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301:181 exit 1 from 'exit 1'
WARNING: Backtrace (BB generated script):
#1: bbfatal_log, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301, line 181
#2: meson_do_configure, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301, line 170
#3: do_configure, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301, line 156
#4: main, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301, line 194

Backtrace (metadata-relative locations):
#1: bbfatal_log, /home/morten/vetscan-spe-instrument/poky/meta/classes/logging.bbclass, line 72
#2: meson_do_configure, /home/morten/vetscan-spe-instrument/poky/meta/classes/meson.bbclass, line 160
#3: do_configure, autogenerated, line 2
ERROR: Logfile of failure stored in: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/log.do_configure.32301

-- Morten
Re: Problems building hardknott for raspberri pi

Morten Bruun
 

On Fri, Apr 23, 2021 at 7:30 AM Khem Raj <raj.khem@...> wrote:
On Thu, Apr 22, 2021 at 10:22 PM Morten Bruun <morten.bruun@...> wrote:
>
> I'm upgrading to hardknott. The meta-raspberry layer does not have a hardknott branch, so I'm building with the master branch.
>

I think meta-raspberrypi should branch before mesa-gl restructuring
initiated changes in meta-raspberrypi can you try with
meta-raspberrypi master@d1f191ed3018e0b130311e443f014e30d2f5ed97
and see if it works

Thanks for your quick reply. I tried to build with d1f191ed3018e0b130311e443f014e30d2f5ed97 which gives me this error instead:

ERROR: mesa-gl-2_21.0.1-r0 do_configure: meson failed
ERROR: mesa-gl-2_21.0.1-r0 do_configure: Execution of '/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301' failed with exit code 1:
The Meson build system
Version: 0.57.1
Source dir: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/mesa-21.0.1
Build dir: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/build
Build type: cross build
Program python3 found: YES (/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot-native/usr/bin/python3-native/python3)

../mesa-21.0.1/meson.build:21:0: ERROR: Options "swrast" are not in allowed choices: "auto, i915, i965, r100, r200, nouveau"

A full log can be found at /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/build/meson-logs/meson-log.txt
WARNING: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301:181 exit 1 from 'exit 1'
WARNING: Backtrace (BB generated script):
        #1: bbfatal_log, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301, line 181
        #2: meson_do_configure, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301, line 170
        #3: do_configure, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301, line 156
        #4: main, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_configure.32301, line 194

Backtrace (metadata-relative locations):
        #1: bbfatal_log, /home/morten/vetscan-spe-instrument/poky/meta/classes/logging.bbclass, line 72
        #2: meson_do_configure, /home/morten/vetscan-spe-instrument/poky/meta/classes/meson.bbclass, line 160
        #3: do_configure, autogenerated, line 2
ERROR: Logfile of failure stored in: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/log.do_configure.32301

-- Morten
Re: Problems building hardknott for raspberri pi

Khem Raj
 

On Thu, Apr 22, 2021 at 10:22 PM Morten Bruun <morten.bruun@apide.com> wrote:

Hi,

I'm upgrading to hardknott. The meta-raspberry layer does not have a hardknott branch, so I'm building with the master branch.
I think meta-raspberrypi should branch before mesa-gl restructuring
initiated changes in meta-raspberrypi can you try with
meta-raspberrypi master@d1f191ed3018e0b130311e443f014e30d2f5ed97
and see if it works

Does anyone know why this error occurs when building mesa-gl?

ERROR: mesa-gl-2_21.0.1-r0 do_compile: Execution of '/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_compile.31992' failed with exit code 1:
[1/7] arm-poky-linux-gnueabi-g++ -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot -o src/gbm/libgbm.so.1.0.0 src/gbm/libgbm.so.1.0.0.p/main_backend.c.o src/gbm/libgbm.so.1.0.0.p/main_gbm.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgbm.so.1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now src/loader/libloader.a src/util/libmesa_util.a src/util/format/libmesa_format.a src/util/libxmlconfig.a -Wl,--gc-sections -ldl -pthread /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libz.so -lm /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libexpat.so /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libdrm.so -Wl,--end-group
FAILED: src/gbm/libgbm.so.1.0.0
arm-poky-linux-gnueabi-g++ -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot -o src/gbm/libgbm.so.1.0.0 src/gbm/libgbm.so.1.0.0.p/main_backend.c.o src/gbm/libgbm.so.1.0.0.p/main_gbm.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgbm.so.1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now src/loader/libloader.a src/util/libmesa_util.a src/util/format/libmesa_format.a src/util/libxmlconfig.a -Wl,--gc-sections -ldl -pthread /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libz.so -lm /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libexpat.so /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libdrm.so -Wl,--end-group
/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/10.2.0/ld: src/gbm/libgbm.so.1.0.0.p/main_backend.c.o: in function `_gbm_create_device':
/usr/src/debug/mesa-gl/2_21.0.1-r0/build/../mesa-21.0.1/src/gbm/main/backend.c:104: undefined reference to `gbm_dri_backend'
collect2: error: ld returned 1 exit status
[2/7] /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot-native/usr/bin/python3-native/python3 ../mesa-21.0.1/bin/git_sha1_gen.py --output src/git_sha1.h
[3/4] rm -f src/mesa/libmesa_classic.a && arm-poky-linux-gnueabi-gcc-ar csrD src/mesa/libmesa_classic.a src/mesa/libmesa_classic.a.p/math_m_xform.c.o src/mesa/libmesa_classic.a.p/tnl_t_context.c.o src/mesa/libmesa_classic.a.p/tnl_t_draw.c.o src/mesa/libmesa_classic.a.p/tnl_t_pipeline.c.o src/mesa/libmesa_classic.a.p/tnl_t_rebase.c.o src/mesa/libmesa_classic.a.p/tnl_t_split.c.o src/mesa/libmesa_classic.a.p/tnl_t_split_copy.c.o src/mesa/libmesa_classic.a.p/tnl_t_split_inplace.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_fog.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_light.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_normals.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_points.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_program.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_render.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_texgen.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_texmat.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_vertex.c.o src/mesa/libmesa_classic.a.p/tnl_t_vertex.c.o src/mesa/libmesa_classic.a.p/tnl_t_vertex_generic.c.o src/mesa/libmesa_classic.a.p/tnl_t_vertex_sse.c.o src/mesa/libmesa_classic.a.p/tnl_t_vp_build.c.o src/mesa/libmesa_classic.a.p/swrast_s_aaline.c.o src/mesa/libmesa_classic.a.p/swrast_s_aatriangle.c.o src/mesa/libmesa_classic.a.p/swrast_s_alpha.c.o src/mesa/libmesa_classic.a.p/swrast_s_atifragshader.c.o src/mesa/libmesa_classic.a.p/swrast_s_bitmap.c.o src/mesa/libmesa_classic.a.p/swrast_s_blend.c.o src/mesa/libmesa_classic.a.p/swrast_s_blit.c.o src/mesa/libmesa_classic.a.p/swrast_s_clear.c.o src/mesa/libmesa_classic.a.p/swrast_s_context.c.o src/mesa/libmesa_classic.a.p/swrast_s_copypix.c.o src/mesa/libmesa_classic.a.p/swrast_s_depth.c.o src/mesa/libmesa_classic.a.p/swrast_s_drawpix.c.o src/mesa/libmesa_classic.a.p/swrast_s_feedback.c.o src/mesa/libmesa_classic.a.p/swrast_s_fog.c.o src/mesa/libmesa_classic.a.p/swrast_s_fragprog.c.o src/mesa/libmesa_classic.a.p/swrast_s_lines.c.o src/mesa/libmesa_classic.a.p/swrast_s_logic.c.o src/mesa/libmesa_classic.a.p/swrast_s_masking.c.o src/mesa/libmesa_classic.a.p/swrast_s_points.c.o src/mesa/libmesa_classic.a.p/swrast_s_renderbuffer.c.o src/mesa/libmesa_classic.a.p/swrast_s_span.c.o src/mesa/libmesa_classic.a.p/swrast_s_stencil.c.o src/mesa/libmesa_classic.a.p/swrast_s_texcombine.c.o src/mesa/libmesa_classic.a.p/swrast_s_texfetch.c.o src/mesa/libmesa_classic.a.p/swrast_s_texfilter.c.o src/mesa/libmesa_classic.a.p/swrast_s_texrender.c.o src/mesa/libmesa_classic.a.p/swrast_s_texture.c.o src/mesa/libmesa_classic.a.p/swrast_s_triangle.c.o src/mesa/libmesa_classic.a.p/swrast_s_zoom.c.o src/mesa/libmesa_classic.a.p/swrast_setup_ss_context.c.o src/mesa/libmesa_classic.a.p/swrast_setup_ss_triangle.c.o src/mesa/libmesa_classic.a.p/drivers_common_driverfuncs.c.o src/mesa/libmesa_classic.a.p/drivers_common_meta_blit.c.o src/mesa/libmesa_classic.a.p/drivers_common_meta_generate_mipmap.c.o src/mesa/libmesa_classic.a.p/drivers_common_meta.c.o src/mesa/libmesa_classic.a.p/x86_x86_xform.c.o src/mesa/libmesa_classic.a.p/x86_3dnow.c.o src/mesa/libmesa_classic.a.p/x86_sse.c.o src/mesa/libmesa_classic.a.p/x86_rtasm_x86sse.c.o src/mesa/libmesa_classic.a.p/sparc_sparc.c.o src/mesa/libmesa_classic.a.p/x86-64_x86-64.c.o
ninja: build stopped: subcommand failed.
WARNING: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_compile.31992:161 exit 1 from 'ninja -v -j 8'
WARNING: Backtrace (BB generated script):
#1: meson_do_compile, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_compile.31992, line 161
#2: do_compile, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_compile.31992, line 156
#3: main, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_compile.31992, line 165

Backtrace (metadata-relative locations):
#1: meson_do_compile, /home/morten/vetscan-spe-instrument/poky/meta/classes/meson.bbclass, line 176
#2: do_compile, autogenerated, line 2
ERROR: Logfile of failure stored in: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/log.do_compile.31992

-- Morten
Problems building hardknott for raspberri pi

Morten Bruun
 

Hi,

I'm upgrading to hardknott. The meta-raspberry layer does not have a hardknott branch, so I'm building with the master branch.

Does anyone know why this error occurs when building mesa-gl?

ERROR: mesa-gl-2_21.0.1-r0 do_compile: Execution of '/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_compile.31992' failed with exit code 1:
[1/7] arm-poky-linux-gnueabi-g++ -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot  -o src/gbm/libgbm.so.1.0.0 src/gbm/libgbm.so.1.0.0.p/main_backend.c.o src/gbm/libgbm.so.1.0.0.p/main_gbm.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgbm.so.1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now src/loader/libloader.a src/util/libmesa_util.a src/util/format/libmesa_format.a src/util/libxmlconfig.a -Wl,--gc-sections -ldl -pthread /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libz.so -lm /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libexpat.so /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libdrm.so -Wl,--end-group
FAILED: src/gbm/libgbm.so.1.0.0
arm-poky-linux-gnueabi-g++ -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot  -o src/gbm/libgbm.so.1.0.0 src/gbm/libgbm.so.1.0.0.p/main_backend.c.o src/gbm/libgbm.so.1.0.0.p/main_gbm.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgbm.so.1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now src/loader/libloader.a src/util/libmesa_util.a src/util/format/libmesa_format.a src/util/libxmlconfig.a -Wl,--gc-sections -ldl -pthread /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libz.so -lm /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libexpat.so /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot/usr/lib/libdrm.so -Wl,--end-group
/home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/10.2.0/ld: src/gbm/libgbm.so.1.0.0.p/main_backend.c.o: in function `_gbm_create_device':
/usr/src/debug/mesa-gl/2_21.0.1-r0/build/../mesa-21.0.1/src/gbm/main/backend.c:104: undefined reference to `gbm_dri_backend'
collect2: error: ld returned 1 exit status
[2/7] /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/recipe-sysroot-native/usr/bin/python3-native/python3 ../mesa-21.0.1/bin/git_sha1_gen.py --output src/git_sha1.h
[3/4] rm -f src/mesa/libmesa_classic.a && arm-poky-linux-gnueabi-gcc-ar csrD src/mesa/libmesa_classic.a src/mesa/libmesa_classic.a.p/math_m_xform.c.o src/mesa/libmesa_classic.a.p/tnl_t_context.c.o src/mesa/libmesa_classic.a.p/tnl_t_draw.c.o src/mesa/libmesa_classic.a.p/tnl_t_pipeline.c.o src/mesa/libmesa_classic.a.p/tnl_t_rebase.c.o src/mesa/libmesa_classic.a.p/tnl_t_split.c.o src/mesa/libmesa_classic.a.p/tnl_t_split_copy.c.o src/mesa/libmesa_classic.a.p/tnl_t_split_inplace.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_fog.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_light.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_normals.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_points.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_program.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_render.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_texgen.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_texmat.c.o src/mesa/libmesa_classic.a.p/tnl_t_vb_vertex.c.o src/mesa/libmesa_classic.a.p/tnl_t_vertex.c.o src/mesa/libmesa_classic.a.p/tnl_t_vertex_generic.c.o src/mesa/libmesa_classic.a.p/tnl_t_vertex_sse.c.o src/mesa/libmesa_classic.a.p/tnl_t_vp_build.c.o src/mesa/libmesa_classic.a.p/swrast_s_aaline.c.o src/mesa/libmesa_classic.a.p/swrast_s_aatriangle.c.o src/mesa/libmesa_classic.a.p/swrast_s_alpha.c.o src/mesa/libmesa_classic.a.p/swrast_s_atifragshader.c.o src/mesa/libmesa_classic.a.p/swrast_s_bitmap.c.o src/mesa/libmesa_classic.a.p/swrast_s_blend.c.o src/mesa/libmesa_classic.a.p/swrast_s_blit.c.o src/mesa/libmesa_classic.a.p/swrast_s_clear.c.o src/mesa/libmesa_classic.a.p/swrast_s_context.c.o src/mesa/libmesa_classic.a.p/swrast_s_copypix.c.o src/mesa/libmesa_classic.a.p/swrast_s_depth.c.o src/mesa/libmesa_classic.a.p/swrast_s_drawpix.c.o src/mesa/libmesa_classic.a.p/swrast_s_feedback.c.o src/mesa/libmesa_classic.a.p/swrast_s_fog.c.o src/mesa/libmesa_classic.a.p/swrast_s_fragprog.c.o src/mesa/libmesa_classic.a.p/swrast_s_lines.c.o src/mesa/libmesa_classic.a.p/swrast_s_logic.c.o src/mesa/libmesa_classic.a.p/swrast_s_masking.c.o src/mesa/libmesa_classic.a.p/swrast_s_points.c.o src/mesa/libmesa_classic.a.p/swrast_s_renderbuffer.c.o src/mesa/libmesa_classic.a.p/swrast_s_span.c.o src/mesa/libmesa_classic.a.p/swrast_s_stencil.c.o src/mesa/libmesa_classic.a.p/swrast_s_texcombine.c.o src/mesa/libmesa_classic.a.p/swrast_s_texfetch.c.o src/mesa/libmesa_classic.a.p/swrast_s_texfilter.c.o src/mesa/libmesa_classic.a.p/swrast_s_texrender.c.o src/mesa/libmesa_classic.a.p/swrast_s_texture.c.o src/mesa/libmesa_classic.a.p/swrast_s_triangle.c.o src/mesa/libmesa_classic.a.p/swrast_s_zoom.c.o src/mesa/libmesa_classic.a.p/swrast_setup_ss_context.c.o src/mesa/libmesa_classic.a.p/swrast_setup_ss_triangle.c.o src/mesa/libmesa_classic.a.p/drivers_common_driverfuncs.c.o src/mesa/libmesa_classic.a.p/drivers_common_meta_blit.c.o src/mesa/libmesa_classic.a.p/drivers_common_meta_generate_mipmap.c.o src/mesa/libmesa_classic.a.p/drivers_common_meta.c.o src/mesa/libmesa_classic.a.p/x86_x86_xform.c.o src/mesa/libmesa_classic.a.p/x86_3dnow.c.o src/mesa/libmesa_classic.a.p/x86_sse.c.o src/mesa/libmesa_classic.a.p/x86_rtasm_x86sse.c.o src/mesa/libmesa_classic.a.p/sparc_sparc.c.o src/mesa/libmesa_classic.a.p/x86-64_x86-64.c.o
ninja: build stopped: subcommand failed.
WARNING: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_compile.31992:161 exit 1 from 'ninja -v -j 8'
WARNING: Backtrace (BB generated script):
        #1: meson_do_compile, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_compile.31992, line 161
        #2: do_compile, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_compile.31992, line 156
        #3: main, /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/run.do_compile.31992, line 165

Backtrace (metadata-relative locations):
        #1: meson_do_compile, /home/morten/vetscan-spe-instrument/poky/meta/classes/meson.bbclass, line 176
        #2: do_compile, autogenerated, line 2
ERROR: Logfile of failure stored in: /home/morten/yocto/spe/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/mesa-gl/2_21.0.1-r0/temp/log.do_compile.31992

-- Morten
Re: #yocto #sdk #cmake #yocto #sdk #cmake

Khem Raj
 

take a look at
https://github.com/kraj/meta-clang/blob/master/recipes-core/meta/clang-environment.inc#L11-L19

perhaps that can be something you might find useful

On Thu, Apr 22, 2021 at 11:51 AM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:




When setting up an SDK, (standard or extensible), build which will be using cmake, is there a proper way to pre-configure OEToolchainConfig.cmake for ones env/applications ?



Currently I build the SDK, install, and then manually edit…



Thanks,

Steve
Re: [meta-openssl102-fips][PATCH 0/6] hardknott fixes

Jason Wessel <jason.wessel@...>
 

Merged.

On 4/22/21 1:56 AM, Yi Zhao wrote:

Changqing Li (1):
openssh: refresh patches to 8.5p1

Chen Qi (1):
layer.conf: add hardknott to LAYERSERIES_COMPAT

Yi Zhao (4):
README.build: add "Known Issues" section
openssh: refresh patches to 8.4p1
openssh: fix the double free error for ssh-cavs
openssh: set kex->sessin_id via sshbuf_put in ssh-cavs

README.build | 28 +++
conf/layer.conf | 2 +-
.../0001-conditional-enable-fips-mode.patch | 46 ++---
...ps.patch => 0001-openssh-8.4p1-fips.patch} | 173 +++++++-----------
...1-ssh-cavs-fix-the-double-free-error.patch | 161 ++++++++++++++++
...avs-set-kex-sessin_id-via-sshbuf_put.patch | 45 +++++
recipes-connectivity/openssh/openssh_fips.inc | 4 +-
7 files changed, 327 insertions(+), 132 deletions(-)
rename recipes-connectivity/openssh/openssh/{0001-openssh-8.2p1-fips.patch => 0001-openssh-8.4p1-fips.patch} (73%)
create mode 100644 recipes-connectivity/openssh/openssh/0001-ssh-cavs-fix-the-double-free-error.patch
create mode 100644 recipes-connectivity/openssh/openssh/0001-ssh-cavs-set-kex-sessin_id-via-sshbuf_put.patch
#yocto #sdk #cmake #yocto #sdk #cmake

Monsees, Steven C (US)
 

 

When setting up an SDK, (standard or extensible),  build which will be using cmake, is there a proper way to pre-configure OEToolchainConfig.cmake for ones env/applications ?

 

Currently I build the SDK, install, and then manually edit…

 

Thanks,

Steve
Re: #bitbake Can't use 'bitbake -g <image-name> -u taskdep #bitbake

Ross Burton <ross@...>
 

Basically, taskdep needs gobject-introspection and gtk3 on the host.
You're most likely missing the GTK3 gir files.

Ross

On Thu, 22 Apr 2021 at 17:00, keydi <krzysztof.dudziak@thalesgroup.com> wrote:

Myself wonders if the answer is just to enable a recipe building native package gtk of version 3.0.
Re: #bitbake Can't use 'bitbake -g <image-name> -u taskdep #bitbake

keydi <krzysztof.dudziak@...>
 

If yes, me wonders how to force Bitbake to build that recipe, if for target system gtk is not built, there is actually no target depending on gtk. Hence, I add such recipe Bitbake might ignore it as target system image does not order, nor any other target depends on.
Re: #bitbake Can't use 'bitbake -g <image-name> -u taskdep #bitbake

keydi <krzysztof.dudziak@...>
 

Myself wonders if the answer is just to enable a recipe building native package gtk of version 3.0.
Re: [meta-security][PATCH] packagegroup-core-security: exclude apparmor in mips64

Armin Kuster
 

On 4/20/21 9:07 AM, Khem Raj wrote:


On 4/20/21 7:41 AM, Armin Kuster wrote:
Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
  recipes-core/packagegroup/packagegroup-core-security.bb | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb
b/recipes-core/packagegroup/packagegroup-core-security.bb
index 9ac0d2c..a6142a8 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -80,6 +80,9 @@ RDEPENDS_packagegroup-security-mac = " \
      ${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack", "",d)} \
      "
  +RDEPENDS_packagegroup-security-mac_remove_mips64 = "apparmor"
+RDEPENDS_packagegroup-security-mac_remove_mips64le = "apparmor"
+
this should be mips64el
Actuall, this is the wrong patch. working on too many systems.

Thanks for the review.

-armin

  RDEPENDS_packagegroup-meta-security-ptest-packages = "\
      ptest-runner \
      samhain-standalone-ptest \
Re: [PATCH] [yocto-autobuilder-helper 1/2] config.json: Add default MACHINE qemux86-64

Yi Fan Yu
 

+cc RP

On 4/19/21 10:36 PM, Yi Fan Yu wrote:
This is the default oe-core MACHINE value.
Prevent error-reporting tool to report simply False.
It was seen in check-layer where the MACHINE wasn't specified.
[YOCTO #14208]
Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
---
config.json | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.json b/config.json
index 962d8ae..2d1a698 100644
--- a/config.json
+++ b/config.json
@@ -26,6 +26,7 @@
"defaults" : {
"NEEDREPOS" : ["poky"],
"DISTRO" : "poky",
+ "MACHINE" : "qemux86-64",
"SDKMACHINE" : "i686",
"PACKAGE_CLASSES" : "package_rpm package_deb package_ipk",
"DLDIR" : "DL_DIR = '${BASE_SHAREDDIR}/current_sources'",
[yocto-autobuilder2] [PATCH] config/schedulers: Add check-layer-nightly

Richard Purdie
 

Add a new target to run layer checks every 24 hours on various layers we don't
test as part of the standard test runs.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
config.py | 2 ++
schedulers.py | 5 +++++
2 files changed, 7 insertions(+)

diff --git a/config.py b/config.py
index 54ec9ce8..82076cd3 100644
--- a/config.py
+++ b/config.py
@@ -23,6 +23,7 @@ buildertorepos = {
"qemuarm-oecore": ["oecore", "bitbake"],
"checkuri": ["poky"],
"check-layer": ["poky", "meta-mingw", "meta-gplv2"],
+ "check-layer-nightly": ["poky", "meta-agl", "meta-arm", "meta-aws", "meta-intel", "meta-openembedded", "meta-virtualization"],
"docs": ["yocto-docs", "bitbake"],
"default": ["poky"]
}
@@ -110,6 +111,7 @@ builders_others = [
"qemuarm-armhost",
"meta-agl-core",
"meta-aws",
+ "check-layer-nightly",
"auh"
]

diff --git a/schedulers.py b/schedulers.py
index 9d81806b..8b166e0b 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -352,6 +352,11 @@ schedulers.append(sched.Nightly(name='nightly-quick', branch='master', propertie
schedulers.append(sched.Nightly(name='nightly-full', branch='master', properties=parent_default_props('a-full'),
builderNames=['a-full'], hour=1, minute=0, dayOfWeek=6))

+# Run check-layer-nightly each day
+schedulers.append(sched.Nightly(name='nightly-check-layer', branch='master', properties=parent_default_props('check-layer-nightly'),
+ builderNames=['check-layer-nightly'], hour=0, minute=0))
+
+
# Run the build performance tests at 3am, 9am, 3pm and 9pm
schedulers.append(sched.Nightly(name='nightly-buildperf-ubuntu1604', branch='master', properties=parent_default_props('buildperf-ubuntu1604'),
builderNames=['buildperf-ubuntu1604'], hour=[3,9,15,21], minute=0))
--
2.30.2
hardknott build issue

Marek Belisko
 

Hi,

I'm meta-sunxi co-maintainer and in order to add hardknott support to
meta-sunxi I try to build few days ago image from hardknott release
and hitting this issue:

WARNING: core-image-base-1.0-r0 do_rootfs: libglib-2.0-0.postinst
returned 126, marking as unpacked only, configuration required on
target.
WARNING: core-image-base-1.0-r0 do_rootfs: eudev-hwdb.postinst
returned 126, marking as unpacked only, configuration required on
target.
ERROR: core-image-base-1.0-r0 do_rootfs: Postinstall scriptlets of
['libglib-2', 'eudev-hwdb'] have failed. If the intention is to defer
them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in
/home/builder/build/tmp/work/orange_pi_zero-poky-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_rootfs.
ERROR: Logfile of failure stored in:
/home/builder/build/tmp/work/orange_pi_zero-poky-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_rootfs.8491
ERROR: Task (/home/builder/poky/meta/recipes-core/images/core-image-base.bb:do_rootfs)
failed with exit code '1'

I'm building core-image-base without any other changes. Ideas?

Thanks and BR,

marek


--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
3901 - 3920 of 57104