Any chance of Bitmain S1/S2/S3 support? This is all kinda pending waiting on Bitmain since the S1... :/ Just no dev unit? Or no source to go off? If I can get a MIPS compiler setup in a Linux VM tonight I would be willing to at least start poking around They did send a dev S1, but no docs, and the source is essentially useless  They have a Github acct. and were supposed to have posted the open code somewhere for people who bought chips, access to S1 controller boards was also stated as part of the chip deal. One thing holding me back from buying S1/S3 is I would prefer to use BFG Miner. Maybe a request sent thru the github repo would get a response from Bitmain. They have code, but it isn't useful - besides being poorly written and hard to read, it's just code, and doesn't tell you the underlying logic in the chips and controller. Documentation and/or interaction with someone who knows these things is somewhat necessary, else there are many days of reverse engineering work to be done. Note that if you're making your own boards with their chips, that's mostly unrelated to S1-S3 driver support; even if S1-S3 were supported, it's not necessarily going to "just work" with any other PCB using the same chips. On the other hand, that may be a good thing for you: you don't need their driver either. But we'd still need some kind of documentation for the chips... |
|
|
|
Any chance of Bitmain S1/S2/S3 support? This is all kinda pending waiting on Bitmain since the S1... :/ Just no dev unit? Or no source to go off? If I can get a MIPS compiler setup in a Linux VM tonight I would be willing to at least start poking around They did send a dev S1, but no docs, and the source is essentially useless |
|
|
|
Any chance of Bitmain S1/S2/S3 support? This is all kinda pending waiting on Bitmain since the S1... :/ |
|
|
|
|
There is no encryption involved in Bitcoin.
As Eleuthria said, you are clueless.
|
|
|
|
The Bitcoin wiki is not "owned" by bitcoin.org. It's independent, which is good.
Agreed. Let bitcoin.org be the site for the official client and bitcoin.it be the wikipedia for all things Bitcoin (including third-party clients, the Bitcoin economy, etc.) bitcoin.org isn't for any specific client either, nor is any client official... |
|
|
|
|
How do we know which tor link is legit? Maybe user "Dull" is putting the fake one? Or maybe both... Sgornick reviewed it a while back, and that had yet a different tor link than both of these :|
For now, I've just removed the tor link entirely. When/if the website clarifies the correct one, we can put it up.
|
|
|
|
So I`m guessing better leave it alone  TY for quick heads-up. Edit: They are working on it https://github.com/KnCMiner/cgminerBut I preasume lots of work to commit any changes... Some FAQ/HOWTO compile it under linux/ubuntu to run on miner? I know they keep updating their tree, but they have not pushed a single patch to mainline cgminer. Compiling it requires putting aside a writable partition on the embedded bbb device in it and that is far from trivial unfortunately and I'm not sure there is a set of instructions anywhere public to do that (and I've long since lost those instructions myself too). You can do it in RAM just fine: https://github.com/luke-jr/bfgminer/blob/bfgminer-4.5.0/README.ASIC#L145(pretty sure these steps should work for cgminer just as well) |
|
|
|
NEW VERSION 4.5.0, JULY 26 2014Human readable changelog:- bitforce: A new setup-vfio shell script is included to simplify configuring VFIO for Monarchs on PCIe.
- bitforce: Support for PCIe on Windows.
- cairnsmore, icarus, zeusminer: Per-core mining statistics support.
- gridseed: Ability to set clock speed via Manage TUI.
- hashfast: Include chip/core address in RPC procdetails.
- hashfast: Implement ability to change clock setting at runtime.
- rockminer: Allow setting clock 300-2560 as long as prefixed by "unsafe:".
- zeusminer: Support for the GAW War Machine.
- zeusminer: Ability to set clock speed via Manage TUI.
Full changelog:- Bugfix: zeusminer: Fix crash in TUI with newly introduced feature
- Bugfix: gridseed: Fix crash in TUI with newly introduced feature
- gridseed: Add the ability to set clock speed via the TUI
- bitforce: Support for Monarch devices on Windows using new "mswin" lowlevel interface to scan for KMDF driver
- Bugfix: gridseed: Implement a proper scanhash routine for GridSeeds
- zeusminer: Add the ability to set clock speed via the TUI
- Bugfix: gridseed: Only set PLL frequency once (not once per processor)
- Bugfix: zeusminer: Retry detection on failure - ZM fails detection 1 / ~30 times
- Bugfix: zeusminer: Enabling the ZeusMiner driver should flag needing lowl-vcom
- aan: Silence false warnings
- Include broad udev rules when configured with --enable-broad-udevrules option
- Bugfix: util: Lower the threshold for considering pool Scrypt diff broken
- Bugfix: gc3355: Do not send work_id (or anything) in the last 4 bytes of work
- gridseed: Refactor code to clean up and organize
- gridseed: Document GridSeed specifics with comments and URLs
- Copyright cleanups and updates
- Bugfix: zeusminer: using icarus timing can lead to false positive Idle detection
- zeusminer: Return the Chip # via the RPC API call procdetails
- zeusminer: Display the Chip # in the UI when viewing per-proc details
- Bugfix: miner: Check work->blk.nonce to see if work should be abandoned
- rockminer: Allow setting clock 300-2560 as long as prefixed by "unsafe:"
- util: Work around broken Scrypt pools automatically using realistic pdiff assumptions
- scanhash: Document scanhash related methods with comments
- Bugfix: gridseed: Report communication errors using dev_error()
- gc3355: Return bytes read to distinguish 0 bytes from error
- Bugfix: gridseed: Add delay between Scrypt reset and sending work
- gridseed: Bugfix: fix the constant used for estimated hash rates
- klondike: zero_stats support
- bitforce: zero_stats support (Temperature, Voltage, and Avg Wait)
- avalon: zero_stats support (temp_max, no_matching_work, match_work_count%d)
- Add driver interface for zero_stats function
- Bugfix: bitforce: Short-circuit bitforce_read(0) to avoid lowlif issues
- Bugfix: bitforce: Ensure data for the current command is always read (and only once), with lowl-pci
- Bugfix: setup-vfio: Add device ids to vfio-pci even if they didn't have a driver previously
- Bugfix: lowl-pci: Use volatile qualifier for PCI mmaps
- Bugfix: bitforce: Use lowlevel interface device was probed with, for actual mining
- setup-vfio: New shell script to automatically configure VFIO
- README.ASIC: Monarch: Need to do new_id for every affected device, and only after unbinding them
- README.ASIC: Monarch: Use shell variables for commands
- gridseed: Bugfix: Revert earlier changes to scanhash based on feedback
- hashfast: Support for changing clock at runtime
- hashfast: Store a copy of what we believe to be the chip configuration data
- hashfast: Store firmware revision
- util: pk_uNle macro for changing a number inside a packed structure
- README.ASIC: KnCMiner: Talk about additional i2c-tools dependency
- README.ASIC: KnCMiner: Remove mention of now-obsolete Bertmod
- README.ASIC: KnCMiner: Grammatical corrections
- Bugfix: RPC: Avoid processor-specific details in devdetails
- gridseed: Bugfix: log invalid detect responses as debug info, not an error
- zeusminer: Support setting clock via RPC API procset call
- README: Add Controla and Minera controller software links & info
- gridseed: Bugfix: Fix hash-rate calculation when no nonces are being found
- dualminer: Bugfix: assign the proper value for work_division
- gridseed: Refactor to clarify GridSeed terminology
- gridseed: Add support for displaying per-chip statistics
- gridseed: Convert to use newer set_device_funcs interface
- Bugfix: gridseed: Don't leak cgpu_info when devices are already claimed
- icarus: Processor detail support
- DevAPI: Allow using device_proc_by_id with const struct cgpu_info
- icarus: Ensure fpga_count is finalised before add_cgpu is called
- icarus: Move work_division autodetection code into new icarus_probe_work_division function
- icarus: Remove ability to change fpga_count at runtime
- Bugfix: gen-version.sh: Replace bashism ("here string")
- gridseed: Support devices with more than 255 physical processors
- Use `git describe` to generate version.h to avoid user confusion over builds from git
- zeusminer: Support devices with more than 255 physical processors
- hashfast: Include chip/core address in RPC procdetails
- gridseed: Reduce traffic sending work to GridSeed devices
- gridseed: Bugfix: previous refactor (unpublished) changed logic
- gc3355: Refactor to remove SHA2 code specific to the 5-Chip GridSeed Orb
- lowl-vcom: Bugfix: do not attempt to open the USB devices when enumerating
|
|
|
|
|
Note that unless the firmware issues were fixed (your 2 working ones look to be buggy still), you'll still need the workarounds in README.ASIC.
|
|
|
|
Undefined reference would mean you're trying to use a BFGMiner compiled with a newer version of libblkmaker, on a system that only has an older version of it. Copying the newer libblkmaker should work (it's backward compatible with stuff using older versions). |
|
|
|
|
Probably at least want the usbfs stuff so libusb-based drivers work.
|
|
|
|
FWIW, init-ng does everything important systemd does, but without the insanity...  |
|
|
|
|
Sounds pointless, since addresses should only ever be used once.
|
|
|
|
Luke-Jr, we've been running eloiopol to connect a pool to eligius, quite successfully (Thanks!) and have a few questions:
1) To connect to an upstream pool (ie eligius) the loop branch is required The loop branch was never finished and does not work completely. Use it at your own risk... - when stratum workers become disconnected, they don't want to reconnect without the human restarting miner software Be sure miners are using the latest version of BFGMiner. Unmaintained versions and forks thereof, my have bugs - those are however unrelated to Eloipool. Well. Maybe one more. I'm sure you've seen nomp's mining keys? What do you think of this idea and code? And, if you think that's a good idea, would that be something you'd have an interest in supporting in eloipool? (maybe a module that figures a pubkey from a miningkey and drops it into config.py?) Nope, no idea what you're talking about. I know you're not the biggest altcoin fan, but I can't see any reason you shouldn't earn something from pools using your software to mine them. (forrestv has something similar for --give-author in p2pool I've not seen how this works though) The sample config file has a Coinbaser example that donates. |
|
|
|
I would love to see BFG in the S3 and other hardware from the start instead of old forked cgminer versions that rot on the vine. Please encourage Bitmain to send a sample unit and docs. It's far more effective (for obvious reasons) for customers to ask for BFGMiner support than for devs. |
|
|
|
But bfgminer seems to have a problem with manicminer pool and it didn't seem to play nice with nicehash. Worked ok with coinking, but I noticed that the hashrates were a little strange....first 2 numbers were in the hundreds, last number was 23mhs. I'm running a Falcon/Thunder x3 and it's consistently running around 29mhs with cgminer. I was just trying to give bfgminer a shot due to the success others seem to be having with it. I don't seem to have that sort of luck it seems though  Try regular pools. As a rule of thumb, mult-pools don't work. This is not driver-specific. I never said it was driver-specific, just that it doesn't work with those pools. Coinking is also a multipool. So is there a programmatic reason that it doesn't work with certain pools while cgminer tends to not care and just works? BFGMiner has always had blockchain tracking code to minimise stale shares and avoid broken pools. As a side effect, it breaks when trying to use multiple blockchains - hence the warning in README. This has always been true of cgminer as well. So... when it "works", it's pretty much coincidence and could stop "working" at any time. |
|
|
|
Do you have any compilation instructions for how to build these images from source?
Not really, it is kind of a work in progress. Builing an entire OS like this is not for the feint of heart anyway. I do note though that I have FINALY got hidapi to work correctly on the raspberry pi! No more odd patches to get half of the bfgminer drivers working correctly  . Neil Wait, really? I thought Raspberry Pi had hardware issues with HID device O.o |
|
|
|
I got around the version.h by doing a git describe >>version.h. May not be the right way but it worked.
I'm surprised, that should break the build... Edit: I bet it immediately replaced yours |
|
|
|
cmp: version.h: No such file or directory It is still pointing to version.h This is expected on a fresh clone (or the first update since a few days ago). |
|
|
|
|
Show Posts
