On 5/17/21 10:44 AM, Jasper Orschulko wrote:

Hi,
my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html
I am trying to find a way to list statically linked libraries in the
license manifest, but so far I am at a loss. To my understanding Yocto
does not understand packages included using DEPENDS and not RDEPENDS as
part of the resulting image, however technically source code from the
dependee can (and will) end up on the image as part of the dependent
package. This is a serious issue from a legal point of view, as the
developer ultimately might end up with an incomplete list of licenses,
when relying on the Yocto license manifest.
Please, do correct me if I'm wrong :)

partly yes. there is a provision to disable static linking using DISABLE_STATIC, so atleast some of packages can be cleared of. depends are effective during build time and its the linking which decides on static vs dynamic linking and bitbake does not have much control over that but you can perhaps easily write a probe and extract this information from linker cmdline perhaps by dumping linker map and post processing it.

On 5/17/21 3:13 AM, Volker Vogelhuber wrote:

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

yes. Please send this change as a proper patch for inclusion to openembedded-core mailing list.

Hi All,
I'm trying to bitbake a recipe for python3-dlib (the python API).
Here is the recipe:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries in the
license manifest, but so far I am at a loss. To my understanding Yocto
does not understand packages included using DEPENDS and not RDEPENDS as
part of the resulting image, however technically source code from the
dependee can (and will) end up on the image as part of the dependent
package. This is a serious issue from a legal point of view, as the
developer ultimately might end up with an incomplete list of licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@...

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/



-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCiq3AACgkQYgqew07V
MNWgRQf/Z3Hs3YOf5CT6TynZp9rNPEpYAP2d4lgJ9upep3WvTfQsm0gXTqLvYWDO
PZ1awuWdNAp054BdvhJnApYnM0UOOAmVg9lMO3PTBKGQvDdDBRX0LToHViky2npu
m/n2fIWpoMjuRQdo4QbErCm6foVc9aXaxGT/6nVhGb1fjkX8acjlyvRo/cpQDrWL
pYb2Nkqz4V1bB+lzWi9gr/Io7SM/EGzlu3EFS/PEidff+bPFiQr4cmI+NXXOhr8k
mYS4K6KENaT+wD9reVqJABnbtxJxCZu4JHlCg+CqlfYheblCAZhe1SDtYJBgisEq
1allapNlrNJAqH5UN1jT7ZKAwrt0ww==
=/wvF
-----END PGP SIGNATURE-----

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@...

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

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

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

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

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