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

Thank you much going to give it a try now and inform you of any bugs

All,

Thank you for your support. I have updated the first post in this thread with details on the version 2.0 release. I am sure I have left some things out as it is 3:30AM where I am at. I will catch up on responses/questions/etc, in the morning.

Please see the beginning of the thread and/or http://releases.broked.net to download the image.

Thank you!

Jason

Yes sir, working on it right now... trying to button the image up and fix a couple of last things. It's just after 11PM my time and I normally go to bed around 2-3AM.. so it'll be in the next couple of hours barring anything unusual.

Thank you,

Jason

will you still be releasing the dev fee version this evening

Please read the top of the thread -- if it isn't for you, that is fine.

Jason

What features are to be included in the upcoming mini firmware mod? we can already OC them as is.

How can I purchase and download the full version of Z9 Overclock Firmware ?

That would be sweet maybe I can push this thing a little harder What is the paid version fee for the full firmware for 1 z9? One feature I did add to the web gui was a refresh of the miner status page for every 60 seconds this way I can monitor the rates without refreshing the page manually

While I do not have an extra board to test it, I believe that yes, it will work. It will be easy enough for you to test!

Thanks,

Jason

Folk,

I am now ready to release version 2.0 of the Z9 firmware. Soon after this, I will be releasing these same features for the Z9 Mini series.

This firmware will be released late Eastern time on 10/23 barring any unforeseen circumstances.

This next release will be available in 2 forms. The current method, and a new dev-fee supported method. The dev-fee supported version will be the first to be released with the prepaid version soon to follow. If you have purchased the previous firmware, you will receive a 2.0 update for free, with no dev-fee included in the near future.

The developer fee version will be configured to mine for 5 minutes every 140 minutes. This means 140 minutes mining for you, and 5 minutes mining to support on-going development. The one exception to this is when the system is first started, it will mine for you for 10 minutes (to give you time to tune frequencies, etc.) and then 5 minutes to support development. After the first 15 minutes, it will continue along the 140 minutes for you, 5 minutes to the development pool.

I have put a lot of time and effort into this and intend to continue to support the community. I firmly believe that anyone who has dealt with me will see that I try to operate in a fair manner and strive to provide excellent support.

I will update this post with more details soon and this image will replace the current 575Mhz Demo version.

Thank you,

Jason

Will the new version support these features for 4 ASIC boards hooked to the Z9, I ask because I went in on a unit with 2 other guys and we split the boards so I am running about 70-75k/sol with the 4th board added to a Z9 at 656mhz any higher 1 board drops an ASIC. The 4th sits alongside with 2 CPU fans attached to the upper and lower heatsink in the middle. It runs 20 degrees cooler with 2 cpu fans then when the case. Also do you look for beta testers for your full versions if so I am interested I push mine to the limit to try and the most for my buck. I am a old developer of another type of devices.

Thanks for the work done) Find another way to run Z9 on EQUIHASH 144.5:) If you can find a way to slow down the memory chips maybe this will help ?

Thanks Jason.

I have been testing the per-hashboard feature for the last 24 hours or so, and it is working as I would expect. There are a couple of pieces i need to finish up before releasing the next revision. These include:

* Adding a user interface to control the frequencies per hashboard
* Updating the frequency reporting to show properly in the webUI
* Updating the default frequencies to better match reality
* Looking into the ability to set frequencies on the fly without restarting the whole 'cgminer'. I think I know how to do this, I just need to test it.
* I have located voltage control, but will not be enabling it yet. That will come in another version in the future, if at all. I need to do a lot more testing on that first.
* Lots more in the future....

Some of the current delay is also associated with folk acquiring the firmware and then selling it on eBay. I will begin enforcing the pre-existing node locks in the next release -- I did not want to have to go to that step. :/ This means the firmware will only work on the number of machines you specified when speaking with me. If this is an area of concern, please contact me ahead of time or downgrade to stock firmware.

... and some of the current delay is just that this has been a lot of work to figure out. Without the source code, it is quite a challenge to add functionality to a binary and I've probably put another 60-80+ hours of work into the next set of features in the last 9 days.

Thank you,

Jason

You're the man ! ! !

Folk,

Quick update -- this is a snippet of the startup log from the machine I'm currently working on. Of note here is the part in bold, "freq=". One board is running at 650Mhz, the other 2 are running at 500Mhz. Unfortunately the API that feeds the web interface does not output these numbers, but instead outputs whatever is set for the main frequency.... so the web interface currently is still showing 650.

Regardless -- this is much closer to working now.

...
[2018-10-18 02:51:00] check_every_chain_asic_number
[2018-10-18 02:51:01] check_asic_reg: chain J0 has 16 ASIC
[2018-10-18 02:51:03] check_asic_reg: chain J1 has 16 ASIC
[2018-10-18 02:51:04] check_asic_reg: chain J2 has 16 ASIC
[2018-10-18 02:51:05] calculate_address_interval:addrInterval = 16
[2018-10-18 02:51:08] chainid0 set_frequency_chain freq=650
[2018-10-18 02:51:10] chainid1 set_frequency_chain freq=500
[2018-10-18 02:51:13] chainid2 set_frequency_chain freq=500
[2018-10-18 02:51:14] set_ticket_mask_chain chainID0 ticket_mask = 0x0000000c
[2018-10-18 02:51:14] set_ticket_mask_chain chainID1 ticket_mask = 0x0000000c
[2018-10-18 02:51:14] set_ticket_mask_chain chainID2 ticket_mask = 0x0000000c
[2018-10-18 02:51:14] software_set_address_chain chainID0 asics 16 addrInterval 16
[2018-10-18 02:51:14] software_set_address_chain chainID1 asics 16 addrInterval 16
[2018-10-18 02:51:14] software_set_address_chain chainID2 asics 16 addrInterval 16
[2018-10-18 02:51:14] chainid0 set_core_timeout_chain: core timeout = 00100000
...

Thanks,

Jason

Bliss's firmware was built from source to the best of my awareness.

These modifications are being done in assembly -- so it's a slightly different challenge. If this was in C I'd have had it done a couple of weeks ago.

That said, check out the next post!

If you can look at a disassembly of the D3 machine with BlissX firmware they it has separate voltage and frequency control for each board. From what I can tell most the BM firmwares are the same with a few exceptions of the compilation.

if you have time, look at my letter, this function will also be useful to you
so that the coolers do not scream when rebooting

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