From: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>

This set of patches relates to what I discussed at https://lists.yoctoproject.org/g/yocto/message/55285.

Four major issues (and one minor issue)are dealt with in this series. The first is a logical split of the
meta-zephyr layer into a machine BSP layer and a functional core layer.

The second is the removal for the need of MACHINEOVERRIDES as a method of telling zephyr it's'-DZEPHYR_MODULES. Zephyr
already knows this, so by abusing west list a bit, we can pull that information out and generate the needed config
line to be passed into cmake. Out of tree ZEPHYR_MODULES should be added via ZEPHYR_EXTRA_MODULES.

The third major issue is as we're now relying on west to know what modules Zephyr needs, we need to checkout the
complete Zephyr source.

The last major issue is that Zephyr knows it's own machine config and I would like us to support as many of the Zephyr
machines as possible. As I've yet to find a way to do this at build time, with a little abuse of cmake exports we can
generate machine configurations based on what is in Zephyr itself. These have obviously not all been tested

I've not added the machines it generates as there are still some issues around automatic machine generation that I wish
to solve before adding those machines, however 288 machines will build helloworld without issue. More work needs to be
done here. A few machines will most likely never work at all without some significant work.

Lastly there was a minor issue with the 2.6.1 kernel in that the dtc patch Ross created for 2.7.0 (moved to 2.7.1) wasn't
applied which causes 2.6.1 to fail with the same error


Eilís Ní Fhlannagáin (8):
meta-zephyr-core/bsp: Restructure into sublayers
west: Add west and python dependencies
zephyr.bbclass: Remove need for MACHINEOVERRIDES for ZEPHYR_MODULES
zephyr-kernel-src: Add complete zephyr source
zephyr-kernel-src-2.6.1: Add dtc patch.
recipes-meta: Abuse CMake to create OE machine definitions
zephyr-kernel: Modify recipes to work with new -DZEPHYR_MODULES
README.txt: Document generate-zephyr-machine use

