Every reboot it will reset it back to disabled without modifying /etc/init.d/bitmainer_setup.sh.

You do bring up a good point -- the previous web pages are all there, just not linked directly. That said, what I stated about what is used and what is not used in cgminer.conf is still valid. No frequency/voltages are used from it anymore.

I have yet to see any Z11s with more than 142kSol average (not the R/T, average) -- I think these things may automatically underclock to maintain that as a maximum...

-j

You will find that enabling SSH  does not actually help with anything. Cgminer.conf is not used to provide frequencies or voltages anymore. It only provides for pool configuration and for fan speed manual or auto. Everything else is ignored.

So what this really does by itself is open up a Z11 to being taken over by the antminer malware with no other benefit. Anyone who may want to load another firmware in the future would already have to do something like this with the new firmware anyway.

It is good to share though, I guess.

-j

Is anyone getting more than 142KSol out of their Z11? If so, how much?

I have a theory that I need to prove as true/false that the auto-tuning functionality might be auto-limiting to prevent it from going above 142kSol and will auto-adjust frequency down to ensure that is the case.

-j

Is anyone getting more than 142kSol out of their Z11 on average? I am wondering if the auto-tuning feature is not actually auto-limiting. I cannot confirm this at the moment from a reverse engineering perspective as I am away from my equipment. It's just a hypothesis since I have not heard of anyone with more than 142kSol yet.....

@iceman2k2 - Yes, SSH is disabled. Any image will have to be installed from SD card for now. I agree with you on power. I'm hoping to be able to test as soon as I can get things lined up with a couple of individuals.

Thank you,

Jason

If someone has A) teamviewer and/or B) (preferred) knowledge enough to create an SSH/web port forward AND C) knowledge enough to do a SD card based install on a Z11, I've got an image to start testing with and see what these things can do.

PM me A and C or B and C with a Z11 are true.

Thank you,

Jason

If someone has A) teamviewer and/or B) (preferred) knowledge enough to create an SSH/web port forward AND C) knowledge enough to do a SD card based install on a Z11, I've got an image to start testing with and see what these things can do.

PM me A and C or B and C with a Z11 are true.

Thank you,

Jason

Interesting these are actually clocking hardware errors.

Would you be willing to send me a copy of the system log from one of your z11s? If so, I will provide you an email address.

I’m hoping having some log contest will help with understanding some of what they have implemented in my reverse engineering efforts.

I can generate an image that provides the same control as my Z9 and mini variants (ie manual control over each hashboard), but I would have to disable auto tuning on an initial release with the information I have so far... and who knows if more can be squeezed out of these things...

Thank you,

Jason

interesting. Right now I'm only seeing about a 12% hit for the day. Yours is a 22% hit.

-j

Z11's landing.

Watch your frequencies -- it auto-adjusts. Will be interesting to see how/where it stabilizes. It is not clear to me if it continually adjusts frequencies or if it settles.

-j

Nice - I posted an update at the end of my "ZSeries" thread, but for posterity I'll toss a quick update here. I don't know if unlocks for the Z11 will be needed or not. It defaults to 718Mhz ("Turbo") mode on a fresh install, and 681Mhz in "Balance" mode. Beyond that, the firmware attempts to auto-tune the frequency.

The user cannot specify a frequency (there is an exception via the command line, but that is locked out).
A frequency specified in the cgminer.conf is ignored.
SSH is disabled.
The image is "signatured" so other firmwares cannot (easily) be installed.

I have an individual or two in the pipeline who are expecting to receive Z11s and I will test on them remotely to see if there is further "oomph" (ability) in the hardware with the software limits removed.

If there is more to be had out of the hardware, I will release a firmware for it -- or if there is a desire to actually be able to configure the unit as one desires instead of it being "automatic".
I do have the ability to bypass the signature checking, but if I do end up releasing a firmware will likely only support the SD card method for installation... I don't really want to release the first of my bypass methods into the wild for a couple of reasons.

-j

Aye, https://blog.bitmain.com/en/z11-shipping/2019-04-11.html and https://blog.bitmain.com/en/z11-shipping/2019-04-12.html

The date spread on these two shipping days are odd for the orders... the first one covers 2 weeks but is "only" 124 orders. Day 2 is 10 orders over right at 2 weeks also.

-j

Folk,

Quick update on the Z11 -- at this point in time, I think I'm going to wait and see what happens with the Z11s as they arrive before deciding on releasing a firmware.

Here is what i know so far:

The stock configuration file defaults to 718mhz (turbo mode).
If that is not specified, it defaults to 681Mhz (Balance mode).

It looks like in both cases, there is an attempt to auto-tune the frequency. It's a little hard to tell what is going on without seeing a running system yet, however.

It does not look like the user can specify a frequency at all -- it is ignored.

Voltage appears controllable, although not exposed to the user.

As your Z11s arrive, I would be interested in seeing logs from the unit via PM and/or teamviewer sessions. If there is a need, I will remove the limits and given an opportunity, I will test other possibilities with the controls... I do not have a unit coming to me this time, however.

It may be that the factory firmware provides you what you'll need... if it doesn't, I will work to do something about it.

Thank you,

Jason

Yes.

Folk,

First batch of Z11s have shipped as of today: https://blog.bitmain.com/en/z11-shipping/2019-04-11.html

-j

Yes -- that's actually how the product works even with the rest of the power plugged in. During initialization of a hashboard, DC is toggled on. When hashing stops, DC is toggled off. And yeah, I'm sure there is some vampire current somewhere, but I wouldn't expect anything major.

I've almost got my lab rebuilt (physical move) and can start working on the hardware RE again.

-j

Does that firmware also disable ssh? That's their new method, signature + disabling SSH.

-j

Mind taking pictures of the board with the IC you've identified?

I only have a Z9 around, no minis.

-j

The simpler thing is to simply not check for the fans if that is the needed.

Data logging is not a problem I have.
The chip is question has not been identified as best I am aware by any method ... go run your finger over the white part of that chip... it's actually been cut into to remove the top layers and hide the markings.

... my office/lab is better equipped than any radio shack ever was.

Voltage path: FPGA->(via i2c) PIC->(via separate i2c/i2s) ISL->VRM->hashboard
Fan Path: FPGA->fans (FPGA generates the pulse, "pulling to ground" does not make sense in this context).
Communications to the hashboard are a combination of things: FPGA->PIC->(Magic i2c interface over rs232 end-point terminated in fpga memory [kind of like a poor man's rDMA])->hashboard

Certain components downstream of the PIC are mapped to FPGA space through the use of the PIC as an interface. The PIC firmware on the z9/mini does not implement a couple of calls that are implemented (I think) on the Z11 PIC firmware. Voltage controls are included in this statement.

There is also another communication path I have not yet isolated directly related to how Z9/Z9mini ISL is communicated with. In bitmain's cgminer implementation, the payload is set up to communicate on an i2c bus (i.e., the bytes are what would be necessary to send out SDA), but since i2c is open-collector and the backend i2c is always low... it is not in use.

A useful endeavor would do know if the read protect bit is set on the PIC and then the FPGA, in that order.

... yeah, my self teaching covers a lot.

-j

The VRM is controlled via a PWM signal off of the ISL68127 -- it'd need to respond to that.. and unfortunately it's also hidden behind the one chip type on the board that is etched off. It's been etched off on all of their recent miners.

-j