Date   

QA notification for completed autobuilder build (yocto-3.3.1.rc1)

Pokybuild User <pokybuild@...>
 

A build flagged for QA (yocto-3.3.1.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.3.1.rc1


Build hash information:

bitbake: b67476d4758915db7a5d9f58bc903ae7501a1774
meta-arm: 7ca13b4f15cc8f51d6c99b40b7ffafeb47dce28e
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 4d5791d9ff515ba1660234b1987eae4d4e90eeca
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
oecore: efce6334bf122a64f63d46c1c04e3dbffe298c51
poky: 05a8aad57ce250b124db16705acec557819905ae



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...


Re: Opencv build generates Pseudo Abort

Richard Purdie
 

On Mon, 2021-05-17 at 13:25 +0200, Morten Bruun wrote:
Hi,

When building on the new hardknott branch I often get the error below, so far the solution is to delete the
tmp directory. Any suggestions?

debug_logfile: fd 2
pid 6668 [parent 6667], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 6667.
creat for ' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
r0/package/usr/lib/stMOsGHa' replaces existing 11214613 [' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-
linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/libopencv_xfeatures2d.so.4.5.2'].
creat for ' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
r0/package/usr/lib/stUxt79H' replaces existing 11214665 [' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-
linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/libopencv_sfm.so.4.5.2'].
creat for ' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
r0/package/usr/lib/staYWmKL' replaces existing 11214480 [' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-
linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/libopencv_imgproc.so.4.5.2'].
db cleanup for server shutdown, 00:12:21.579
memory-to-file backup complete, 00:12:21.579.
db cleanup finished, 00:12:21.579
debug_logfile: fd 2
pid 4234 [parent 4192], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 4192.
db cleanup for server shutdown, 00:19:10.704
memory-to-file backup complete, 00:19:10.705.
db cleanup finished, 00:19:10.705
debug_logfile: fd 2
pid 17609 [parent 17585], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 17585.
path mismatch [3 links]: ino 12076677 db
This is the key part of the log:

<path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
r0/package/usr/src/debug/opencv/4.5.2-
r0/contrib/modules/intensity_transform/include/opencv2/intensity_transform.hpp' req
'<path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
r0/contrib/modules/intensity_transform/include/opencv2/intensity_transform.hpp'.
and the question is why a file that looks to be in what I'd guess is ${S}:

<path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-
r0/contrib/modules/intensity_transform/include/opencv2/intensity_transform.hpp

was created under pseudo context. Does the recipe give any clue about that?

Cheers,

Richard


[meta-rockchip][PATCH v7 6/6] WIP NanoPi-M4: activate BT support

Yann Dirson
 

From: Yann Dirson <yann@...>

Take the firmware from rbwifibt, as a compatible one does not seem to
be available in broadcom-bt-firmware.

Disclaimer: I have only been able to scan/pair with devices, I could
not establish a connection. However, with the same board I've had the
same results with the board vendor's own FriendlyCore image.
---
conf/machine/include/nanopi-m4.inc | 6 +++++-
recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg | 6 ++++++
2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/na=
nopi-m4.inc
index cb27928..3bd5c97 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -3,7 +3,7 @@
=20
require rk3399.inc
=20
-MACHINE_FEATURES +=3D "usbhost serial wifi"
+MACHINE_FEATURES +=3D "usbhost serial wifi bluetooth"
=20
KMACHINE =3D "nanopi-m4"
KERNEL_DEVICETREE =3D "rockchip/rk3399-nanopi-m4.dtb"
@@ -26,3 +26,7 @@ SERIAL_CONSOLES =3D "1500000;ttyS2"
=20
# wifi firmware
MACHINE_EXTRA_RRECOMMENDS +=3D "linux-firmware-bcm4356"
+
+# bluetooth firmware
+#MACHINE_EXTRA_RRECOMMENDS +=3D "broadcom-bt-firmware-bcm4356a2"
+MACHINE_EXTRA_RRECOMMENDS +=3D "rkwifibt-firmware-ap6356-bt"
diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg b/reci=
pes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
index d42b744..d45e879 100644
--- a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
@@ -14,3 +14,9 @@ CONFIG_REALTEK_PHY=3Dm
CONFIG_WLAN_VENDOR_BROADCOM=3Dy
CONFIG_BRCMFMAC=3Dm
CONFIG_BRCMFMAC_SDIO=3Dy
+
+# AP6356S BT
+CONFIG_BT_HCIUART=3Dm
+CONFIG_SERIAL_DEV_BUS=3Dy
+CONFIG_SERIAL_DEV_CTRL_TTYPORT=3Dy
+CONFIG_BT_HCIUART_BCM=3Dy
--=20
2.30.2


[meta-rockchip][PATCH v7 5/6] WIP Import rkwifibt-firmware from vendor's meta-rockchip

Yann Dirson
 

From: Yann Dirson <yann@...>

As far as the AP6356S in NanoPi-m4 is concerned, the included wifi firmwa=
re
is for Rockchip's kernel tree, but for Bluetooth firmware this seems to b=
e
the proper "upstream" package.

Changes from Rockchip's version:
- use /lib/firmware/brcm/, not /system/etc/firmware/
- include LICENSE.rockchip in package tree

The chip powers on:

[ 4.695193] Bluetooth: hci0: BCM: chip id 101
[ 4.696142] Bluetooth: hci0: BCM: features 0x2f
[ 4.697882] Bluetooth: hci0: BCM4354A2
[ 4.698345] Bluetooth: hci0: BCM4356A2 (001.003.015) build 0000
[ 4.701994] Bluetooth: hci0: BCM4356A2 'brcm/BCM4356A2.hcd' Patch
[ 5.464146] Bluetooth: hci0: BCM4356 37.4MHz AMPAK AP6356-0055
[ 5.464813] Bluetooth: hci0: BCM4356A2 (001.003.015) build 0266

It is able to pair with devices, but connect fails.
---
.../rkwifibt-firmware/files/LICENSE.rockchip | 41 +++++++
.../rkwifibt-firmware/rkwifibt-firmware.bb | 110 ++++++++++++++++++
2 files changed, 151 insertions(+)
create mode 100644 recipes-kernel/rkwifibt-firmware/files/LICENSE.rockch=
ip
create mode 100644 recipes-kernel/rkwifibt-firmware/rkwifibt-firmware.bb

diff --git a/recipes-kernel/rkwifibt-firmware/files/LICENSE.rockchip b/re=
cipes-kernel/rkwifibt-firmware/files/LICENSE.rockchip
new file mode 100644
index 0000000..69b445b
--- /dev/null
+++ b/recipes-kernel/rkwifibt-firmware/files/LICENSE.rockchip
@@ -0,0 +1,41 @@
+Copyright (c) 2020, Rockchip Electronics Co.Ltd
+All rights reserved.
+
+Redistribution. Redistribution and use in binary form, without
+modification, are permitted provided that the following conditions are
+met:
+
+* Redistributions must reproduce the above copyright notice and the
+ following disclaimer in the documentation and/or other materials
+ provided with the distribution.
+
+* Neither the name of Rockchip Electronics Co.Ltd, its products
+ nor the names of its suppliers may be used to endorse or promote produ=
cts
+ derived from this Software without specific prior written permission.
+
+* No reverse engineering, decompilation, or disassembly of this software
+ is permitted.
+
+Limited patent license. Rockchip Electronics Co.Ltd grants a world-wide,
+royalty-free, non-exclusive license under patents it now or hereafter
+owns or controls to make, have made, use, import, offer to sell and
+sell ("Utilize") this software, but solely to the extent that any
+such patent is necessary to Utilize the software alone, or in
+combination with an operating system licensed under an approved Open
+Source license as listed by the Open Source Initiative at
+http://opensource.org/licenses. The patent license shall not apply to
+any other combinations which include this software. No hardware per
+se is licensed hereunder.
+
+DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
+BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
+OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGE.
diff --git a/recipes-kernel/rkwifibt-firmware/rkwifibt-firmware.bb b/reci=
pes-kernel/rkwifibt-firmware/rkwifibt-firmware.bb
new file mode 100644
index 0000000..870177b
--- /dev/null
+++ b/recipes-kernel/rkwifibt-firmware/rkwifibt-firmware.bb
@@ -0,0 +1,110 @@
+# Copyright (C) 2019, Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SUMMARY =3D "Rockchip WIFI/BT firmware files"
+SECTION =3D "kernel"
+
+LICENSE =3D "LICENSE.rockchip"
+LIC_FILES_CHKSUM =3D "file://LICENSE.rockchip;md5=3Dd63890e209bf038f44e7=
08bbb13e4ed9"
+
+PV_append =3D "+git${SRCPV}"
+
+SRCREV =3D "af2cf8772078b0246ac805e7ed78a62cf8f21993"
+SRC_URI =3D " \
+ git://github.com/rockchip-linux/rkwifibt.git \
+ file://LICENSE.rockchip;subdir=3Dgit \
+"
+#SRC_URI =3D "git://github.com/JeffyCN/mirrors.git;branch=3Drkwifibt;"
+
+S =3D "${WORKDIR}/git"
+
+inherit allarch deploy
+
+do_install() {
+ install -d ${D}/lib/firmware/brcm/
+ install -m 0644 ${S}/firmware/broadcom/all/*/* \
+ -t ${D}/lib/firmware/brcm/
+ install -d ${D}/lib/firmware/rtlbt/
+ install -m 0644 ${S}/realtek/RTL*/* -t ${D}/lib/firmware/rtlbt/
+}
+
+PACKAGES =3D+ " \
+ ${PN}-ap6181-wifi \
+ ${PN}-ap6212a1-wifi \
+ ${PN}-ap6212a1-bt \
+ ${PN}-ap6236-wifi \
+ ${PN}-ap6236-bt \
+ ${PN}-ap6255-wifi \
+ ${PN}-ap6255-bt \
+ ${PN}-ap6354-wifi \
+ ${PN}-ap6354-bt \
+ ${PN}-ap6356-wifi \
+ ${PN}-ap6356-bt \
+ ${PN}-rtl8723ds-bt \
+"
+
+FILES_${PN}-ap6181-wifi =3D " \
+ lib/firmware/brcm/fw_bcm40181a2_apsta.bin \
+ lib/firmware/brcm/fw_bcm40181a2.bin \
+ lib/firmware/brcm/nvram_ap6181.txt \
+"
+
+FILES_${PN}-ap6212a1-wifi =3D " \
+ lib/firmware/brcm/fw_bcm43438a1_apsta.bin \
+ lib/firmware/brcm/fw_bcm43438a1.bin \
+ lib/firmware/brcm/nvram_ap6212a.txt \
+"
+FILES_${PN}-ap6212a1-bt =3D " \
+ lib/firmware/brcm/bcm43438a1.hcd \
+"
+
+FILES_${PN}-ap6236-wifi =3D " \
+ lib/firmware/brcm/fw_bcm43436b0_apsta.bin \
+ lib/firmware/brcm/fw_bcm43436b0.bin \
+ lib/firmware/brcm/nvram_ap6236.txt \
+"
+FILES_${PN}-ap6236-bt =3D " \
+ lib/firmware/brcm/BCM4343B0.hcd \
+"
+
+FILES_${PN}-ap6255-wifi =3D " \
+ lib/firmware/brcm/fw_bcm43455c0_ag.bin \
+ lib/firmware/brcm/nvram_ap6255.txt \
+"
+FILES_${PN}-ap6255-bt =3D " \
+ lib/firmware/brcm/BCM4345C0_ap.hcd \
+ lib/firmware/brcm/BCM4345C0.hcd \
+"
+
+FILES_${PN}-ap6354-wifi =3D " \
+ lib/firmware/brcm/fw_bcm4354a1_ag.bin \
+ lib/firmware/brcm/nvram_ap6354.txt \
+"
+FILES_${PN}-ap6354-bt =3D " \
+ lib/firmware/brcm/bcm4354a1.hcd \
+"
+
+FILES_${PN}-ap6356-wifi =3D " \
+ lib/firmware/brcm/fw_bcm4356a2_ag.bin \
+ lib/firmware/brcm/nvram_ap6356.txt \
+ lib/firmware/brcm/nvram_ap6356s.txt \
+"
+FILES_${PN}-ap6356-bt =3D " \
+ lib/firmware/brcm/BCM4356A2.hcd \
+"
+
+FILES_${PN}-rtl8723ds-bt =3D " \
+ lib/firmware/rtlbt/rtl8723d_config \
+ lib/firmware/rtlbt/rtl8723d_fw \
+"
+
+FILES_${PN} =3D "*"
+
+# Make it depend on all of the split-out packages.
+python () {
+ pn =3D d.getVar('PN')
+ firmware_pkgs =3D oe.utils.packages_filter_out_system(d)
+ d.appendVar('RDEPENDS_' + pn, ' ' + ' '.join(firmware_pkgs))
+}
+
+INSANE_SKIP_${PN} +=3D "arch"
--=20
2.30.2


[meta-rockchip][PATCH v7 4/6] NanoPi-M4: activate Wifi support

Yann Dirson
 

From: Yann Dirson <yann@...>

---
conf/machine/include/nanopi-m4.inc | 5 ++++-
recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg | 5 +++++
2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/na=
nopi-m4.inc
index a14b705..cb27928 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -3,7 +3,7 @@
=20
require rk3399.inc
=20
-MACHINE_FEATURES +=3D "usbhost serial"
+MACHINE_FEATURES +=3D "usbhost serial wifi"
=20
KMACHINE =3D "nanopi-m4"
KERNEL_DEVICETREE =3D "rockchip/rk3399-nanopi-m4.dtb"
@@ -23,3 +23,6 @@ IMAGE_BOOT_FILES ?=3D "\
"
=20
SERIAL_CONSOLES =3D "1500000;ttyS2"
+
+# wifi firmware
+MACHINE_EXTRA_RRECOMMENDS +=3D "linux-firmware-bcm4356"
diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg b/reci=
pes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
index f3a2abf..d42b744 100644
--- a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
@@ -9,3 +9,8 @@ CONFIG_PWRSEQ_SIMPLE=3Dy
=20
# RTL8211E
CONFIG_REALTEK_PHY=3Dm
+
+# AP6356S Wifi
+CONFIG_WLAN_VENDOR_BROADCOM=3Dy
+CONFIG_BRCMFMAC=3Dm
+CONFIG_BRCMFMAC_SDIO=3Dy
--=20
2.30.2


[meta-rockchip][PATCH v7 3/6] linux-firmware: import variables file for ap4356s firmware from armbian

Yann Dirson
 

From: Yann Dirson <yann@...>

This is required for wifi support on nanopi-m4 with kernel 5.10.

This is dependant on poky commit commit 698fd81c551b52ff7f4a26e42d9acf9ad=
4ce5639,
"linux-firmware: include all relevant files in -bcm4356".

This file was fetched from
https://github.com/armbian/firmware/commit/9c800d7e16616dd30cfd854f26e563=
fb675e3f8a

Signed-off-by: Yann Dirson <yann@...>
---
.../files/brcmfmac4356-sdio.txt | 126 ++++++++++++++++++
.../linux-firmware/linux-firmware_%.bbappend | 13 ++
2 files changed, 139 insertions(+)
create mode 100644 recipes-kernel/linux-firmware/files/brcmfmac4356-sdio=
.txt
create mode 100644 recipes-kernel/linux-firmware/linux-firmware_%.bbappe=
nd

diff --git a/recipes-kernel/linux-firmware/files/brcmfmac4356-sdio.txt b/=
recipes-kernel/linux-firmware/files/brcmfmac4356-sdio.txt
new file mode 100644
index 0000000..a8c1ff8
--- /dev/null
+++ b/recipes-kernel/linux-firmware/files/brcmfmac4356-sdio.txt
@@ -0,0 +1,126 @@
+# Sample variables file for BCM94356Z NGFF 22x30mm iPA, iLNA board with =
PCIe for production package
+NVRAMRev=3D$Rev: 492104 $
+#4356 chip =3D 4354 A2 chip
+sromrev=3D11
+boardrev=3D0x1102
+boardtype=3D0x073e
+boardflags=3D0x02400201
+#0x2000 enable 2G spur WAR
+boardflags2=3D0x00802000
+boardflags3=3D0x0000000a
+#boardflags3 0x00000100 /* to read swctrlmap from nvram*/
+#define BFL3_5G_SPUR_WAR 0x00080000 /* enable spur WAR in 5G band */
+#define BFL3_AvVim 0x40000000 /* load AvVim from nvram */
+macaddr=3D00:90:4c:1a:10:01
+ccode=3DX2
+regrev=3D205
+antswitch=3D0
+pdgain5g=3D4
+pdgain2g=3D4
+tworangetssi2g=3D0
+tworangetssi5g=3D0
+paprdis=3D0
+femctrl=3D10
+vendid=3D0x14e4
+devid=3D0x43ec
+manfid=3D0x2d0
+#prodid=3D0x052e
+nocrc=3D1
+otpimagesize=3D502
+xtalfreq=3D37400
+rxgains2gelnagaina0=3D0
+rxgains2gtrisoa0=3D7
+rxgains2gtrelnabypa0=3D0
+rxgains5gelnagaina0=3D0
+rxgains5gtrisoa0=3D11
+rxgains5gtrelnabypa0=3D0
+rxgains5gmelnagaina0=3D0
+rxgains5gmtrisoa0=3D13
+rxgains5gmtrelnabypa0=3D0
+rxgains5ghelnagaina0=3D0
+rxgains5ghtrisoa0=3D12
+rxgains5ghtrelnabypa0=3D0
+rxgains2gelnagaina1=3D0
+rxgains2gtrisoa1=3D7
+rxgains2gtrelnabypa1=3D0
+rxgains5gelnagaina1=3D0
+rxgains5gtrisoa1=3D10
+rxgains5gtrelnabypa1=3D0
+rxgains5gmelnagaina1=3D0
+rxgains5gmtrisoa1=3D11
+rxgains5gmtrelnabypa1=3D0
+rxgains5ghelnagaina1=3D0
+rxgains5ghtrisoa1=3D11
+rxgains5ghtrelnabypa1=3D0
+rxchain=3D3
+txchain=3D3
+aa2g=3D3
+aa5g=3D3
+agbg0=3D2
+agbg1=3D2
+aga0=3D2
+aga1=3D2
+tssipos2g=3D1
+extpagain2g=3D2
+tssipos5g=3D1
+extpagain5g=3D2
+tempthresh=3D255
+tempoffset=3D255
+rawtempsense=3D0x1ff
+pa2ga0=3D-147,6192,-705
+pa2ga1=3D-161,6041,-701
+pa5ga0=3D-194,6069,-739,-188,6137,-743,-185,5931,-725,-171,5898,-715
+pa5ga1=3D-190,6248,-757,-190,6275,-759,-190,6225,-757,-184,6131,-746
+subband5gver=3D0x4
+pdoffsetcckma0=3D0x4
+pdoffsetcckma1=3D0x4
+pdoffset40ma0=3D0x0000
+pdoffset80ma0=3D0x0000
+pdoffset40ma1=3D0x0000
+pdoffset80ma1=3D0x0000
+maxp2ga0=3D76
+maxp5ga0=3D74,74,74,74
+maxp2ga1=3D76
+maxp5ga1=3D74,74,74,74
+cckbw202gpo=3D0x0000
+cckbw20ul2gpo=3D0x0000
+mcsbw202gpo=3D0x99644422
+mcsbw402gpo=3D0x99644422
+dot11agofdmhrbw202gpo=3D0x6666
+ofdmlrbw202gpo=3D0x0022
+mcsbw205glpo=3D0x88766663
+mcsbw405glpo=3D0x88666663
+mcsbw805glpo=3D0xbb666665
+mcsbw205gmpo=3D0xd8666663
+mcsbw405gmpo=3D0x88666663
+mcsbw805gmpo=3D0xcc666665
+mcsbw205ghpo=3D0xdc666663
+mcsbw405ghpo=3D0xaa666663
+mcsbw805ghpo=3D0xdd666665
+mcslr5glpo=3D0x0000
+mcslr5gmpo=3D0x0000
+mcslr5ghpo=3D0x0000
+sb20in40hrpo=3D0x0
+sb20in80and160hr5glpo=3D0x0
+sb40and80hr5glpo=3D0x0
+sb20in80and160hr5gmpo=3D0x0
+sb40and80hr5gmpo=3D0x0
+sb20in80and160hr5ghpo=3D0x0
+sb40and80hr5ghpo=3D0x0
+sb20in40lrpo=3D0x0
+sb20in80and160lr5glpo=3D0x0
+sb40and80lr5glpo=3D0x0
+sb20in80and160lr5gmpo=3D0x0
+sb40and80lr5gmpo=3D0x0
+sb20in80and160lr5ghpo=3D0x0
+sb40and80lr5ghpo=3D0x0
+dot11agduphrpo=3D0x0
+dot11agduplrpo=3D0x0
+phycal_tempdelta=3D255
+temps_period=3D15
+temps_hysteresis=3D15
+rssicorrnorm_c0=3D4,4
+rssicorrnorm_c1=3D4,4
+rssicorrnorm5g_c0=3D1,2,3,1,2,3,6,6,8,6,6,8
+rssicorrnorm5g_c1=3D1,2,3,2,2,2,7,7,8,7,7,8
+
diff --git a/recipes-kernel/linux-firmware/linux-firmware_%.bbappend b/re=
cipes-kernel/linux-firmware/linux-firmware_%.bbappend
new file mode 100644
index 0000000..45ab311
--- /dev/null
+++ b/recipes-kernel/linux-firmware/linux-firmware_%.bbappend
@@ -0,0 +1,13 @@
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
+
+SRC_URI +=3D "\
+ file://brcmfmac4356-sdio.txt \
+"
+
+BRCMDIR =3D "${nonarch_base_libdir}/firmware/brcm"
+
+do_install_append() {
+ install -m644 ${WORKDIR}/brcmfmac4356-sdio.txt ${D}${BRCMDIR}/
+}
+
+FILES_${PN}-bcm4356 +=3D "${BRCMDIR}/brcmfmac4356-sdio.*"
--=20
2.30.2


[meta-rockchip][PATCH v7 1/6] linux-yocto: add an initial NanoPi-M4 BSP

Yann Dirson
 

From: Yann Dirson <yann@...>

This patch provides "standard" and "tiny" BSP.

There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
Not all SoC/board features are covered yet either (esp. Wifi/Bluetooth an=
d
audio jack), and properly-woking HDMI still needs patches.

Tiny is not fully testable by itself, it can be minimally booted with
serial console (though still missing CONFIG_MULTIUSER for serial getty,
and CONFIG_INOTIFY_USER for proper udev operation) using:

PREFERRED_PROVIDER_virtual/kernel =3D "linux-yocto-tiny"
KERNEL_FEATURES_append =3D "\
ktypes/base/base.scc \
features/debug/printk.scc \
cfg/fs/ext4.scc \
cfg/8250.scc \
"

Such a tiny build is still using mainline defconfig with lots of hardware
features, and the kernel can be slimmed down even more by using:

KBUILD_DEFCONFIG =3D ""

Kernel weight using default configurations:
- standard 11MB
- tiny 5MB
- tiny with no defconfig 2.5MB

Signed-off-by: Yann Dirson <yann@...>
---
.../files/bsp/rockchip/nanopi-m4-standard.scc | 8 +++
.../files/bsp/rockchip/nanopi-m4-tiny.scc | 8 +++
.../linux/files/bsp/rockchip/nanopi-m4.cfg | 11 +++
.../linux/files/bsp/rockchip/nanopi-m4.scc | 5 ++
.../linux/files/bsp/rockchip/rk3399.cfg | 70 +++++++++++++++++++
.../linux/files/bsp/rockchip/rk3399.scc | 5 ++
.../linux/files/bsp/rockchip/rockchip.cfg | 50 +++++++++++++
.../linux/files/bsp/rockchip/rockchip.scc | 6 ++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++
9 files changed, 169 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-sta=
ndard.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tin=
y.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rk3399.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rockchip.scc

diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.s=
cc b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.scc
new file mode 100644
index 0000000..7d28b2b
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.scc
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE nanopi-m4
+define KTYPE standard
+define KARCH arm
+define KMETA_EXTERNAL_BSP t
+
+include ktypes/standard/standard.scc nopatch
+include nanopi-m4.scc
diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tiny.scc b=
/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tiny.scc
new file mode 100644
index 0000000..fe1f5b8
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tiny.scc
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE nanopi-m4
+define KTYPE tiny
+define KARCH arm
+define KMETA_EXTERNAL_BSP t
+
+include ktypes/tiny/tiny.scc nopatch
+include nanopi-m4.scc
diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg b/reci=
pes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
new file mode 100644
index 0000000..f3a2abf
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
@@ -0,0 +1,11 @@
+CONFIG_MFD_RK808=3Dy
+CONFIG_COMMON_CLK_RK808=3Dy
+
+CONFIG_REGULATOR_RK808=3Dy
+CONFIG_REGULATOR_FAN53555=3Dy
+
+CONFIG_MMC_BLOCK=3Dy
+CONFIG_PWRSEQ_SIMPLE=3Dy
+
+# RTL8211E
+CONFIG_REALTEK_PHY=3Dm
diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc b/reci=
pes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc
new file mode 100644
index 0000000..f4267aa
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware nanopi-m4.cfg
+
+include rk3399.scc
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg b/recipes=
-kernel/linux/files/bsp/rockchip/rk3399.cfg
new file mode 100644
index 0000000..42adfd1
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
@@ -0,0 +1,70 @@
+# A72 errata, all past revisions
+CONFIG_ARM64_ERRATUM_1319367=3Dy
+# A53 errata, all patched on boot when needed
+CONFIG_ARM64_ERRATUM_826319=3Dy
+CONFIG_ARM64_ERRATUM_827319=3Dy
+CONFIG_ARM64_ERRATUM_824069=3Dy
+CONFIG_ARM64_ERRATUM_819472=3Dy
+
+# cru
+CONFIG_CLK_RK3399=3Dy
+
+CONFIG_PL330_DMA=3Dy
+CONFIG_I2C_RK3X=3Dy
+CONFIG_SERIAL_8250_DW=3Dy
+
+# usb
+CONFIG_PHY_ROCKCHIP_INNO_USB2=3Dy
+CONFIG_PHY_ROCKCHIP_TYPEC=3Dy
+
+# ethernet
+CONFIG_NET_VENDOR_STMICRO=3Dy
+CONFIG_STMMAC_ETH=3Dm
+CONFIG_STMMAC_PLATFORM=3Dm
+CONFIG_DWMAC_ROCKCHIP=3Dm
+CONFIG_PHYLIB=3Dm
+
+# display
+CONFIG_ROCKCHIP_DW_HDMI=3Dy
+CONFIG_ROCKCHIP_DW_MIPI_DSI=3Dy
+CONFIG_ROCKCHIP_ANALOGIX_DP=3Dy
+CONFIG_ROCKCHIP_CDN_DP=3Dy
+CONFIG_PHY_ROCKCHIP_DP=3Dy
+CONFIG_DRM_DW_HDMI=3Dm
+CONFIG_DRM_DW_HDMI_I2S_AUDIO=3Dm
+CONFIG_DRM_DW_HDMI_CEC=3Dm
+CONFIG_DRM_DW_MIPI_DSI=3Dm
+CONFIG_DRM_PANFROST=3Dm
+
+# HDMI audio
+CONFIG_DRM_DW_HDMI_AHB_AUDIO=3Dm
+
+CONFIG_VIDEO_DEV=3Dm
+CONFIG_V4L_MEM2MEM_DRIVERS=3Dy
+CONFIG_VIDEO_ROCKCHIP_RGA=3Dm
+
+CONFIG_V4L2_H264=3Dm
+CONFIG_MEDIA_CONTROLLER_REQUEST_API=3Dy
+CONFIG_VIDEO_HANTRO=3Dm
+CONFIG_VIDEO_HANTRO_ROCKCHIP=3Dy
+CONFIG_VIDEO_ROCKCHIP_VDEC=3Dm
+
+# usb
+CONFIG_USB_DWC2=3Dy
+CONFIG_USB_DWC3=3Dy
+CONFIG_USB_DWC3_DUAL_ROLE=3Dy
+
+# sd/mmc
+CONFIG_MMC=3Dy
+CONFIG_MMC_SDHCI=3Dy
+CONFIG_MMC_SDHCI_PLTFM=3Dy
+CONFIG_MMC_DW=3Dy
+CONFIG_MMC_DW_ROCKCHIP=3Dy
+CONFIG_MMC_SDHCI_OF_ARASAN=3Dy
+
+# temperature sensors
+CONFIG_THERMAL=3Dy
+CONFIG_THERMAL_OF=3Dy
+CONFIG_ROCKCHIP_THERMAL=3Dm
+CONFIG_IIO=3Dy
+CONFIG_ROCKCHIP_SARADC=3Dm
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rk3399.scc b/recipes=
-kernel/linux/files/bsp/rockchip/rk3399.scc
new file mode 100644
index 0000000..9b1a88e
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rk3399.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rk3399.cfg
+
+include rockchip.scc
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg b/recip=
es-kernel/linux/files/bsp/rockchip/rockchip.cfg
new file mode 100644
index 0000000..05a397d
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg
@@ -0,0 +1,50 @@
+CONFIG_CPU_ISOLATION=3Dy
+CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=3Dy
+CONFIG_HZ_250=3Dy
+CONFIG_CPU_IDLE=3Dy
+CONFIG_ARM_CPUIDLE=3Dy
+
+CONFIG_ARCH_ROCKCHIP=3Dy
+CONFIG_COMMON_CLK_ROCKCHIP=3Dy
+CONFIG_REGULATOR=3Dy
+CONFIG_REGULATOR_FIXED_VOLTAGE=3Dy
+CONFIG_REGULATOR_PWM=3Dy
+CONFIG_I2C=3Dy
+CONFIG_FW_LOADER=3Dy
+CONFIG_PHY_ROCKCHIP_EMMC=3Dy
+CONFIG_PINCTRL=3Dy
+CONFIG_PINCTRL_ROCKCHIP=3Dy
+CONFIG_ROCKCHIP_IODOMAIN=3Dy
+CONFIG_ROCKCHIP_PM_DOMAINS=3Dy
+
+CONFIG_SPI=3Dy
+CONFIG_SPI_ROCKCHIP=3Dm
+
+CONFIG_PWM=3Dy
+CONFIG_PWM_ROCKCHIP=3Dy
+
+CONFIG_DRM_KMS_HELPER=3Dm
+CONFIG_DRM_FBDEV_EMULATION=3Dy
+CONFIG_ROCKCHIP_IOMMU=3Dy
+CONFIG_DRM_ROCKCHIP=3Dm
+CONFIG_DRM_BRIDGE=3Dy
+
+CONFIG_SND=3Dy
+CONFIG_SND_SOC=3Dy
+CONFIG_SND_HDA_CODEC_HDMI=3Dm
+CONFIG_SND_SOC_ROCKCHIP=3Dm
+CONFIG_SND_SOC_ROCKCHIP_I2S=3Dm
+CONFIG_SND_SOC_ROCKCHIP_SPDIF=3Dm
+
+CONFIG_NVMEM=3Dy
+CONFIG_ROCKCHIP_EFUSE=3Dm
+
+CONFIG_CPU_FREQ=3Dy
+CONFIG_CPU_FREQ_THERMAL=3Dy
+CONFIG_HWMON=3Dy
+CONFIG_THERMAL_HWMON=3Dy
+
+CONFIG_CRYPTO_HW=3Dy
+CONFIG_CRYPTO_DEV_ROCKCHIP=3Dm
+
+CONFIG_MMC_BLOCK_MINORS=3D32
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc b/recip=
es-kernel/linux/files/bsp/rockchip/rockchip.scc
new file mode 100644
index 0000000..800f105
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rockchip.cfg
+
+include cfg/dmaengine.scc
+include features/mmc/mmc-block.cfg
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 7702e3f..9658681 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -1,3 +1,9 @@
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
+
+SRC_URI_append =3D "\
+ file://bsp;type=3Dkmeta;subdir=3Dkernel-meta \
+"
+
COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
COMPATIBLE_MACHINE_radxarock =3D "radxarock"
--=20
2.30.2


[meta-rockchip][PATCH v7 2/6] linux-yocto: add workaround to disable VOPL usage on HDMI

Yann Dirson
 

From: Yann Dirson <yann@...>

There is a known issue in mainline kernel making the machine unusable
once a HDMI screen is plugged. This patch lets VOPB be alone to use
the HDMI port and avoids the issue while providing wupport for the larges=
t
set of video modes, at the expense of double-screen support.
---
.../files/bsp/rockchip/hdmi-no-vopl.patch | 65 +++++++++++++++++++
.../linux/files/bsp/rockchip/rockchip.scc | 2 +
2 files changed, 67 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/hdmi-no-vopl.=
patch

diff --git a/recipes-kernel/linux/files/bsp/rockchip/hdmi-no-vopl.patch b=
/recipes-kernel/linux/files/bsp/rockchip/hdmi-no-vopl.patch
new file mode 100644
index 0000000..72ed753
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/hdmi-no-vopl.patch
@@ -0,0 +1,65 @@
+From 92d9cf4e6c2767c8c5aa8d97e684f2f77d950e7d Mon Sep 17 00:00:00 2001
+From: Jonas Karlman <jonas@...>
+Date: Sun, 19 Jul 2020 16:35:11 +0000
+Subject: [PATCH] HACK: dts: rockchip: do not use vopl for hdmi
+Upstream-Status: Inappropriate [other]
+
+---
+ arch/arm/boot/dts/rk3288.dtsi | 9 ---------
+ arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 ---------
+ 2 files changed, 18 deletions(-)
+
+diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dt=
si
+index 03e86d012edd..746acfac1e92 100644
+--- a/arch/arm/boot/dts/rk3288.dtsi
++++ b/arch/arm/boot/dts/rk3288.dtsi
+@@ -1104,11 +1104,6 @@ vopl_out: port {
+ #address-cells =3D <1>;
+ #size-cells =3D <0>;
+=20
+- vopl_out_hdmi: endpoint@0 {
+- reg =3D <0>;
+- remote-endpoint =3D <&hdmi_in_vopl>;
+- };
+-
+ vopl_out_edp: endpoint@1 {
+ reg =3D <1>;
+ remote-endpoint =3D <&edp_in_vopl>;
+@@ -1249,10 +1244,6 @@ hdmi_in_vopb: endpoint@0 {
+ reg =3D <0>;
+ remote-endpoint =3D <&vopb_out_hdmi>;
+ };
+- hdmi_in_vopl: endpoint@1 {
+- reg =3D <1>;
+- remote-endpoint =3D <&vopl_out_hdmi>;
+- };
+ };
+ };
+ };
+diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/=
dts/rockchip/rk3399.dtsi
+index a855805649ef..418d16b0b648 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+@@ -1640,11 +1640,6 @@ vopl_out_edp: endpoint@1 {
+ remote-endpoint =3D <&edp_in_vopl>;
+ };
+=20
+- vopl_out_hdmi: endpoint@2 {
+- reg =3D <2>;
+- remote-endpoint =3D <&hdmi_in_vopl>;
+- };
+-
+ vopl_out_mipi1: endpoint@3 {
+ reg =3D <3>;
+ remote-endpoint =3D <&mipi1_in_vopl>;
+@@ -1816,10 +1811,6 @@ hdmi_in_vopb: endpoint@0 {
+ reg =3D <0>;
+ remote-endpoint =3D <&vopb_out_hdmi>;
+ };
+- hdmi_in_vopl: endpoint@1 {
+- reg =3D <1>;
+- remote-endpoint =3D <&vopl_out_hdmi>;
+- };
+ };
+ };
+ };
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc b/recip=
es-kernel/linux/files/bsp/rockchip/rockchip.scc
index 800f105..4d61509 100644
--- a/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc
+++ b/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc
@@ -4,3 +4,5 @@ kconf hardware rockchip.cfg
=20
include cfg/dmaengine.scc
include features/mmc/mmc-block.cfg
+
+patch hdmi-no-vopl.patch
--=20
2.30.2