README.txt | 18 +-
{conf => meta-zephyr-bsp/conf}/layer.conf | 12 +-
.../conf}/machine/96b-avenger96.conf | 0
.../conf}/machine/96b-nitrogen.conf | 0
.../conf}/machine/arduino-nano-33-ble.conf | 0
.../conf}/machine/include/nrf52.inc | 2 -
.../machine/include/stm32mp1-cortex-m4.inc | 3 -
.../conf}/machine/include/tune-arc.inc | 0
.../machine/include/tune-corei7-common.inc | 0
.../conf}/machine/include/tune-cortexm0.inc | 0
.../conf}/machine/include/tune-cortexm3.inc | 0
.../conf}/machine/include/tune-cortexm4.inc | 0
.../conf}/machine/include/tune-iamcu.inc | 0
.../conf}/machine/include/tune-nios2.inc | 0
.../conf}/machine/intel-x86-64.conf | 0
.../conf}/machine/nrf52840dk-nrf52840.conf | 0
.../conf}/machine/qemu-cortex-m3.conf | 0
.../conf}/machine/qemu-nios2.conf | 0
.../conf}/machine/qemu-x86.conf | 0
.../conf}/machine/stm32mp157c-dk2.conf | 0
...xport-an-OpenEmbedded-machine-config.patch | 184 ++++++++++++++++++
.../meta/generate-zephyr-machines.bb | 45 +++++
COPYING.MIT => meta-zephyr-core/COPYING.MIT | 0
meta-zephyr-core/README.txt | 119 +++++++++++
.../classes}/siteinfo-zephyr.bbclass | 0
.../classes}/zephyr-flash-bossac.bbclass | 0
.../classes}/zephyr-flash-dfu.bbclass | 0
.../classes}/zephyr-flash-pyocd.bbclass | 0
.../classes}/zephyr-qemuboot.bbclass | 0
.../classes}/zephyr.bbclass | 42 ++++
.../classes}/zephyrtest.bbclass | 0
.../conf}/distro/zephyr.conf | 0
meta-zephyr-core/conf/layer.conf | 22 +++
.../lib}/oeqa/controllers/__init__.py | 0
.../oeqa/controllers/zephyrtargetcontrol.py | 0
.../lib}/oeqa/runtime/__init__.py | 0
.../lib}/oeqa/runtime/cases/zephyr.py | 0
.../lib}/oeqa/utils/qemuzephyrrunner.py | 0
.../recipes-core}/newlib/newlib_%.bbappend | 0
.../binutils/binutils-2.26arc.inc | 0
.../binutils-cross-canadian_2.26arc.bb | 0
.../binutils/binutils-cross_2.26arc.bb | 0
...e54244cd02bdcf4f1057be3ce96631f35ac3.patch | 0
.../recipes-devtools-arc}/gcc/gcc-6.x.arc.inc | 0
.../gcc/gcc-cross-canadian_6.x.arc.bb | 0
.../gcc/gcc-cross_6.x.arc .bb | 0
.../gcc/gcc-source_6.x.arc.bb | 0
.../gcc/libgcc_6.x.arc.bb | 0
.../gcc/gcc-cross_6.%.bbappend | 0
.../recipes-devtools}/gcc/libgcc_6.%.bbappend | 0
.../python/python3-anytree_2.8.0.bb | 14 ++
.../python/python3-breathe_4.31.0.bb | 17 ++
.../python/python3-canopen_1.2.1.bb | 17 ++
.../python/python3-cbor_1.0.0.bb | 19 ++
.../python/python3-gitlint_0.15.1.bb | 14 ++
.../python/python3-imgtool_1.7.2.bb | 14 ++
.../python/python3-junithtml_30.0.4.bb | 14 ++
.../python/python3-junitparser_2.1.1.bb | 14 ++
.../python/python3-lpc-checksum_2.2.0.bb | 14 ++
.../python/python3-packaging_21.0.bb | 14 ++
.../python/python3-pyelftools_0.27.bb | 14 ++
.../python/python3-pygithub_1.55.bb | 14 ++
.../python/python3-pygments_2.10.0.bb | 15 ++
.../recipes-devtools/python/python3-pylink | 11 ++
.../python/python3-pyocd_0.32.0.bb | 14 ++
.../python/python3-pyparsing_2.4.7.bb | 14 ++
.../python/python3-sphinx_4.2.0.bb | 14 ++
.../qemu/files/nios2-add-support.patch | 0
.../recipes-devtools}/qemu/qemu_%.bbappend | 0
.../recipes-devtools/west/west_0.12.99.bb | 22 +++
.../0001-cmake-add-yocto-toolchain.patch | 0
...0001-cmake-added-missing-file-ext-to.patch | 0
...ry-generation-issue-in-cross-compila.patch | 0
...rduino-nano-33-ble-storage-partition.patch | 0
.../zephyr-kernel/files/dtc.patch | 0
.../zephyr-kernel/zephyr-blinky.bb | 0
.../zephyr-kernel/zephyr-coap-client.bb | 2 -
.../zephyr-kernel/zephyr-coap-server.bb | 2 -
.../zephyr-kernel/zephyr-echo-client.bb | 2 -
.../zephyr-kernel/zephyr-hci-uart.bb | 0
.../zephyr-kernel/zephyr-helloworld.bb | 0
.../zephyr-kernel/zephyr-http-client.bb | 1 -
.../zephyr-kernel/zephyr-image.inc | 0
.../zephyr-kernel/zephyr-kernel-common.inc | 13 +-
.../zephyr-kernel/zephyr-kernel-src-2.6.1.inc | 54 +++++
.../zephyr-kernel/zephyr-kernel-src-2.7.1.inc | 69 +++++++
.../zephyr-kernel/zephyr-kernel-src-dev.inc | 0
.../zephyr-kernel/zephyr-kernel-src.bb | 0
.../zephyr-kernel/zephyr-kernel-src.inc | 58 ++++++
.../zephyr-kernel/zephyr-kernel-test-all.bb | 0
.../zephyr-kernel/zephyr-kernel-test.bb | 0
.../zephyr-kernel/zephyr-kernel-test.inc | 0
.../zephyr-kernel/zephyr-lvgl.bb | 8 +
.../zephyr-kernel/zephyr-mqtt-publisher.bb | 2 -
.../zephyr-kernel/zephyr-openamp-rsc-table.bb | 0
.../zephyr-openthread-echo-client.bb | 3 -
.../zephyr-kernel/zephyr-peripheral-esp.bb | 2 -
.../zephyr-kernel/zephyr-peripheral-hr.bb | 2 -
.../zephyr-kernel/zephyr-philosophers.bb | 0
.../zephyr-kernel/zephyr-sample.inc | 0
.../zephyr-kernel/zephyr-websocket-client.bb | 2 -
.../zephyr-kernel/zephyr-kernel-src-2.6.1.inc | 20 --
.../zephyr-kernel/zephyr-kernel-src-2.7.1.inc | 20 --
.../zephyr-kernel/zephyr-kernel-src.inc | 27 ---
recipes-kernel/zephyr-kernel/zephyr-lvgl.bb | 18 --
105 files changed, 898 insertions(+), 123 deletions(-)
rename {conf => meta-zephyr-bsp/conf}/layer.conf (62%)
rename {conf => meta-zephyr-bsp/conf}/machine/96b-avenger96.conf (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/96b-nitrogen.conf (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/arduino-nano-33-ble.conf (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/include/nrf52.inc (89%)
rename {conf => meta-zephyr-bsp/conf}/machine/include/stm32mp1-cortex-m4.inc (67%)
rename {conf => meta-zephyr-bsp/conf}/machine/include/tune-arc.inc (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/include/tune-corei7-common.inc (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/include/tune-cortexm0.inc (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/include/tune-cortexm3.inc (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/include/tune-cortexm4.inc (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/include/tune-iamcu.inc (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/include/tune-nios2.inc (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/intel-x86-64.conf (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/nrf52840dk-nrf52840.conf (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/qemu-cortex-m3.conf (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/qemu-nios2.conf (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/qemu-x86.conf (100%)
rename {conf => meta-zephyr-bsp/conf}/machine/stm32mp157c-dk2.conf (100%)
create mode 100644 meta-zephyr-bsp/recipes-meta/meta/files/0001-zephyr-Export-an-OpenEmbedded-machine-config.patch
create mode 100644 meta-zephyr-bsp/recipes-meta/meta/generate-zephyr-machines.bb
rename COPYING.MIT => meta-zephyr-core/COPYING.MIT (100%)
create mode 100644 meta-zephyr-core/README.txt
rename {classes => meta-zephyr-core/classes}/siteinfo-zephyr.bbclass (100%)
rename {classes => meta-zephyr-core/classes}/zephyr-flash-bossac.bbclass (100%)
rename {classes => meta-zephyr-core/classes}/zephyr-flash-dfu.bbclass (100%)
rename {classes => meta-zephyr-core/classes}/zephyr-flash-pyocd.bbclass (100%)
rename {classes => meta-zephyr-core/classes}/zephyr-qemuboot.bbclass (100%)
rename {classes => meta-zephyr-core/classes}/zephyr.bbclass (54%)
rename {classes => meta-zephyr-core/classes}/zephyrtest.bbclass (100%)
rename {conf => meta-zephyr-core/conf}/distro/zephyr.conf (100%)
create mode 100644 meta-zephyr-core/conf/layer.conf
rename {lib => meta-zephyr-core/lib}/oeqa/controllers/__init__.py (100%)
rename {lib => meta-zephyr-core/lib}/oeqa/controllers/zephyrtargetcontrol.py (100%)
rename {lib => meta-zephyr-core/lib}/oeqa/runtime/__init__.py (100%)
rename {lib => meta-zephyr-core/lib}/oeqa/runtime/cases/zephyr.py (100%)
rename {lib => meta-zephyr-core/lib}/oeqa/utils/qemuzephyrrunner.py (100%)
rename {recipes-core => meta-zephyr-core/recipes-core}/newlib/newlib_%.bbappend (100%)
rename {recipes-devtools-arc => meta-zephyr-core/recipes-devtools-arc}/binutils/binutils-2.26arc.inc (100%)
rename {recipes-devtools-arc => meta-zephyr-core/recipes-devtools-arc}/binutils/binutils-cross-canadian_2.26arc.bb (100%)
rename {recipes-devtools-arc => meta-zephyr-core/recipes-devtools-arc}/binutils/binutils-cross_2.26arc.bb (100%)
rename {recipes-devtools-arc => meta-zephyr-core/recipes-devtools-arc}/gcc/files/cbd8e54244cd02bdcf4f1057be3ce96631f35ac3.patch (100%)
rename {recipes-devtools-arc => meta-zephyr-core/recipes-devtools-arc}/gcc/gcc-6.x.arc.inc (100%)
rename {recipes-devtools-arc => meta-zephyr-core/recipes-devtools-arc}/gcc/gcc-cross-canadian_6.x.arc.bb (100%)
rename {recipes-devtools-arc => meta-zephyr-core/recipes-devtools-arc}/gcc/gcc-cross_6.x.arc .bb (100%)
rename {recipes-devtools-arc => meta-zephyr-core/recipes-devtools-arc}/gcc/gcc-source_6.x.arc.bb (100%)
rename {recipes-devtools-arc => meta-zephyr-core/recipes-devtools-arc}/gcc/libgcc_6.x.arc.bb (100%)
rename {recipes-devtools => meta-zephyr-core/recipes-devtools}/gcc/gcc-cross_6.%.bbappend (100%)
rename {recipes-devtools => meta-zephyr-core/recipes-devtools}/gcc/libgcc_6.%.bbappend (100%)
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-anytree_2.8.0.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-breathe_4.31.0.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-canopen_1.2.1.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-cbor_1.0.0.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-gitlint_0.15.1.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-imgtool_1.7.2.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-junithtml_30.0.4.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-junitparser_2.1.1.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-lpc-checksum_2.2.0.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-packaging_21.0.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-pyelftools_0.27.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-pygithub_1.55.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-pygments_2.10.0.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-pylink
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-pyocd_0.32.0.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-pyparsing_2.4.7.bb
create mode 100644 meta-zephyr-core/recipes-devtools/python/python3-sphinx_4.2.0.bb
rename {recipes-devtools => meta-zephyr-core/recipes-devtools}/qemu/files/nios2-add-support.patch (100%)
rename {recipes-devtools => meta-zephyr-core/recipes-devtools}/qemu/qemu_%.bbappend (100%)
create mode 100644 meta-zephyr-core/recipes-devtools/west/west_0.12.99.bb
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/files/0001-cmake-add-yocto-toolchain.patch (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/files/arduino-nano-33-ble-storage-partition.patch (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/files/dtc.patch (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-blinky.bb (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-coap-client.bb (60%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-coap-server.bb (60%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-echo-client.bb (60%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-hci-uart.bb (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-helloworld.bb (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-http-client.bb (61%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-image.inc (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-kernel-common.inc (76%)
create mode 100644 meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
create mode 100644 meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.1.inc
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-kernel-src-dev.inc (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-kernel-src.bb (100%)
create mode 100644 meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-kernel-test-all.bb (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-kernel-test.bb (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-kernel-test.inc (100%)
create mode 100644 meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-lvgl.bb
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-mqtt-publisher.bb (59%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-openamp-rsc-table.bb (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-openthread-echo-client.bb (77%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-peripheral-esp.bb (58%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-peripheral-hr.bb (58%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-philosophers.bb (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-sample.inc (100%)
rename {recipes-kernel => meta-zephyr-core/recipes-kernel}/zephyr-kernel/zephyr-websocket-client.bb (61%)
delete mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
delete mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.1.inc
delete mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
delete mode 100644 recipes-kernel/zephyr-kernel/zephyr-lvgl.bb

--
2.25.1

Peter, Ross

On 1/19/22 1:56 PM, Peter Bergin wrote:

Hi,

On 2022-01-19 13:16, Michael Opdenacker wrote:

Greetings,

I reused a simple "hello" recipe and added a non-matching checksum to
it:

...
SRC_URI = "file://helloworld.c"
SRC_URI[md5sum] = "34f0efd76b4f18888888888833cdd129"
...

The rest of the recipe comes from
https://git.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/hello-single.


Why doesn't Bitbake stop, reporting that the checksum doesn't match the
source file?
Anyway, why does the recipe build without a checksum? Shouldn't
checksums be mandatory?

No they are not mandatory for all fetchers. They are only used for
content downloaded from non-local archives.
https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#the-download-fetch


https://github.com/openembedded/bitbake/blob/32180d5057c818a69987aada482e82acf3c72ef2/lib/bb/fetch2/__init__.py#L1268


^^ here you can see the selection of URI's that automatically needs a
checksum.

Thanks for your replies. This all makes perfect sense then.
Thanks again
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hi,

On 2022-01-19 13:16, Michael Opdenacker wrote:

Greetings,

I reused a simple "hello" recipe and added a non-matching checksum to it:

...
SRC_URI = "file://helloworld.c"
SRC_URI[md5sum] = "34f0efd76b4f18888888888833cdd129"
...

The rest of the recipe comes from
https://git.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/hello-single.

Why doesn't Bitbake stop, reporting that the checksum doesn't match the
source file?
Anyway, why does the recipe build without a checksum? Shouldn't
checksums be mandatory?

No they are not mandatory for all fetchers. They are only used for content downloaded from non-local archives. https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#the-download-fetch


https://github.com/openembedded/bitbake/blob/32180d5057c818a69987aada482e82acf3c72ef2/lib/bb/fetch2/__init__.py#L1268

^^ here you can see the selection of URI's that automatically needs a checksum.

Best regards,
/Peter

On Wed, 19 Jan 2022 at 12:16, Michael Opdenacker
<michael.opdenacker@...> wrote:

Greetings,

I reused a simple "hello" recipe and added a non-matching checksum to it:

...
SRC_URI = "file://helloworld.c"
SRC_URI[md5sum] = "34f0efd76b4f18888888888833cdd129"
...

The rest of the recipe comes from
https://git.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/hello-single.

Why doesn't Bitbake stop, reporting that the checksum doesn't match the
source file?
Anyway, why does the recipe build without a checksum? Shouldn't
checksums be mandatory?

Checksums are for files that are fetched via http:// and friends, not
local files.

Ross

Greetings,

I reused a simple "hello" recipe and added a non-matching checksum to it:

...
SRC_URI = "file://helloworld.c"
SRC_URI[md5sum] = "34f0efd76b4f18888888888833cdd129"
...

The rest of the recipe comes from
https://git.openembedded.org/openembedded-core/tree/meta-skeleton/recipes-skeleton/hello-single.

Why doesn't Bitbake stop, reporting that the checksum doesn't match the
source file?
Anyway, why does the recipe build without a checksum? Shouldn't
checksums be mandatory?

I'm using the "master" version of Poky.

Thanks in advance
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hi Tomasz,

Thanks for your response.

Are you using custom Linux kernel / custom device tree? Maybe there is
some issue there?

Yes, but the Zeus build image uses the same device tree that could run
WiFi connection without any issues, I am comparing the same source and
configuration between Zeus and Honister, the only difference is the
two different OE Yocto versions.

Thank you.

Kind regards,

- jh

Hi JH,

Are you using custom Linux kernel / custom device tree? Maybe there is
some issue there?

 

Kind regards,
Tomasz Żyjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59
https://3mdeb.com | @3mdeb_com

 

Signed-off-by: Anuj Mittal <anuj.mittal@...>
---
config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.py b/config.py
index 4c0b83b..0f99557 100644
--- a/config.py
+++ b/config.py
@@ -149,7 +149,7 @@ all_workers = workers + workers_bringup + workers_buildperf + workers_arm

# Worker filtering for older releases
workers_prev_releases = {
- "hardknott" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora31", "fedora32", "fedora33", "fedora34", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu2004", "perf-"),
+ "hardknott" : ("centos7", "centos8", "debian8", "debian9", "debian10", "debian11", "fedora31", "fedora32", "fedora33", "fedora34", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu2004", "perf-"),
"gatesgarth" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora30", "fedora31", "fedora32", "opensuse150", "opensuse151", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
"dunfell" : ("centos7", "centos8", "debian8", "debian9", "debian10", "debian11", "fedora29", "fedora30", "fedora31", "fedora32", "fedora33", "fedora34", "opensuse150", "opensuse151", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
"zeus" : ("centos7", "debian8", "debian9", "debian10", "fedora28", "fedora29", "fedora30", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "perf-"),
--
2.34.1

Hi Rudolf,

Thanks for your response and comments.

If you run ifconfig -a does your WiFi interface show up? If not there is an
issue with the driver. Use dmesg and filter for the driver. Often a driver
cannot load the firmware. What is your WiFi hardware?

Not that bad, the WiFi interfaces was fine, but it could not get dhcp
response and IP address so an automatic private IP address 169.254 was
assigned

mlan0 Link encap:Ethernet HWaddr D4:CA:6E:A4:E8:B4
inet addr:169.254.193.101 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:330 (330.0 B) TX bytes:16392 (16.0 KiB)

I could see WiFi information well, it is not a major problem, but the
subtle issues are connman and wpa_supplicant did not set up the WiFi
driver correctly.

Connected to 34:08:04:12:b1:a2 (on mlan0)
SSID: JupiterIoT
freq: 2437
RX: 660 bytes (4 packets)
TX: 46622 bytes (129 packets)
signal: -57 dBm
rx bitrate: 1.0 MBit/s
tx bitrate: 72.2 MBit/s MCS 7 short GI

bss flags: short-slot-time
dtim period: 1
beacon int: 100

Did you install the regulatory database?

Did you mean to enable CONFIG_CFG80211_INTERNAL_REGDB? No, I did not
install it in the Zeus version either so I don't see that could be an
issue.

What error messages are you seeing when attempting to connect to a WiFi
network? Did you look at the connman logs?

No error in connman, I don't think it is connman or wpa_supplicant
issue, my suspicion is something missing in Honister built image to
prevent connman and wpa_supplicant to set up the WiFi driver
correctly.

It is not the first time I have the WiFi setup trouble to get WiFi
169.254 address, when I upgraded from Thud to Zeus, I got the exactly
the same problem that WiFi was assigned by a 169.254 address, no dhcp
response, at time, I was totally convinced it was connman issue, I
spend several months to debug connman and wpa_supplicant without any
results, then after waiting several months to pull updated Zeus again,
that problem was disappeared miraculous, that is why I suspect the
same problem in oe-core and bitbake in Honister as well.

Are there anyone in oe-core and bitbake tested connman, wpa_supplicant
for the current Honister branch? I can help to test and to debug it if
more advanced people in oe-core, bitbake, kernel, WiFi driver mwifiex
can provide me more information.

Thank you.

Kind regards,

- jupiter

On 1/16/22 3:26 PM, dacav wrote:

On Wed, Jan 12, 2022 at 02:15:38AM +0000, dacav wrote:

How can I include aarch64-foobar-gdb in the devshell's PATH?

Follow up on this thread: I've been kindly helped by kroon on #yocto.
The trick consists in adding a build-time dependency to gdb-cross-aarch64
in my recipe:
DEPEND = "gdb-cross-aarch64"

perhaps gdb-cross-${TARGET_ARCH} would be more generic.

At this point I can just use `bitbake -c devshell $myrecipe` and the
debugger is available.
Bonus: the devshell turns out to be very useful as a replacement
for the SDK: the environment allows me to do the cross-compilation
with just a `make`, while earlier I needed to run `bitbake $myrecipe`
and wait several seconds.
- dacav

On 1/18/22 12:04 PM, Richard Purdie wrote:

On Tue, 2022-01-18 at 10:44 +0100, Michael Opdenacker wrote:

Greetings,

I see more and more people using links to the lore.kernel.org archives,
for example the ones for this list: https://lore.kernel.org/yocto/

These look more convenient to use than the ones on
https://lists.yoctoproject.org/.

So what about advertising such archives on
https://www.yoctoproject.org/community/mailing-lists/, at least for the
ones which have archives on lore.kernel.org? I was thinking about just
adding an "(archives)" or "(archives / public mailbox) link at the end
of the description for each list.

What do you think?

Sounds fine to me.

Thanks for the feedback.
Done on https://www.yoctoproject.org/community/mailing-lists/

I added lore.kernel.org links when applicable, and also added the
openembedded-devel mailing list which was missing.
I could shorten "Archives / Public Inbox" by just "Public Inbox" if you
think it makes more sense.

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

On 17 Jan 2022, at 06:41, rgovostes@... wrote:

I'm a complete newcomer to Yocto, trying to translate a manual process of building software for an embedded device based on the PHYTEC phyCORE-LPC3250 SOM. I did not find an existing BSP layer for this board so I am trying to create my own.

Just a short hint if you didn’t discover it yourself, there is a (very) old BSP available from PHYTEC [1]. The downloads don’t seem to work, but they’re available on a probably forgotten FTP server [2].

[1]: https://web.archive.org/web/20120501212117/http://www.phytec.com/products/linux/bsp-LPC3180.html
[2]: ftp://ftp.phytec.com/temp/PCM-031_phyCORE-LPC3180

When I build a kernel for this device manually, I use the CONFIG_APPENDED_DTB=y option, which instructs the kernel to find the device tree right after the kernel image itself. I build the zImage, then append my DTB and finally create the uImage file:

cat arch/arm/boot/zImage ./arch/arm/boot/dts/lpc3250-phy3250.dtb > arch/arm/boot/zImage-dtb
mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n Linux -d arch/arm/boot/zImage-dtb arch/arm/boot/uImage-dtb

I'm trying to figure out how to properly replicate this process in Yocto.

I see that Poky's meta/classes/kernel-devicetree.bbclass uses the KERNEL_DEVICETREE_BUNDLE variable to do something similar. If I have KERNEL_IMAGETYPE set to "zImage", then it will create a zImage+DTB file.

However, it expects the zImage file to be called "zImage", and the one that gets built is called "zImage-5.14.6-yocto-standard". Since it cannot find "zImage", the build fails.

cat: .../tmp/work/lpc3250-poky-linux-gnueabi/linux-yocto/5.14.6+gitAUTOINC+4f4ad2c808_7ae156be3b-r0/image/boot/zImage: No such file or directory


I also see that meta-ti has a bundle-devicetree.inc file that has a similar aim, but it deals with uImages instead.

https://git.yoctoproject.org/meta-ti/tree/recipes-kernel/linux/bundle-devicetree.inc

My concern with using this is that it appends the DTB directly to the uImage. However the uImage header structure includes a field for data size and another one for checksum. These fields are only computed correctly if the DTB is already appended before the uImage file is built.


I think if I can figure out how to make KERNEL_DEVICETREE_BUNDLE create the zImage+DTB file, then I can write a do_deploy:append() function that invokes mkimage to produce the uImage. But I'm not sure how to diagnose the problem.

Thanks,
Ryan

On Wed, Jan 12, 2022 at 02:15:38AM +0000, dacav wrote:

How can I include aarch64-foobar-gdb in the devshell's PATH?

Follow up on this thread: I've been kindly helped by kroon on #yocto.
The trick consists in adding a build-time dependency to gdb-cross-aarch64
in my recipe:

DEPEND = "gdb-cross-aarch64"

At this point I can just use `bitbake -c devshell $myrecipe` and the
debugger is available.

Bonus: the devshell turns out to be very useful as a replacement
for the SDK: the environment allows me to do the cross-compilation
with just a `make`, while earlier I needed to run `bitbake $myrecipe`
and wait several seconds.


- dacav

On Tue, 2022-01-18 at 10:44 +0100, Michael Opdenacker wrote:

Greetings,

I see more and more people using links to the lore.kernel.org archives,
for example the ones for this list: https://lore.kernel.org/yocto/

These look more convenient to use than the ones on
https://lists.yoctoproject.org/.

So what about advertising such archives on
https://www.yoctoproject.org/community/mailing-lists/, at least for the
ones which have archives on lore.kernel.org? I was thinking about just
adding an "(archives)" or "(archives / public mailbox) link at the end
of the description for each list.

What do you think?

Sounds fine to me.

Cheers,

Richard

Hi,

Has anyone successfully built a Linux image by Honister to run WiFi
driver, connman and wpa_supplicant for WiFi interface?

I could build an image by Zeus to run WiFi driver, wpa_supplicant,
connman and dbus well, but after upgrading to Honister, the Linux
image building was fie, but the WiFi is now broken, the WiFi failed to
respond DHCP the WiFi could not connect to Internet, something is
broken between wpa_supplicant and connman which setting kernel WiFi
driver, WiFi interface and connection. I don't see any issues in
kernel WiFi driver, connman and wpa_supplicant, something missing in
the Linux image failing to set up the WiF network interface.

Appreciate your comments.

Thank you.

Kind regards,

- jupiter

Greetings,

I see more and more people using links to the lore.kernel.org archives,
for example the ones for this list: https://lore.kernel.org/yocto/

These look more convenient to use than the ones on
https://lists.yoctoproject.org/.

So what about advertising such archives on
https://www.yoctoproject.org/community/mailing-lists/, at least for the
ones which have archives on lore.kernel.org? I was thinking about just
adding an "(archives)" or "(archives / public mailbox) link at the end
of the description for each list.

What do you think?
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Was wondering if there was a way to edit the distitils3.bbclass or a similar file to only install the python .pyc files onto a yocto image?

I saw something about editing the distutils-common-base.bbclass online, however, it was only mentioned and not elaborated on.

I am currently working with a setup that installs .py files, then generates the .pyc files and removes the .py files. I am now looking for a method that will only install the .pyc files.

Any help would be appreciated.