Topic: T17 OC/OV. S17 Series OC/OV, Antminer B7 OC/OV, S9k, Z11 + others 100% FREE - page 9. (Read 10235 times)

I will look at the files again today to see if there is a way to disable it on the x3. If you have ssh enabled it can be done using ssh

> 776 runs 1 command and if its over 776 runs something else. Not too hard to understand.

Right now because of the typo it may set a blank line if you bypass otherwise you just type in what you want and save and all is ok. If you try to bypass then you get what you get. The 3 typos are fixed already took 2 minutes.
Also the typos didnt stop you from mining it only set the wrong value in a config file which the web gui uses not cgminer.

In the end all that matters is the ability to control the freq and voltage, I dont think users care how I coded it. Maybe I kept it a cluster fuck to confuse people and something more is going on, never know.

I can always add some encryption but why

How do I disable that?

Stop being hard headed.

The test for: if [ blah > “776”.. is a fail always comparison on that line.

You need to treat that as a variable and access the value itself. That is $blah.. or ${blah} as many will use

... and stop with the bullshit of “more speed less power” as you are delusional or consciously lying.

-j

If you have signature checking disable on it then you can update thru the web gui and not the SD

That's too bad. Its hosted so I can't access it with an SD.

It is for any. The loading process is by sd.

@chipless -- what a complete clusterF your 2.2 release is. Here are the things you need to fix before you take money from folk..

rm /init (useless 0 byte file)
/etc/init.d/cgminer.sh - your "antminer" virus fix is broken. I told you about this a month or more ago. it is ".antminers", not ".antminer"
/etc/init.d/bitmainer_setup.sh - same thing.
/www/pages/cgi-bin/set_miner_conf.cgi: line 127 - your comparison (which is the difference between your private/public) for "ant_freq_user" > 776 is broken. In the current state, it will _always_ fail.
/www/pages/cgi-bin/set_miner_conf.cgi: lines 154, 155 -- you can't even spell your own variables correctly which makes all of your frequency selections *BROKEN*. You are welcome.
/www/pages/cgi-bin/set_miner_conf.cgi: lines 127-179 are a complete cluster. Instead of re-using the same lines over and over again, just write /config/cgboot once, and then call it.
/www/pages/cgi-bin/set_miner_conf.cgi: lines 127-179 -- your implementation here creates a race condition which will cause multiple cgminers to run in certain conditions. This will wreak havoc on things. I'll leave it up to you to figure out what the race is, and how to fix it, but it *IS* there.

There's probably more, I didn't check the math on any of your attempts at hex conversion and I didn't check to see which of this is in use and which is crap you haven't cleaned up from previous attempts.

None of this is bullshit or trolling you, it is simply broken.

.... and if this is what your Z11 firmware looks like, what does the rest of your "modded" firmware look like?

Bonus points for the readers -- assuming he fixes all of this, no need to pay him for his "Nitrous" version or whatever as the only viable difference in his public/private version is the check on line 127 in set_miner_conf which simply checks to see if you, the user, have specified a frequency > 776, and if so, it simply sats the variables to a hard coded set.

-j

Is your firmware for the X1 only for 4.22 and up?

The wallet and pool info is stored in the standard cgminer.conf file

Looks fine. Update to the newest version I released a little while ago. It should fix any problems make sure you set your settings after the update. The newest is 2.2

Here the list of "config" dir and list of cgboot and voltage. And there is no wallet or pool data.
PS. In the evening I will upgrade to 2.2 firmware and test again.

Recently updated Nitro Public, Private releases and SD card recovery image. Updated all updated to v2.2

It can take from 2-20 minutes to complete the initial scan depending on the frequency you select. After you see this in the log everything should be good to go. I apologize for this but the wait is well worth what you get in the end.

End of scanning process avg. freq will vary but the max should always be 825 ...............

NOS Boost chain0 asic0 freq 825
NOS Boost chain0 asic1 freq 825
NOS Boost chain0 asic2 freq 825
NOS Boost chain1 asic0 freq 825
NOS Boost chain1 asic1 freq 825
NOS Boost chain1 asic2 freq 825
NOS Boost chain2 asic0 freq 800
NOS Boost chain2 asic1 freq 825
NOS Boost chain2 asic2 freq 825
NOS Boost done, avg freq 822 max 825, Nitrous is On


Changes from 2.1 and v2.2
Has current Nicehash Support
Frequency control Limit is 775m for the public version Paid version is 825m
Added full voltage and frequency control
fixed reboot holding settings
Fixed bug where freq was setting odd frequencies per board

Yup... that is the format. What you are missing is it is only an intermediate step in frequency selection and not the end state. That is elsewhere.

Aka, it won’t work for providing a custom frequency.

The ONLY way is to bypass all of the stock functionality and replace it with custom code, linked in at runtime.... or hack in one frequency by editing the binary as you have been doing.

Really.

-j

I tried the 0 750 1 750 2 750 you posted as well as other ways and same crap every time. I have an idea how I want to use it if I can get it working. If not no big deal.

I’ve told you the format of that file a few times now.... and all it does is save the previously tested autotune state. Aka, auto tune is still the controlling factor and decides what to set the frequency to, not the user.

-j

That is what I figured on the boot.bin file. That is why I had left it out.

I get an open chips-freq.config open file failed message in the log. I have been playing with it for fun. I use part of the auto-tune and if the numbers arent in the right order for checking then you get 33k-100k at any freq. I just redid the file and am testing it.

Highly likely that it ends up back at 681 because of an autotune thread, not the format.

BOOT.bin is not what you think it is if you think that helps with setting freq/voltage. It has absolutely nothing to do with the ASIC/PIC and is literally just about booting the FPGA/linux.

Anyway, enough of me being helpful for today, back to my corner.

-j

Understand, the files and setting are still being used by my mods in a different way. I am wondering though if the boot.bin file needs to be updated on some miners. The 6/05 had a new boot.bin with it. My miners have been updated with it but i left it out of the package until I compare them. I havent compared them yet but will have to look in a minute. Most miners it is ok except a couple of them. I also may have to redo a few things to trigger the pic write that helped on older versions.

I have one where I did relinked the chip_freq.config but cant seem to get the format correct in it. It reads and tries to select the freq but ends up back at 681 due to the file format

chipless - microcontroller saves previous voltage/frequency state in certain situations, which might begin to explain some of what you are seeing. It can serve to fool one into thinking that they've got control of freq/voltage, and then "not work" the next time around.

For Z11, the bitmain-voltage setting in the config file is *not* connected to voltage setting in their cgminer, nor is bitmain-freq connected to the frequency setting in their cgminer.

-j