I got a fetcher failure on go-systemd today, which puzzled me. That
recipe has not changed in ages, and the SRCPV hash is clearly visible
in the repository.

After looking at it closer, it seems that github.com/coreos/go-systemd
has changed its default branch from master to main about six days ago.
This appears to break a fundamental assumption on the part of the
fetcher when looking for SRCREV and SRCPV hashes.

Looking at lib/bb/fetch2/git.py makes it evident that this is the
case. I can trivially fix this with a .bbappend, but it seems to me
that the fundamental default branch assumption needs to be updated.

Has anyone discussed adding main to the list of default branches to
try? If not, I may be able to come up with a patch, but the code does
process default branches as a list, so I will need to think a bit on
the best way to approach this. Any guidance would be appreciated.

..Ch:W..


--
"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire

Facing following issue :
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['hostapd'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: Logfile of failure stored in: /home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/imx6ull14x14evk-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.31340
ERROR: Task (/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/sources/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1'

Please guide me if anyone have any idea to resolve.

Thanks in advance.

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
- 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 ?

[1] https://lists.yoctoproject.org/g/yocto/message/53454
[2] https://lists.yoctoproject.org/g/yocto/message/53452
[3] https://lists.yoctoproject.org/g/yocto/topic/61340326

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

Hello All,

This is the full report for yocto-3.2.4.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

One new issue found:

Bug 14392 - [QA 3.2.4 RC1] failure in ptest : ptestresult.lttng-tools.tools


======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14392

Thanks,
Sangeeta

On Sat, May 8, 2021 at 6:25 PM Robert Joslyn
<robert.joslyn@...> wrote:

There is the oe-stylize.py script that attempts to format recipes
according to the style guide:
https://git.openembedded.org/meta-openembedded/tree/contrib/oe-stylize.py

Last time I played with it, I was a bit disappointed with some of the
changes it makes, some of which are different than what devtool does.
When I need to introduce new developers to bitbake, I'd love to be able
to hand them oe-stylize or something similar and just tell them to run
it before committing to make sure everything is formatted consistently.

I've had updating oe-stylize.py on my TODO list for a while, but more
important things always come up.

Given what I have seen so far, I am wondering if that is the right
place to start.

To summarize:

There appears to be general agreement that the idea is a good one, but a large
patch wall is considered rather objectionable by at least Bruce Ashfield.

Khem Raj brought up a good point that a big change like the one I am proposing
needs some sort of tooling to make sure we do not regress.

And the above reply from Robert Joslyn has me wondering if there is already
something in place to do the linting Khem Raj is referring to, or if
oe-stylize.py
would form the basis for such a tool if we added it to an automated system.

So taking a step back, does it make sense to update the guidance on the
styleguide (https://www.openembedded.org/wiki/Styleguide) page first?

If so, I would be happy to make the updates. I requested an account,
but I got an
error - "Error sending mail: Unknown error in PHP's mail() function."

..Ch:W..

--
"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "minnowboard"

By default it set to MinnowBoard Max 'minnowboard'

Currently 32-bit supported boards:
* up_squared_32
* minnowboard

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/machine/include/tune-core2-common.inc | 6 ++++++
conf/machine/intel-x86-32.conf | 12 ++++++++++++
2 files changed, 18 insertions(+)
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf

diff --git a/conf/machine/include/tune-core2-common.inc b/conf/machine/include/tune-core2-common.inc
new file mode 100644
index 0000000..012f078
--- /dev/null
+++ b/conf/machine/include/tune-core2-common.inc
@@ -0,0 +1,6 @@
+DEFAULTTUNE ?= "core2-32"
+require conf/machine/include/tune-core2.inc
+require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDES
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-32.conf b/conf/machine/intel-x86-32.conf
new file mode 100644
index 0000000..06f6da5
--- /dev/null
+++ b/conf/machine/intel-x86-32.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: intel-x86-32
+#@DESCRIPTION: common MACHINE for 32-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'minnowboard' board.
+
+require conf/machine/include/tune-core2-common.inc
+
+ARCH_intel-x86-32 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "minnowboard"
+# ZEPHYR_BOARD ?= "up_squared_32"
+ZEPHYR_BOARD ?= "minnowboard"
--
2.17.1

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "ehl_crb"

By default it set to Elkhart Lake CRB 'ehl_crb'

Currently 64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/machine/include/tune-corei7-common.inc | 3 +++
conf/machine/intel-x86-64.conf | 12 ++++++++++++
2 files changed, 15 insertions(+)
create mode 100644 conf/machine/intel-x86-64.conf

diff --git a/conf/machine/include/tune-corei7-common.inc b/conf/machine/include/tune-corei7-common.inc
index 7ad9516..509d190 100644
--- a/conf/machine/include/tune-corei7-common.inc
+++ b/conf/machine/include/tune-corei7-common.inc
@@ -1,3 +1,6 @@
DEFAULTTUNE ?= "corei7-64"
require conf/machine/include/tune-corei7.inc
require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDE
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-64.conf b/conf/machine/intel-x86-64.conf
new file mode 100644
index 0000000..15e3ad8
--- /dev/null
+++ b/conf/machine/intel-x86-64.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: intel-x86-64
+#@DESCRIPTION: common MACHINE for 64-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'ech_crb' board.
+
+require conf/machine/include/tune-corei7-common.inc
+
+ARCH_intel-x86-64 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "up_squared"
+# ZEPHYR_BOARD ?= "ehl_crb_sbl"
+ZEPHYR_BOARD ?= "ehl_crb"
--
2.17.1

(1) zephyr-kernel-src: fix efi generation failure for x86 boards

With zephyr v2.5.0, EFI binary generation support has been added for x86 board (64-bit mode).
To achieve this, an python tool[1] has been added to convert zephyr EFL file
into an EFI appliable. But unfortunately at current this does not work with Yocto cross-compilation env.
This patch fix this issue and allow to build zephyr.efi for ehl_crb and up_squared boards.


(2)
Instead of creating machine configuration for each
supported boards, I would like to have common machine configurations for
supported boards. One for 64-bit (intel-x86-64.conf) and one for 32-bit
(intel-x86-32.conf).

User need to specify board value to ZEPHYR_BOARD in local.conf based on
targeted board i.e
ZEPHYR_BOARD = "ehl_crb"

64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb (default)

32-bit supported boards:
* up_squared_32
* minnowboard (default)



Naveen Saini (3):
zephyr-kernel-src: fix efi generation failure for x86 boards
intel-x86-64.conf: add common MACHINE for x86 (64-bit) BOARDS
intel-x86-32.conf: add common MACHINE for x86 (32-bit) BOARDS

conf/machine/include/tune-core2-common.inc | 6 ++
conf/machine/include/tune-corei7-common.inc | 3 +
conf/machine/intel-x86-32.conf | 12 +++
conf/machine/intel-x86-64.conf | 12 +++
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src.inc | 1 +
6 files changed, 114 insertions(+)
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf
create mode 100644 conf/machine/intel-x86-64.conf
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

--
2.17.1

With zephyr v2.5.0, EFI binary support has been added for x86 board (64-bit mode).

To achieve this, an python tool[1] has been added to convert zephyr ELF file
into an EFI appliable. But currently this does not work with Yocto
cross-compilation env.
This patch fix this issue and allow to build zephyr.efi

Ref:
[1]https://github.com/zephyrproject-rtos/zephyr/commit/928d31125f0b4eb28fe1cf3f3ad02b0ae071d7fd

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src.inc | 1 +
2 files changed, 81 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

diff --git a/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
new file mode 100644
index 0000000..fd6fc6b
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
@@ -0,0 +1,80 @@
+From cfde3b1018c3151b6cc1fbe3e9e163d0aaf16954 Mon Sep 17 00:00:00 2001
+From: Naveen Saini <naveen.kumar.saini@...>
+Date: Tue, 11 May 2021 13:46:39 +0800
+Subject: [PATCH] x86: fix efi binary generation issue in cross compilation env
+
+Set root directory for headers.
+
+Upstream-Status: Inappropriate [Cross-compilation specific]
+
+Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
+---
+ arch/x86/zefi/zefi.py | 6 +++++-
+ boards/x86/ehl_crb/CMakeLists.txt | 1 +
+ boards/x86/qemu_x86/CMakeLists.txt | 1 +
+ boards/x86/up_squared/CMakeLists.txt | 1 +
+ 4 files changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/zefi/zefi.py b/arch/x86/zefi/zefi.py
+index d3514391a8..b9eccbfa10 100755
+--- a/arch/x86/zefi/zefi.py
++++ b/arch/x86/zefi/zefi.py
+@@ -106,7 +106,10 @@ def build_elf(elf_file):
+ # + We need pic to enforce that the linker adds no relocations
+ # + UEFI can take interrupts on our stack, so no red zone
+ # + UEFI API assumes 16-bit wchar_t
+- cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.",
++
++ # Pass --sysroot path for cross compilation
++ sysrootarg = "--sysroot=" + args.sysroot
++ cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.", sysrootarg,
+ "-fno-stack-protector", "-fpic", "-mno-red-zone", "-fshort-wchar",
+ "-Wl,-nostdlib", "-T", ldscript, "-o", "zefi.elf", cfile]
+ verbose(" ".join(cmd))
+@@ -145,6 +148,7 @@ def parse_args():
+ parser.add_argument("-o", "--objcopy", required=True, help="objcopy to be used")
+ parser.add_argument("-f", "--elf-file", required=True, help="Input file")
+ parser.add_argument("-v", "--verbose", action="store_true", help="Verbose output")
++ parser.add_argument("-s", "--sysroot", required=True, help="Cross compilation --sysroot=path")
+
+ return parser.parse_args()
+
+diff --git a/boards/x86/ehl_crb/CMakeLists.txt b/boards/x86/ehl_crb/CMakeLists.txt
+index 0d572eff30..6a228107dc 100644
+--- a/boards/x86/ehl_crb/CMakeLists.txt
++++ b/boards/x86/ehl_crb/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/qemu_x86/CMakeLists.txt b/boards/x86/qemu_x86/CMakeLists.txt
+index 1131a5c7ce..489f17192b 100644
+--- a/boards/x86/qemu_x86/CMakeLists.txt
++++ b/boards/x86/qemu_x86/CMakeLists.txt
+@@ -4,6 +4,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/up_squared/CMakeLists.txt b/boards/x86/up_squared/CMakeLists.txt
+index 0eaa9753fc..2e8ce7cfbc 100644
+--- a/boards/x86/up_squared/CMakeLists.txt
++++ b/boards/x86/up_squared/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+--
+2.17.1
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 8c987bb..8d5f176 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -21,5 +21,6 @@ SRC_URI = "\
git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=libmetal \
git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=https;destsuffix=git/modules/crypto/tinycrypt;name=tinycrypt \
file://0001-cmake-add-yocto-toolchain.patch \
+ file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
"
S = "${WORKDIR}/git"
--
2.17.1

Thanks for the suggestion, but they are using the C++ API as well. I already created a recipe for the C++ API of dlib and it is working, the only thing needed is compitling the Python API.

On Tue, May 11, 2021 at 1:00 PM Bel Hadj Salem Talel <bhstalel@...> wrote:

Hi All,

Did anyone manage to create a recipe for python dlib from the official site https://github.com/davisking/dlib ?
They provide C++ and Python API, (CMakeLists + setup.py). All recipes found for dlib are inheriting cmake for C++.
But when inheriting setuptools3 error occurs.

did you look into http://layers.openembedded.org/layerindex/recipe/135534/

Thanks,
Talel

Hi All,

Did anyone manage to create a recipe for python dlib from the official site https://github.com/davisking/dlib ?
They provide C++ and Python API, (CMakeLists + setup.py). All recipes found for dlib are inheriting cmake for C++. 
But when inheriting setuptools3 error occurs.

Thanks,
Talel

Signed-off-by: Khem Raj <raj.khem@...>
Cc: Ross Burton <ross.burton@...>
---
.../files/0001-Fix-build-with-gcc-11.patch | 34 ++++++++++++++++++
.../0001-dram-Fix-build-with-gcc-11.patch | 34 ++++++++++++++++++
...-Use-compatible-.asciz-asm-directive.patch | 31 ++++++++++++++++
...rk-already-defined-functions-as-weak.patch | 35 +++++++++++++++++++
.../trusted-firmware-a_%.bbappend | 4 +++
5 files changed, 138 insertions(+)
create mode 100644 recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch
create mode 100644 recipes-bsp/trusted-firmware-a/files/0001-dram-Fix-build-with-gcc-11.patch
create mode 100644 recipes-bsp/trusted-firmware-a/files/0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch
create mode 100644 recipes-bsp/trusted-firmware-a/files/0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch b/recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch
new file mode 100644
index 0000000..7956717
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch
@@ -0,0 +1,34 @@
+From d4c60a312271e000e8339f0b47a302c325313758 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Tue, 11 May 2021 11:46:30 -0700
+Subject: [PATCH] Fix build with gcc 11
+
+Fixes
+plat/rockchip/rk3399/drivers/dram/dram.c:13:22: error: ignoring attribute 'section (".pmusram.data")' because it conflicts with previous 'section (".sram.data")' [-Werror=attributes]
+
+See [1]
+
+[1] https://developer.trustedfirmware.org/T925
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ plat/rockchip/rk3399/drivers/dram/dram.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/drivers/dram/dram.h b/plat/rockchip/rk3399/drivers/dram/dram.h
+index 0eb12cf29..5572b1612 100644
+--- a/plat/rockchip/rk3399/drivers/dram/dram.h
++++ b/plat/rockchip/rk3399/drivers/dram/dram.h
+@@ -149,7 +149,7 @@ struct rk3399_sdram_params {
+ uint32_t rx_cal_dqs[2][4];
+ };
+
+-extern __sramdata struct rk3399_sdram_params sdram_config;
++extern struct rk3399_sdram_params sdram_config;
+
+ void dram_init(void);
+
+--
+2.31.1
+
diff --git a/recipes-bsp/trusted-firmware-a/files/0001-dram-Fix-build-with-gcc-11.patch b/recipes-bsp/trusted-firmware-a/files/0001-dram-Fix-build-with-gcc-11.patch
new file mode 100644
index 0000000..14defed
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/0001-dram-Fix-build-with-gcc-11.patch
@@ -0,0 +1,34 @@
+From a09a1de53aba422249a8376b0d95024200021317 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Tue, 11 May 2021 11:55:31 -0700
+Subject: [PATCH] dram: Fix build with gcc 11
+
+This is a redundant assignment which GCC warns about.
+
+Fixes
+
+plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c:781:11: error: explicitly assigning value of variable of type 'uint32_t' (aka 'unsigned int') to itself [-Werror,-Wself-assign]
+ twr_tmp = twr_tmp;
+ ~~~~~~~ ^ ~~~~~~~
+
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c b/plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c
+index 3cdb7a296..76bc5ee96 100644
+--- a/plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c
++++ b/plat/rockchip/rk3399/drivers/dram/dram_spec_timing.c
+@@ -778,7 +778,7 @@ static void lpddr3_get_parameter(struct timing_related_config *timing_config,
+ else if (twr_tmp <= 8)
+ twr_tmp = 8;
+ else if (twr_tmp <= 12)
+- twr_tmp = twr_tmp;
++ ; /* do nothing */
+ else if (twr_tmp <= 14)
+ twr_tmp = 14;
+ else
+--
+2.31.1
+
diff --git a/recipes-bsp/trusted-firmware-a/files/0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch b/recipes-bsp/trusted-firmware-a/files/0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch
new file mode 100644
index 0000000..8807fca
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch
@@ -0,0 +1,31 @@
+From 5f78ce7eb9ab6bf5af682a715a9264d2a5ee7666 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Tue, 11 May 2021 12:06:34 -0700
+Subject: [PATCH] plat_macros.S: Use compatible .asciz asm directive
+
+clang asm does not like two strings to .asciz therefore make it single
+string which works on clang too.
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ plat/rockchip/common/include/plat_macros.S | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/plat/rockchip/common/include/plat_macros.S b/plat/rockchip/common/include/plat_macros.S
+index 691beeb44..c07be9ca9 100644
+--- a/plat/rockchip/common/include/plat_macros.S
++++ b/plat/rockchip/common/include/plat_macros.S
+@@ -23,8 +23,7 @@ icc_regs:
+
+ /* Registers common to both GICv2 and GICv3 */
+ gicd_pend_reg:
+- .asciz "gicd_ispendr regs (Offsets 0x200 - 0x278)\n" \
+- " Offset:\t\t\tvalue\n"
++ .asciz "gicd_ispendr regs (Offsets 0x200 - 0x278)\n Offset:\t\t\tvalue\n"
+ newline:
+ .asciz "\n"
+ spacer:
+--
+2.31.1
+
diff --git a/recipes-bsp/trusted-firmware-a/files/0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch b/recipes-bsp/trusted-firmware-a/files/0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch
new file mode 100644
index 0000000..bd4d2b5
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch
@@ -0,0 +1,35 @@
+From 9d963cd69faf94bdcb80624132fd10392f57875b Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Tue, 11 May 2021 12:11:51 -0700
+Subject: [PATCH] pmu: Do not mark already defined functions as weak
+
+These functions are already defined as static functions in same header
+Fixes
+
+| plat/rockchip/common/drivers/pmu/pmu_com.h:35:14: error: weak identifier 'pmu_power_domain_ctr' never declared [-Werror] | #pragma weak pmu_power_domain_ctr | ^
+| plat/rockchip/common/drivers/pmu/pmu_com.h:36:14: error: weak identifier 'check_cpu_wfie' never declared [-Werror]
+| #pragma weak check_cpu_wfie
+| ^
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ plat/rockchip/common/drivers/pmu/pmu_com.h | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/plat/rockchip/common/drivers/pmu/pmu_com.h b/plat/rockchip/common/drivers/pmu/pmu_com.h
+index 5359f73b4..3f9ce7df9 100644
+--- a/plat/rockchip/common/drivers/pmu/pmu_com.h
++++ b/plat/rockchip/common/drivers/pmu/pmu_com.h
+@@ -32,8 +32,6 @@ enum pmu_pd_state {
+ };
+
+ #pragma weak plat_ic_get_pending_interrupt_id
+-#pragma weak pmu_power_domain_ctr
+-#pragma weak check_cpu_wfie
+
+ static inline uint32_t pmu_power_domain_st(uint32_t pd)
+ {
+--
+2.31.1
+
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 1942c17..c90673e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -8,4 +8,8 @@ COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "\
file://serial-console-baudrate.patch \
+ file://0001-Fix-build-with-gcc-11.patch \
+ file://0001-dram-Fix-build-with-gcc-11.patch \
+ file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
+ file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
"
--
2.31.1

On 11.05.21 18:14, Bel Hadj Salem Talel wrote:

Hi All,
I integrated python3-numpy in my image and when trying to import it I get this error: (python3 version: 3.7.7)
------
>>> import cv2
OpenCV bindings requires "numpy" package.
Install it via command:
    pip install numpy
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/numpy/core/__init__.py", line 17, in <module>
    from . import multiarray
  File "/usr/lib/python3.7/site-packages/numpy/core/multiarray.py", line 14, in <module>
    from . import overrides
  File "/usr/lib/python3.7/site-packages/numpy/core/overrides.py", line 7, in <module>
    from numpy.core._multiarray_umath import (
ModuleNotFoundError: No module named 'numpy.core._multiarray_umath'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/site-packages/cv2/__init__.py", line 8, in <module>
    import numpy
  File "/usr/lib/python3.7/site-packages/numpy/__init__.py", line 142, in <module>
root@menzu-media:~# python3
Python 3.7.7 (default, Apr 22 2021, 09:42:29)
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cv2
OpenCV bindings requires "numpy" package.
Install it via command:
    pip install numpy
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/numpy/core/__init__.py", line 17, in <module>
    from . import multiarray
  File "/usr/lib/python3.7/site-packages/numpy/core/multiarray.py", line 14, in <module>
    from . import overrides
  File "/usr/lib/python3.7/site-packages/numpy/core/overrides.py", line 7, in <module>
    from numpy.core._multiarray_umath import (
ModuleNotFoundError: No module named 'numpy.core._multiarray_umath'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/site-packages/cv2/__init__.py", line 8, in <module>
    import numpy
  File "/usr/lib/python3.7/site-packages/numpy/__init__.py", line 142, in <module>
    from . import core
  File "/usr/lib/python3.7/site-packages/numpy/core/__init__.py", line 47, in <module>
    raise ImportError(msg)
ImportError:
IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!
Importing the numpy c-extensions failed.
- Try uninstalling and reinstalling numpy.
- If you have already done that, then:
  1. Check that you expected to use Python3.7 from "/usr/bin/python3",
     and that you have no directories in your PATH or PYTHONPATH that can
     interfere with the Python and numpy version "1.17.0" you're trying to use.
  2. If (1) looks fine, you can open a new issue at
     https://github.com/numpy/numpy/issues.  Please include details on:
     - how you installed Python
     - how you installed numpy
     - your operating system
     - whether or not you have multiple versions of Python installed
     - if you built from source, your compiler versions and ideally a build log
- If you're working with a numpy git repository, try `git clean -xdf`
  (removes all files not under version control) and rebuild numpy.
Note: this error has many possible causes, so please don't comment on
an existing issue about this - open a new one instead.
Original error was: No module named 'numpy.core._multiarray_umath'
----------
Did any one encounter this issue?

According to [1] yes - you might want to consider back porting one of the more recent versions of numpy from [2], as you are using a pretty outdated one

[1] https://stackoverflow.com/questions/54665842/when-importing-tensorflow-i-get-the-following-error-no-module-named-numpy-cor
[2] http://layers.openembedded.org/layerindex/recipe/51338/

Also the github issue tracker of numpy contains at least one issue of the same sort

Thanks,
Talel

Hi All,
I integrated python3-numpy in my image and when trying to import it I get this error: (python3 version: 3.7.7)

------

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