Anyone happen to know how to get into the serial console on currently shipping Antminer control boards? I'm looking at "Miner_Ctrlboard_V1.1" which is used in at least the Z9mini and Z9 (and I believe V9 also). I'm trying to use a buspirate right on the TX/RX/GND pins with no luck. I'm wondering if it isn't designed have it so you have to short something else on boot to enable serial terminal now. Any pointers would be welcomed (I have and am continuing to search/try). *EDIT*: Was able to get into the serial ports -- my buspirate was bad.. and you have to invert the logic on the RX side. ... But now I am in at the lowest levels of this thing. More fun ensues. Xilinx First Stage Boot Loader
Release 2017.1 Mar 12 2018-19:08:47
Devcfg driver initialized
Silicon Version 3.1
Boot mode is NAND
InitNand: Geometry = 0x8
Nand driver initialized
NAND Init Done
Flash Base Address: 0xE1000000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 3
Partition Number: 1
Header Dump
Image Word Len: 0x0007F2E8
Data Word Len: 0x0007F2E8
Partition Word Len:0x0007F2E8
Load Addr: 0x00000000
Exec Addr: 0x00000000
Partition Start: 0x000075D0
Partition Attr: 0x00000020
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xFFE7AF06
Bitstream
In FsblHookBeforeBitstreamDload function
PCAP:StatusReg = 0x40000A30
PCAP:device ready
PCAP:Clear done
Level Shifter Value = 0xA
Devcfg Status register = 0x40000A30
PCAP:Fabric is Initialized done
PCAP register dump:
PCAP CTRL 0xF8007000: 0x4C00E07F
PCAP LOCK 0xF8007004: 0x0000001A
PCAP CONFIG 0xF8007008: 0x00000508
PCAP ISR 0xF800700C: 0x0802000B
PCAP IMR 0xF8007010: 0xFFFFFFFF
PCAP STATUS 0xF8007014: 0x50000F30
PCAP DMA SRC ADDR 0xF8007018: 0x00100001
PCAP DMA DEST ADDR 0xF800701C: 0xFFFFFFFF
PCAP DMA SRC LEN 0xF8007020: 0x0007F2E8
PCAP DMA DEST LEN 0xF8007024: 0x0007F2E8
PCAP ROM SHADOW CTRL 0xF8007028: 0xFFFFFFFF
PCAP MBOOT 0xF800702C: 0x0000C000
PCAP SW ID 0xF8007030: 0x00000000
PCAP UNLOCK 0xF8007034: 0x757BDF0D
PCAP MCTRL 0xF8007080: 0x30800100
DMA Done !
FPGA Done !
In FsblHookAfterBitstreamDload function
Partition Number: 2
Header Dump
Image Word Len: 0x000216CC
Data Word Len: 0x000216CC
Partition Word Len:0x000216CC
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000868C0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7F1506A
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1
U-Boot 2016.07-g7640c9f-dirty (Feb 27 2018 - 17:57:23 +0800)
Model: Zynq MicroZED Board
Board: Xilinx Zynq
DRAM:
dram_init: sys_sdram_size = 0x10000000
dram_init: sys_sdram_size = 256 MB
dram_init: gd->ram_size = 0x0f000000
ECC disabled 240 MiB
NAND: 256 MiB
MMC: sdhci@e0100000: 0
Invalid bus 0 (err=-1)
*** Warning - spi_flash_probe() failed, using default environment
In: serial@e0000000
Out: serial@e0000000
Err: serial@e0000000
Model: Zynq MicroZED Board
Board: Xilinx Zynq
board_late_init: bootargs: mem=240M console=ttyPS0,115200 ramdisk_size=33554432 root=/dev/ram rw earlyprintk
--- boot gpio value = 0x003fff3c
--- nand boot nand ---
Net: --- phy_broadcom_init
ZYNQ GEM: e000b000, phyaddr 0, interface gmii
--- zynq_gem_probe
--- mdio_register
--- mdio_register 1
--- mdio_register 2
--- mdio_register 3
--- zynq_phy_init: interface = 1
--- zynq_phy_init
0000000000
PHY is not detected
GEM PHY init failed
No ethernet found.
Hit any key to stop autoboot: 0
Copying Linux from NAND flash to RAM...
NAND read: device 0 offset 0x2000000, size 0x800000
8388608 bytes read: OK
NAND read: device 0 offset 0x1a00000, size 0x20000
131072 bytes read: OK
Copying ramdisk...
NAND read: device 0 offset 0x2800000, size 0x2000000
33554432 bytes read: OK
## Booting kernel from Legacy Image at 02000000 ...
Image Name: Linux-4.6.0-xilinx-gff8137b-dirt
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3851576 Bytes = 3.7 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy for 0, Image at 04000000 ...
Image Name:
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 12693249 Bytes = 12.1 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
get ramdisk ok
## Flattened Device Tree blob at 03000000
Booting using the fdt blob at 0x3000000
Loading Kernel Image ... OK
Loading Ramdisk to 0cee5000, end 0dafff01 ... OK
Loading Device Tree to 0cee0000, end 0cee4d99 ... OK
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 4.6.0-xilinx-gff8137b-dirty (lzq@armdev2) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-23) ) #22 SMP PREEMPT Fri Dec 22 12:25:44 CST 2017
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Xilinx Zynq
cma: Reserved 16 MiB at 0x0e000000
Memory policy: Data cache writealloc
percpu: Embedded 12 pages/cpu @cddf1000 s19776 r8192 d21184 u49152
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 60960
Kernel command line: mem=240M console=ttyPS0,115200 ramdisk_size=33554432 root=/dev/ram rw earlyprintk
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 205988K/245760K available (5317K kernel code, 230K rwdata, 1844K rodata, 1024K init, 222K bss, 23388K reserved, 16384K cma-reserved, 0K highmem)
Virtual kernel memory layout:
....
-j |
|
|
|
|
Update: I've managed to remove the limits they put in place and can re-enable full frequency selection. I'm still working on building an image that others can test with.
"Soon(tm)".
-j
|
|
|
|
Success. I have overclocked my Z9 to 650... here's a picture of it at 600. https://imgur.com/n87ky6JI'm going to let this 650 run for a while to check stability. The change I have made is hard coded at the moment, it'll take me a little longer to make something that should work for others... and even longer to make an image we can just install (maybe). -j Definitely looking forward to what you come up with keep us posted I'm running mine at 681Mhz now. At 700 the voltage regulators start to cut back voltage, power draw and hashrates bottom out. I haven't tested to see how far I can push past 681 that I randomly selected. What I'm doing is lost on each reboot. I'm working to build an image that can be flashed to the Z9 that will let it run up to 575Mhz and will persist across reboots. My first attempt at a flashable image failed and until I can connect to to a serial console on these boards, I won't be able to troubleshoot it. What bitmain has done is purposefully try to lock these down -- I'm still hoping to be able to restore the ability to select 500-750Mhz or so, but that is on the backburner at the moment. My next goal is to build that test image and get some feedback. Given the fact that my last image bricked it, I'm going to have to connect to the serial on the unit and see why it failed. I also expect that the tactic they have used here may apply to more of their product line... but one thing at a time. -j |
|
|
|
Anyone know how to fix a 'bricked' Z9?  Yeah - read through a bunch of useless bitmain articles, piece together components, find the recovery for "V9-Tools.zip", pretend your Z9 is a V9, extract that V9-tools.zip to your 32GB or less FAT32 formatted SD card, power off miner, insert SD card, power on, wait for all lights but ethernet to go off (~60 seconds), unplug miner, remove SD card, replug miner in. Then go find the Z9 firmware image and use the web interface to flash your "V9" back to a "Z9" while unchecking the option to "Keep Settings". Once that reboots, congratulations, you now have 1 factory hobbled Z9 back up and running.  -j |
|
|
|
i received my Z9 mini 3 days ago, overclocked it to 743 about 5 hours ago, fan 100% (i dont care about the noise), temp of the cells is 58 celcius
so far i have an average of around 17 KH/s with peaks at up to 25KH/S
edit: also without overlocking it was around 11 KH/S, so it was pretty good even though it was running at 500
My best Batch1 Z9 mini only sustained (long average, weeks.....) 16.58kSol/s. If you have one sustaining 17kSol on a long average, congrats, you found a golden egg. -j |
|
|
|
Success. I have overclocked my Z9 to 650... here's a picture of it at 600. https://imgur.com/n87ky6JI'm going to let this 650 run for a while to check stability. The change I have made is hard coded at the moment, it'll take me a little longer to make something that should work for others... and even longer to make an image we can just install (maybe). -j |
|
|
|
|
Folk,
I wanted to provide a brief rundown of my observations on the Bitmain Z9 series (mini and big one). This is based on my experience with the Z9 and Batch1 minis, plus various forum posts here. I'm not sure of the order in which Bitmain changed things after the Batch1 minis, so I'll just refer to the changes in a non-specific order as Batch1+X, etc.
To overclock these things, we have both a software component which consists of the WebUI (which is where many people were OCing after batch1 using "F12" in their browser) and the cgminer executable, and a hardware component which is the actual hashboards themselves which consists of things like the VRM (voltage regulation, which would impact the voltage through the chips as well as limitations around current flowing to the chips) and the general capabilities of each chip (temperature sensitivity, etc. will vary as the chips are made to some tolerances).
That gives us 2 factors to focus on: the hardware and cgminer since the webUI is really just an interface on cgminer.
Batch1 Mini
Sold as 10k, screamed along at 16-17k for the really good ones, temperature sensitivity varied greatly, but mostly all stable OC'd at 750. This requires good voltage, current to the chips, and just "good chips", plus the ability to modify the frequency (web UI + cgminer support).
Batch1 Mini+X
Sold as 10k, came in around 15k, unstable when OCd much past 681Mhz. Web UI said "balanced" and "turbo", but people were able to modify the frequency just by editing the web UI. These were "good chips", but I expect the voltage and/or current to the chips were limited and the Web UI was limited, but NOT cgminer.
Batch1 Mini+X+X
Sold as 10k, came in around 13-14k. WEb UI said "balanced" and "turbo". Trying to modify the webUI and/or the cgminer.conf did NOT work. These people that know are simply moving back to a previous build of the release, but the voltage/current to the chips are still limited, basically turning these into Bactch1+X.
The Big Z9
Prepped, ready to go out the door on time, bitmain realized the hashrates were growing faster than they calculated and it would impact their sales, they investigated and realized they needed to put at LEAST the "webUI" and "cgminer" changes into the Z9s. I don't know if they retooled the boards, and I'm hoping they did not, which would mean voltage/current capabilities are still there.
In the 2 week delay, they rebuilt cgminer (it's compiled as of 9/13/2018) to limit the frequency selection AND not let you override it via command line, API, or cgminer.conf. Only accepts 500-550 and defaults back to 500 if things are out of range.
What does this mean?
If the boards are like the Batch1 Mini boards in that they can handle the current/voltage (I've not checked the volatges/currents, it's just a best guess), THEN, we should be able to revert the cgminer functionality by disassembly and patching. Bitmain doesn't release their changes to cgminer (illegally), so that is our only recourse. If this works, the tricks such as "f12" that people were using in their browser, SSHing in, API would all work and we should be somewhere between Batch1 and Batch1+X in capability (mulitplied by the increase ASIC count per chain).
I welcome other information to clarify my best-guesses.
Lastly, here is an image of the current cgminer (left) and the old (mini batch1) cgminer on the right .. I'm still learning ARM assembly in doing this, but the left has checks to ensure the frequency is between 500 and 550 and resets back to 500 if out of bounds. The right says, check to make sure the frequency is between 200 and 4294967240 Mhz, and that is it.
... I'll work on this more as I get time/energy/focus today.
-j
|
|
|
|
Well, I've found where the conditional checks are for 500 to 550mhz. I need to understand the code around it a little more and then work on a binary patch. *EDIT*: This is where it seems to be if there are any others so inclined... https://imgur.com/L20jFnoI'm new to ARM assembly, but this basically has a comparison on the left for the frequency being between 500 and 550. I'll work on this more after sleep. -j |
|
|
|
|
One of my Z9s arrived and I've been able to spend a little time with it working on overclock.
1) The control board is exactly the same as the Z9 mini (batch1, at least).
2) cgminer executable has been modified, how, I don't yet know.
3) Using the cgminer executable from the mini on the Z9 does initialize one of the chains, and I can then overclock that chain greater than 550Mhz, but does not fully bring the system up.
4) brute force swapping the control boards produces the same result as #3.
In the factory configuration, I think what they have done is modify the cgminer executable to simply not accept frequencies greater than 550, and if provided a frequency greater than 550, to simply default back to 500. I say this because when I start up the factory configuration at 575 Mhz by editing /config/cgminer.conf, the chains (asics) initialize at 500Mhz.
Since bitmain has not provided the changes they have made to cgminer back to the community, the only option here is to reverse engineer the Z9 cgminer and see my hypothesis is correct, and if it is, generate a small binary patch to remove that check.
I don't currently know ARM assembly, so that is going to take me a while, if ever... but I can at least disassemble it in IDA Pro and see if what I believe appears to be true.
Otherwise, 500 ("Balance") produces around 42kSol and 550 ("Turbo") produces north of 50kSol... it'll probably land on 50kSol on a long average.
-j
|
|
|
|
is anyone else getting "mechanical failure" delays for their shipments? I'm yet to receive my z9s from batch 1. Very frustrating  mine are now delayed till MONDAY. |
|
|
|
That's what I expected. Everything I have tried doesn't allow me to make changes, they locked everything down on this. Piece of shit bitmain.. delay our miners and cost us 100s and 1000s just so they can limit what WE can do with OUR miners that we bought. Typical bitmain treating customers like shit. Literally costed us money so they can limit us to overclocking what we bought.
Copy the cgminer executable from one of the other Mini's and try it on the Z9 -- if anything, they simply modified the cgminer executable to only accept a set of specific frequencies. I expect that the cgminer functionality is otherwise the same and/or very darned similiar. -j |
|
|
|
Mine are running. Overclock ideas? As said in other thread: Turbo mode is 550m and runs about 48-50KH solid avg after running multiple z9's for 3 hours. I feel like if we can push these to 600 or 650m we def. have a solid 60kh miner on hands. The inspect element does not work as I just tried it on mine as well.
1) ssh in, cd /config, make a backup opy of cgminer.conf, edit cgminer.conf, change "bitmain-freq" value to something else... save file. 2) Run "/etc/init.d/d cgminer.sh restart" 3) Profit... hopefully. -j I am not used to ssh as much as other people, anyone try this to verify if it works on the z9? They blocked saving this on the batch 3 mini's I heard. While I didn't have a batch3, I think people just didn't know what they were doing... in theory I can test tomorrow when my DHL shipment arrives if someone else doesn't beat me to it. |
|
|
|
Turbo mode is 550m and runs about 48-50KH solid avg after running multiple z9's for 3 hours. I feel like if we can push these to 600 or 650m we def. have a solid 60kh miner on hands. The inspect element does not work as I just tried it on mine as well.
Try editing the config file? My UPS ones are delayed, again. :/ DHL arrives tomorrow, in theory. I can try it now if you can explain me in details how to or show me a link with explanation ssh to miner. edit /config/cgminer.conf see bitmain-freq in config file, change value. save file. "/etc/init.d/cgminer.sh restart" see: https://bitcointalk.org/index.php?topic=2056032.0-j |
|
|
|
Mine are running. Overclock ideas? As said in other thread: Turbo mode is 550m and runs about 48-50KH solid avg after running multiple z9's for 3 hours. I feel like if we can push these to 600 or 650m we def. have a solid 60kh miner on hands. The inspect element does not work as I just tried it on mine as well.
1) ssh in, cd /config, make a backup opy of cgminer.conf, edit cgminer.conf, change "bitmain-freq" value to something else... save file. 2) Run "/etc/init.d/d cgminer.sh restart" 3) Profit... hopefully. -j |
|
|
|
Turbo mode is 550m and runs about 48-50KH solid avg after running multiple z9's for 3 hours. I feel like if we can push these to 600 or 650m we def. have a solid 60kh miner on hands. The inspect element does not work as I just tried it on mine as well.
Try editing the config file? My UPS ones are delayed, again. :/ DHL arrives tomorrow, in theory. |
|
|
|
|
In theory DHL order arrives tomorrow.
UPS order is delayed yet again.
!@#!#
*EDIT*: Called UPS and apparently this is delayed due to "plane damage" -- so good news, BITMAIN will get a refund on the shipping.
!@#!#
-j
|
|
|
|
|
DHL shipment: The import duty/tax due on your shipment is USD 36.67.
.... vs $950 /each on UPS.
Meh.
-j
|
|
|
|
Z9's are showing up now. So.. anyone know how to overclock of if these can be? The max they run is 550m. I wanna see them at 650m
Mine got delayed due to "equipment failure" -- did yours actually arrive and can you confirm this? Or are you basing this on the fact that they have a 550Mhz image available for download? -j Mine arrive tomorrow, friend already has his so I can confirm. 500 is "balance" mode, 550 is "turbo" mode. I have heard that people were getting close to 50kh in the discord I am in, but my friend gets around 44-46kh in turbo mode and very quiet meaning the damn miner isn't even trying. This miner should be able to do at least 600-650m but we need to figure out how to actually overclock to that. Also, the inspect element trick does not seem to work and no firmware other than what it has to try so we gotta figure out another way unless we do actual editing of the cfg file. I was using the config file with my batch1 minis. I'd give that a shot. I'm also curious about the hash boards and how they compare to batch1 and batch2+. -j |
|
|
|
WTF is this shitola?
"A mechanical failure has delayed delivery.
We're adjusting plans to deliver your package as quickly as possible."
They got payment several months ago
They got tax paid.
Where is my stuff!?
What did I pay tariffs for???
Exact same thing with my UPS ones. My DHL order is awaiting customs clearance. Sigh. -j |
|
|
|
Z9's are showing up now. So.. anyone know how to overclock of if these can be? The max they run is 550m. I wanna see them at 650m
Mine got delayed due to "equipment failure" -- did yours actually arrive and can you confirm this? Or are you basing this on the fact that they have a 550Mhz image available for download? -j |
|
|
|
|
Show Posts