[meta-rockchip][PATCH v7 0/6] kmeta BSP for nanopi-m4

Yann Dirson
 

From: Yann Dirson <yann@...>

With this version the most board features work (Wifi requires recent
poky master for a linux-firmware fix), except for the audio jack and
possibly Bluetooth support (the WIP patches are mostly here for
discussion).

I'm not especially happy with the BT support:
- it uses the rkwifibt repo because I don't have any other BT firmware
for this chip
- I was not able to get it to work on the board I have (even with vendor
image with legacy kernel), so I may have a problem with this particular
piece of hardware. At least it can do discover and pairing, maybe wide=
r
testing will be useful.


Changes in v7:
- use "KMETA_EXTERNAL_BSP" and "nopatch" in the BSP definition to get the
patches properly applied, as discussed in
https://lists.yoctoproject.org/g/yocto/topic/82769152
- remove WIP tag from "add workaround to disable VOPL usage on HDMI" than=
ks
to this

Changes in v6:
- support for Wifi and BT

Changes in v5:
- removed AP6356S-related config options, will come later with proper
wifi/bt support
- removed CONFIG_SND_SOC_RK3288_HDMI_ANALOG which turns out not to be
needed for HDMI audio
- new patch to get HDMI to work

Changes in v4:
- install our bsp files in bsp/rockchip/ rather than directly in bsp/
- also add "serial" to MACHINE_FEATURES

