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

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

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

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

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')]}

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

* 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

Hello all,

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

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

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

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

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

The autobuilders have 128GB memory, we don't want them using 50% which is
the default, 5% should be enough. Also limit the number of threads down
from 48 to something reasonable. This may be partly causing some of our
performance issues?

Signed-off-by: Richard Purdie <richard.purdie@...>
---
config.json | 2 ++
1 file changed, 2 insertions(+)

diff --git a/config.json b/config.json
index 6533dab..cf62815 100644
--- a/config.json
+++ b/config.json
@@ -45,6 +45,8 @@
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
"PARALLEL_MAKE = '-j 16'",
+ "XZ_MEMLIMIT = '5%'",
+ "XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",
"BB_TASK_NICE_LEVEL_task-testimage = '0'",
"BB_TASK_IONICE_LEVEL = '2.7'",
--
2.30.2

Just saw that the issue is that you can't use rootfs-dir with a subfolder as the pseudo folder is missing in the parent folder, ended up using overlayfs

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index 0bddf64..d7349b0 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -51,9 +51,9 @@ RDEPENDS_packagegroup-security-scanners = "\
isic \
nikto \
checksecurity \
- ${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 riscv64", "", " clamav clamav-freshclam",d)} \
+ ${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 riscv64", "", " clamav clamav-daemon clamav-freshclam",d)} \
"
-RDEPENDS_packagegroup-security-scanners_remove_libc-musl = "clamav clamav-freshclam"
+RDEPENDS_packagegroup-security-scanners_remove_libc-musl = "clamav clamav-daemon clamav-freshclam"

SUMMARY_packagegroup-security-audit = "Security Audit tools "
RDEPENDS_packagegroup-security-audit = " \
--
2.25.1

cleanup recipe

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-scanners/clamav/clamav_0.104.0.bb | 44 ++++++++++---------
.../clamav/files/fix_systemd_socket.patch | 25 +++++++++++
2 files changed, 48 insertions(+), 21 deletions(-)
create mode 100644 recipes-scanners/clamav/files/fix_systemd_socket.patch

diff --git a/recipes-scanners/clamav/clamav_0.104.0.bb b/recipes-scanners/clamav/clamav_0.104.0.bb
index 6892bb0..ce5b0ea 100644
--- a/recipes-scanners/clamav/clamav_0.104.0.bb
+++ b/recipes-scanners/clamav/clamav_0.104.0.bb
@@ -16,9 +16,9 @@ SRC_URI = "git://github.com/vrtadmin/clamav-devel;branch=dev/0.104 \
file://freshclam.conf \
file://volatiles.03_clamav \
file://tmpfiles.clamav \
- file://${BPN}.service \
file://headers_fixup.patch \
file://oe_cmake_fixup.patch \
+ file://fix_systemd_socket.patch \
"
S = "${WORKDIR}/git"

@@ -70,31 +70,29 @@ do_install_append () {
rm ${D}/${libdir}/libmspack.so

if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};then
- install -D -m 0644 ${WORKDIR}/clamav.service ${D}${systemd_unitdir}/system/clamav.service
install -d ${D}${sysconfdir}/tmpfiles.d
install -m 0644 ${WORKDIR}/tmpfiles.clamav ${D}${sysconfdir}/tmpfiles.d/clamav.conf
fi
oe_multilib_header clamav-types.h
}

