Efudd Z-Series Fuddware 2.3 -Z11/Z11e/Z11j/Z9/Mini

[tahoeminer]

Update... I couldn’t be happier!

https://imgur.com/a/6G5YgxO

[1714635160]

1714635160

[1714635160]

1714635160

[1714635160]

1714635160

[Rooaraak]

I put my Z9 at 681 mhz and it wouldn't make it past 12 minutes.   I adjusted the frequency to 675 mhz and I have been running for 40 min at avg. sol sped of 59.26.  Im getting 62.45 sol currently.  Chip temps are at 69c/70c.... I have noticed that the machine LOVES under 72c.  I am pretty sure that the avg. will increase over the next hour or so.  Current temp outside where I live is 50f or 10c...I'm sure this helps too!  GREAT JOB JASON!

I hope this helps the group

Awesome -- you are doing better than mine did! My "good" z9 would do 681, but would not do 675! lol.... and you are getting the same/better sol at a lower wattage.

win!

-j

Can you help me on how to adjust frequency to 675 mhz. I would like to test it? Thank you!

[ltdray]

Hey, am i the only one Chain1 always crashing while overclocking? Is there a way to clock chain 2 and 3 only?

[efudd]

Hey, am i the only one Chain1 always crashing while overclocking? Is there a way to clock chain 2 and 3 only?

ltdray -

To answer your question, You are the only person I know of who was apparently unable to get even the lowest of frequencies working.

I thought you were going to downgrade to factory firmware since, if memory serves, you said yours does not even work at 550Mhz. I offered you a refund, and then it appeared your image was enabled at another location so I did not process the refund. Rather than jumping to a conclusion, I reached out to you via email to understand both the extra download as well as the other issues you were having.

I responded "I do not believe your machine can handle an overclock" after you sent me this message from your logfile "Sep 28 15:23:39 (none) local0.notice cgminer[21054]: recheck: chainid 0 exist 1 asicnum 0 realnum 16". That message, as best I can interpret it, states "the firmware was expecting 16 ASICs, but when trying to initialize it, none responded". I didn't have the full log, and just that single line from this event, so that is my best guess.

Where we last left our conversation, I told you that per the screenshot, you had not yet reloaded the factory firmware. I've since followed up with another email after that, but have not heard back.

Thank you,

Jason

[efudd]

Hey, am i the only one Chain1 always crashing while overclocking? Is there a way to clock chain 2 and 3 only?

ltdray -

To answer your question, You are the only person I know of who was apparently unable to get even the lowest of frequencies working.

I thought you were going to downgrade to factory firmware since, if memory serves, you said yours does not even work at 550Mhz. I offered you a refund, and then it appeared your image was enabled at another location so I did not process the refund. Rather than jumping to a conclusion, I reached out to you via email to understand both the extra download as well as the other issues you were having.

I responded "I do not believe your machine can handle an overclock" after you sent me this message from your logfile "Sep 28 15:23:39 (none) local0.notice cgminer[21054]: recheck: chainid 0 exist 1 asicnum 0 realnum 16". That message, as best I can interpret it, states "the firmware was expecting 16 ASICs, but when trying to initialize it, none responded". I didn't have the full log, and just that single line from this event, so that is my best guess.

Where we last left our conversation, I told you that per the screenshot, you had not yet reloaded the factory firmware. I've since followed up with another email after that, but have not heard back.

Thank you,

Jason

ltdray -- A full refund has been provided to the return address you gave me. I am sorry this did not work out for you. I honestly think you may have a hardware problem with the machine given the information provided. I would use the stock firmware and test on 500/550Mhz.

I will recommend, going forward, anyone wanting to use the full firmware, try the demo firmware first.

Thank you for your patience and if you happen to be able to figure things out with your machine, the overclock firmware I provided will still work, as my gift to you for  your patience and troubles.

Jason

[psychosunshine]

When overclocking, what chip temps would you guys consider to be too high?

I'm seeing 66°C to 67°C at 700 MHz.

Of course, I have my fan set at 100%

I wonder if the chip heatsinks are smaller on the Z9 than the Z9 Mini.

My temps on the Z9 Mini, at 750 MHz are about 63°C

If that's true.  To really overclock these. We would need to make a hardware modification and heatsink the chips better.

[badbart]

When overclocking, what chip temps would you guys consider to be too high?

I'm seeing 66°C to 67°C at 700 MHz.

Of course, I have my fan set at 100%

I wonder if the chip heatsinks are smaller on the Z9 than the Z9 Mini.

My temps on the Z9 Mini, at 750 MHz are about 63°C

If that's true.  To really overclock these. We would need to make a hardware modification and heatsink the chips better.

Stable at 700?  I can't get my miner past 650 without affecting performance or crashing.  I'm changing the frequency using awesome miner, is their a better way to do it?

[efudd]

When overclocking, what chip temps would you guys consider to be too high?

I'm seeing 66°C to 67°C at 700 MHz.

Of course, I have my fan set at 100%

I wonder if the chip heatsinks are smaller on the Z9 than the Z9 Mini.

