Search

[digg_er]

Hi all. I've compiled Wownero on my Raspberry PI 4. But when I try to use wownerod, it fails when synchronising blockchain with "Bus Error" . Most often in synchronises next 1-3% and fails.

Is there any special compilation procedure for ARM?

[digg_er]

I will answer to myself :slight_smile: During compilation I get a lot of such warnings:

note: parameter passing for argument of type '__gnu_cxx::__normal_iterator >' changed in GCC 7.1
  121 |    _M_realloc_insert(end(), std::forward<_Args>(__args)...);

I have one more ARM box where wownerod works just fine (not PI, different distro, slightly different processor). But I don't get any warnings during compilation. There are some differences in packages (different GCC version - 9 vs 10, etc.), but since I got this working I'm not going to solve it exactly on PI.

[wowowl]

Hi digg_er

Are you compiling the miner inside a 64bit shell?
The error you posted below:

parameter passing for argument of type '__gnu_cxx::__normal_iterator' changed in GCC 7.1 [...] etc.

looks like the error I got when compiling XMRig (standard build) on a RPi4b without a 64 bit container.

I used nspawn64 on raspbian fresh out of the box:
https://github.com/sakaki-/raspbian-nspawn-64
Then a couple of commands to open the container, then do a clean compile, build, make and execute within that container using the command line.

Now I haven't tried wownerod for mining on the Pi, but it's on my list. My hunch is that it should work, perhaps with some tweaking.
I'll update here how we get along. Would be nice to have a clean howto for wownerod on a Pi, for the memes!

Sidebar: the hashrate for a Pi4 is absurdly low ~90h/s mining XMR on rx/0, which equates to $2 a year. Their CPU is not optimal for mining, something to do with the chips not having certain ARM architecture. Doesn't stop me looping it into the network, running stable for 2 weeks straight so far.

[orklemerkle]

A "Bus error" usually indicates a misaligned memory access. It might have to do with compiling for 32-bit ARM, which the RandomX code isn't optimised for (or even tested properly on?). I recall having had to monkey-patch `new` to get 16-byte alignment by default when compiling xmrig for 32-bit ARM (it worked, but the hashrate was terrible anyway).

Sidebar: the hashrate for a Pi4 is absurdly low ~90h/s mining XMR on rx/0

I managed almost 200H/s rx/wow on a Pi 4 (64-bit Ubuntu Server) with only modest overclocking. It still wasn't worth it though, what with the CPU not having AES extensions and its generally high power consumption. Even a years-old Haswell has it beat in terms of power efficiency.

[digg_er]

Hi guys, thanks for feedback. Maybe it will give a clue to someone else in case of similar issues. I changed my plans.

I also have FutureBit Apollo BTC full node (ARM), and I just decided to run wownerod on the same box. :slight_smile: No issues. Works like a charm.

I do not mine with wownerod. I just need a full node with inbound connections enabled in my DMZ. One of miners runs xmrig-proxy with secret spend key inside of my LAN and connects to full node which is in DMZ. My xmrig-proxy shuts downs sometimes together with other miners while I have full node running all the time.

I'm happy with this setup, supporting Bitcoin and Wownero network .