-pkg_postinst_ontarget_${PN} () {
- if command -v systemd-tmpfiles >/dev/null; then
- systemd-tmpfiles --create ${sysconfdir}/tmpfiles.d/clamav.conf
- elif [ -e ${sysconfdir}/init.d/populate-volatile.sh ]; then
- ${sysconfdir}/init.d/populate-volatile.sh update
+pkg_postinst_${PN} () {
+ if [ -z "$D" ]; then
+ if command -v systemd-tmpfiles >/dev/null; then
+ systemd-tmpfiles --create ${sysconfdir}/tmpfiles.d/clamav.conf
+ elif [ -e ${sysconfdir}/init.d/populate-volatile.sh ]; then
+ ${sysconfdir}/init.d/populate-volatile.sh update
+ fi
+ chown -R ${CLAMAV_UID}:${CLAMAV_GID} ${localstatedir}/lib/clamav
fi
- mkdir -p ${localstatedir}/lib/clamav
- chown -R ${CLAMAV_UID}:${CLAMAV_GID} ${localstatedir}/lib/clamav
}

-
-PACKAGES = "${PN} ${PN}-dev ${PN}-dbg ${PN}-daemon ${PN}-doc \
- ${PN}-clamdscan ${PN}-freshclam ${PN}-libclamav ${PN}-staticdev"
+PACKAGES += "${PN}-daemon ${PN}-clamdscan ${PN}-freshclam ${PN}-libclamav"

FILES_${PN} = "${bindir}/clambc ${bindir}/clamscan ${bindir}/clamsubmit ${sbindir}/clamonacc \
${bindir}/*sigtool ${mandir}/man1/clambc* ${mandir}/man1/clamscan* \
${mandir}/man1/sigtool* ${mandir}/man1/clambsubmit* \
- ${docdir}/clamav/* ${libdir}/libmspack* "
+ ${docdir}/clamav/*"

FILES_${PN}-clamdscan = " ${bindir}/clamdscan \
${docdir}/clamdscan/* \
@@ -106,11 +104,11 @@ FILES_${PN}-daemon = "${bindir}/clamconf ${bindir}/clamdtop ${sbindir}/clamd \
${mandir}/man5/clamd* ${mandir}/man8/clamd* \
${sysconfdir}/clamd.conf* \
/usr/etc/clamd.conf* \
- ${systemd_unitdir}/system/clamav-daemon/* \
+ ${systemd_system_unitdir}/clamav-daemon/* \
${docdir}/clamav-daemon/* ${sysconfdir}/clamav-daemon \
${sysconfdir}/logcheck/ignore.d.server/clamav-daemon \
- ${systemd_unitdir}/system/clamav-daemon.service \
- ${systemd_unitdir}/system/clamav-clamonacc.service \
+ ${systemd_system_unitdir}/clamav-daemon.service \
+ ${systemd_system_unitdir}/clamav-clamonacc.service \
"

FILES_${PN}-freshclam = "${bindir}/freshclam \
@@ -121,7 +119,7 @@ FILES_${PN}-freshclam = "${bindir}/freshclam \
${localstatedir}/lib/clamav \
${docdir}/${PN}-freshclam ${mandir}/man1/freshclam.* \
${mandir}/man5/freshclam.conf.* \
- ${systemd_unitdir}/system/clamav-freshclam.service"
+ ${systemd_system_unitdir}/clamav-freshclam.service"

FILES_${PN}-dev = " ${bindir}/clamav-config ${libdir}/*.la \
${libdir}/pkgconfig/*.pc \
@@ -131,7 +129,8 @@ FILES_${PN}-dev = " ${bindir}/clamav-config ${libdir}/*.la \
FILES_${PN}-staticdev = "${libdir}/*.a"

FILES_${PN}-libclamav = "${libdir}/libclamav.so* ${libdir}/libclammspack.so* \
- ${libdir}/libfreshclam.so* ${docdir}/libclamav/* "
+ ${libdir}/libfreshclam.so* ${docdir}/libclamav/* \
+ ${libdir}/libmspack* "

FILES_${PN}-doc = "${mandir}/man/* \
${datadir}/man/* \
@@ -140,12 +139,15 @@ FILES_${PN}-doc = "${mandir}/man/* \
USERADD_PACKAGES = "${PN}"
GROUPADD_PARAM_${PN} = "--system ${CLAMAV_UID}"
USERADD_PARAM_${PN} = "--system -g ${CLAMAV_GID} --home-dir \
- ${localstatedir}/spool/${BPN} \
- --no-create-home --shell /bin/false ${BPN}"
+ ${localstatedir}/lib/${BPN} \
+ --no-create-home --shell /sbin/nologin ${BPN}"

RPROVIDES_${PN} += "${PN}-systemd"
RREPLACES_${PN} += "${PN}-systemd"
RCONFLICTS_${PN} += "${PN}-systemd"
-SYSTEMD_SERVICE_${PN} = "${BPN}.service"
+SYSTEMD_PACKAGES = "${PN}-daemon ${PN}-freshclam"
+SYSTEMD_SERVICE_${PN}-daemon = "clamav-daemon.service"
+SYSTEMD_SERVICE_${PN}-freshclam = "clamav-freshclam.service"

RDEPENDS_${PN} = "openssl ncurses-libncurses libxml2 libbz2 ncurses-libtinfo curl libpcre2 clamav-freshclam clamav-libclamav"
+RDEPENDS_${PN}-daemon = "clamav"
diff --git a/recipes-scanners/clamav/files/fix_systemd_socket.patch b/recipes-scanners/clamav/files/fix_systemd_socket.patch
new file mode 100644
index 0000000..3e9abe2
--- /dev/null
+++ b/recipes-scanners/clamav/files/fix_systemd_socket.patch
@@ -0,0 +1,25 @@
+clamd not installing clamav-daemon.socket
+
+Fixes:
+__main__.SystemdUnitNotFoundError: (PosixPath('../security-build-image/1.0-r0/rootfs'), 'clamav-daemon.socket')
+%post(clamav-daemon-0.104.0-r0.core2_64): waitpid(3587571) rc 3587571 status 100
+warning: %post(clamav-daemon-0.104.0-r0.core2_64) scriptlet failed, exit status 1
+
+Upstream-Status: Pending
+Signed-off-by: Armin Kuster <akuster808@...>
+
+Index: git/clamd/CMakeLists.txt
+===================================================================
+--- git.orig/clamd/CMakeLists.txt
++++ git/clamd/CMakeLists.txt
+@@ -54,4 +54,10 @@ if(SYSTEMD_FOUND)
+ install(
+ FILES ${CMAKE_CURRENT_BINARY_DIR}/clamav-daemon.service
+ DESTINATION ${SYSTEMD_UNIT_DIR})
++ configure_file(
++ ${CMAKE_CURRENT_SOURCE_DIR}/clamav-daemon.socket.in
++ ${CMAKE_CURRENT_BINARY_DIR}/clamav-daemon.socket @ONLY)
++ install(
++ FILES ${CMAKE_CURRENT_BINARY_DIR}/clamav-daemon.socket
++ DESTINATION ${SYSTEMD_UNIT_DIR})
+ endif()
--
2.25.1