From: Eilís Ní Fhlannagáin <elizabeth.flanagan@...> This commit removes the need for calling out ZEPHYR_MODULES via MACHINEOVERRIDES. It uses west list to figure out what ZEPHYR_MODULES are

From: Eilís Ní Fhlannagáin <elizabeth.flanagan@...> This commit restructures meta-zephyr into meta-zephyr-core and meta-zephyr-bsp. It moves machine definitions into meta-zephyr-bsp in

From: Eilís Ní Fhlannagáin <elizabeth.flanagan@...> We will need west for a few things. First, west knows about all the boards supported, so for automatic machine generation, we will need

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

This is a classic problem with software that doesn't consider cross-compilation (and even when building for a similar architecture, like genericx86-64 on an x86 host, you're cross-compiling in

The documentation mentions a relationship between enable_uart and (lower) core frequency on some hardware variants - could there be a side-effect (if yes, maybe gpu_freq/arm_freq could play a factor)

For a reason I can't quite understand, everything stated working when I added ENABLE_UART = "1" Does anyone understand the relation between ENABLE_UART = "1" and RPI_USE_U_BOOT = "1"

I need to include an old open source project named judy for a legacy utility dependency. The recipe I have so far is listed at the end of this email. The build host is 64bit linux, I'm using dunfell

Signed-off-by: Ross Burton <ross.burton@...> --- config.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.py b/config.py index 6da8d58..4c0b83b 100644 ---

Signed-off-by: Ross Burton <ross.burton@...> --- config.json | 4 ++++ scripts/publish-artefacts | 6 ++++++ 2 files changed, 10 insertions(+) diff --git a/config.json

The exception for github.com was implemented in bitbake fetcher and backported to various versions, e.g. 1.46 used with dunfell

Thanks Matthias for your input. I have the same problem using the raspberrypi4-64 target. On my end, the mere fact of enabling RPI_USE_U_BOOT yields a non-bootable image. The image I generated/burned

Hi, Not really. Because this is a GitLab specific behaviour. Changing the default to https would change the general assumptions everyone has in their layers. Andrei

Hei, would not the "easier" approach be to change the bitbake tooling to use https as the default git fetching protocol, rather than modify every single recipe in the world? Best Regards, Janne

Hello Jean-Philippe, >I'm trying to create a simple image that uses the RPI_USE_U_BOOT option but the pi hangs with the rainbow image. I'm able to generate bootable images when not using the

Hello, I'm trying to create a simple image that uses the RPI_USE_U_BOOT option but the pi hangs with the rainbow image. I'm able to generate bootable images when not using the RPI_USE_U_BOOT option

Michael, I noticed that the https://www.yoctoproject.org/reproducible-build-results/ website went down (it always shows "Error fetching test results"). I did a little debugging and I think that the

Hi Quentin, Thanks for the advice! Right, I was thinking of leaving this aside, and just working with a local archive instead, as fetching the files is not the primary concern here. Many thanks.

Hi Michael, IMO that makes it unsuitable for the docs as we strive to have "simple" examples and having some custom unpack task seems a bit too much to me. Anyway, just my 2¢ and I don't have any

From: Bruce Ashfield <bruce.ashfield@...> 5.14 is no longer actively maintained, so we bump our default to the 5.15 LTS. Signed-off-by: Bruce Ashfield <bruce.ashfield@...> ---