Changes 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=
)

Yann Dirson (6):
linux-yocto: add an initial NanoPi-M4 BSP
linux-yocto: add workaround to disable VOPL usage on HDMI
linux-firmware: import variables file for ap4356s firmware from
armbian
NanoPi-M4: activate Wifi support
WIP Import rkwifibt-firmware from vendor's meta-rockchip
WIP NanoPi-M4: activate BT support

conf/machine/include/nanopi-m4.inc | 9 +-
.../files/brcmfmac4356-sdio.txt | 126 ++++++++++++++++++
.../linux-firmware/linux-firmware_%.bbappend | 13 ++
.../files/bsp/rockchip/hdmi-no-vopl.patch | 65 +++++++++
.../files/bsp/rockchip/nanopi-m4-standard.scc | 8 ++
.../files/bsp/rockchip/nanopi-m4-tiny.scc | 8 ++
.../linux/files/bsp/rockchip/nanopi-m4.cfg | 22 +++
.../linux/files/bsp/rockchip/nanopi-m4.scc | 5 +
.../linux/files/bsp/rockchip/rk3399.cfg | 70 ++++++++++
.../linux/files/bsp/rockchip/rk3399.scc | 5 +
.../linux/files/bsp/rockchip/rockchip.cfg | 50 +++++++
.../linux/files/bsp/rockchip/rockchip.scc | 8 ++
recipes-kernel/linux/linux-yocto%.bbappend | 6 +
.../rkwifibt-firmware/files/LICENSE.rockchip | 41 ++++++
.../rkwifibt-firmware/rkwifibt-firmware.bb | 110 +++++++++++++++
15 files changed, 545 insertions(+), 1 deletion(-)
create mode 100644 recipes-kernel/linux-firmware/files/brcmfmac4356-sdio=
.txt
create mode 100644 recipes-kernel/linux-firmware/linux-firmware_%.bbappe=
nd
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/hdmi-no-vopl.=
patch
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-sta=
ndard.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tin=
y.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rk3399.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rockchip.scc
create mode 100644 recipes-kernel/rkwifibt-firmware/files/LICENSE.rockch=
ip
create mode 100644 recipes-kernel/rkwifibt-firmware/rkwifibt-firmware.bb

