-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Rpi4: distributing binaries with no AES for 64-bit OSes #7979
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
Conversation
ArqTras
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn’t that disable aes for all depends builds ?
Yes it is, but it's far from being perfect yet, hence the "draft" status. |
Mayby add something in depends section of Makefile
|
|
I'll figure it out. I'm just preparing the workplace right now, so to say. But thanks for the active participation. |
|
I confirm, that the binary |
I did test same on Ubuntu 21.04 64 bit rpi 4, works fine |
|
@ArqTras : Thanks. Could you also share some expertise, if the |
|
BTW, in case you didn't know, you may directly test the built binaries by clicking on Checks, and then "Depends". Then scroll down for the bins. |
I will check as soon as I get my computer on hands ;) |
|
I ran tests on RPi 3 and RPi 3B+, both using ARM v7. Both versions: with and without AES were working fine. I'd love to be able to assume here, that all the RPi 3 versions had the AES support. Care to help me research this online maybe @ArqTras ? |
|
No Raspberry has hardware AES support |
|
32bit ARM code for RandomX has never used hardware AES, it is all 100% software. And too slow to be worth using. The ARMv7 instruction set doesn't include AES instructions. They're only available in ARMv7l, an ARMv8 processor running in 32bit mode. |
|
Thanks for the replies.
This explains, why the switch NO_AES wasn't needed for the ARM v7. Then I'd say that the |
This would be quite an interesting use case. Do y'all think we should cover it in the future? However that reply about 32bit ARM code for RX disqualifies this. |
|
I already wrote the code for it. No, I don't think it's useful. tevador/RandomX#148 |
|
The next step shall be |
|
Overall I think supporting Rpi in any form is a waste of effort since they all lack hardware AES. Alternatives like Odroid, Pine64, etc are all plentiful and easily found, with solid Linux support already. |
|
A dumb question maybe, but does AES matter so much, if an RPi user wishes just to run a node and use the CLI wallet to perform transactions? |
|
it will probably be too slow to finish intiial block download on its own. Copying a blockchain DB from a PC may be ok to get it started but if it ever spends more than a day offline it will never catch up on its own. |
|
Sync take a day as mentioned early on ssd drive. No issues with create / restore wallet. It’s good to have own trusted node also there is no issue to share blockchain data with others. Not sure about pi3 versions but pi4 is cheap and most popular in EU |
FYI Pi4 4gb and 4gb swap takes over a week straight to sync from 0 using microSD card as storage and no pruning :) |
7051729 to
b2fba88
Compare
|
If you really want to support Rpi, setting up an entire new build seems the wrong way to go. Instead just add dynamic AES detection at runtime, like we do for x86. One way to get started on that would be to add the output of Here's output from RK3399 in rockpro64 |
|
Sounds good. Thanks. |
|
processor : 0 processor : 1 processor : 2 processor : 3 Hardware : BCM2709 |
|
@Minthos According to other docs, BCM2709 is in the Rpi2, which we don't care about here since it's 32bit only. Ah, never mind. It's running a 32bit OS. again, we don't care about this, we only need the info for 64bit OS. But I think it's already cleaar that the |
|
Raspberry Pi 3B+ Raspberry Pi 4B |
|
@endorxmr looks like both of yours are running 32bit OS too. So again, not what we need. |
|
processor : 0 processor : 1 processor : 2 processor : 3 Hardware : BCM2835 |
|
2 Rpi4's, running 64-bit Raspbian OS: |
|
RPi3 Model B (64-bit OS) |
|
I assume this is also superseded by #8001? |
|
Yes |
|
Closed by #8001 |

Continuing the discussion and performing concrete experiments from #7953
Generating 64-bit binaries for Rpi in both
dependsandgitianThe
gitianpart could not be tested, due tominiupnpnot being able to be synched. I was testing it on my branch of my project with:The full error message was:
UPDATE:
I was able to go through the above error by issuing:
git submodule sync > /dev/null && git submodule updatemanually from withininputs/monero