Howdy folk,

Just a quick update on progress. Addition of per-board frequency support is moving along, but a little slower than I would have liked. If anyone happens to have a spare Z9 control board, please let me know -- I'm looking to acquire one.

If anyone else is looking for Z9 firmware, I'll be online the next couple of hours for instant processing.

Thank you!

Jason

Biodom, are you using Awesomeminer to manage your miner by chance? There are some conditions in awesome miner as it manages these where the status page will no longer work and just be blank, yet the data can be returned from the API.

As far as the modified, my current version supports 500-650 in 5Mhz increments and also allows selection of 651-700 in 1Mhz increments all via the web page/pulldown.

-j

I released my Z9 hack basically the same day I got my Z9, so, unsure about the "hack coming out after z9 no longer great" -- if it did, it's cause of bitmain.

Yes sir. The primary dashboard will say "Version 1.1" if I remember what I wrote correctly. :-)

I'll try to update the download infrastructure soon to send a versioned filename to make this easier in the future.

-j

As of 10/2/2018 the download links for all unlocked firmware have been updated to an image that now supports 500-650 in 5Mhz steps, and 651-700 in 1Mhz steps. There is no guarantee that your machine(s) will work with these frequencies, they have just been exposed to make it easier on users.

Thank you,

Jason

Nod - ok. That was the conclusion I came to, different starting firmware.

Thank you.

-j

Ok. I will contact you.

Your patch is interesting.

It looks like you actually left the conditional check for a maximum of 550Mhz in place, and simply changed the result call which otherwise would force 500, to force what the user put in... it looks like you just copied the opcode at the end of the subroutine to the previous opcode to make both results the same.

In mine, I simply removed the conditional checks, leaving the result in place.

I'm trying to understand why your resulting cgminer is 28kB smaller than stock, however. Can you help me understand why that is the case? What else did you change?

-j

Going forward, I am available to work with commercial entities for consulting, customization, on all aspects of crypto-mining to help maximize profit margins. PM/DM to discuss details as I am still accepting commercial consulting clients for long-term working relationships.

Future updates will go to pre-existing customers, as promised.

Thank you,

Jason

I understand what they are talking about -- they responded to me with the same information last night. I asked another question in response and they replied immediately.

Thank you for the follow-up -- I'll see if I can throw together some basic instructions and get what we'd need pulled together.

I'll "add it to the list", lol!

-j

...and ship via DHL, not UPS. My UPS Z9s got hit with 25%, DHL ones just got 2.9%.

Batch1 minis, if you can find them at a good price, hash well, and overclock well.