--=20
2.30.2


Opencv build generates Pseudo Abort

Morten Bruun
 

Hi,

When building on the new hardknott branch I often get the error below, so far the solution is to delete the tmp directory. Any suggestions?

debug_logfile: fd 2
pid 6668 [parent 6667], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 6667.
creat for ' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/stMOsGHa' replaces existing 11214613 [' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/libopencv_xfeatures2d.so.4.5.2'].
creat for ' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/stUxt79H' replaces existing 11214665 [' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/libopencv_sfm.so.4.5.2'].
creat for ' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/staYWmKL' replaces existing 11214480 [' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-r0/package/usr/lib/libopencv_imgproc.so.4.5.2'].
db cleanup for server shutdown, 00:12:21.579
memory-to-file backup complete, 00:12:21.579.
db cleanup finished, 00:12:21.579
debug_logfile: fd 2
pid 4234 [parent 4192], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 4192.
db cleanup for server shutdown, 00:19:10.704
memory-to-file backup complete, 00:19:10.705.
db cleanup finished, 00:19:10.705
debug_logfile: fd 2
pid 17609 [parent 17585], doing new pid setup and server start
Setup complete, sending SIGUSR1 to pid 17585.
path mismatch [3 links]: ino 12076677 db
' <path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-r0/package/usr/src/debug/opencv/4.5.2-r0/contrib/modules/intensity_transform/include/opencv2/intensity_transform.hpp' req
'<path>/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/opencv/4.5.2-r0/contrib/modules/intensity_transform/include/opencv2/intensity_transform.hpp'.
db cleanup for server shutdown, 10:55:44.549
memory-to-file backup complete, 10:55:44.549.
db cleanup finished, 10:55:44.549

