[2013-06-21 22:59:37] Devices detected:
[2013-06-21 22:59:37] 0. BFL 0 (driver: bitforce_queue) This looks fine to me. What's the problem? Its actually connected to my old htpc at the moment since it does not work at all on my new intel i7 system even if i install any of them given winsub drivers
The new machine has many usb3 ports i am not sure if this is the reason why it totally fails to see the device even though its clearly listed in the usb devices under hardware. You don't want the WinUSB driver for BFL devices. Uninstall that first. FTDI's current official driver has problems with USB 3 ports. If it's already installed, you will need to use their CDM_Uninstaller to remove it completely. Put VID 0403 and clear PID (it should be blank); add it to the list and uninstall. Once that's done, the simple workaround is to use a USB 2 hub (or port) the first time you plug each device in. After the device has installed correctly, you should be safe to move it back to a USB 3 port/hub. |
|
|
|
Now comes the idiot part when i use cgminer or bfgminer from a command batch it simply does not find the asic miner
So i start the easyminer crap and poof it runs again.
For parameters i used the help provided on eligius wiki and help pages
Is this with BFGMiner version 3.1.0? Can you post the output from |
|
|
|
Hope you greatnesses can answer these soon.
How to overclock/crack jalapenos?
How to fix p2pool?
For Jalapenos, you might be able to trivially hack them to work with p2pool in BFGMiner at least - without firmware changes. Basically, you want to get it to use the noncerange interface instead of the bqueue interface. |
|
|
|
I don't suppose anyone has details about how to compile the firmware on linux?  I have a "make" branch on GitHub with a Makefile. This is still very WIP-quality: I don't know if the output works at all. But first, you need a toolchain... Here's how to get one on Gentoo (not intended for novice users!): crossdev -t avr32 -s1 # this will fail! but sets up stuff for us
# BEGIN binutils
mkdir -p /etc/portage/patches/cross-avr32/binutils/
cd /etc/portage/patches/cross-avr32/binutils/
PATCHES="
20-binutils.2.20.1-avr32-autoconf.patch
30-binutils-2.20.1-avr32-bfd.patch
31-binutils-2.20.1-avr32-binutils.patch
32-binutils-2.20.1-avr32-gas.patch
33-binutils-2.20.1-avr32-include.patch
34-binutils-2.20.1-avr32-ld.patch
35-binutils-2.20.1-avr32-opcodes.patch
40-binutils-2.20.1-avr32-fixes.patch
41-binutils-2.20.1-avr32-fpu.patch
42-binutils-2.20.1-avr32-bug-7435.patch
50-binutils-2.20.1-avr32-mxt768e.patch
51-binutils-2.20.1-avr32-uc3c.patch
52-binutils-2.20.1-avr32-uc3l0128.patch
53-binutils-2.20.1-avr32-uc3a4.patch
54-binutils-2.20.1-avr32-uc3d.patch
55-binutils-2.20.1-avr32-uc3l3l4.patch
"
for patch in $PATCHES; do
wget http://distribute.atmel.no/tools/opensource/avr32-gcc/binutils-2.20.1/$patch
done
# Possibly change make.conf to MAKEOPTS=-j1 - not sure if necessary
USE='-* multitarget' emerge =cross-avr32/binutils-2.20.1-r1
# interrupt build (Ctrl-Z) immediately after patches are applied
cd /var/tmp/portage/cross-avr32/binutils-2.20.1-r1/work/binutils-2.20.1
$EDITOR opcodes/Makefile.am # find avr-dis.c and add under it: avr32-asm.c avr32-dis.c avr32-opc.c
for d in . gold intl libiberty gprof ld binutils etc gas opcodes bfd; do ( cd "$d"; autoreconf; ); done
fg
aclocal -I config
autoconf
automake
autoheader
for d in bfd opcodes binutils gas ld; do
pushd $d
autoconf
automake
autoheader
popd
done
fg
# interrupt build (Ctrl-Z) after bfd has configured
cd /var/tmp/portage/cross-avr32/binutils-2.20.1-r1/work/build/bfd
make headers
fg
# DONE binutils
# BEGIN gcc
mkdir -p /etc/portage/patches/cross-avr32/gcc/
cd /etc/portage/patches/cross-avr32/gcc/
PATCHES="
30-gcc-4.4.3-avr32.patch
31-gcc-4.4.3-avr32-rmw.patch
32-gcc-4.4.3-avr32-sleep-builtin.patch
33-gcc-4.4.3-avr32-ucr3fp.patch
34-gcc-4.4.3-avr32-fpu.patch
35-gcc-4.4.3.avr32-delay-cycles.patch
36-gcc-4.4.3.avr32-list-devices.patch
40-gcc-4.4.3-avr32-fpemul-fixes.patch
41-gcc-4.4.3-avr32-fix-const_int_addr.patch
42-gcc-4.4.3-avr32-fix-reorg_opt_bug11763.patch
43-gcc-4.4.3-avr32-4_4_3-upgrade.patch
44-gcc-4.4.3-avr32-bug-12671.patch
45-gcc-4.4.3-avr32-bug-7435.patch
46-gcc-4.4.3-avr32-bug-9675.patch
50-gcc-4.4.3-avr32-mxt768e.patch
51-gcc-4.4.3-avr32-uc3c.patch
52-gcc-4.4.3-avr32-uc3l0128.patch
53-gcc-4.4.3-avr32-uc3a4.patch
54-gcc-4.4.3-avr32-uc3d.patch
55-gcc-4.4.3-avr32-uc3l3l4u.patch
"
for patch in $PATCHES; do
wget http://distribute.atmel.no/tools/opensource/avr32-gcc/gcc-4.4.3/$patch
done
USE='-*' ACCEPT_KEYWORDS=** emerge =cross-avr32/gcc-4.4.3-r3
# DONE gcc
# BEGIN atmel-headers
layman -a luke-jr
ACCEPT_KEYWORDS=** emerge cross-avr32/atmel-headers
# DONE atmel-headers
# BEGIN newlib
mkdir -p /etc/portage/patches/cross-avr32/newlib/
cd /etc/portage/patches/cross-avr32/newlib/
# skip 10-newlib-1.16.0-avr32-atmel-version.patch
PATCHES="
30-newlib-1.16.0-avr32.patch
31-newlib-1.16.0-flashvault.patch
"
for patch in $PATCHES; do
wget http://distribute.atmel.no/tools/opensource/avr32-gcc/newlib-1.16.0/$patch
done
ln -s /usr/portage/sys-libs/newlib /usr/portage/local/crossdev/cross-avr32/
USE=-* ACCEPT_KEYWORDS=** emerge =cross-avr32/newlib-2.0.0
# interrupt build (Ctrl-Z) immediately after source unpacks
cd /var/tmp/portage/cross-avr32/newlib-2.0.0/work/newlib-2.0.0/
for patch in $PATCHES; do
patch -p0 <"/etc/portage/patches/cross-avr32/newlib/$patch"
done
cd newlib
autoreconf
fg
# interrupt build (Ctrl-Z) immediately after you see:
# >>> Install newlib-2.0.0 into /var/tmp/portage/cross-avr32/newlib-2.0.0/image/ category cross-avr32
mkdir -p /var/tmp/portage/cross-avr32/newlib-2.0.0/image//usr/avr32/lib
# DONE newlib
ln -s /usr/lib/binutils/avr32/2.20.1/ldscripts/ /usr/avr32/lib/ |
|
|
|
Can you post the image somewhere?
My offer still stands ... I mean in hosting a small site keeping the images for others.
one4many
I believe luke-jr already compiled the unmodified 1.2.5 source code. https://bitcointalk.org/index.php?topic=235312.0 (the hex file) No, that file is as-is from BFL, I didn't compile it. I've got one compiled myself, but for all I know it bricks it. Maybe a bit more poking and I'll try it out.  |
|
|
|
Disclaimer: I have nothing to do with this link. I do not in any sense endorse or confirm their product. Lol are you even a member there? No. |
|
|
|
Disclaimer: I have nothing to do with this link. I do not in any sense endorse or confirm their product. |
|
|
|
If you only plug in one of the power supplies, does the device still function but only running up half the boards at 250GH/s?
Just thinking about if a breaker trips.
Since this rig is running with a USB hub inside, yes, that is exactly what will happen. When they start using xlink, it will depend on if the master board is taken out or not so if one PSU goes down, you could lose the whole rig. I thought they had already been told about this problem at one of the trade shows? Why have they not fixed this to date? I'm pretty sure everyone considers it more important to get it delivered and mining... |
|
|
|
I wonder if GigaVPS made the pic that way to give a false impression? How is it gigavps's fault that you can't read??  |
|
|
|
|
BTW, if anyone wants to hack at something... I'd suggest going back in the git history to get at the interleaved works (or maybe it's still in the latest code too, just disabled?) before the change to one-job-per-chip. If you get that working, Little Singles and better should be fine on p2pool... (and lower stales mining normally too)
|
|
|
|
In a business like mining where each past second is more valuable than the future one, I'd say that could be expected that "burnins" would be done against the customers address, especially considering that we are speaking about preorders. I guess the *promise* of profit in ASIC mining its been huge for a limited window, and the companies could get away with it. This is going to change. ROI is going to be very tight for everybody. Maybe the burning income was counted in the original pricing of the units...? Same net effect as trying to "rebate" via a burnin later. Doing burnins on mainnet is not in any sense "stealing".
The burnings have to be done anyway, no point throwing that away. @Luke-Jr: Here is the difference; Throwing away would mean that it would otherwise be wasted. And in the case of burning, it would otherwise be wasted. Vice: You aren’t doing any mining at all?
Yifu: Nope. Fun fact: none of the Avalon team have their own mining units (outside of test units). This sounds to me like he's talking about their own personal mining, not what goes on with burnin testing of units they're selling. |
|
|
|
|
Doing burnins on mainnet is not in any sense "stealing".
The burnings have to be done anyway, no point throwing that away.
|
|
|
|
|
I don't know why this comes as a surprise to anyone.
For political purposes, it makes sense that BFL decided not to mine mainnet for burnins, but other than that, why would a company want to basically throw away potential revenue?
The pattern here certainly does look like testing/burnin to me, at least - if someone wants to bother, they can plot when people received units against the hashrates seen on Eligius (that data is public, I think).
Besides, didn't someone at Avalon say outright that they were mining on them before shipping?
I seem to recall reading that somewhere...
|
|
|
|
I'm not missing the driver. Each time ubuntu updates it makes a new kernel version folder. each with a build and updates folder. The original kernel folder has all the drivers and etc....
I rebooted and ran bfgminer again with -S /dev/ttyUSB0 and it appears to still be using my GPU. What flags do I need to use to make it use the block erupter? I've googled all day and can't find any clear instructions for linux. Plenty for Windoze 7 though.
-S all is sufficient if the driver is in order. |
|
|
|
Edit 2: I got bfgminer to start by using the -S /dev/ttyUSB0 flag, but it's not mining anything. I looked around in my folders and the usb to uart bridge drivers(cp210x.ko in linut) are in the "3.8.0-19-generic" directory, but not in the newer kernel directories. Does this make a difference? Shouldn't it access it from the previous kernel directories? I'm at a loss here. I'd like to get this block erupter hashing.
Linux is a a monolithic kernel. So its "drivers" are technically builtin, even if they're loaded at runtime. This means you cannot use a driver compiled for any other version, with the current one; it must be the matching version. Where did you get your kernel from that it is missing the driver? :/ |
|
|
|
|
midstate is not needed for anything except DiabloMiner.
|
|
|
|
Hi Luke
We are a group of South Africans that is going down this route.
We will however make use of BFL's reference designs.
Its still early days.
We dont know yet what our product will look like!
Do we qualify?
Well, I expect everyone is going to make use of BFL's designs. What I'm looking for is new designs going beyond simply making clones. |
|
|
|
does this mean we can flash our current miners? Overclock? You'll need to disassemble it and connect a JTAG programmer, but other than that, I believe so... Step one when I get around to poking at this, will be to get it building with standard GCC (or at least free software). |
|
|
|
I've decided I'll probably give away my $25-off-chips coupons from BFL, to hardware designers making new products based on them. Tentative conditions: - You must be making a new device; simply building clones of existing BFL devices doesn't count!
- You must provide specifications and at least one sample unit to me for maintaining BFGMiner support for it.
Quantity of coupon codes per project depends on how many people are interested in taking me up on this, but I should have plenty. I reserve the right to favour more interesting projects So, anyone interested? |
|
|
|
|
Show Posts
