Folk,
For the month of January, I will be giving away a Nintendo Switch to firmware users. The rules will be the same as December, with 1 entry per day per system. This is for users of 2.1(d) or higher.
Thank you,
Jason
do you know who the winner was for the Switch? @tahoeminer - thank you for reminding me to update. Hectic crap and all that. I am waiting on a part that was DoA and in theory arrives tuesday so I can bring a computer back to life. That's the computer which has the dataset for the drawing. I was in the middle of an upgrade when "bad things happened". So it will still cover the same time period, just delayed a few days on the announcement for when I can get that computer online. Thank you, Jason |
|
|
|
I will advise them to just remove your firmware. Apparently you cant be civil
Thank you for your patronage. -j |
|
|
|
Jason
Any idea when you are releasing the 2% dev fee version. I have a couple of clients I mentioned it to that are waiting. They figure mining on antpool with 0% fee makes your pretty reasonable it works out that way as a 1% dev fee when compared to other servers with a 1% fee
never. I changed my mind the moment you asked. -j Let me rephrase -- when I make the change, it will be for pre-existing users only. So advise your clients accordingly. -j |
|
|
|
Jason
Any idea when you are releasing the 2% dev fee version. I have a couple of clients I mentioned it to that are waiting. They figure mining on antpool with 0% fee makes your pretty reasonable it works out that way as a 1% dev fee when compared to other servers with a 1% fee
never. I changed my mind the moment you asked. -j |
|
|
|
Z9 mini sometimes wont connect again to pool after dev fee mining time
PM me your support ID please? I just performed some server maintenance which might be the issue you are seeing. It has been completed now. -j |
|
|
|
|
Folk,
At the end of this month I will be releasing a version with a fixed 2% dev fee, once per day which will drop the dev fee by 33%.
Thank you,
Jason
|
|
|
|
hello...startet today with 2 used Z9 mini and just wondering - which static diff is recommended atm for ZEN?
Unfortunately I do not have a personal recommendation for this. One thing you could do is observe where the difficulty goes to automatically over a long run (8hrs or so perhaps) and then use that as a basis for setting your difficulty. Jason |
|
|
|
|
Try the stock firmware and see how it works and let me know. I have a couple of ideas, one of which chipless mentioned above.
Thank you,
Jason
|
|
|
|
|
Folk,
Bitmain has decided to "fight back" against third party firmware on their units. Their most recent units are shipping with firmware that has ssh disabled and some firmware integrity checks in place to prevent you from installing another firmware. As of this post, the change is not in all of their firmwares, but they are adding it as they update them as best I can tell.
The checks are simplistic in nature, but effective because ssh is disabled by default.
I know this is the case on the new S/T15 units and it is the case on the latest (November?) DR3 firmware.... Once you move to that firmware, you cannot go to another one.
While this can easily be circumvented with physical access to a miner, it isn't something that is (as of yet) easily solvable with a normal firmware upgrade.
Net-net, don't upgrade to their latest firmwares without a good reason to (they don't release release notes).
Their method is embedded in the firmware upgrades "runme" script, as well as the "upgrade" CGI script. It's a set of checks that look for a file signature against the script and if it matches via an openssl return code, the upgrade continues. If it doesn't, the upgrade fails with an "invalid signature" message.
Without SSH and/or serial console access to the units, fixing this is non-trivial, but not impossible.
I know how to go about breaking this, but I don't have any of the miners that are implementing this at the moment. My analysis so far has been a static analysis on their firmware files themselves... and I think they've done a simple but effective job.
I'll update this thread if/when I come up with some alternative ideas.
Thank you,
Jason
|
|
|
|
I have an issue with my Z9 Mini (Original Bitmain Firmware, all my hashboards tested one by one and are Ok!), When the miner lost connection for any reason and tries to reconnect to the pool, the system shows: Socket connect failed: socket refused!, power off for some minutes and power on again solve the problem, but this can be made some times in a day. The Efudd's Z9 Mini Firmware can fix that issue?.
Thanks.
That message is normal and exists until cgminer in the firmware starts up AND properly connects to a pool. To understand what is going on with your system, I would need to see the logs when it happens. -j |
|
|
|
I added more miners and swapping them around for better cooling but will get some log data for you within the next few days. Kind of weird how the temps show ok but yet is still throttles back for a few minutes then goes back to full speed.
Jason I found the problem it was a bad pigtail on a power adapter heating up causing the board to drop and come back. Fixed it.
Thanks for offering to look at it.
Cool deal. Good troubleshooting and I’m glad it worked out. -j |
|
|
|
Gotcha… I like to play with this stuff and am sorry I didn't pm instead.
One last question when I run my Z9 up to or higher then 700m I don't get any x errors but after a few hours the machine seems to throttle slowly 1 or 2 boards back down to a 0 k/sol and sits like that for a little bit then will throttle slowly back up to the full speed. The temps are showing fine usually board tmp in the 40-50 range and the chip tmp around 60-63 it don't matter what fw I use the result is the same.
So the question is do you have any idea what this could be or is it just overclocked too much causing this. I can lower back down to about 668 and it goes away and never throttles the board.
I'd have to see the logs to guess, to be honest. There could be a couple of explanations. -j |
|
|
|
|
try nicehash support/discord?
|
|
|
|
Oh, if you are looking at cgminer in your statement of "they just took away the jmp into it", then you just don't understand software or compilers in that comment.
I suggest you look at what "static inline" does when something is compiled (google it. seriously. then write some code, disassemble it, and understand what it does) before making the comment you made. That is what you are referring to, but don't yet realize it.
As far as the rest of cgminer goes, bitmain modifies cgminer slightly to support hardware. They build with a set of options, lots of stagnant code is left as a result.
Bitmain doesn't have the clue to "take away a jmp". Their OS design is horrible. Their web interface is horrible. Their OS integration is horrible. Their scripting is horrible. Their code is pathetic. I don't mean how things "look", I mean how they are implemented. It is very clear to me that they don't know what they are doing and they cobble things together at best. If their hardware design is similar (I don't have the experience to comment on that yet), then they are not long for this market no matter the name they have.
The only code in cgminer that's worth a darn is the code bitmain didn't contribute.
If you are still trying to figure out how to control the hardware through their cgminer, you are wasting your time. Instead, go map out the pins on the ZYNQ, and then read up on the /proc interface until you become aware of how to expose additional gpio's to the linux subsystem. Once you map the gpios from the ZYNQ to the downstream hardware components (PIC, i2c, etc.), THEN you can make progress.
The OS and hardware are mailboxing the hardware control calls over the memory mapped axi regions. That's why you don't see it in the OS directly. If you don't understand 'mailboxing', search for 'mailbox software concept' -- it's akin to (but not scalable) message queues in concept.
Honestly. That's the way. That's the secret. That's the work I'm not doing at the moment because mapping out 191 pins for little return is not in my game plan. If you want to use that as a learning exercise, go ahead.
-j
I understand what your saying....The code I am use to looking at uses jmp and other commands. There is a difference between the language disassembly's but yet they can be similar. Coding for Dallas Micro's and AVR's was similar but different and a PIC different, many of them I was working the othr way though not backwards thru a bunch of mess. I definitely have the equipment to interface directly. I have jtags, hardware emulators, programmers and a few other tools even a couple of Rasberry Pi 2's around. I have a couple of test boards I designed for AVR's that you can setup to control ,log, or whatever else whatever. Thanks for the feedback I'm not sure you got what I'm saying. What you'll notice most about my posts are me explaining what I don't know, not what I do know instead of a 'look at me, here is what i used to do!'. As far as gear goes, Yeah, I have a lot of gear I don't know how to use properly, too. One might would think I were an EE if they saw my home lab. I have plenty of test boards, data loggers, FPGAs, oscilloscopes, function generators, programmable power supplies, soldering irons, desoldering stations (yeah, plural on all of these for some reason), programming boards for random chips, serial interfaces for anything you can think of, beagleboards, raspi's, blah, blah, blah. (I have a dozen of these for some reason; probably unfinished projects I can't remember pre-coffee). I don't have a pick-n-place, though. :-) .... None of that makes me experienced with this device nor reverse engineering. Every bit of the work I've done on this has been done on a raspberry pi, actually, after the initial hardware evaluations.... I temporarily decommissioned my HAM Radio hotspot for this project. BTW, I recommend a 'jtagulator' if you like trying to crack hardware open and aren't always sure which pins are JTAG. The reason the fan controls are not "accessible" directly as a function pointer is that the fan control function in cgminer is compiled "static inline". That means the function is written separately, but is effectively just part of another function (as if it were never a function by itself) when compiled. It is an optimization, among other things. My point simply is if you'd like to guess about something, leave it in a PM OR have the awareness to make it very clear the difference in what you know and what you suppose so readers are not lead astray. -j |
|
|
|
|
Oh, if you are looking at cgminer in your statement of "they just took away the jmp into it", then you just don't understand software or compilers in that comment.
I suggest you look at what "static inline" does when something is compiled (google it. seriously. then write some code, disassemble it, and understand what it does) before making the comment you made. That is what you are referring to, but don't yet realize it.
As far as the rest of cgminer goes, bitmain modifies cgminer slightly to support hardware. They build with a set of options, lots of stagnant code is left as a result.
Bitmain doesn't have the clue to "take away a jmp". Their OS design is horrible. Their web interface is horrible. Their OS integration is horrible. Their scripting is horrible. Their code is pathetic. I don't mean how things "look", I mean how they are implemented. It is very clear to me that they don't know what they are doing and they cobble things together at best. If their hardware design is similar (I don't have the experience to comment on that yet), then they are not long for this market no matter the name they have.
The only code in cgminer that's worth a darn is the code bitmain didn't contribute.
If you are still trying to figure out how to control the hardware through their cgminer, you are wasting your time. Instead, go map out the pins on the ZYNQ, and then read up on the /proc interface until you become aware of how to expose additional gpio's to the linux subsystem. Once you map the gpios from the ZYNQ to the downstream hardware components (PIC, i2c, etc.), THEN you can make progress.
The OS and hardware are mailboxing the hardware control calls over the memory mapped axi regions. That's why you don't see it in the OS directly. If you don't understand 'mailboxing', search for 'mailbox software concept' -- it's akin to (but not scalable) message queues in concept.
Honestly. That's the way. That's the secret. That's the work I'm not doing at the moment because mapping out 191 pins for little return is not in my game plan. If you want to use that as a learning exercise, go ahead.
-j
|
|
|
|
Jason
Have you come across a pic.txt file in any of the images? From what I am gathering it is the update file for the pic on the hashboard.
Normally cgminer looks for it in the /sbin folder
I am wondering if this is how the different revisions are limited to speed. If the pic chip code was changed. I would like a dump of each board revision to compare. I do see it is possible to dump the pic with cgminer
No. I wouldn't "gather too much" from the existence of that check. There is a significant quantity of legacy crap in bitmain's scripts and it wouldn't surprise me one bit if that was not left over from some previous PIC they used as a live or at-factory or in QA/dev ability to update the PICs firmware if needed. If you want the PIC firmware, pull it from the PIC itself. -j |
|
|
|
Hello, just trying to update to latest fw version
Keep getting "tar short read"
I unzipped the file as per the instructions, and then tried to upload the .tar and it fails.
I've tried winzip, winrar, 7zip, no dice.
No matter how i unzip the "UNZIP ME" file, it just fails?
Any ideas?
Thank you
jamiec, you are mixing up the firmware upgrade from the license application -- and the confusion is my fault. When I first provided download links to paid users, it was the whole firmware. The updated links are just the license file. So.. apply 2.1d, CLEAR YOUR BROWSER CACHE, then follow the instructions in your "UNZIP_ME_*" file. PM me if you have any other questions. -j |
|
|
|
They actually VERY accurate. I've measured before with other diagnostic equipment.
As long as you are not using it to measure the Microwave power consumption...
Sorry to bring up an old thread, but I was having trouble with a kill-a-watt and measuring a microwave. The microwave supposedly has 1650 input and 1200 output watts. When I measured it with a kill-a-watt it showed input between 1900 and 2000 watts. Is there a problem with kill-a-watts measuring microwaves? Maybe because of their higher wattage? When I saw the above comment by adaseb, I thought he or maybe someone else might know something about this. Thanks for any help that can be provided. likely startup/peak vs. running - the output watts are likely rated as running/sustained for some period of time. -j |
|
|
|
|
Folk,
This will be a "Dev-fee" free weekend, with the dev-fee being disabled until Monday January 6th, 2019.
This will require 2.1(d) to be installed -- 2.1(c) expired due to a mistake I made -- I still have approximately 20 systems running it that need to upgrade. Please check to make sure you are not one of them.
Thank you,
Jason
|
|
|
|
|
Folk,
For the month of January, I will be giving away a Nintendo Switch to firmware users. The rules will be the same as December, with 1 entry per day per system. This is for users of 2.1(d) or higher.
Thank you,
Jason
|
|
|
|
|
Show Posts