My temps on the Z9 Mini, at 750 MHz are about 63°C

If that's true.  To really overclock these. We would need to make a hardware modification and heatsink the chips better.

Stable at 700?  I can't get my miner past 650 without affecting performance or crashing.  I'm changing the frequency using awesome miner, is their a better way to do it?

badbart, awesomeminer is simply automating editing the /config/cgminer.conf file. That's the simplest way to do it, and how I actually managed my Z series miners.

It may be that psychosunshine just has an exceptional set of ASICs.

-j

[efudd]

When overclocking, what chip temps would you guys consider to be too high?

I'm seeing 66°C to 67°C at 700 MHz.

Of course, I have my fan set at 100%

I wonder if the chip heatsinks are smaller on the Z9 than the Z9 Mini.

My temps on the Z9 Mini, at 750 MHz are about 63°C

If that's true.  To really overclock these. We would need to make a hardware modification and heatsink the chips better.

psychosunshine - I try to stay 75C or less, personally. So you are in good shape. These are not temp limited, but rather voltage limited on higher overclocks... although it's possible that with exceptional cooling, you can get away with higher frequencies.

This is all supposition, but there are more ASICs per board, a longer board, and the same fans, times 2 (well, i think thye are the same, I didn't verify). I think thermal management (heat dissipation in this case) may be more of a challenge on the Z9s vs. minis.

Those numbers are excellent though if you are getting that. I personally couldn't ever go over 681Mhz on any of mine. Good job!

-j

[psychosunshine]

It does appear that the heatsinks on the Z9 are different from the heatsinks on the Z9 Mini.

The heatsinks on the Z9 Full are one per 2 chips.  The Z9 Mini are 1 per chip.  It also appears to me, only from looking, not weighing.  That the heatsinks on the Z9 Full have smaller fins.  I didn't know Bitmain needed to worry about cost cutting.

Now, I'm thinking about removing the plate on the rear and adding another fan.  I'm not sure I want to change the heatsinks.  But, I know it would help.

Here are my most recent results.  It's only been 10 minutes, so we'll see.

https://i.imgur.com/vkdmGuu.jpg

https://i.imgur.com/dVl3QfJ.png

If anyone knows what I have to do to get these images to show up in my post, please let me know.

[efudd]

It does appear that the heatsinks on the Z9 are different from the heatsinks on the Z9 Mini.

The heatsinks on the Z9 Full are one per 2 chips.  The Z9 Mini are 1 per chip.  It also appears to me, only from looking, not weighing.  That the heatsinks on the Z9 Full have smaller fins.  I didn't know Bitmain needed to worry about cost cutting.

Now, I'm thinking about removing the plate on the rear and adding another fan.  I'm not sure I want to change the heatsinks.  But, I know it would help.

Here are my most recent results.  It's only been 10 minutes, so we'll see.





If anyone knows what I have to do to get these images to show up in my post, please let me know.

psycho, did you happen to count the # of fins on the heatsinks? By smaller, do you mean they are thinner fins? heat dissipation there is about surface area, so if htey increased fin count by making them thinner, it might be a neat gain.. but thermodynamics isn't my area of expertise.

[avi2]

Hey Efudd,
Any plans on making z9 mini custom firmware? a voltage mod would be nice.

[efudd]

Hey Efudd,
Any plans on making z9 mini custom firmware? a voltage mod would be nice.

@avi2 - no direct plans. I'd need a donor mini at a minimum to attempt. I need to get other features done first tho, I think.

[adrian5]

Hi Efudd,
could you please post a high resolution photo of the z9 hashing board?

[efudd]

Hi Efudd,
could you please post a high resolution photo of the z9 hashing board?

Unfortunately, I cannot. At this point my Z9 access is not physical but remote only.

-j

[efudd]

Hi all,

Based on community feedback, and taking into consideration the 25% tariff many of us had to pay, difficulty increases, etc., I have decided to add a single node option that is 25% less than the 2 node option (which has stayed the same).

This means for 25% less you can get up to 25% more (and those rare systems that can go well above 650Mhz can gain up to 50% more than factory... but this is _RARE_) for a single Z9; it is like adding a Z9 mini to your Z9!

Thank you,

Jason

[efudd]

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

[efudd]

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

[Crypto305]

Really appreciate your hard work.   I messaged you regarding the unlocked version I received.  As far as batch 1 z9.   I tried a little research of my own by taking the control board from my 750 hashing batch one mini and placing it on the batch 2 mini and the same issue existed where the hashing would go to zero after some time and could only handle 650 at times.  So not sure what they really changed with batch 2 as I assumed all config were stored on the control board.

Thanks

[efudd]

Really appreciate your hard work.   I messaged you regarding the unlocked version I received.  As far as batch 1 z9.   I tried a little research of my own by taking the control board from my 750 hashing batch one mini and placing it on the batch 2 mini and the same issue existed where the hashing would go to zero after some time and could only handle 650 at times.  So not sure what they really changed with batch 2 as I assumed all config were stored on the control board.

Thanks

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