/Morten


Make busybox's syslog.cfg depend on VIRTUAL-RUNTIME_base-utils-syslog #dunfell

Volker Vogelhuber
 

I'm working with Yocto Dunfell. I just wanted to remove syslog
from the busybox package by setting VIRTUAL-RUNTIME_base-utils-syslog
to an empty string. But it seems like the syslog.cfg is added to the SRC_URI
independent of the VIRTUAL-RUNTIME_base-utils-syslog which in turn will
enable syslogd again. Wouldn't it be better to include syslog.cfg in
SRC_URI only if VIRTUAL-RUNTIME_base-utils-syslog is set to busybox-syslog?

So something like

${@["", "file://syslog.cfg"][(d.getVar('VIRTUAL-RUNTIME_base-utils-syslog') == 'busybox-syslog')]}


Re: Understanding kernel patching in linux-yocto

Yann Dirson
 

Le mer. 12 mai 2021 à 20:33, Diego Santa Cruz
<Diego.SantaCruz@...> a écrit :

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Bruce Ashfield via lists.yoctoproject.org
Sent: 12 May 2021 16:25
To: Yann Dirson <yann.dirson@...>
Cc: Yocto discussion list <yocto@...>
Subject: Re: [yocto] Understanding kernel patching in linux-yocto

On Wed, May 12, 2021 at 10:07 AM Yann Dirson
<yann.dirson@...> wrote:

