meta-riscv VS meta-balena

There does exist a Yocto recipe for RISC-V that claims to support both 32 and 64-bit. I haven't used it myself, but your best bet may be spin up a custom Yocto/OE based distro. You can find the source and documentation here: https://github.com/riscv/meta-riscv

Great news !. We have a yocto port for JH7110 here https://github.com/riscv/meta-riscv/blob/master/conf/machine/visionfive.conf, I will be happy to add a machine conf for pine64, It should be easy enough to start from above as template.

Remember our blog post about #Nezha board? It is an SBC with a #RISC-V D1 chip onboard. If you have knowledge of #Yocto, from now on you can create a system image using the #meta-riscv layer. For more please refer to our pull request at GitHub repository: https://github.com/riscv/meta-riscv/pull/327

Disclaimer: I've not used this myself yet... but I've also been looking at how I can manage models in production too - came across https://www.balena.io/os

From what has been stated thus far, it becomes obvious that most of the opportunities would be in enabling containers for embedded targets. Currently companies like pantacor, BalenaOS, Toradex, Mender, and Foundries all offer solutions for containers for Linux-based embedded targets. This means that these solutions cannot support all types of embedded targets as not all have the computational power to support the needed underlying infrastructure. Right now, there is at least still a couple of other promising solutions out there that can support a wider range of controllers and are lighter weight, and don't require a Linux environment. For one, there is MicroEJ that aims to transform electronic "things" into smart things like Android transformed phones into smartphones. Another really interesting effort out there is Luos that provides an open-source lightweight microservices solution for distributed embedded devices.

What i found out: After spending a lot of time looking stuff up and comparing the finestra files to a normal helium image , i figured out that they were pretty different which is why one of the other reddit solutions which involves using a normal helium image i wasnt such a big fan of because you lose some of the functionality of the finestras. Finestra internally use BalenaOS for their raspberry pi's and use a base image for raspberry pi 4 (64 bit) from here . A good chunk of what comes in a finestra and whats in the base image of BalenaOS is the same, mainly the differences being in the config.json file inside of the SD card of the finestra. Theres also a folder called overlays which has small differences between the 2 but im not sure exactly what they are since there are a lot of files. The contents should look similar to this.

FWIW we recently started using the Yocto-based BalenaOS[0] in our project and have been rather happy with it because we get to focus on developing and running our software and don't have to bother with the low-level hardware stuff too much.

Unfortunately, as we're getting closer to shipping our product, we've realized that Balena seems to be rather cavalier when it comes to respecting software licenses. They offer pre-built .img files and Docker base images but don't provide a comprehensive list of licenses (let alone the source code) of third-party software components anywhere, as this issue[1] attests to. I'm currently talking to one of their customer service representatives and, as of this morning (when they sent me another email), they don't even acknowledge that this is an issue.

Looks like we'll now have to compile this list on our own. :\

[0]: https://www.balena.io/os

[1]: https://github.com/balena-os/meta-balena/issues/1955