rollmeister
commented
6 years ago Nevermind. I think I worked it out in the end. I forked this repository and all the changes are basically limited to algo/scrypt.c. I did a "pull request"? You are invited to review the changes, which are commented in said file and merge into your repository in the event of which I will likely delete my fork. I also stripped back the scrypt_core_3way() to a scrypt_core_1way() but found performance regression and while it is still defined in scrypt.c, it is not used. Minor changes applied to scrypt_shuffle(), xor_salsa8() and xor_salsa8_prefetch() also. I have had 3 boards running a total of 6 threads using the now default thread for aarch64 scrypt_core_2way() and the pool accepts 100% of shares. My part in this is minor I must admit. What I did is documented in the Readme.md in my fork along with some more optimal compile instructions. Thank you and cheers for the great work you and others have done.
I was trying to create a stripped down version of scrypt_core_3ways() for aarch64/armv8. The justification is (or so I imagine) that these sbc's do not have the memory capacity or bandwidth to benefit much from a full scrypt 3 ways and these four core soc's could run four threads consuming 256mb each for the 1gb ram many of these boards have. I have made some limited efforts in trying to make it work but cannot complete due to lack of skill. So far I got a miner that produces invalid work but the 2ways implementation has a similar hashrate to the scrypt_core_3ways(). For the aarch64 defined section you could replace the scrypt_core_3ways() and default to scrypt_core_2ways() in scanhash_scrypt(). You can download the WIP files from another comment I made, probably in the wrong place sorry. I also considered porting the asm/scrypt-arm.S to armv8. More details in comment link below. Thank you. https://github.com/effectsToCause/veriumMiner/commit/4530b31b9dd4913bfe02be4f13a8a09e5a16acad#commitcomment-29544892