-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cross Compilation: add a sv2-rpi.sh
script to generate tarball distributions for Raspberry Pi OS
#684
Conversation
4c13a0d
to
1b92dcc
Compare
just some alt. variant = i can compile sv2 roles direct on a rpi and get a bin for dist. cross compile for Antminer hosting tProxy direct is possible, a Antminer CB(Controlboard) has plenty CPU and Mem left when running its FW, a cross compile of tProxy, then can scp to device and set regular FW UI pool to 127.0.0.1:port that in turn points to next ie. pool-endpoint ... this for ppl with one or few machines not wanting to run role on a separate machine ... |
@GitGab19 yesterday I suggested to add a github action that check if cross compilation works: just try to compile with cargo cross from a linux vm for the target that we care about and check that no errors or warning are emitted. |
Right, thanks for better explanation (I failed in taking notes on that yesterday 😆). |
thanks for your input @s2dd however, the vision here is to have a way to aid non-technical users to deploy SV2/SRI infrastructure with the smallest possible friction (and avoid long compilation times natively on the RPi) once SRI has stable releases, we can simply add the end of the day, the goal is to boost SV2 adoption by combining these two factors:
|
yes but to get a rpi dist it could be compiled on rpi was what i tried convey also i find cross-compile tProxy for Antminer a interesting path forward |
compiling natively on the RPi is not ideal for a release workflow for multiple reasons:
during my experience in the Embedded Software industry I learned that cross compilation workflows should always be preferred for production scenarios, while native compilation should only be a last resort for quick-n-dirty PoCs
that is a good idea, I wrote this issue to keep track of it #711 |
done
the workflow calls this is not necessarily checking for cross compilation warnings or errors like @Fi3 suggested, since if we eventually decide to expand cross-compilation support to different targets beyond only however that is probably overkill at the moment, IMO |
closing in favor of #815 |
Most edge network hardware that will run the SRI stack will most likely not be x86-64 cloud servers.
A much more likely target will be ARM SoCs and SBCs, especially when it comes to pleb mining.
Therefore it is important to make sure SRI supports the most popular off-the-shelf platforms on this category (e.g.: Raspberry Pi).
This contribution is also the first step towards SRI supporting ASIC Control Boards in the future.
This PR introduces a shell script (
sri-rpi.sh
) that automates cross compilation for tarball distributions (32 and 64 bits) of the different SRI executables.sv2-rpi.sh
Here is how to use
sv2-rpi.sh
:After the package generation, you are ready to
scp
the tarball to the RPi:package layout
Configuration files are placed under
/etc/sri
, and executables are placed under/bin
. For example, here is the tarball layout ofjd_server
:cargo-cross
Under the hood,
sv2-rpi.sh
leveragescargo-cross
, so it is a pre-requisite for executing the script. It can be installed viaToolchain management via
cargo-cross
enables a stable cross-compilation experience. It also requires that at least one of these dependencies is available:docker
podman