I know this is a dead topic but its incomplete as the instructions are missing a step and I have been pulling my hair out for months (very part time) trying to get a firmware to load.
For anyone else looking how to do this the answer seems to be here but not specifying '-9' as the compression level for the gzip command:
https://groups.google.com/g/beagleboard/c/eMEPdEuAQjE?pli=1
I have been using the steps posted earlier with the gzip command like this to repack the firmware up:
find . | cpio -o -H newc > ../Angstrom-antminer_m-eglibc-ipk-v2013.06-beaglebone.rootfs.cpio
cd ..
gzip Angstrom-antminer_m-eglibc-ipk-v2013.06-beaglebone.rootfs.cpio
mkimage -n 'Angstrom-antminer_m-eglibc-ipk-v' -A arm -O linux -T ramdisk -d Angstrom-antminer_m-eglibc-ipk-v2013.06-beaglebone.rootfs.cpio.gz ../initramfs.bin.SD
cd ..
tar czvf Antminer-D3-myversion.tar.gz initramfs.bin.SD runme.sh am335x-boneblack-bitmainer.dtb
This should then generate the same file structure as you see in a working firmware image as before it was just putting the file system tree straight into the initramfs image.
Hope this helps someone and may work for newer miners but I havent got one yet as still working on a PoC
Thanks
Adam
Topic: Antminer D3 firmware testing (Read 3323 times)
what Linux you use?
can you update cgminer to 4.10 version?
can you update cgminer to 4.10 version?
I run arch linux
Ill look into updating to 4.10
thx d4nnthemanCould you tell me how to make it with firmware?
tar xvf to extract the tar
then use 7z to extract the .SD file
you should get a .cpio file use
Code:
cpio -idv < /tmp/object.cpio
to extract the cpio filemake sure you are root when you extract the cpio file
once its extracted you can replace any files in the firmware like cgminer the web pages ect.
to build the firmware
Code:
find . | cpio -o -H newc > ../Angstrom-antminer_m-eglibc-ipk-v2013.06-beaglebone.rootfs.cpio
cd ..
mkimage -n 'Angstrom-antminer_m-eglibc-ipk-v' -A arm -O linux -T ramdisk -d Angstrom-antminer_m-eglibc-ipk-v2013.06-beaglebone.rootfs.cpio ../initramfs.bin.SD
cd ..
tar czvf Antminer-D3-myversion.tar.gz initramfs.bin.SD runme.sh am335x-boneblack-bitmainer.dtb
make sure the first command is as root as wellcd ..
mkimage -n 'Angstrom-antminer_m-eglibc-ipk-v' -A arm -O linux -T ramdisk -d Angstrom-antminer_m-eglibc-ipk-v2013.06-beaglebone.rootfs.cpio ../initramfs.bin.SD
cd ..
tar czvf Antminer-D3-myversion.tar.gz initramfs.bin.SD runme.sh am335x-boneblack-bitmainer.dtb
I extracter the tar, used 7z to extract the .SD and i got the .cpio file. Then i extracted that one using the method u wrote.
I edited some web page files and wanted to repack everything again. Even using ur commands, i can't get it to work. The CPIO file gets a root folder name "." before all the files packed. The original firmware doesn't have that "." folder at the beggining. How can i pack all the files into the .cpio without that "." folder appearing first, like the original .cpio i extracted. am i missing something?
What you think, there are people out there that claims that have a firmware for D3 that can make diffrent a*go than x11,
is it might be possible to get from asics printed on silicon level to calculate different pow than x11?
modding and recompiling the cgminer? Hmm most unlikely possible.
Assume that is possible, then why then D3 is sold by Bitmain for 310$, why not unlock it? Or suddenly they care about killing a*goritms.
is it might be possible to get from asics printed on silicon level to calculate different pow than x11?
modding and recompiling the cgminer? Hmm most unlikely possible.
Assume that is possible, then why then D3 is sold by Bitmain for 310$, why not unlock it? Or suddenly they care about killing a*goritms.
Ya, not possible with software alone.. ASIC = application specific, meaning they burn the code to the chip itself, so there is no way to change
the underlying code of the chip. Others use FPGA (field programmable) which are able to be controlled by software (just write new code to chip)..
So what baikal either is doing is using FPGA and calling them asic's, or, are using asic's and burning all the different algo's onto the chip..
I'm guessing they are using FPGA's since they can "add" different algos in the future, which would not be possible with asic's alone.
Since x11 is 11 different algo's my attempt was to try to trick the d3 into doing just one of those over and over, there is something I am missing though - because it should be able to do each of the algos.. the problem seems to be whatever it is that is telling it to skip to the next algo in the sequence -(if the part that tells it to skip to the next one is on the chip itself then it probably can't be done-) I have not worked on it since my last post though because life reached up and slapped me in the face.
Ok I played with D3 till yesterday and my findings are :
I have modified xcoin.c to do just one algo, moreover, I have verified it with golden block in fn bitmain_scanhash my chosen algo, I have also changed the merkle root calc for my algo in gen_stratum_work....
but after that the i noticed the bad thing:
in DASH_work_fill is the answer that is impossible to do other algo!
there is filled the work on the asics ( through PIC ?? ) and the diff , the asics do the job and answers with good nonces(only) found and readen by cgminer in one common buffer which are sent to fn bitmain_scanhash and to famous Xhash() to be verifed on armv7, then with all info prepared and packed back to the stratum.
Game over then , unless if there is a way to set asic chain with registers with chosen algo or if the PIC is an actor in that. I doubt with D3 such performance speed that asics algo are selectable or the algo chain inside could be selectable in the burned asic pipe, whatever is the ant strategy.
So unless someone have saints in bitmain to have a clue how to change a chain on the (if the ants are designed in chain asic by algo or asic registers ) is dead end, D3 is x11 only for now.
What you think, there are people out there that claims that have a firmware for D3 that can make diffrent a*go than x11,
is it might be possible to get from asics printed on silicon level to calculate different pow than x11?
modding and recompiling the cgminer? Hmm most unlikely possible.
Assume that is possible, then why then D3 is sold by Bitmain for 310$, why not unlock it? Or suddenly they care about killing a*goritms.
is it might be possible to get from asics printed on silicon level to calculate different pow than x11?
modding and recompiling the cgminer? Hmm most unlikely possible.
Assume that is possible, then why then D3 is sold by Bitmain for 310$, why not unlock it? Or suddenly they care about killing a*goritms.
Ya, not possible with software alone.. ASIC = application specific, meaning they burn the code to the chip itself, so there is no way to change
the underlying code of the chip. Others use FPGA (field programmable) which are able to be controlled by software (just write new code to chip)..
So what baikal either is doing is using FPGA and calling them asic's, or, are using asic's and burning all the different algo's onto the chip..
I'm guessing they are using FPGA's since they can "add" different algos in the future, which would not be possible with asic's alone.
Since x11 is 11 different algo's my attempt was to try to trick the d3 into doing just one of those over and over, there is something I am missing though - because it should be able to do each of the algos.. the problem seems to be whatever it is that is telling it to skip to the next algo in the sequence -(if the part that tells it to skip to the next one is on the chip itself then it probably can't be done-) I have not worked on it since my last post though because life reached up and slapped me in the face.
What you think, there are people out there that claims that have a firmware for D3 that can make diffrent a*go than x11,
is it might be possible to get from asics printed on silicon level to calculate different pow than x11?
modding and recompiling the cgminer? Hmm most unlikely possible.
Assume that is possible, then why then D3 is sold by Bitmain for 310$, why not unlock it? Or suddenly they care about killing a*goritms.
is it might be possible to get from asics printed on silicon level to calculate different pow than x11?
modding and recompiling the cgminer? Hmm most unlikely possible.
Assume that is possible, then why then D3 is sold by Bitmain for 310$, why not unlock it? Or suddenly they care about killing a*goritms.
Ya, not possible with software alone.. ASIC = application specific, meaning they burn the code to the chip itself, so there is no way to change
the underlying code of the chip. Others use FPGA (field programmable) which are able to be controlled by software (just write new code to chip)..
So what baikal either is doing is using FPGA and calling them asic's, or, are using asic's and burning all the different algo's onto the chip..
I'm guessing they are using FPGA's since they can "add" different algos in the future, which would not be possible with asic's alone.
What you think, there are people out there that claims that have a firmware for D3 that can make diffrent a*go than x11,
is it might be possible to get from asics printed on silicon level to calculate different pow than x11?
modding and recompiling the cgminer? Hmm most unlikely possible.
Assume that is possible, then why then D3 is sold by Bitmain for 310$, why not unlock it? Or suddenly they care about killing a*goritms.
is it might be possible to get from asics printed on silicon level to calculate different pow than x11?
modding and recompiling the cgminer? Hmm most unlikely possible.
Assume that is possible, then why then D3 is sold by Bitmain for 310$, why not unlock it? Or suddenly they care about killing a*goritms.
Running into a really weird problem.. Stock cgminer runs at temps: 58 (pcb) 77 (chip)..
The 'newest' cgminer is running: 58 (pcb) 85 (chip)..
This is kind of interesting and disturbing at the same time.. What is bitmain doing to either lower the chips temp,
or are they just displaying a lower rate to make it seem as though its not running as high??
In any case, still playing around with it.. Don't really feel confident in giving it to others just yet based upon the
temps.. If the temps are just +8 and stable for a few days to a week running, I will feel better about getting it out.
The 'newest' cgminer is running: 58 (pcb) 85 (chip)..
This is kind of interesting and disturbing at the same time.. What is bitmain doing to either lower the chips temp,
or are they just displaying a lower rate to make it seem as though its not running as high??
In any case, still playing around with it.. Don't really feel confident in giving it to others just yet based upon the
temps.. If the temps are just +8 and stable for a few days to a week running, I will feel better about getting it out.
Hello,
nice to see you are still working on improve D3 performance.
If you have a Firmware to test i will do it.
BTW ... would be nice to think about modify cgminer for other algos
i think its possible
nice to see you are still working on improve D3 performance.
If you have a Firmware to test i will do it.
BTW ... would be nice to think about modify cgminer for other algos
i think its possible
Been playing around trying to see how easy/hard it actually is to adjust freq per board, but I don't have a D3 to play
with.. Would someone be willing to run a cgminer binary and post the log to see if indeed it is setting each board?
update:
I am guessing that ALL my compile warnings are making things really unstable while trying to run cgminer..
I am using Ubuntu and cross compiling with: CC=/usr/bin/arm-linux-gnueabihf-gcc CFLAGS="-O2 -march=armv7" ./configure --enable-bitmain-D1 --disable-libcurl --host armv7
but its spitting out a huge amount of warnings..
Are others experiencing the same issue??
If not, which distro are you running, and how exactly did you setup your compile environment?
update to update:
Installed arch linux in a vm, and all the errors I was experiencing while compiling in ubuntu are gone.. lesson learned..
I currently have frequency being set per each board along with voltage being set per board.. There is a slight problem with the frequency displaying
properly in the status page, but thats more down to how the api is getting/returning the stats from cgminer..
with.. Would someone be willing to run a cgminer binary and post the log to see if indeed it is setting each board?
update:
I am guessing that ALL my compile warnings are making things really unstable while trying to run cgminer..
I am using Ubuntu and cross compiling with: CC=/usr/bin/arm-linux-gnueabihf-gcc CFLAGS="-O2 -march=armv7" ./configure --enable-bitmain-D1 --disable-libcurl --host armv7
but its spitting out a huge amount of warnings..
Are others experiencing the same issue??
If not, which distro are you running, and how exactly did you setup your compile environment?
update to update:
Installed arch linux in a vm, and all the errors I was experiencing while compiling in ubuntu are gone.. lesson learned..
I currently have frequency being set per each board along with voltage being set per board.. There is a slight problem with the frequency displaying
properly in the status page, but thats more down to how the api is getting/returning the stats from cgminer..
Hello.. really strange problem.. Compile cgminer from sources..
All ok.. Its works, but when im get API call cgminer crash!
with
cgminer:
*** buffer overflow detected ***
cgminer-api:
Reply was ''
Where is the problem?
All ok.. Its works, but when im get API call cgminer crash!
with
cgminer:
*** buffer overflow detected ***
cgminer-api:
Reply was ''
Where is the problem?
anivff, did you ever figure out this issue?
beem working on so many other things I have not looked into this but at a guess notice that there is a cgminer-api binary in the same folder as cgminer on the machine. so I'm betting it has to do with that.. will get around to digging at it later if no one else does though it will be a whiiiiiile for me.
Hello.. really strange problem.. Compile cgminer from sources..
All ok.. Its works, but when im get API call cgminer crash!
with
cgminer:
*** buffer overflow detected ***
cgminer-api:
Reply was ''
Where is the problem?
All ok.. Its works, but when im get API call cgminer crash!
with
cgminer:
*** buffer overflow detected ***
cgminer-api:
Reply was ''
Where is the problem?
anivff, did you ever figure out this issue?
Hi, sorry to disturb you again, is necessary to recompile CGMiner to pass voltage controls?
Cheers W_M
[/quote
pre-coffee me here, but you know what? I never thought of that. "technically" the ability to pass voltage is "built in", so you "should" be able to do it with just the conf file. - I do not know this 100% as I have not tested it.
Cheers W_M
[/quote
pre-coffee me here, but you know what? I never thought of that. "technically" the ability to pass voltage is "built in", so you "should" be able to do it with just the conf file. - I do not know this 100% as I have not tested it.
Who can tell please, how i can open bitmain firmware and some change in there ?
Some script for ubuntu or what ? Help please
Some script for ubuntu or what ? Help please
tar xvf to extract the tar
then use 7z to extract the .SD file
you should get a .cpio file use
cpio -idv < /tmp/object.cpio
to extract the cpio file
make sure you are root when you extract the cpio file
Question what did I do wrong here....
7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)
Processing archive: initramfs.bin.SD
Error: Can not open file as archive
Nevermind .. think I got it.. seems (and if I am wrong please let me know) that I need to open the .SD file AS a cpio file and it extracts everything. not sure if there would be some header issues?? when putting it back together or not.
Is it possible to solo-mine to a wallet with this firmware or do you know of any way to do so with the D3? Thanks 
Wish I had found this thread earlier, reading through now... BUT this particular thing I know the answer to.
On all the newer bitmain stuff you can't mine directly to a wallet, older sha-256 you can. I'm not 100% sure on s9's since I
do not have one. That being said: --disable-libcurl <-- there is the issue. You can compile with disabling libcurl, but you get
errors if you leave it enabled. (I'm trying to look and see what the deal is there.. but libcurl is what is needed for it to accept
getwork and GBT which is needed if it directly connects to a wallet.)
I've been trying something on my own, but would have saved myself ages if I had found this thread earlier. hehe.
If I sort out what the deal is with libcurl I'll be sure to post something about it. I'm cross compiling as well and really
going through each problem by hand having never cross compiled anything before was... screamy-stabby-feeling.
I should search through topics more often. Hahaha.. but I have to admit I've learned alot so might have been worth it.
Anyone have fix for high rpm fans when there is no internet or connection to pool is lost ?
All the rest is working good.
Maybe and separate option for each board to control voltage and some kind of high temp protection.
So if it goes over 100% just to stop cgminer.
All the rest is working good.
Maybe and separate option for each board to control voltage and some kind of high temp protection.
So if it goes over 100% just to stop cgminer.
Hello.. really strange problem.. Compile cgminer from sources..
All ok.. Its works, but when im get API call cgminer crash!
with
cgminer:
*** buffer overflow detected ***
cgminer-api:
Reply was ''
Where is the problem?
All ok.. Its works, but when im get API call cgminer crash!
with
cgminer:
*** buffer overflow detected ***
cgminer-api:
Reply was ''
Where is the problem?
Hi, sorry to disturb you again, is necessary to recompile CGMiner to pass voltage controls?
Cheers W_M
from the code it looks like you need to if you look in the dash_init() in driver_btm_DASH.c the voltage with the stock FW is never set.Cheers W_M
listed out the changes now for you.
its literally just custom voltage and slowing the fans so far
its literally just custom voltage and slowing the fans so far
I have not tried this your FW, could your FW reboot if there is a "xxxx" error on the board? or MH / S (RT) reduced? If so, then too good.
If you develop it well, even if you charge a fee (just get one, I'm willing to support it). Do not like Blissz, charge life d3, I hate it
I am moving to San Diego so my development may be limited in the near future
Hi, sorry to disturb you again, is necessary to recompile CGMiner to pass voltage controls?
Cheers W_M
from the code it looks like you need to if you look in the dash_init() in driver_btm_DASH.c the voltage with the stock FW is never set.Cheers W_M
listed out the changes now for you.
its literally just custom voltage and slowing the fans so far
its literally just custom voltage and slowing the fans so far
I have not tried this your FW, could your FW reboot if there is a "xxxx" error on the board? or MH / S (RT) reduced? If so, then too good.
If you develop it well, even if you charge a fee (just get one, I'm willing to support it). Do not like Blissz, charge life d3, I hate it
I am moving to San Diego so my development may be limited in the near future
listed out the changes now for you.
its literally just custom voltage and slowing the fans so far
its literally just custom voltage and slowing the fans so far
I have not tried this your FW, could your FW reboot if there is a "xxxx" error on the board? or MH / S (RT) reduced? If so, then too good.
If you develop it well, even if you charge a fee (just get one, I'm willing to support it). Do not like Blissz, charge life d3, I hate it
Hi, sorry to disturb you again, is necessary to recompile CGMiner to pass voltage controls?
Cheers W_M
Cheers W_M
Jump to: