Search content
Sort by
Showing 3 of 3 results by dlethe
Re: Antminer D3 firmware modification thread (voltage & fan mods)
Let me make this clear, changing to a different algorithm is NON-TRIVIAL, but doable.
It is a deal-killer if the published source code isn't ALL the source code to the miner application. For all I know there are some other daemons that are not published, that get in, get out at boot time, or at other intervals that modify the miner logic. (That is what I would do, so I would be surprised if bitmain didn't do the same thing).
So anybody who has worked with that source code .. have you tried to compile the published code, and do you end up with the same binary?
How do you ssh into the kernel? Does published source code exist for everything?
It is a deal-killer if the published source code isn't ALL the source code to the miner application. For all I know there are some other daemons that are not published, that get in, get out at boot time, or at other intervals that modify the miner logic. (That is what I would do, so I would be surprised if bitmain didn't do the same thing).
So anybody who has worked with that source code .. have you tried to compile the published code, and do you end up with the same binary?
How do you ssh into the kernel? Does published source code exist for everything?
Re: Antminer D3 firmware modification thread (voltage & fan mods)
Well, i studied the source code. Assuming that the source code is complete and this is the ONLY program that interfaces with those 80 microcontrollers then yes, absolutely it is possible to change the algorithm. (But there are limits due to the tiny amount of RAM and flash RAM on each processor)
But here is the deal. It is a pain. I'd have to get some development hardware to facilitate this, and probably brick a D3 (or two) in the process.
The big caveat, as a first step, is to be 100% sure that the code you referenced is the actual code that is running, and there are no undocumented daemons running that interact with the micro controllers.
So here is the test.. Can you recompile the unmodified software and get same checksum and binary? (Note, you may have to set some compile flags to match any __DATE__ type macros. My concern is that we really don't have all the code for the mining software in GitHub.
Here is the other concern. Bitmain could easily put in a sorta poison pill in a later firmware update (or for all I know, one of the programs that is already running under their LINUX O/S is listening for a internet-based kill switch that can make reprogramming the D3 to use different algorithm impossible). So anything further on the subject would be unwise.
Suffice to say, I know what I am doing, and I am intrigued by the possibility (I have 2 x D3s). Now some algorithms are totally impractical for this hardware, and it is way too early for me to commit to spending more time on it.
I also see some opportunities to improve and optimize the code so it will take fewer clock cycles to crunch, and/or do more crunching in the same amount of time. I don't know whether it would be significant w/o profiling and that would be a pain. There is very little code written in assembly language.
Anyway, no commitment, but I am awaiting word whether or not a straight recompile gives us the same binary the latest firmware is running.
But here is the deal. It is a pain. I'd have to get some development hardware to facilitate this, and probably brick a D3 (or two) in the process.
The big caveat, as a first step, is to be 100% sure that the code you referenced is the actual code that is running, and there are no undocumented daemons running that interact with the micro controllers.
So here is the test.. Can you recompile the unmodified software and get same checksum and binary? (Note, you may have to set some compile flags to match any __DATE__ type macros. My concern is that we really don't have all the code for the mining software in GitHub.
Here is the other concern. Bitmain could easily put in a sorta poison pill in a later firmware update (or for all I know, one of the programs that is already running under their LINUX O/S is listening for a internet-based kill switch that can make reprogramming the D3 to use different algorithm impossible). So anything further on the subject would be unwise.
Suffice to say, I know what I am doing, and I am intrigued by the possibility (I have 2 x D3s). Now some algorithms are totally impractical for this hardware, and it is way too early for me to commit to spending more time on it.
I also see some opportunities to improve and optimize the code so it will take fewer clock cycles to crunch, and/or do more crunching in the same amount of time. I don't know whether it would be significant w/o profiling and that would be a pain. There is very little code written in assembly language.
Anyway, no commitment, but I am awaiting word whether or not a straight recompile gives us the same binary the latest firmware is running.