|
Update:
Still working on this... was able to get through a hurdle that has had me blocked for the last couple of days today. Unfortunately a problem on the target board (with how bitmain has compiled their stuff) that I thought I had solved has reared its head. I was hoping to be able to put at least a picture of a system with hashboards at different frequencies tonight but it does not look like that is going to happen.
Will update as I can.
I apologize this next update is taking longer than I had hoped.
Jason
|
|
|
|
The only one on bitmain homepage:
Antminer-Z9-Mini-NAND-500M-201808311812.tar.gz
I tried both, keep settings and also unchecked it.
Did it several times and tried every combination.
the only tiny success:
installing batch 2 firmware --> change to turbo --> keep settings ---> install original firmware
Result: 550 frequency + working temperature sensor + working fan
sadly this trick does not work with batch 1 firmware and (e.g.) 650 frequency.
Keeping setting and reverting to batch 3 firmware resets the frequency to 500.
I expect batch3 firmware may be restricted to specific frequencies like the Z9 was (guessing, not verified).. If so, then it makes sense that it would reset back to 500Mhz. Jason |
|
|
|
Hello, I want to buy firmware for Z9. Write me in a personal message please
Responded. You have exceeded the limit of 1 personal messages per hour. Buying a Copper membership may increase your limit. I have responded to your email. |
|
|
|
Folk,
I wanted to post a quick update on the per-hashboard-frequency control modification (and associated functionality). The short version: no good progress as of 1:30AM Eastern on 10/13/2018.
The long version (which is a collection of random thoughts and probably won't make sense to many):
* Hardware was loaned to me (a Z9, thank you...) so I could continue some development work. This arrived on Wednesday.
* Since then I've been working on various methods to modify the firmware to extend functionality.
* The methods I normally would use for this are running into issues with bitmain's release. The basic gist is, it looks like they built things with gcc, and there is an issue I don't yet understand that prevents me from using my preferred method to extend functionality. If it were built with clang, this would be different...
* I've been at this more or less non-stop the last 36+ waking hours... and I'm going to take a break now....
* With some luck I'll have another good idea(s) on other ways to attack this... I've been through countless variations so far.
* The problem is not with knowing what to modify inside the firmware, it's with actually modifying things at run-time in system memory.
* The most challenging solution is: trace the hardware (via software and/or external devices), reverse engineer the hardware communications and extend public sources to support this BM1704 and PICF16704... the -DASH variant firmware has an older incarnation of the PIC control code... yet the comms endpoints are not correct.
* ... lots of other thoughts, but gonna pause for now.
What's next?
* Hopefully I get another good idea at attacking a highly esoteric problem...
* ... I have lots of improvement ideas for the firmware; things that would apply to all Z series and even future miners... but I must break through the current roadblock to get to any of those things.
More soon(ish).
Thank you,
Jason
Small update -- I got through the "wall" I was banging my head against when I wrote this update. I'm now "climbing the hill", which means slow but steady progress. I have a couple of infrastructure pieces to complete that are the more challenging components, and then I should be able to make some quick progress towards the per-hashboard frequency management. More soon. -j |
|
|
|
Hello, I want to buy firmware for Z9. Write me in a personal message please
Responded. |
|
|
|
Hi guys I did anything that You told, but it is not overclocked.
1:https://pasteboard.co/HIk6hcW.jpg
I changed value from 500 to 668 in
/www/pages/cgi-bin/minerAdvanced.cgi
2:https://pasteboard.co/HIk6ZaM.jpg
But is not changed in status
3:https://pasteboard.co/HIk8RnP.jpg
How should I do?
Info about firmware versions and link to may 26 2018 firmware from batch 1: https://bitcointalk.org/index.php?topic=4610213.msg45735658#msg45735658"May 26 firmware: File: Antminer-Z9-Mini-201805262047-500M.tar.gz sha-1: 8791eee569dfff728c8363e5d8fd93f68957a2ee https://ufile.io/cwnf6 (New link - Uploaded 10 october 2018) (This link goes to the May 26 firmware which I've shared at Uploadfiles.io and should work for 30 days from october 10, 2018!)" If you check this link that is in the posting before yours you can read that aug 30 and aug 31 firmware versions does NOT work to change the way you tried. If you download may 26 firmware in link above and install you can use the web-interface like God intended and choose your desired frequence as everyone with a batch 1. Try with 668 MHz if batch 2. If problem go down to 637 MHz to try to find stable overclock. Good luck! Z9 mini, stock firmware, will be permanently available at: http://releases.broked.net/antminer-z9-mini-201805262047-500m.tar.gzYou can find it by going to http://releases.broked.net if you do not remember the name. Thank you. Jason |
|
|
|
|
Folk,
I wanted to post a quick update on the per-hashboard-frequency control modification (and associated functionality). The short version: no good progress as of 1:30AM Eastern on 10/13/2018.
The long version (which is a collection of random thoughts and probably won't make sense to many):
* Hardware was loaned to me (a Z9, thank you...) so I could continue some development work. This arrived on Wednesday.
* Since then I've been working on various methods to modify the firmware to extend functionality.
* The methods I normally would use for this are running into issues with bitmain's release. The basic gist is, it looks like they built things with gcc, and there is an issue I don't yet understand that prevents me from using my preferred method to extend functionality. If it were built with clang, this would be different...
* I've been at this more or less non-stop the last 36+ waking hours... and I'm going to take a break now....
* With some luck I'll have another good idea(s) on other ways to attack this... I've been through countless variations so far.
* The problem is not with knowing what to modify inside the firmware, it's with actually modifying things at run-time in system memory.
* The most challenging solution is: trace the hardware (via software and/or external devices), reverse engineer the hardware communications and extend public sources to support this BM1704 and PICF16704... the -DASH variant firmware has an older incarnation of the PIC control code... yet the comms endpoints are not correct.
* ... lots of other thoughts, but gonna pause for now.
What's next?
* Hopefully I get another good idea at attacking a highly esoteric problem...
* ... I have lots of improvement ideas for the firmware; things that would apply to all Z series and even future miners... but I must break through the current roadblock to get to any of those things.
More soon(ish).
Thank you,
Jason
|
|
|
|
Interested in the firmware, could you PM me
Will pay you in Zcash. PM me your address.
Responded. |
|
|
|
I am certain I do not have the batch 1 and I am at 650, I was unable to use the firmware to change frequency so I used awesome miner.
Translation, and please feel free to correct me: You were unable to change frequency via the web interface, so you used awesome miner to change the frequency for you. Behind the scenes, awesomeminer modifies /config/cgminer.conf to set the frequency and restarts cgminer to make that frequency take effect. I didn't say "only on batch1 hardware", I said "batch1 firmware". anyway. -j |
|
|
|
you can use Awesome miner to Overclock the batches that do not have it built in.
Only if the firmware supports it -- all awesomeminer does in this scenario is configure /config/cgminer.conf. This works best, as far as I am aware, with batch1 firmware installed. -j |
|
|
|
|
Orders today (10/08/2018) will be processed after 5:00PM Eastern time (GMT-4).
Thank you,
Jason
|
|
|
|
|
Folk,
Just a status update -- I have more hardware on the way so I can test and continue development on the per-hashboard overclock feature. I'm hoping to complete in in 24-48 hours after the hardware I have been waiting on arrives (maybe thursay/friday?). *IF* that all pans out, I should be able to add that feature to a firmware for the Z9 mini, also.
Thank you all for the support,
Jason
|
|
|
|
I'm unsure if the 16F1704 fits into what was used on the A3 or not.
A3 and L3+ have same 16F1704, also as z9m. May be it has another adreses, or something else made another. You investigated z9 big. Is there same VRM scheme as on z9m? Are somebody can make good photos of A3 and L3+ hash plate? Ah, ok. That helps a ton then -- I have another Z9 large coming in this wednesday (I'm without hardware at the moment) and can investigate then. -j |
|
|
|
...snip...
Does yours also state in the kernal log about - -
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic)
And
nand: WARNING: pl35x-nand: the ECC used on your system is too weak compared to the one required by the NAND chip
Bad block table found at page 131008, version 0x01
I don't have a dr3, just trying to see if there's a underlying issue
Those messages are fine and can be ignored. The set_temperature_offset_value_chain_sensor() is simply a function that is called associated with auto-fans. Try manual fans at 100% and see if it helps. |
|
|
|
Hello dear freind. I glad to hear your again! You may be right, but I asked about little another. There are present code for control voltage via 16f1704 on github, made by darval: set_voltage_new (v0.3): https://github.com/darval/bitmain-tools/releases/tag/v0.3But I need compiled binary file for this code which not present there. I'm beginer in Linux and cann't compile it myself - something do wrong. Can somebody show me right commands for compile c code to binary, using Linux inside Asic? I would love to help, but at the moment I do not have an ARM environment to compile in. I just checked the code there and it does not mention 16f1704 at all... instead it is an attempt at a generic implementation that covers multiple PICs. I'm unsure if the 16F1704 fits into what was used on the A3 or not. -j |
|
|
|
Hello All!
Does somebody have last version of binary from darval: set_voltage_new (v0.3) which can work with 16f1704 in both protocols?
I didn't find it on github.
Pls, put here or in PM.
I do not think anything exists yet for the 16F1704, but I welcome correction. That is one of the things I'm hoping to work on soon. -j |
|
|
|
Has anyone experienced problems running 650 mhz and up on the standard bitmain provided awp3 psu? The 1370 watt drawn at 650 mhz seems disturbingly close to the 1600w max on the psu since 1600 x 0,8 = 1280.
zeric, perhaps others will provide some input. I tested on APW7 and APW3s, both at 240V. I also considered the "80 percent" rule -- in fact, higher overclocks, if possible, may require the APW7 as you have pointed out. In my particular environment I monitored equipment with a thermal imaging camera and never found the APW3 to be outside of what I would have been worried about. Are you experiencing problems, or just a question of concern? Regardless, I think this is an excellent question. Jason |
|
|
|
Just a quick update on progress. Addition of per-board frequency support is moving along...
REALLY looking forward to this. I have one ASIC where one board runs 10 degrees higher than the other two. Has anybody tried re-pasting the heat-sync or something to try to lower temps? I have a couple that are 10 degrees higher than other boards. No idea why What temps are ya'll hitting? Still 75C or under even with the higher one? |
|
|
|
Just a quick update on progress. Addition of per-board frequency support is moving along...
REALLY looking forward to this. I have one ASIC where one board runs 10 degrees higher than the other two. Has anybody tried re-pasting the heat-sync or something to try to lower temps? xPETEx - I'm literally _currently_ working on this. I'm awaiting on some hardware to arrive for testing but am really hoping to get this closed out early next week at the latest. It'll have huge value to all users! Pray, keep fingers crossed, whatever it is you do for success. :-) |
|
|
|
using this : antminer-z9-mini-201805262047-500m.tar.gz my miners are OC-able and have no problem with temp readings, just FYI
are you saying you used the mini firmware on the non-mini and it worked? It will not work properly. It will only initialize 4 of the 16 ASICs. Otherwise, yes, the mini firmware will work on the Z9, just not to potential. -j |
|
|
|
|
Show Posts
