So, here's where I'm up to: I've proposed a bunch of clean-ups and improvements here: https://github.com/agherzan/meta-raspberrypi/pull/120. The main thing for this discussion is that I have u-boot wo

Unfortunately "booti" is only supported on arm64 and "bootm" is only supported on 32-bit arm. I'm leaning towards having one variable, RPI_USE_U_BOOT, which when set to "1" will set KERNEL_IMAGETYPE c

Good timing, this is what I'm actually looking at today! The arm64 arch does not support the legacy "uImage" format. We need to use the "Image" format (or "Image.gz") and use "booti" in u-boot instead

There is one initial thing you could try adding in your local.conf: MACHINE_FEATURES_remove = "bluetooth wifi" If that doesn't work, I think we need a bit more detail to give further advice here. - Wh

<mickey.happygolucky@...> wrote: This and the follow up patch look excellent, should be easy to modify in the future if we need to. We have switched to using github pull requests for meta-raspbe

I'm seeing the same issue on builds from both pyro and master branches. I've confirmed this isn't a HW issue by trying out an OpenSUSE Leap 42.2 64-bit build for Raspberry Pi 3. Khem, are you saying t

<mickey.happygolucky@...> wrote: I don't like the amount of duplication here. Could you define some common variables and use those in the appends? This will make it easier to change/upgrade in t

You should be able to run "bitbake <recipe> -c devshell" to get a development shell for that recipe with the PATH set up. See http://www.yoctoproject.org/docs/2.3.1/mega-manual/mega-manual.html#platde

It looks like you're mixing branches here. Could you re-try this using the pyro branch of meta-raspberrypi? Cheers,

It looks like you're mixing branches here. All your layers should typically be on the same branch - so either all on morty or all on master here. Could you align these and re-try your build? Thanks,

I've submitted the patch via GitHub as per the new contributing instructions for meta-raspberrypi. https://github.com/agherzan/meta-raspberrypi/pull/82 Cheers,

I was thinking of a different approach entirerly. We can add the following at the top of the recipe file: python __anonymous() { if "linux-raspberrypi-dev" not in d.getVar("PREFERRED_PROVIDER_virtual/

We should be able to skip the recipe if it isn't selected as the preferred version and/or provider of "virtual/kernel". I'm out at the minute so can't look at it now but will try to take a look later

Hi all, Yocto Project 2.3 has now been released so I think it's time to create a pyro branch for meta-raspberrypi. I've briefly discussed stable branch maintainership with Andrei and I'd like to volun

<costamagna.gianfranco@...> wrote: This looks good, I'll add it to my queue to test next week unless Andrei has time to pick it up. We've all been a bit busy, sorry you've not had a response soo

This looks great, cheers for setting it up! I'm doing nightly builds of my setup but that's a bit non-standard (custom distro, musl libc, u-boot enabled, etc). For meta-raspberrypi itself I think you'

I'd like to be able to say to users that all layers should be on the same branch, it's confusing if some need to be on pyro and others on master. It also makes our release much easier as we can point

This looks like the error I'd expect when mixing an older branch of poky with the master branch of meta-openembedded or meta-amd. Could you ensure that all git repositories are checked out at the same

Hi all, I've now got a bit of a vested interest in the next meta-raspberrypi stable branch as I'm planning to use it as a demo platform for our new Oryx distro. In the past, the stable branch hasn't b

I've just tried to reproduce this using a fresh clone of poky and meta-raspberrypi on the morty branch. I edited bblayers.conf to add the meta-raspberrypi layer and then edited local.conf to set MACHI