In the container, I clone the repo, checkout the branch, init the submodules and then run ./balena-yocto-scripts/build/barys -m raspberrypi4-64. Unfortunately, the building stops at
ERROR: Nothing PROVIDES 'resin-image'
resin-image was skipped: missing required distro feature 'systemd' (not in DISTRO_FEATURES
Being a complete yocto newbie, I’m not sure how to proceed here.
Hello @wngr unfortunately we don’t support rpi4 yet, but we are working hard have it ready as soon as possible. I forwarded this to the devices team in the hopes they can find some time to take a look and point you in the right direction, but keep in mind we can not guarantee support for this yet.
1- We aren’t releasing 32-bit as you can easily use the 64bit image with a 32bit container if needed.
2- We have recently updated our backend and enabled the ability to move aarch64 devices into armv7 fleet. so yes.
Not in the short term, but in the long term this is something that we would like to allow, but there are some things that need to be ironed out first. We’ll keep you posted.
Hi,
You can track progress on the SDK side of this on this GitHub issue:
Once that’s done, there will be a period of extra internal testing before releasing, but for sure getting this resolved would mean that we are getting close.
Hey @wlisac I wanted to let you know that we have finally added mixed fleet support for the PI family. To be clear we do provide backwards Pi model compatibility, in the sense that RPi4 & RPi3-64bit devices can be added in RPi3/2/1/0 apps, RPi3 devices can be added in RPi2/1/0 apps. BUT RPi 1/0 devices can’t be added in RPi 2/3/4 apps because of their CPU architecture.
I think my use case is actually the one that’s not supported – mixing armv6 / armv7 / armv8 devices, but having the devices run containers native to their own architecture.
I understand why this isn’t supported right now, but it would still be nice to allow a single app to build for multiple architectures (especially when using a Dockerfile.template that supports multi-arch).
We have an IoT app that works on Raspberry Pi 0/1/2/3/4. It’s written in Swift and uses docker images via Swift on Balena.
We’d like to be able to have a single application on balena that includes all of the different Pi variations, but we still want all of the containers to run against the native architecture of the device.
Right now, it sounds like we either have to drop down to the lowest common denominator (armv6) or use different balena apps for each architecture type.
Currently, we’re using different apps on balena and using a multi-arch Dockerfile.template:
FROM wlisac/%%BALENA_ARCH%%-swift:5.0.1-build
This isn’t great, since we have to manage all of our env vars, releases, etc in different apps.
The alternative of using armv6 containers on all of our devices also isn’t great, since we want to take advantage of armv7 / aarch64 instruction improvements where possible (most of our devices are armv7 / aarch64).
We’d like to have mixed architecture applications, and (ideally) be able to specify the architecture to use for a device type (maybe in some cases folks do want to run armv7 containers on an aarch64 OS / device, for example).
I’m happy to expand on the use case more, but hopefully that helps
Hi @wlisac, thank you for the explanation of your use case. Appreciated.
I took a note in our internal system that you are interested in having an application with mixed device architectures. We had more users asking for this feature as well. So thanks for the further encouragement to build it : )
We will post an update as we make progress on that front.
Do you happen to have a GitHub issue we can use to track this?