Pages:
Author

Topic: Efudd Z-Series Fuddware 2.3 -Z11/Z11e/Z11j/Z9/Mini - page 33. (Read 45536 times)

member
Activity: 504
Merit: 51
Folk,

This is hopefully the last update before the release. The firmware images are ready for both the Z9 as well as the mini, but I am working to resolve on piece of infrastructure before I can release the image. That should be done sometime later today.

There will be two images available, one for the Z9s and one for the Z9 minis. In a later release I will merge these two images, but for now they are still separate (you will find a pull down in the "General Settings" page to select which miner type you are running the image on, it just does not function for this next release.

The Paid user and Dev-Fee user image is the same. It will take me a few days to get the license files out to the paid users, so in the interim, I will be disabling dev-fees (except for the very first 10 minute cycle) until I can get the license files packaged up (they have been created, I just need to package them up).

What this means is if you are a paid user or a dev fee user, this next image is the one for you. On the System->Upgrade page there is an option to "Upload License upgrade file" for paid users to add a new license without having to reinstall the image.

From a feature perspective, this image includes the fully unlocked frequencies and the per-hashboard overclock for both dev-fee and paid users. However, there is much more going on behind the scenes as this is a major infrastructure release.

The "Summary" page will dynamically update to inform you if there is a new image available and provide a direct download link, as well as "live" updates as to the status of features.
The summary page also will include a "Support ID" that will be unique to your system -- it will help us work together to resolve any issues or questions that may arise.
There is more, I'm sure, and pictures will do a lot of justice, but for now these words will have to suffice.

For dev fee users, I will be adjusting the dev-fee as we go to decrease it over time, as well as disable it on some occasions ("dev fee free weekend" for example, where no developer fees will be taken over 2-3 days).

A couple of folk have asked "What if I have a batch1 mini, why would I use your firmware?" -- I don't have a good answer for you on that as the initial mini release is not targeted to increase your hashrate by 400%. That said, with the per-hashboard overclocking abilities, I have been able to squeeze another 5-10% out of batch2 systems in test. Your individual mileage will vary and I encourage discussion so we can figure out what works best for all of us.

After this release I am focused on hardware aspects; specifically getting control over the fan, temp, and hopefully voltage. I've put a number of hours into research and testing on those aspects and now have some confidence in my understanding of how the controls currently work -- its just a matter of me getting control over them now.

Lastly, a quick update on nicehash support -- I've spent a few more hours looking at this and have been in touch with nicehash on the issue. I think I have a pretty good understanding as to what is going on now, but it is going to take some time to fix (I have to recalculate the nonce/share submission on the fly it looks like and I simply do not know how to do that just yet). Nicehash is trying to work with me, but the ball is in my court at the moment and I just need to "get the time" to work with them.

A quick teaser image -- all of the text for the license, support ID, upgrade, message, and summaries at the top are dynamic. I will use those features to stay in communication with the user base more directly as many folk have raised concerns that they do not read the forums all the time and were not aware of updates.




Thank you,

Jason
jr. member
Activity: 559
Merit: 4
i have first batch z9mini hashing 750Mhz stable for months. may i ask what benefits have your firmware about bitmains from batch 1?

thanks

my batch 1 minis run best at 762mhz batch 4 at 737
jr. member
Activity: 169
Merit: 1
i have first batch z9mini hashing 750Mhz stable for months. may i ask what benefits have your firmware about bitmains from batch 1?

thanks
newbie
Activity: 13
Merit: 0
It is very likely that the mini variant will be released at the same time. I've got an image for the mini under test now as well.
Awesome, can’t wait!  Grin you rock Jason!
member
Activity: 504
Merit: 51
Quick update:

Z9 paid and dev fee firmware is effectively complete. I'm running another test over night and need to get the license files together for paid users, plus write instructions, and get this post updated. It's 12:14AM Monday now, so I'll be able to release it this evening I'm hoping.

It is very likely that the mini variant will be released at the same time. I've got an image for the mini under test now as well.

Thank you,

Jason
jr. member
Activity: 559
Merit: 4
I get it. Check if there are any buffer input circuits between the contact of the plug and the io chip. Maybe something can be replaced there.

it is direct to io on chip only thing in between on the line is a resistor it checks ok. One thing it the fan don't read on fan 2 connector either somehow internally they are on same io or it blew more in the cpu then I first assumed. I solved my problem with a batch 4 mini fan I had to replace the controller of course the new one I hooked the fan to fan2 and built a variable fan simulator with a LM555 and variable 5k resistor and a 1.0uf capacitor. I set the simulator for 6000 rpm and it is fine with the exception of the temps not reading right so I still have the fault light. No biggy it is up and going at almost 16k/sol. To lower the fan speed I removed the PWM line from the board and tied it to ground thru a 100k variable resistor done on the fan side not board side
newbie
Activity: 24
Merit: 1
I get it. Check if there are any buffer input circuits between the contact of the plug and the io chip. Maybe something can be replaced there.
jr. member
Activity: 559
Merit: 4

I'm not claiming to be the best at this by any means, but I've spent more than a handful of hours on that so far without the progress I was hoping for. The checks would be easy enough to disable (although it is interwoven in a main thread)... but what I really want to do is gain control over them. I now know how the firmware communicates with things like the fan at least, and I've got an indication of "where"... anyway, figuring out the fan bits is next on my list due to requests after the next version drops later today.

Perhaps my information will be useful to you.
I know how to tell the control board that the fan speed is normal.

It is necessary to disconnect the 3rd and 4th contacts of the plug from the fan and to close these contacts on the connector between them. Then the control board will receive information that the fan speed = 30600.   This is the frequency of the fan control pulses.

  Connect the fan only by applying 12V power to it and its rpm control
It works on  at least 1,2,3 and 4 batch. It was tested in practice.

tried it I am sure I burnt the io on the chip because no matter what I try to get past the rpm the controller  doesn't recognize the rpm pulse  tried pulling hi then drop low etc all trouble shooting leads to a burnt io on chip
newbie
Activity: 24
Merit: 1

I'm not claiming to be the best at this by any means, but I've spent more than a handful of hours on that so far without the progress I was hoping for. The checks would be easy enough to disable (although it is interwoven in a main thread)... but what I really want to do is gain control over them. I now know how the firmware communicates with things like the fan at least, and I've got an indication of "where"... anyway, figuring out the fan bits is next on my list due to requests after the next version drops later today.

Perhaps my information will be useful to you.
I know how to tell the control board that the fan speed is normal.

It is necessary to disconnect the 3rd and 4th contacts of the plug from the fan and to close these contacts on the connector between them. Then the control board will receive information that the fan speed = 30600.   This is the frequency of the fan control pulses.

  Connect the fan only by applying 12V power to it and its rpm control
It works on  at least 1,2,3 and 4 batch. It was tested in practice.
member
Activity: 504
Merit: 51
...snip...
These batch 4 units are being shipped to the USA thru Ebay and Amazon. I agree I am lost some in this disassembly. It has been a few years since I had to deal with coding got too old and cant see well enough to do it much anymore. The fan and PWM checks are the ones I am having a bit of a problem locating to disable for this unit. The pwm line is ok it is just the rpm line that seems to not be working correctly or even if I can change the min rpm from 1440 to 0 and set the check to continue if the fan rpm is 0. if I can disable this then I can at least mine with it until I get a new controller board this week

I'm not claiming to be the best at this by any means, but I've spent more than a handful of hours on that so far without the progress I was hoping for. The checks would be easy enough to disable (although it is interwoven in a main thread)... but what I really want to do is gain control over them. I now know how the firmware communicates with things like the fan at least, and I've got an indication of "where"... anyway, figuring out the fan bits is next on my list due to requests after the next version drops later today.

Jason
jr. member
Activity: 559
Merit: 4
one thing I noticed is that if the fan is set too low manually on the mini batch 4 the machine will cut speed back accordingly. So if the controller sets the fan to say 4500rpm and you drop it too low the speed will reduce. The batch 4 mini's need a fan simulator and other hw mod to fan to run batch 1 firmware unless you don't mind the fan running 100%

What do you mean "cut speed back accordingly"? Are you saying the frequency and hashrate drops?

Otherwise, I would not expect a "fan simulator" to not act any different than a regular fan in the condition you have described.

Another point on the "batch 4 minis" is that I believe their availability is only mainland china?

-j

If cgminer wants the fan to run at a certain rpm and you lower it below what it is expecting the hashrate will drop and eventually goto 0. The batch 4 mini I have been playing with runs in fault mode because of the coding for the temp. When I manually lower the fan to say 5000 rpm from the 5880 it sets due to the fault the hashrate will drop until I bring the fan back to the 5880 rpm. Personally fan checking should be disabled to get around any issues with a fan simulator or the fan itself. I tried bypassing the checking but failed on my first attempt cgminer wouldn't even load. I screwed my board now it wont detect the fan rpm no matter what the circuit is good so I figure playing with it killed it on the processor but I did try a v9 controller and same issue with fan runs at full on the batch 4

these fans default to full speed when first kicked up unless specifically slowed down.
I'm unsure how you are "lowering the fan speed" when "cgminer wants the fan to run at a certain rpm".
And what do you mean "runs in fault mode"? What is the exact error(s)? Where is this "fault mode" seen?
where in cgminer did you try to "bypass the checking"? This one is different than the ones in the past.
What do you mean "cgminer wouldn't even load"? Do you mean you damaged the binary trying to modify it?
How did you "screw your board"? There is not a single software related activity that should "Screw a board".

Your response just creates a ton of questions.

Jason

On the batch 4 with batch 1 firmware the temps don't report on 2 of the hash boards. So because of this the fault light comes on and the fan is set to full speed. If I use a fan simulator or reduce the fan speed thru the PWM line the rpm must be reported as at least 5880 which is what the machine set the fan at due to the fault light if the simulator or fan don't report 5880 or higher cgminer will lower the hash rate and even drop to 0 this seems to be based off the rpm the lower the rpm the lower the hash rate the higher the rpm towards the 5880 the rate picks up. So if I leave the fan run full rpm it hashes away just fine at full hash rate. This could be due only to the fault being triggered by the non-reporting of the temps correctly.  I am waiting for another controller so I can play with it some more. I don't know why this one lost detecting the fan rpm and so far I haven't been able to disable this feature of cgminer. cgminer at startup wants to check the fan rpm and monitors it for any rpm below 1440.

I screwed the input on the board when I shorted it out moving a fan simulator. The error I get is no fan detected and loops on a fan check. Fault is seen in kernel log. Yes I screwed the binary modding it simple fix was reload firmware. Used pwm line to play with fan speed a 100k variable resistor between it and the gnd will vary fan speed. Unhooked pwm line from controller to assure no contact between gnd and controller side of pwm. The processor itself is not detecting any rpm signal. Checked the resistors they test ok so only other thing could be burnt the input on the processor. If I can get past the fan check it will mine just fine so basically I need the fan check and monitor to look for 0 rpm so it will continue to load and hash

fan pwm is checked against rpm and rpm is checked against fan pwm. if those checks fail, the pic is disabled.

i think you are analyzing that section of the disassembly incorrectly.

i also think you may be off base with your understanding of "batch4 with batch1 firmware" and why you are not getting lights you expect also... .and I expect the light blinking issue is easily resolved. but i'm probably not going to spend any time with batch4 minis since they were not distributed outside of china as best i am aware.

goodluck.

jason

These batch 4 units are being shipped to the USA thru Ebay and Amazon. I agree I am lost some in this disassembly. It has been a few years since I had to deal with coding got too old and cant see well enough to do it much anymore. The fan and PWM checks are the ones I am having a bit of a problem locating to disable for this unit. The pwm line is ok it is just the rpm line that seems to not be working correctly or even if I can change the min rpm from 1440 to 0 and set the check to continue if the fan rpm is 0. if I can disable this then I can at least mine with it until I get a new controller board this week
member
Activity: 504
Merit: 51
one thing I noticed is that if the fan is set too low manually on the mini batch 4 the machine will cut speed back accordingly. So if the controller sets the fan to say 4500rpm and you drop it too low the speed will reduce. The batch 4 mini's need a fan simulator and other hw mod to fan to run batch 1 firmware unless you don't mind the fan running 100%

What do you mean "cut speed back accordingly"? Are you saying the frequency and hashrate drops?

Otherwise, I would not expect a "fan simulator" to not act any different than a regular fan in the condition you have described.

Another point on the "batch 4 minis" is that I believe their availability is only mainland china?

-j

If cgminer wants the fan to run at a certain rpm and you lower it below what it is expecting the hashrate will drop and eventually goto 0. The batch 4 mini I have been playing with runs in fault mode because of the coding for the temp. When I manually lower the fan to say 5000 rpm from the 5880 it sets due to the fault the hashrate will drop until I bring the fan back to the 5880 rpm. Personally fan checking should be disabled to get around any issues with a fan simulator or the fan itself. I tried bypassing the checking but failed on my first attempt cgminer wouldn't even load. I screwed my board now it wont detect the fan rpm no matter what the circuit is good so I figure playing with it killed it on the processor but I did try a v9 controller and same issue with fan runs at full on the batch 4

these fans default to full speed when first kicked up unless specifically slowed down.
I'm unsure how you are "lowering the fan speed" when "cgminer wants the fan to run at a certain rpm".
And what do you mean "runs in fault mode"? What is the exact error(s)? Where is this "fault mode" seen?
where in cgminer did you try to "bypass the checking"? This one is different than the ones in the past.
What do you mean "cgminer wouldn't even load"? Do you mean you damaged the binary trying to modify it?
How did you "screw your board"? There is not a single software related activity that should "Screw a board".

Your response just creates a ton of questions.

Jason

On the batch 4 with batch 1 firmware the temps don't report on 2 of the hash boards. So because of this the fault light comes on and the fan is set to full speed. If I use a fan simulator or reduce the fan speed thru the PWM line the rpm must be reported as at least 5880 which is what the machine set the fan at due to the fault light if the simulator or fan don't report 5880 or higher cgminer will lower the hash rate and even drop to 0 this seems to be based off the rpm the lower the rpm the lower the hash rate the higher the rpm towards the 5880 the rate picks up. So if I leave the fan run full rpm it hashes away just fine at full hash rate. This could be due only to the fault being triggered by the non-reporting of the temps correctly.  I am waiting for another controller so I can play with it some more. I don't know why this one lost detecting the fan rpm and so far I haven't been able to disable this feature of cgminer. cgminer at startup wants to check the fan rpm and monitors it for any rpm below 1440.

I screwed the input on the board when I shorted it out moving a fan simulator. The error I get is no fan detected and loops on a fan check. Fault is seen in kernel log. Yes I screwed the binary modding it simple fix was reload firmware. Used pwm line to play with fan speed a 100k variable resistor between it and the gnd will vary fan speed. Unhooked pwm line from controller to assure no contact between gnd and controller side of pwm. The processor itself is not detecting any rpm signal. Checked the resistors they test ok so only other thing could be burnt the input on the processor. If I can get past the fan check it will mine just fine so basically I need the fan check and monitor to look for 0 rpm so it will continue to load and hash

fan pwm is checked against rpm and rpm is checked against fan pwm. if those checks fail, the pic is disabled.

i think you are analyzing that section of the disassembly incorrectly.

i also think you may be off base with your understanding of "batch4 with batch1 firmware" and why you are not getting lights you expect also... .and I expect the light blinking issue is easily resolved. but i'm probably not going to spend any time with batch4 minis since they were not distributed outside of china as best i am aware.

goodluck.

jason
jr. member
Activity: 559
Merit: 4
one thing I noticed is that if the fan is set too low manually on the mini batch 4 the machine will cut speed back accordingly. So if the controller sets the fan to say 4500rpm and you drop it too low the speed will reduce. The batch 4 mini's need a fan simulator and other hw mod to fan to run batch 1 firmware unless you don't mind the fan running 100%

What do you mean "cut speed back accordingly"? Are you saying the frequency and hashrate drops?

Otherwise, I would not expect a "fan simulator" to not act any different than a regular fan in the condition you have described.

Another point on the "batch 4 minis" is that I believe their availability is only mainland china?

-j

If cgminer wants the fan to run at a certain rpm and you lower it below what it is expecting the hashrate will drop and eventually goto 0. The batch 4 mini I have been playing with runs in fault mode because of the coding for the temp. When I manually lower the fan to say 5000 rpm from the 5880 it sets due to the fault the hashrate will drop until I bring the fan back to the 5880 rpm. Personally fan checking should be disabled to get around any issues with a fan simulator or the fan itself. I tried bypassing the checking but failed on my first attempt cgminer wouldn't even load. I screwed my board now it wont detect the fan rpm no matter what the circuit is good so I figure playing with it killed it on the processor but I did try a v9 controller and same issue with fan runs at full on the batch 4

these fans default to full speed when first kicked up unless specifically slowed down.
I'm unsure how you are "lowering the fan speed" when "cgminer wants the fan to run at a certain rpm".
And what do you mean "runs in fault mode"? What is the exact error(s)? Where is this "fault mode" seen?
where in cgminer did you try to "bypass the checking"? This one is different than the ones in the past.
What do you mean "cgminer wouldn't even load"? Do you mean you damaged the binary trying to modify it?
How did you "screw your board"? There is not a single software related activity that should "Screw a board".

Your response just creates a ton of questions.

Jason

On the batch 4 with batch 1 firmware the temps don't report on 2 of the hash boards. So because of this the fault light comes on and the fan is set to full speed. If I use a fan simulator or reduce the fan speed thru the PWM line the rpm must be reported as at least 5880 which is what the machine set the fan at due to the fault light if the simulator or fan don't report 5880 or higher cgminer will lower the hash rate and even drop to 0 this seems to be based off the rpm the lower the rpm the lower the hash rate the higher the rpm towards the 5880 the rate picks up. So if I leave the fan run full rpm it hashes away just fine at full hash rate. This could be due only to the fault being triggered by the non-reporting of the temps correctly.  I am waiting for another controller so I can play with it some more. I don't know why this one lost detecting the fan rpm and so far I haven't been able to disable this feature of cgminer. cgminer at startup wants to check the fan rpm and monitors it for any rpm below 1440.

I screwed the input on the board when I shorted it out moving a fan simulator. The error I get is no fan detected and loops on a fan check. Fault is seen in kernel log. Yes I screwed the binary modding it simple fix was reload firmware. Used pwm line to play with fan speed a 100k variable resistor between it and the gnd will vary fan speed. Unhooked pwm line from controller to assure no contact between gnd and controller side of pwm. The processor itself is not detecting any rpm signal. Checked the resistors they test ok so only other thing could be burnt the input on the processor. If I can get past the fan check it will mine just fine so basically I need the fan check and monitor to look for 0 rpm so it will continue to load and hash
member
Activity: 504
Merit: 51
one thing I noticed is that if the fan is set too low manually on the mini batch 4 the machine will cut speed back accordingly. So if the controller sets the fan to say 4500rpm and you drop it too low the speed will reduce. The batch 4 mini's need a fan simulator and other hw mod to fan to run batch 1 firmware unless you don't mind the fan running 100%

What do you mean "cut speed back accordingly"? Are you saying the frequency and hashrate drops?

Otherwise, I would not expect a "fan simulator" to not act any different than a regular fan in the condition you have described.

Another point on the "batch 4 minis" is that I believe their availability is only mainland china?

-j

If cgminer wants the fan to run at a certain rpm and you lower it below what it is expecting the hashrate will drop and eventually goto 0. The batch 4 mini I have been playing with runs in fault mode because of the coding for the temp. When I manually lower the fan to say 5000 rpm from the 5880 it sets due to the fault the hashrate will drop until I bring the fan back to the 5880 rpm. Personally fan checking should be disabled to get around any issues with a fan simulator or the fan itself. I tried bypassing the checking but failed on my first attempt cgminer wouldn't even load. I screwed my board now it wont detect the fan rpm no matter what the circuit is good so I figure playing with it killed it on the processor but I did try a v9 controller and same issue with fan runs at full on the batch 4

these fans default to full speed when first kicked up unless specifically slowed down.
I'm unsure how you are "lowering the fan speed" when "cgminer wants the fan to run at a certain rpm".
And what do you mean "runs in fault mode"? What is the exact error(s)? Where is this "fault mode" seen?
where in cgminer did you try to "bypass the checking"? This one is different than the ones in the past.
What do you mean "cgminer wouldn't even load"? Do you mean you damaged the binary trying to modify it?
How did you "screw your board"? There is not a single software related activity that should "Screw a board".

Your response just creates a ton of questions.

Jason
jr. member
Activity: 559
Merit: 4
one thing I noticed is that if the fan is set too low manually on the mini batch 4 the machine will cut speed back accordingly. So if the controller sets the fan to say 4500rpm and you drop it too low the speed will reduce. The batch 4 mini's need a fan simulator and other hw mod to fan to run batch 1 firmware unless you don't mind the fan running 100%

What do you mean "cut speed back accordingly"? Are you saying the frequency and hashrate drops?

Otherwise, I would not expect a "fan simulator" to not act any different than a regular fan in the condition you have described.

Another point on the "batch 4 minis" is that I believe their availability is only mainland china?

-j

If cgminer wants the fan to run at a certain rpm and you lower it below what it is expecting the hashrate will drop and eventually goto 0. The batch 4 mini I have been playing with runs in fault mode because of the coding for the temp. When I manually lower the fan to say 5000 rpm from the 5880 it sets due to the fault the hashrate will drop until I bring the fan back to the 5880 rpm. Personally fan checking should be disabled to get around any issues with a fan simulator or the fan itself. I tried bypassing the checking but failed on my first attempt cgminer wouldn't even load. I screwed my board now it wont detect the fan rpm no matter what the circuit is good so I figure playing with it killed it on the processor but I did try a v9 controller and same issue with fan runs at full on the batch 4
newbie
Activity: 24
Merit: 1
Hi there. is there an eta on the Z9 Mini's firmware ?
There you go!  Keep up the good work!
member
Activity: 504
Merit: 51
Hi there. is there an eta on the Z9 Mini's firmware ?
Will it be free or licensed?
thanks

bigjee, the Z9 mini variant will be released at the same time or 1 day behind depending on how much I get completed. I intend to release the Paid/DevFee combined image before midnight Eastern time on Sunday.

I'm in the process of packaging it all up for testing now; if I make good headway on that, I'll work on the mini modifications (base firmware will be the same, only some changes in cgminer otherwise) and release soon after.

I was hoping for a combined image, but there is not a reliable method (so far) to identify which hardware is which.

Paid users will have to upload a license file to the image on the 'Upgade' page, an example is included below:



Thank you,

Jason
full member
Activity: 434
Merit: 107
Hi there. is there an eta on the Z9 Mini's firmware ?
Will it be free or licensed?
thanks
member
Activity: 504
Merit: 51
Any updates for those who paid for the first version?

badbart - it is the same image as the picture above -- that is just example. It also has a 'licensed' mode.

So it will be released at the same time.

Jason
member
Activity: 449
Merit: 24
Any updates for those who paid for the first version?
Pages:
Jump to: