Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: dougztr on July 21, 2010, 05:56:31 PM



Title: Beagleboard / OMAP3530 test binaries available
Post by: dougztr on July 21, 2010, 05:56:31 PM
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 (http://mechalogic.net/dokuwiki/doku.php?id=go_to_the_bitcoin_client_download_page)

Cheers!


Title: Re: Beagleboard / OMAP3530 test binaries available
Post by: Quantumplation on July 21, 2010, 05:59:36 PM
=P Now get to work on an android version. =P


Title: Re: Beagleboard / OMAP3530 test binaries available
Post by: Ground Loop on July 21, 2010, 08:15:19 PM
Very interesting.

What khash/sec rates do you get on Beagleboard?

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


Title: Re: Beagleboard / OMAP3530 test binaries available
Post by: dougztr on July 22, 2010, 02:47:40 AM
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.


Title: Re: Beagleboard / OMAP3530 test binaries available
Post by: teknohog on July 23, 2010, 10:32:28 AM
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?


Title: Re: Beagleboard / OMAP3530 test binaries available
Post by: teknohog on July 23, 2010, 04:43:10 PM
My problem with PowerPC is probably an endian issue, as discussed in another thread (http://bitcointalk.org/index.php?topic=163.msg1358#msg1358). 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 (http://hardwarebug.org/2010/01/14/beware-the-builtins/) for all platforms, but should be better than nothing.


Title: Re: Beagleboard / OMAP3530 test binaries available
Post by: dougztr on July 24, 2010, 03:52:52 AM

#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.



Title: Re: Beagleboard / OMAP3530 test binaries available
Post by: teknohog on July 28, 2010, 11:13:08 AM

#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  ;)

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.)