The Z9s are pretty variable -- most will OC up to 650 ( and around 55-57kSol. Some will go up to 680-700 and get 60-62kSol... but those are the rare ones.
They are voltage limited.
(overclock for Z9: https://bitcointalk.org/index.php?topic=5036968)

-j

Ah, so at 1487W, you don't have much room power wise to push it more with the APW3. That's getting close to the power limits on that PSU. Hmmmm....

I responded to your PM re: unlock/Z9. My understanding, and note I never had a Z9 batch2+ myself - my 12 were all batch1, is that the Batch2s had a hardware change.  From the pictures I saw, my best guess is 2 VRMs (voltage regulation modules) were removed which limited the power distribution ability to the boards. Again, just a wild guess.

-j

Oh, adding to this, the firmware for Z9 and Z9 mini can be combined, I'm 98% confident. One piece would have be tested.

The primary difference between the Mini firmware and the Z9 firmware is a hard coded constant that limits the number of ASICs in a given chain initialized. Both the Mini and Z9 firmware are configured to start up to 4 chains (4 hashboards). The Mini is limited to bringing up 4 ASICs on each chain, while the Z9 firmware will bring up [at least] 16. At least in the Z9 firmware, it has hard coded limits to actually bring up *32* ASICs per chain -- I have not verified if that particular code is the same in the mini firmware.

Net-Net, with just one modification (and 1 test to make sure I'm correct), the Z9 mini firmware will run on the Z9.... and conversely, the Z9 modified firmware would run on the Z9mini. There are a couple of other places that I've flagged to check in the code just to be sure, but are possible conditions where  they have hard coded the number of ASICs. If that were true, then I'd simply have to add a configurable option and/or auto-detect (which is a slight challenge for a couple of reasons) the hardware.

Lastly, a short-cut to voltage regulation questions (I have spent literally 0 time looking at this in the disassembly yet) is to start with the batch1 Z9 mini firmware and evaluate the voltage handling vs. the later batches of mini firmwares and the Z9 large firmware.

I really have put real time/effort into this firmware beyond "greed" as at least one person has suggested.

... I would actually appreciate it if more people supported the Z9 firmware by getting the unlocked version, as it helps to fund research like this.


Thank you,

Jason

Yeah,I meant cgminer.conf, doh.

This will restart it through the command line: "/etc/init.d/cgminer.sh restart"

I expect the web interface, after changing to 415, will be blank (don't worry, if you select any other frequency and apply, it'll be back to the way it was) since the web interface is reading the frequency and doesn't have a match in the html for "415".. so it just shows blank.

Ok, so if the miner status page showed 415, that suggests this one is *NOT* factory locked on frequencies.

It's just a matter of figuring out how far it can be pushed... Thank you!

-j

Yeah, just something simple, pick any frequency that is NOT in the list on the web page, and change the '410' value to that freq. like, if 415 isn't listed, change 410 to 415. (I assume you know how to use vi? I'll try to describe the actual commands, one per line, just below this comment by pretending I'm editing it... Once that's done, run "/etc/init.d/cgminer.sh restart". All I'm looking to see is if the actual frequency changes to what you put in (like 415) or if it goes back to 410. The change will show up in the web interface with the regular miner stats.

SSH in, type these commands:
vi /config/cgminer.sh (hit enter)
/410
cw415 (Hit Escape)
:wq! (hit enter)

Then restart cgminer.sh

So that's literally typing 'c', then 'w', then '4', then '1', then '0', as if it was one word. no spaces, no enters, only, etc.

Thank you for helping as best you can!

-j

try root/admin

that's the default unless you change the password in the web server.

what frequencies are available by default?

Can you set a frequency other than the included ones via the browser/inspect or editing /config/cgminer.comf?

If so, I can move on, if not, I want get get the firmware and open it up.

-j

hashestohashes - I am unsure how I've thrown mud at another developer, and will fix it if I have. Please point me to it.

... as far as millions, don't we all wish...

I can't speak to the capabilities of others, but I spent a reasonable amount of time on my work (if others can do it faster, that is awesome!) and actually acquired licensed copies of IDA Professional and Hex-Rays ARM32 compiler to support this work, that alone cost $4100 USD plus tax. I also had to import a Z9, which after customs/taxes/shipping cost $4179. So before I even started the work, I was out $8279.

I've also spent numerous hours responding to email inquiries and PMs to provide support for installation, for overclocking, etc. I've spent a couple of hours this past week in 'teamviewer' helping another individual load on 8 machines....

I definitely didn't do this to "get rich". I only hacked this because I was frustrated that bitmain had locked 'my unit' after delaying it 3+ weeks.

-j

For posterity, here is how this was done.

A PE file has many segments in it (varies by file), like .data, .bss, .text ... .text is where strings are stored. From the .text segment, with a good disassemeblerwill break those out and point you back to the assembly for the function(s) that reference those strengths.

So, I started backward.

.text -> "frequency" -> function calling it. Then I spent some time exploring that function, it's callers and callees, and started mapping out the code path around it.

In that, I found the setup functions which took in the frequency and passed it down to a function I could readily tell was calld "set_frequency_chain". Using hexrays I was able to track that back to the fact it takes a chain and a frequency as an argument (as an aside...).

The fact that bitmain limited this to 2 frequencies made it easier than it should have been.  In the calling function, I found their 2 hardcoded constansts for 500 and 550.

Initially I just modified 550 to 650 (simplest byte changes), and realized it could do 650/500 -- that's basically what the free one is. 575+500.

The "paid" version is different in that the constants are not changed, but rather the conditionals that limit it are removed.
That allows you to pass anything you want down to set_frequency_chain.

Now, to enable per-board frequency control, we can continue from there.

That same set_frequency_chain has a calling function (this is about the per-board stuff) which bitmain neutered. Right now it iterates over 4 boards (a constant) and calls set_frequency_chain for eacho f those 4 boards with the frequency passsed in.

To enable per-board freuqency, that function calling set_frequency_chain needs to be completely rewritten and the binary patched. From some research papers, I found how how to add segments to a PE file (this wasn't possible a couple of years ago). So a new function can be written to read the config file, just reeanble finding/processing bitmain-freqX, then simply iterate over the number of boards and initialize each chain. The original iterator has to be skipped, so you have to jump into what you add, then jump back.

That'll enable freq-per-board. For bonus points, an API call can be added to enable calling bitmain_ZCASH_reinit_chain on a given chain if you change the frequency. That'll overload the 'reset' condition for a board to enable changing frequency on the fly.

Add some intelligence to tune the frequencies based on observations of the data in the system, and boom, you'll have a self-tuning, maximally overclockable image.

Some of these tactics will work for any cgminer reverse engineering activity.

Thanks,

Jason