Thanks for those clarifications!

Some additional questions below

Le mer. 12 mai 2021 à 15:19, Bruce Ashfield <bruce.ashfield@...> a
écrit :

On Wed, May 12, 2021 at 7:14 AM Yann Dirson <yann.dirson@blade-
group.com> wrote:

I am currently working on a kmeta BSP for the rockchip-based NanoPI
M4
[1], and I'm wondering how I should be providing kernel patches, as
just add ing "patch" directives in the .scc does not get them applied
unless the particular .scc gets included in KERNEL_FEATURES (see [2]).

From an old thread [3] I understand that the patches from the standard
kmeta snippets are already applied to the tree, and that to get the
patches from my BSP I'd need to reference it explicitly in SRC_URI
(along with using "nopatch" in the right places to avoid the
already-applied patches to get applied twice).

I have the feeling that I'm lacking the rationale behind this, and
would need to understand this better to make things right in this BSP.
Especially:
- at first sight, having the patches both applied to linux-yocto and
referenced in yocto-kernel-cache just to be skipped on parsing looks
like both information duplication and parsing of unused lines
At least some of this is mentioned in the advanced section of the
kernel-dev manual, but I can summarize/reword things here, and
I'm also doing a presentation related to this in the Yocto summit at
the end of this month.

The big thing to remember, is that the configuration and changes
you see in that repository, are not only for yocto purposes. The
concepts and structure pre-date when they were first brought in
to generate reference kernels over 10 years ago (the implementation
has changed, but the concepts are still the same). To this day,
there still are cases that they are used with just a kernel tree and
cross toolchain.

With that in mind, the meta-data is used for many different things

