Bitcoin Forum
November 07, 2024, 07:01:42 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Beagleboard / OMAP3530 test binaries available  (Read 10732 times)
dougztr (OP)
Newbie
*
Offline Offline

Activity: 5
Merit: 0



View Profile
July 21, 2010, 05:56:31 PM
 #1

I've managed to make some binaries for beagleboards and closely related devices which should work with pretty much any linux that can run on these things, excluding android. There's also a generic i586 binary which you might want to try if you can't get the official ones to work. These are built from the 0.3.2 linux package source, all I did was tinkered around with the makefile and had to make a minor edit to sha.h to make it build on ARM.

The problem with the official binaries is that glibc is static linked in, so that means you have to have an exact match with it for it to work. Mine have everything except glibc and closely related libs static linked, so it will pick up your own system's glibc and hopefully work flawlessly.

I have both of these binaries in production right now on my servers. You can even use the one server, which is the download server, to bootstrap your clients with if you can't use port 8333 like so:

bitcoind -addnode=mechalogic.net

Anyways, here's a link to my wiki page that houses my current work.
http://mechalogic.net/dokuwiki/doku.php?id=go_to_the_bitcoin_client_download_page

Cheers!
Quantumplation
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250



View Profile
July 21, 2010, 05:59:36 PM
 #2

=P Now get to work on an android version. =P

NOTE: This account was compromised from 2017 to 2021.  I'm in the process of deleting posts not made by me.
Ground Loop
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
July 21, 2010, 08:15:19 PM
 #3

Very interesting.

What khash/sec rates do you get on Beagleboard?

Using the OMAP's DSP might be an interesting SHA256 approach.

Bitcoin accepted here: 1HrAmQk9EuH3Ak6ugsw3qi3g23DG6YUNPq
dougztr (OP)
Newbie
*
Offline Offline

Activity: 5
Merit: 0



View Profile
July 22, 2010, 02:47:40 AM
 #4

My IGEPv2 at 720MHz gets 120 khash/s. Yes my goal is to utilize the DSP to calculate hashes, but getting a running client was a good first step. I'm going to make diffs against the 0.3.2 sources and include them in the tarballs at some point here. I've made some significant changes to the makefiles in the process of learning how to compile these sources.

I'm not a whiz programmer though, so slogging through DSP programming is all new to me. I have a reasonable grasp of ASM, but its rusty with disuse, so I'm mostly doing this for my personal interests in learning new stuff.
teknohog
Sr. Member
****
Offline Offline

Activity: 520
Merit: 253


555


View Profile WWW
July 23, 2010, 10:32:28 AM
 #5

I've managed to make some binaries for beagleboards and closely related devices which should work with pretty much any linux that can run on these things, excluding android. There's also a generic i586 binary which you might want to try if you can't get the official ones to work. These are built from the 0.3.2 linux package source, all I did was tinkered around with the makefile and had to make a minor edit to sha.h to make it build on ARM.

Can you please document how you did this? I am trying to build bitcoind on various architectures running Gentoo Linux. I did get a working client on x86-64, but on PowerPC I get the following error:

Code:
bitcoind: main.cpp:1599: bool LoadBlockIndex(bool): Assertion `block.hashMerkleRoot == uint256("0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b")' failed.

In sha.h I had simply added "&& defined(__x86__)" to line 75, because the bswap instruction was apparently x86 assembler. Perhaps there is something else in sha.h that should be changed?

world famous math art | masternodes are bad, mmmkay?
Every sha(sha(sha(sha()))), every ho-o-o-old, still shines
teknohog
Sr. Member
****
Offline Offline

Activity: 520
Merit: 253


555


View Profile WWW
July 23, 2010, 04:43:10 PM
 #6

My problem with PowerPC is probably an endian issue, as discussed in another thread. Nevertheless, I think this is a problem worth solving, if only for better portability overall. Or am I the only one here using PowerPC?

On a side note, while looking at sha.h, I came across gcc's builtin byte swap functions, which might be useful there. They are not yet optimized for all platforms, but should be better than nothing.

world famous math art | masternodes are bad, mmmkay?
Every sha(sha(sha(sha()))), every ho-o-o-old, still shines
dougztr (OP)
Newbie
*
Offline Offline

Activity: 5
Merit: 0



View Profile
July 24, 2010, 03:52:52 AM
 #7


#if defined(__arm__)
#include <byteswap.h>
        #ifndef CRYPTOPP_BYTESWAP_AVAILABLE
        #define CRYPTOPP_BYTESWAP_AVAILABLE
        #endif
#endif

Then later on, I deleted out all the other byteswap stuff. Particularly, there was a line like:

#ifdef (__GNUC__)
        #define __asm__ (bswap ... )

That stuff is wrong, bswap is an x86 instruction and not found on ARM


I got a report earlier that my static linking scheme wasn't working. Boo. I'm not sure how to work around it now though.
I'll see if I can get some diffs against the source and just put those up.

teknohog
Sr. Member
****
Offline Offline

Activity: 520
Merit: 253


555


View Profile WWW
July 28, 2010, 11:13:08 AM
 #8


#if defined(__arm__)
#include <byteswap.h>
        #ifndef CRYPTOPP_BYTESWAP_AVAILABLE
        #define CRYPTOPP_BYTESWAP_AVAILABLE
        #endif
#endif

Then later on, I deleted out all the other byteswap stuff. Particularly, there was a line like:

#ifdef (__GNUC__)
        #define __asm__ (bswap ... )

That stuff is wrong, bswap is an x86 instruction and not found on ARM

Thanks! I used a different approach with the GCC builtins, such as

#if defined(__GNUC__)
    return __builtin_bswap32(value);

and ditto for 64 bits. I'm getting a whopping 51 khash/s on a 400 MHz armv5, a Buffalo Linkstation Live  Wink

SVN revision 114 with the new sha256 implementation from crypto++ compiles without any source modifications on ARM, which is nice. However, it is a little slower at 46 khash/s maximum. The gcc builtin function does not improve things at all, suggesting that the cryptopp byteswap function is equally fast, and the difference is due to the overall implementation. (While on x86-64, this update has given me an 80% speedup.)

world famous math art | masternodes are bad, mmmkay?
Every sha(sha(sha(sha()))), every ho-o-o-old, still shines
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!