Hi.
I have a release build question. I want to build a release for raspberry pi on my Linux machine. I can’t figure out how it’s done, what steps should I take to build a release for rasberry pi , can it be done with rebar3 , what tools should I use?
1 Like
Hello!
I would suggest that you build on the raspberry pi, it will save you a lot of headaches as cross-compiling is not very easy to do.
That being said, you first have to cross-compile Erlang, which is described in the Erlang -- Cross Compiling Erlang/OTP guide. There is a xcomp-config for rpi3 in our source repo that should work, though we don’t test them so there may bugs.
You then also need to cross-compile any nifs in your project, which means setting the correct CFLAGS etc before calling rebar3 compile. There is a list of all options you can pass here: Plugins | Rebar3.
As I said, it will not be easy to do, but it can be done. If you have the possibility, I would really recommend you build on the rpi instead.
4 Likes
thanks for the answer. It might be easier to do that.
1 Like
For what it’s worth, we have a lengthy script for cross-compiling ARM64 binaries on x64 . It cross-compiles Erlang/OTP and all dependencies, links them statically, and then builds an OTP release using Rebar3. The length of the script gives you an idea of what Lucas had in mind when he mentioned headaches. But it might serve as an example if you do want to have a go at it, after all.
2 Likes
To run AtomVM on a Raspberry Pi it would be far simpler to compile on the Pi as suggested previously. We do not have specific tooling for cross-compiling the generic_unix port of the VM. From there you can just use rebar3 and the atomvm_rebar3_plugin to compile and pack your beam files into a *.avm for AtomVM to run.
I have also successfully compiled and flashed an esp32 board using a Raspberry Pi, if you are interested in using it for microcontroller development.
1 Like
this is interesting, do I need to compile on raspberry so that I can run it on it later?
1 Like
Hi
Just sharing one approach (it depends on the use case targeting Linux… 
Which is to use meta-erlang [1] and Yocto Project to generate
a custom Linux build to raspberry Pi [2]. Including SDK for cross-compilation.
Then, you can use that SDK to cross compile your release on x86 hosts. Getting the
build results and running it on raspberry.
We use a similar approach but for Intel. In our case the release includes erts (which would run
on raspberry, in your case) plus some erlang port drivers in C. That is possible because we compile using a SDK made by Yocto Project.
Of course it depends on the use case but you could save a lot of effort mainly in the cross-compile
area.
1: https://meta-erlang.github.io/
1: GitHub - meta-erlang/meta-erlang: Erlang and Elixir support, https://meta-erlang.github.io/
2: GitHub - agherzan/meta-raspberrypi: Yocto/OE BSP layer for the Raspberry Pi boards
1 Like
Or main focus is on the microcontrollers, so strictly speaking compiling the generic_unix port is completely optional. It can be extremely helpful to test non-MCU specific features on the generic_unix port, as it doesn’t require flashing or opening a serial console to test. It is also helpful in testing network applications between an esp32 and a unix machine, as flashing two devices and opening two serial connections can be fiddly and time consuming - or maybe you only have one esp32 available.
We have a release image that you can flash directly to an esp32 and start working with rebar3 and the atomvm_rebar3_plugin along with esptool.py (provided by Espressif).
We hope to have development builds from master available in the near future, but for now they can be found by looking at the bottom of a recent esp32-mkimage workflow in the AtomVM repository.
There should also be a long overdue 0.6 release coming soon…
1 Like
Also I completely forgot to point out that the generic_unix port does not support GPIO or I2C, SPI functions at this time, those only work for the microcontrollers. This is something that I would like to se added to AtomVM - mainly for use with the Raspberry Pi and other single board computers, but this could potentially support using USB-GPIO breakout boards on other Unix machines.
At the moment we are a small team with a long todo list so this will not likely be supported in the near future… but any PR to add these features would be more than welcome.
1 Like