- It organizes patches / features and their configuration into
reusable blocks. At the same time documenting the changes
that we have applied to a tree
- It makes those patches and configuration blocks available to
other kernel trees (for whatever reason).
- It configures the tree during the build process, reusing both
configuration only and patch + configuration blocks
- It is used to generate a history clean tree from scratch for
each new supported kernel. Which is what I do when creating
new linux-yocto-dev references, and the new <version>/standard/*
branches in linux-yocto.
I'd think (and I take your further remarks about workflow as confirming
this), that when upgrading the kernel the best tool would be git-rebase.
Then, regenerating the linux-yocto branches would only be a akin to a
check that the metadata is in sync with the new tree you rebased ?
The best of anything is a matter of opinion. I heavily use git-rebase and
sure, you could use it to do something similar here. But the result is
the same. There's still heavy use of quilt in kernel circles. Workflows
don't change easily, and as long as they work for the maintainer, they
tend to stay put. Asking someone to change their workflow, rarely goes
over well.


If that conclusion is correct, wouldn't it be possible to avoid using the
linux-yocto branches directly, and let all the patches be applied at
do_patch time ? That would be much more similar to the standard
package workflow (and thus lower the barrier for approaching the
kernel packages).
That's something we did in the past, and sure, you can do anything.
But patching hundreds of changes at build time means constant
failures .. again, I've been there and done that. We use similar patches
in many different contexts and optional stackings. You simply cannot
maintain them and stay sane by whacking patches onto the SRC_URI.
The last impression you want when someone builds your kernel is that
they can't even get past the patch phase. So that's a hard no, to how
the reference kernels are maintained (and that hard no has been around
for 11 years now).

Also, we maintain contributed reference BSPs in that same tree, that
are yanking in SDKs from vendors, etc, they are in the thousands of
patches. So you need the tree and the BSP branches to support that.



So why not just drop all the patches in the SRC_URI ? Been there,
done that. It fails spectacularly when you are managing queues of
hundreds of potentially conflicting patches (rt, yaffs, aufs, ... etc, etc)
and then attempting to constantly merge -stable and other kernel
trees into the repository. git is the tool for managing that, not stacks
of patches. You spend your entire life fixing patch errors and refreshing
fuzz (again, been there, done that).

So why not just keep a history and constantly merge new versions
into it ? Been there, done that. You end up with an absolute garbage
history of octopus merges and changes that are completely hidden,
non-obvious and useless for collaborating with other kernel projects.
Try merging a new kernel version into those same big features, it's
nearly impossible and you have a franken-kernel that you end up trying
to support and fix yourself. All the bugs are yours and yours alone.

So that's why there's a repository that tracks the patches and the
configuration and is used for multiple purposes. Keeping the patches
and config blocks separate would just lead to even more errors as
I update one and forget the other, etc, etc. There have been various
incarnations of the tools that also did different things with the patches,
and they weren't skipped, but detected as applied or not on-the-fly,
so there are other historical reasons for the structure as well.

- kernel-yocto.bbclass does its own generic job of locating a proper
BSP using the KMACHINE/KTYPE/KARCH tags in BSP, it looks like
specifying a specific BSP file would just defeat of this: how should I
deal with this case where I'm providing both "standard" and "tiny"
KTYPE's ?
I'm not quite following the question here, so I can try to answer badly
and you can clarify based on my terrible answer.
The answer is indeed quite useful for a question that may not be that clear
:)

The tools can locate your "bsp entry point" / "bsp definition" in
your layer. Either provided by something on the SRC_URI or something
in a kmeta repository (also specified on the SRC_URI). Since
both of those are added to the search paths they check. Those
are just .scc files with a specified KMACHINE/KTYPE that match, and
as you could guess from my first term I used, they are the entry
point into building the configuration queue.

That's where you start inheriting the base configuration(s) and including
feature blocks, etc. Those definitions are exactly the same as the
internal ones in the kernel-cache repository. By default, that located
BSP definition is excluded from inheriting patches .. because as you
noted, it would start trying to re-apply changes to the tree. It is there
to get the configuration blocks, patches come in via other feature
blocks or directly on the SRC_URI.

So in your case, just provide the two .scc file with the proper
defines so they can be located, and you'll get the proper branch
located in the tree, and the base configurations picked up for those
kernel types. You'd supply your BSP specific config by making
a common file and including it in both definitions, and patches by
a KERNEL_FEATURE variable or by specifying them directly on
the SRC_URI (via .patch or via a different .scc file).
That's what I was experimenting with at the same time, and something like
this does indeed produce the expected output:

KERNEL_FEATURES_append = " bsp/rockchip/nanopi-m4-
${LINUX_KERNEL_TYPE}.scc"

However, it seems confusing, as that .scc is precisely the one that's
already selected
and used for the .cfg: it really looks like we're overriding the
default "bsp entry point"
with a value that's already the default, but with a different result.
Yes, that's one way that we've structured things as the tools evolved
to balance external BSP definitions being able to pull in the base
configuration but not patches. There are two runs of the tools, one looks
for patches (and excludes that bsp entry point) and one that builds the
config.queue (and uses the entry point). That's the balance of the multi
use nature of the configuration blocks. I could bury something deeper
in the tools to hide a bit of that, but it will break uses cases and time
has shown that it is brittle.


So my gut feeling ATM is that everything should be much more clear if
specifying the default entry point would have the same effect as leaving
the default be used, ie. having patches be applied in both cases.
The variable KMETA_EXTERNAL_BSPS was created as a knob to
allow an external definition to both be used for patches AND configuration.
But that is for fully exernal BSPs that do not include the base kernel
meta-data, since once you turn that on, you are getting all the patches
and all the configuration .. and will have the patches applied twice.
For what its worth I am using KMETA_EXTERNAL_BSPS in a BSP definition file in an in-recipe kernel metadata tree (but I guess it could be off recipe too), and that metadata tree includes scc files from yocto-kernel-cache, the trick is to add the nopatch tag when including scc files from yocto-kernel-cache for which do not want or need the patches.

With KMETA_EXTERNAL_BSPS was added I switched to that and removed the equivalent of your
KERNEL_FEATURES_append = " bsp/rockchip/nanopi-m4-${LINUX_KERNEL_TYPE}.scc"
that is kind of confusing and includes things twice.
That does look nicer that way, much closer to what I intended, thanks!

Best regards,
--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech


[meta-zephyr][PATCH] zephyr-kernel-src: switch from master branch to main

Naveen Saini
 

* branch was renamed in upstream repo

It fixes do_fetch failure

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 8d5f176..dfc2250 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -13,7 +13,7 @@ inherit cmake
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI = "\
- git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=master;name=default \
+ git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=main;name=default \
git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;destsuffix=git/modules/hal/nordic;name=nordic \
git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
--
2.17.1


BitBake recipe cache - tasks remain available after removing inheritance #yocto #bitbake

Jindra Sindelar
 

Hello all,

I'm starting with the Yocto project (Zeus) and I made some experiments with the kernel recipe. For one of my assignments, I needed a do_kernel_configme task, but it wasn't provided by our kernel recipe (i.e. not listed in the available tasks). I searched the available layers and found that this task is defined in poky/meta/classes/kernel-yocto.bbclass. Out of fun, I tried to inherit from that class in our kernel recipe and after parsing the recipe again, the do_kernel_configme task was available.
 
Later I decided to revert all my changes and removed the inheritance of kernel-yocto.bbclass. What surprises me is that the do_kernel_configme task remains available in the kernel recipe and I can still successfully run that task. I also tried to remove the content of build/tmp/cache, which, if I understand correctly, is the cache for parsing recipes. After running BitBake again, I could see the recipe was parsed from scratch. But even after that, the do_kernel_configme task still remains available for the kernel recipe.
 
Could anyone explain this behavior? What am I missing here?
Thank you in advance


[meta-security][PATCH 4/4] lkrg-module: update 0.9.1

Armin Kuster
 

LIC_FILES_CHKSUM updated do to yr change and adding new copyrights

Signed-off-by: Armin Kuster <akuster808@...>
---
.../lkrg/{lkrg-module_0.9.0.bb => lkrg-module_0.9.1.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename recipes-kernel/lkrg/{lkrg-module_0.9.0.bb => lkrg-module_0.9.1.bb} (84%)

diff --git a/recipes-kernel/lkrg/lkrg-module_0.9.0.bb b/recipes-kernel/lkrg/lkrg-module_0.9.1.bb
similarity index 84%
rename from recipes-kernel/lkrg/lkrg-module_0.9.0.bb
rename to recipes-kernel/lkrg/lkrg-module_0.9.1.bb
index dbc195d..287b4e8 100644
--- a/recipes-kernel/lkrg/lkrg-module_0.9.0.bb
+++ b/recipes-kernel/lkrg/lkrg-module_0.9.1.bb
@@ -5,14 +5,14 @@ SECTION = "security"
HOMEPAGE = "https://www.openwall.com/lkrg/"
LICENSE = "GPLv2"

-LIC_FILES_CHKSUM = "file://LICENSE;md5=d931f44a1f4be309bcdac742d7ed92f9"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=5105ead24b08a32954f34cbaa7112432"

DEPENDS = "virtual/kernel elfutils"

SRC_URI = "https://www.openwall.com/lkrg/lkrg-${PV}.tar.gz \
file://makefile_cleanup.patch "

-SRC_URI[sha256sum] = "a997e4d98962c359f3af163bbcfa38a736d2a50bfe35c15065b74cb57f8742bf"
+SRC_URI[sha256sum] = "cabbee1addbf3ae23a584203831e4bd1b730d22bfd1b3e44883214f220b3babd"

S = "${WORKDIR}/lkrg-${PV}"

--
2.25.1


[meta-security][PATCH 3/4] python3-scapy: update to 2.4.5

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
.../scapy/{python3-scapy_2.4.4.bb => python3-scapy_2.4.5.bb} | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
rename recipes-security/scapy/{python3-scapy_2.4.4.bb => python3-scapy_2.4.5.bb} (95%)

diff --git a/recipes-security/scapy/python3-scapy_2.4.4.bb b/recipes-security/scapy/python3-scapy_2.4.5.bb
similarity index 95%
rename from recipes-security/scapy/python3-scapy_2.4.4.bb
rename to recipes-security/scapy/python3-scapy_2.4.5.bb
index 23ddfce..8f36520 100644
--- a/recipes-security/scapy/python3-scapy_2.4.4.bb
+++ b/recipes-security/scapy/python3-scapy_2.4.5.bb
@@ -5,9 +5,7 @@ LICENSE = "GPLv2"

LIC_FILES_CHKSUM = "file://LICENSE;md5=b234ee4d69f5fce4486a80fdaf4a4263"

-S = "${WORKDIR}/git"
-
-SRCREV = "95ba5b8504152a1f820bbe679ccf03668cb5118f"
+SRCREV = "32cd7eb0f620d9adf171c48d55514e8326a538d7"
SRC_URI = "git://github.com/secdev/scapy.git \
file://run-ptest"

--
2.25.1


[meta-security][PATCH 2/4] opendnssec: upgrade 2.1.8 -> 2.1.9

Armin Kuster
 

From: Upgrade Helper <akuster808@...>

Signed-off-by: Armin Kuster <akuster808@...>
---
.../opendnssec/{opendnssec_2.1.8.bb => opendnssec_2.1.9.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-security/opendnssec/{opendnssec_2.1.8.bb => opendnssec_2.1.9.bb} (92%)

diff --git a/recipes-security/opendnssec/opendnssec_2.1.8.bb b/recipes-security/opendnssec/opendnssec_2.1.9.bb
similarity index 92%
rename from recipes-security/opendnssec/opendnssec_2.1.8.bb
rename to recipes-security/opendnssec/opendnssec_2.1.9.bb
index cf6bdbd..2b79609 100644
--- a/recipes-security/opendnssec/opendnssec_2.1.8.bb
+++ b/recipes-security/opendnssec/opendnssec_2.1.9.bb
@@ -10,7 +10,7 @@ SRC_URI = "https://dist.opendnssec.org/source/opendnssec-${PV}.tar.gz \
file://libdns_conf_fix.patch \
"

-SRC_URI[sha256sum] = "900a213103ff19a405e446327fbfcea9ec13e405283d87b6ffc24a10d9a268f5"
+SRC_URI[sha256sum] = "6d1d466c8d7f507f3e665f4bfe4d16a68d6bff9d7c2ab65f852e2b2a821c28b5"

inherit autotools pkgconfig perlnative

--
2.25.1


[meta-security][PATCH 1/4] clamav: upgrade to latest revision

Armin Kuster
 

From: Upgrade Helper <akuster808@...>

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-scanners/clamav/clamav_0.104.0.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-scanners/clamav/clamav_0.104.0.bb b/recipes-scanners/clamav/clamav_0.104.0.bb
index ce5b0ea..4f20309 100644
--- a/recipes-scanners/clamav/clamav_0.104.0.bb
+++ b/recipes-scanners/clamav/clamav_0.104.0.bb
@@ -8,8 +8,8 @@ DEPENDS = "glibc llvm libtool db openssl zlib curl libxml2 bison pcre2 json-c li

LIC_FILES_CHKSUM = "file://COPYING.txt;beginline=2;endline=3;md5=f7029fbbc5898b273d5902896f7bbe17"

-# May 2nd
-SRCREV = "de0086aa918b79cd22570d0c05977a288b197e23"
+# May 15th
+SRCREV = "fe96de86bb90c489aa509ee9135f776b7a2a7eb4"

SRC_URI = "git://github.com/vrtadmin/clamav-devel;branch=dev/0.104 \
file://clamd.conf \
--
2.25.1


Re: meta-selinux issues. Depending on what I put in my local.conf, I get boot loops or can't log in.

Brian Hutchinson <b.hutchman@...>
 



On Sun, May 16, 2021, 9:07 AM Richard Purdie <richard.purdie@...> wrote:
On Sat, 2021-05-15 at 22:15 -0400, Brian Hutchinson wrote:
>
>
> On Fri, May 14, 2021 at 12:35 AM Yi Zhao <yi.zhao@...> wrote:
> >
> > On 5/14/21 9:40 AM, Brian Hutchinson wrote:
> >  
> > > Hi,
> > >
> > > Pretty new to selinux.  I've worked through a lot of issues to get this far but am stumped at the moment
> > > so any pointers, clues are appreciated.
> > >
> > > I'm trying to add selinux to my custom image.  After running into problems, I decided it was best to
> > > start with building core-image-selinux for my NXP imx8mm-evk board as a reference for getting my custom
> > > image to work.
> > >
> > > I'm using fscl-community-bsp meta-freescale Dunfell release which is building a 5.4.114 kernel.
> > >
> > > My first issues were getting kernel config options right (.config attached).  I kept booting my rootfs
> > > and sestatus would result in selinux not being enabled.
> > >
> > > After getting kernel config somewhat worked out, then I started getting either boot loops or locked out.
> > >
> > > I'll stay focused on my core-image-selinux image as hopefully if I can get it working it will help me
> > > get my custom image working too.
> > >
> > > Here is my last iteration of my local.conf that results in me not being able to log in.  With core-
> > > image-selinux image, it freezes before it gets to login prompt.  On my custom image, I get log in prompt
> > > but when I try to log in a root I get audit messages and dropped back to login prompt.
> > >
> > > local.conf for core-image-selinux:
> > >
> > > MACHINE ??= 'imx8mmevk'
> > >  DISTRO ?= 'poky'
> > >  PACKAGE_CLASSES ?= 'package_rpm'
> > >  EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
> > >  DISTRO_FEATURES_remove = " sysvinit"
> > >  DISTRO_FEATURES_append += " acl xattr pam selinux systemd"
> > >  VIRTUAL-RUNTIME_init_manager = "systemd"
> > >  DISTRO_FEATURES_BACKFILL_CONSIDERED = ""
> > >  PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls"
> >
> > You can try refpolicy-mcs or refpolicy-targeted. The mls policy doesn't work for systemed on dunfell.
> >  
> > //Yi
> >
>
>  Thank you very much for that!  I made that change to my core-image-selinux build and it worked!  When it
> booted I saw a systemd process take a while to finish, I assume that was the relable process.  And when I
> logged in as root, there is a significant delay before being logged in, not sure what is going on there.
>
> When I made the same change to my imx8mm-evk core-image-base image with selinux added, I saw the same
> systemd process run but it didn't take quite as long and it made the system reboot.  Once it rebooted I did
> get a login prompt but it won't let me login as root.  So something is still miss-configured and still at a
> loss as to what to look at next.

I know nothing about this but I was surprised you were using busybox login 
utilities with selinux. I'm not sure if that is well tested or not...

Cheers,

Richard

Hey Richard,  good to hear from you again (last was ELC-E).

I really didn't change anything except add selinux layer and (attempt) to follow instructions on meta-selinux README.

I guess we're the blind leading the blind.  This is my first attempt to incorporate selinux into custom image so be gentle ;).

Regards,

Brian



Re: meta-selinux issues. Depending on what I put in my local.conf, I get boot loops or can't log in.

Richard Purdie
 

On Sat, 2021-05-15 at 22:15 -0400, Brian Hutchinson wrote:


On Fri, May 14, 2021 at 12:35 AM Yi Zhao <yi.zhao@...> wrote:

On 5/14/21 9:40 AM, Brian Hutchinson wrote:
 
Hi,

Pretty new to selinux.  I've worked through a lot of issues to get this far but am stumped at the moment
so any pointers, clues are appreciated.

I'm trying to add selinux to my custom image.  After running into problems, I decided it was best to
start with building core-image-selinux for my NXP imx8mm-evk board as a reference for getting my custom
image to work.

I'm using fscl-community-bsp meta-freescale Dunfell release which is building a 5.4.114 kernel.

My first issues were getting kernel config options right (.config attached).  I kept booting my rootfs
and sestatus would result in selinux not being enabled.

After getting kernel config somewhat worked out, then I started getting either boot loops or locked out.

I'll stay focused on my core-image-selinux image as hopefully if I can get it working it will help me
get my custom image working too.

Here is my last iteration of my local.conf that results in me not being able to log in.  With core-
image-selinux image, it freezes before it gets to login prompt.  On my custom image, I get log in prompt
but when I try to log in a root I get audit messages and dropped back to login prompt.

local.conf for core-image-selinux:

MACHINE ??= 'imx8mmevk'
 DISTRO ?= 'poky'
 PACKAGE_CLASSES ?= 'package_rpm'
 EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
 DISTRO_FEATURES_remove = " sysvinit"
 DISTRO_FEATURES_append += " acl xattr pam selinux systemd"
 VIRTUAL-RUNTIME_init_manager = "systemd"
 DISTRO_FEATURES_BACKFILL_CONSIDERED = ""
 PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls"
You can try refpolicy-mcs or refpolicy-targeted. The mls policy doesn't work for systemed on dunfell.
 
//Yi
 Thank you very much for that!  I made that change to my core-image-selinux build and it worked!  When it
booted I saw a systemd process take a while to finish, I assume that was the relable process.  And when I
logged in as root, there is a significant delay before being logged in, not sure what is going on there.

When I made the same change to my imx8mm-evk core-image-base image with selinux added, I saw the same
systemd process run but it didn't take quite as long and it made the system reboot.  Once it rebooted I did
get a login prompt but it won't let me login as root.  So something is still miss-configured and still at a
loss as to what to look at next.
I know nothing about this but I was surprised you were using busybox login 
utilities with selinux. I'm not sure if that is well tested or not...

Cheers,

Richard

5161 - 5180 of 58669