Bitcoin Forum
November 03, 2024, 12:45:14 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 »
1  Bitcoin / Mining support / Re: X17 Mystery Chip on: September 18, 2021, 02:45:45 PM
Not sure what you mean by the 'boost circuit'

Asicboost is a modification of the internal ASIC hashing function to produce more nonces.
Thus it's simply part of the internals of the BM1397 i.e. a change in the silicon design of the BM1397 vs pre S9 chips.

Hi Kano, This chip is located below the "boost circuit" zone according to the manual (image beow). I'm now leaning towards some type of linear regualtor but still guessing at this point.

https://drive.google.com/file/d/1vZ-mMlRZMI8XntUU3hC0SJa4MF-a6OjP/view?usp=sharing
2  Bitcoin / Mining support / X17 Mystery Chip on: September 18, 2021, 01:26:38 AM
I've been searching high and low for any clues on this mystery SXE chip by the boost circuit. Could anyone provide a clue what it is and if you can obtain it online. If so, where I could start to look. Or if anyone is selling a few of their personal stash of these I'd love to take a few off your hands.

https://drive.google.com/file/d/1xG1nWswjRZ-J_TJAzsqG365K60t_I7zK/view?usp=sharing


NKBTW

3  Bitcoin / Mining support / Re: Where to fix your Asic miners. on: September 07, 2021, 08:41:38 PM
Quote
Update

Last night s17+ turned off. Only hashing on 2 chains instead of 3 now. Emailed Core to see if I need to send it back or what to do. Will report back. I can get 50 tH out of it for the time being. Sounds like this is a common issues with the s17 series. Super frustrating.

It would be great to know how this is handled. 'After the repair' policy is something that is muddy at best, if at all.
4  Bitcoin / Mining support / Re: Where to fix your Asic miners. on: August 30, 2021, 08:18:35 PM
I had a S17+ repaired by Core Scientific

I recommend them. Works great. Needed 7 new chips installed. Great experience and very professional.

I had the opposite experience with Core Scientific. S17pro went in limping and came out of their facility much worse. Add insult to injury, it took over two months, when it was returned a heat sink was loose inside the box, and under a stereo microscope, one side of the PIC chip wasn't even touching it's pads after I assume they reflowed (had to resolder this myself and still doesn't work). The first diagnosis was all temp sensors were bad at a quote for $400 to a PIC, Boost circuit, some temp. sensors were bad on two boards - that were then deemed "unrepairable", $129. From my experience, there is one point of contact there - he is knowledgeable and professional when you are able to talk to him. As of Nov. 2020 they had 6 techs. there.  

Repair Initiation: A
Diagnosis: D
Customer Service while in repair: B
Actual Repairs: F
Pricing: B

5  Bitcoin / Mining support / Re: PIC Chip Errors (Again) on: August 17, 2021, 02:52:47 PM
A closing update: Thierry tried everything and we concluded it was a hardware issue after hours of work in diagnosis. Thank you Thierry for the efforts, merit given. The test output is below for the record if anyone else runs into this. The board will be sold for parts or will be at the bottom of the local river.

 
Code:
--- version:
last commit version: ac6658d commit time: 2019-06-19 17:54:11 build: 2019-06-19 18:10:08

--- cgpu_init
mmap axi_fpga_addr = 0xb6fc5000
axi_fpga_addr data = 0xb013
mmap fpga_mem_addr = 0xb5e55000
power firmware version is 00 06
power type APW9 3600W

---read_config: gHashBoard_BHB07601

CcDelay1_test_times = 0x04
CoreClockDelay1 = 0xb4
CcDelay2_test_times = 0x00
CoreClockDelay2 = 0xf4
gPattern_number = 8
Invalid_Asic_Num = 48
Invalid_Core_Num = 128
Least_nonce_per_core = 14
Most_HW_Num = 128
timeout_percent = 10
baudrate = 3
io_strength = 0x02172111
Only_find_ASIC = 0
pre_open_core_voltage = 2000
Voltage1 = 1800
StartTemp = 0
TargetTemp = 100
AlarmTemp = 105
fan_speed = 10
HashBoard_Hardware_Version_1 = 1
HashBoard_Hardware_Version_2 = 1
HashBoard_Bom_Version_1 = 1
HashBoard_Bom_Version_2 = 3
HashBoard_Product_ID = 0
repair_mode = 0
Dump_Lost_Nonce = 0
bad_chip_nonce_rate_upper_limit = 90
bad_chip_nonce_rate_lower_limit = 75
per_domain_received_nonce_limit = 110
per_asic_domain_received_nonce_limSun Aug 15 15:55:53 UTC 2021
it = 75
bad_chip_num = 1
check_sensor_times = 5

--- get_works_v2
get_works took 4.555s


Ready begin test


Begin singleBoardTest_BHB07601_BM1397 test


--- init_fpga
FPGA version 0xb013

--- reset_global_arg

--- check_chain

--- check_chain: gChain = 0, gI2c = 0

--- BHB07601_show_status_func: which_chain = 0, which_i2c = 0

--- singleBoardTest_BHB07601_BM1397: Test_EEPROM: Check EEPROM ok!!!

--- reset_dsPIC33EP16GS202_pic failed! read_back_data[0] = 0xff, read_back_data[1] = 0xff


--- jump_from_loader_to_app_dsPIC33EP16GS202 failed! read_back_data[0] = 0xff, read_back_data[1] = 0xff


--- heart_beat_dsPIC33EP16GS202 failed!


--- APW9_calculate_voltage: voltage_n = 48.745106, N = 48

--- set_pre_open_core_voltage: Conf.pre_open_core_voltage = 2000, N = 48
set_pre_open_core_voltage line 529: Enter hash board power on flow:
set_pre_open_core_voltage line 533: Reset hash board done

--- enable_dsPIC33EP16GS202_dc_dc

--- enable_dsPIC33EP16GS202_dc_dc failed! read_back_data[0] = 0x00, read_back_data[1] = 0x
6  Bitcoin / Mining support / Re: PIC Chip Errors (Again) on: August 14, 2021, 12:01:10 AM
Following up with thierry on discord. Will post if we find a solution. The latest is I checked with a MM (drew the layout and recorded the numbers) all capacitors surrounding the PIC chip with a good board and the numbers check out.
7  Bitcoin / Mining support / Re: PIC Chip Errors (Again) on: August 10, 2021, 01:56:41 AM
An update: So I replaced the PIC chip again, programmed it with the good board's hex (programmed successful and verified). Then used the latest Bitmain firmware to boot the miner. For some sick and twisted reason, it's back to PIC fw version = 0xff. Besides throwing it off the highest building in the city, is there anything I can do next? Could it be something with the EEPROM? I went ahead and tested the 3rd board and it also shows PIC fw version=0xb9 (hexcompare also shows they are the same). So two boards show 0xb9 but this one board keeps posting 0xff. At a total loss here and I'm all ears if you might be able to think of another approach.  Undecided
8  Bitcoin / Mining support / Re: PIC Chip Errors (Again) on: August 08, 2021, 02:59:30 PM
I went back and checked all the PIC chips Mfr. Part #'s on the boards against the one I bought. All are dsPIC33EP16's however the numbers below them don't match up. Also, the one I bought is an E/SS - they seem to come in different flavors.

The ones I bought are here https://www.mouser.com/ProductDetail/Microchip-Technology/dsPIC33EP16GS202T-E-SS?qs=3K5NeMAIBDnNgLENVtd%2Fng%3D%3D

The numbers below the dsPIC33EP16 printed on the chips vary:

Bought PIC chips from Mouser # is 201048B. (edit) the old removed chip 1812A4E
On Board 1 = 1812A
On Board 2 = 1812A46


9  Bitcoin / Mining support / Re: PIC Chip Errors (Again) on: August 08, 2021, 01:24:07 PM
If the PIC file that you flash is from modified firmware I heard that you will get an error and the firmware version will turn to "PIC fw version=0xff" and also you will get that issue if you didn't set the voltage properly.

So possible that the PIC chip is bricked. Do you have an extra PIC chip? Use the extra PIC chip and don't use hot air to solder it use a soldering iron and check if it is in the right position and then repeat the procedure from thierry4wd's post but this time make sure it was from the original stock firmware don't use non-stock firmware this might be the reason why you get the "PIC fw version=0xff".

Also, take note if you misconfigure the memory settings it will erase the other program from the chip that may lead to bricked chip.

Thanks Bit, I think I can go back and Erase the chip, Blank Check, and Verify inside of MPLAB IPE instead of replacing the chip? I used soldering iron on this one and have two more spares. I'm really hoping not to have to replace it again.  Undecided

Those memory settings were from programing the new PIC chip with the good PIC chip from the other good board. What I do is hook up the good board, Press the Read button, then go File>Export>Hex. I also compared hex file sizes with the T9 I think it's 62.2kb and my exported one is 63kb. So that seems to make sense.
10  Bitcoin / Mining support / Re: PIC Chip Errors (Again) on: August 08, 2021, 02:33:01 AM
Thanks for this direction, there is def a glitch in my process somewhere. I threw the good board in and got exactly what you described.

Quote
2021-08-08 01:41:47 board.c:36:jump_and_app_check_restore_pic: chain[1] PIC jump to app
2021-08-08 01:41:49 board.c:40:jump_and_app_check_restore_pic: Check chain[1] PIC fw version=0xb9
2021-08-08 01:41:49 thread.c:778:create_pic_heart_beat_thread: create thread

Attached are images to my last attempt to transfer the hex in MPLAB and an image of the memory settings because I get that error "MPLAB's memory is blank so no programming operation was attempted" if I don't use "manual" in the drop down. I'm not sure if this issue is connected in some way and in addition, I'm not sure you can check firmware version after programming in MPLAB IPE v5.50?

https://drive.google.com/file/d/17fim5jZ3uOYlWNrmfMHy8P7I9Jj3XKvB/view?usp=sharing
https://drive.google.com/file/d/1S542Y1p1xquG3lYRuWTmwRbKHQABMvJt/view?usp=sharing

To be sure it couldn't be anything else, I triple-checked all solder pads at and around the PIC location and checked all capacitors with a MM. Things seem to check out on that front.

This is humbling but I'm grateful for the help.

 
11  Bitcoin / Mining support / Re: PIC Chip Errors (Again) on: August 07, 2021, 06:45:18 PM
Installed Bitmain's original firmware Bitmain_Antminer-S17Pro-user-OM-201908201037-sig. I've included the whole log and what sticks out is

Chain[2] PIC init failed!
set_miner_status: ERROR_SOC_INIT
stop mining: soc init failed!

So replaced PIC chip with new, flashed a good hex onto it. I'm not sure what to look for next and appreciate any direction on next moves. Thank you.

Edit: I am running with just this board connected.


Code:

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) ) #25 SMP PREEMPT Fri Nov 23 15:30:52 CST 2018
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
On node 0 totalpages: 61440
free_area_init_node: node 0, pgdat c0b39280, node_mem_map cde10000
  Normal zone: 480 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 61440 pages, LIFO batch:15
percpu: Embedded 12 pages/cpu @cddf1000 s19776 r8192 d21184 u49152
pcpu-alloc: s19776 r8192 d21184 u49152 alloc=12*4096
pcpu-alloc: [0] 0 [0] 1
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: 203504K/245760K available (6345K kernel code, 231K rwdata, 1896K rodata, 1024K init, 223K bss, 25872K reserved, 16384K cma-reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xcf800000 - 0xff800000   ( 768 MB)
    lowmem  : 0xc0000000 - 0xcf000000   ( 240 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc090c424   (9234 kB)
      .init : 0xc0a00000 - 0xc0b00000   (1024 kB)
      .data : 0xc0b00000 - 0xc0b39fe0   ( 232 kB)
       .bss : 0xc0b39fe0 - 0xc0b71c28   ( 224 kB)
Preemptible hierarchical RCU implementation.
Build-time adjustment of leaf fanout to 32.
RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
efuse mapped to cf800000
ps7-slcr mapped to cf802000
L2C: platform modifies aux control register: 0x72360000 -> 0x72760000
L2C: DT/platform modifies aux control register: 0x72360000 -> 0x72760000
L2C-310 erratum 769419 enabled
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 ID prefetch enabled, offset 1 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 8 ways, 512 kB
L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x76760001
zynq_clock_init: clkc starts at cf802100
Zynq clock init
sched_clock: 64 bits at 333MHz, resolution 3ns, wraps every 4398046511103ns
clocksource: arm_global_timer: mask: 0xffffffffffffffff max_cycles: 0x4ce07af025, max_idle_ns: 440795209040 ns
Switching to timer-based delay loop, resolution 3ns
clocksource: ttc_clocksource: mask: 0xffff max_cycles: 0xffff, max_idle_ns: 537538477 ns
ps7-ttc #0 at cf80a000, irq=18
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 666.66 BogoMIPS (lpj=3333333)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x100000 - 0x100058
CPU1: failed to boot: -1
Brought up 1 CPUs
SMP: Total of 1 processors activated (666.66 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor menu
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
zynq-ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xcf880000
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
media: Linux media interface: v0.10
Linux video capture interface: v2.00
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
EDAC MC: Ver: 3.0.0
Advanced Linux Sound Architecture Driver Initialized.
clocksource: Switched to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 1, 8192 bytes)
TCP bind hash table entries: 2048 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 0 bytes, default 64
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 12832K (cce79000 - cdb01000)
hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
futex hash table entries: 512 (order: 3, 32768 bytes)
workingset: timestamp_bits=28 max_order=16 bucket_order=0
jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
dma-pl330 f8003000.ps7-dma: Loaded driver for PL330 DMAC-241330
dma-pl330 f8003000.ps7-dma: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 158, base_baud = 6249999) is a xuartps
console [ttyPS0] enabled
xdevcfg f8007000.ps7-dev-cfg: ioremap 0xf8007000 to cf86e000
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
loop: module loaded
CAN device driver interface
gpiod_set_value: invalid GPIO
libphy: MACB_mii_bus: probed
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 31 (00:0a:35:00:00:00)
Generic PHY e000b000.etherne:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
Xilinx Zynq CpuIdle Driver started
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: SDHCI controller on e0100000.ps7-sdio [e0100000.ps7-sdio] using ADMA
ledtrig-cpu: registered to indicate activity on CPUs
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAGAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
nand: WARNING: pl35x-nand: the ECC used on your system is too weak compared to the one required by the NAND chip
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
nand_read_bbt: bad block at 0x000002420000
nand_read_bbt: bad block at 0x000002440000
nand_read_bbt: bad block at 0x000002460000
6 ofpart partitions found on MTD device pl35x-nand
Creating 6 MTD partitions on "pl35x-nand":
0x000000000000-0x000002800000 : "BOOT.bin-env-dts-kernel"
0x000002800000-0x000004800000 : "ramfs"
0x000004800000-0x000005000000 : "configs"
0x000005000000-0x000006000000 : "reserve"
0x000006000000-0x000008000000 : "ramfs-bak"
0x000008000000-0x000010000000 : "reserve1"
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
can: broadcast manager protocol (rev 20120528 t)
can: netlink gateway (rev 20130117) max_hops=1
zynq_pm_ioremap: no compatible node found for 'xlnx,zynq-ddrc-a05'
zynq_pm_late_init: Unable to map DDRC IO memory.
Registering SWP/SWPB emulation handler
hctosys: unable to open rtc device (rtc0)
ALSA device list:
  No soundcards found.
RAMDISK: gzip image found at block 0
EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (ram0): mounted filesystem without journal. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 1024K (c0a00000 - c0b00000)
EXT4-fs (ram0): re-mounted. Opts: block_validity,delalloc,barrier,user_xattr
random: dd urandom read with 0 bits of entropy available
ubi0: attaching mtd2
ubi0: scanning is finished
ubi0: attached mtd2 (name "configs", size 8 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 4/2, WL threshold: 4096, image sequence number: 2669066886
ubi0: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 40
ubi0: background thread "ubi_bgt0d" started, PID 708
UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 711
UBIFS (ubi0:0): recovery needed
UBIFS (ubi0:0): recovery completed
UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "configs"
UBIFS (ubi0:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS (ubi0:0): FS size: 1396736 bytes (1 MiB, 11 LEBs), journal size 888833 bytes (0 MiB, 5 LEBs)
UBIFS (ubi0:0): reserved for root: 65970 bytes (64 KiB)
UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 9310506E-3F77-43CC-B7AB-7CFF20C05DA7, small LPT model
ubi1: attaching mtd5
ubi1: scanning is finished
ubi1: attached mtd5 (name "reserve1", size 128 MiB)
ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi1: good PEBs: 1020, bad PEBs: 4, corrupted PEBs: 0
ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi1: max/mean erase counter: 53/24, WL threshold: 4096, image sequence number: 121791118
ubi1: available PEBs: 0, total reserved PEBs: 1020, PEBs reserved for bad PEB handling: 36
ubi1: background thread "ubi_bgt1d" started, PID 720
UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 723
UBIFS (ubi1:0): recovery needed
UBIFS (ubi1:0): recovery completed
UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "reserve1"
UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
UBIFS (ubi1:0): FS size: 123039744 bytes (117 MiB, 969 LEBs), journal size 6221824 bytes (5 MiB, 49 LEBs)
UBIFS (ubi1:0): reserved for root: 4952683 bytes (4836 KiB)
UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID 15BA4C69-FA5C-4D1E-BF20-090C8AD78A1C, small LPT model
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
macb e000b000.ethernet eth0: unable to generate target frequency: 25000000 Hz
macb e000b000.ethernet eth0: link up (100/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
In axi fpga driver!
request_mem_region OK!
AXI fpga dev virtual address is 0xcfb38000
*base_vir_addr = 0xab013
In fpga mem driver!
request_mem_region OK!
fpga mem virtual address is 0xd2000000
random: nonblocking pool is initialized
2021-08-07 18:20:04 driver-btm-api.c:758:init_freq_mode: This is scan-user version
2021-08-07 18:20:04 driver-btm-api.c:1954:bitmain_soc_init: opt_multi_version     = 1
2021-08-07 18:20:04 driver-btm-api.c:1955:bitmain_soc_init: opt_bitmain_ab        = 1
2021-08-07 18:20:04 driver-btm-api.c:1956:bitmain_soc_init: opt_bitmain_work_mode = 0
2021-08-07 18:20:04 driver-btm-api.c:1957:bitmain_soc_init: Miner compile time: Tue Aug 20 10:37:07 CST 2019 type: Antminer S17 Pro
2021-08-07 18:20:04 driver-btm-api.c:1958:bitmain_soc_init: commit version: 4b64fd6 2019-08-19 22:09:12, build by: lol 2019-08-20 10:47:29
2021-08-07 18:20:04 driver-btm-api.c:1776:show_sn: no SN got, please write SN to /nvdata/sn
2021-08-07 18:20:04 driver-btm-api.c:1236:miner_device_init: Detect 256MB control board of XILINX
2021-08-07 18:20:04 driver-btm-api.c:1184:init_fan_parameter: fan_eft : 0  fan_pwm : 0
2021-08-07 18:20:04 thread.c:653:create_read_nonce_reg_thread: create thread
2021-08-07 18:20:10 driver-btm-api.c:1168:init_miner_version: miner ID : 8164ac2e57408854
2021-08-07 18:20:10 driver-btm-api.c:1174:init_miner_version: FPGA Version = 0xB013
2021-08-07 18:20:11 driver-btm-api.c:820:get_product_id: product_id[2] = 0
2021-08-07 18:20:11 driver-btm-api.c:771:_set_project_type: project:0
2021-08-07 18:20:11 driver-btm-api.c:796:_set_project_type: Project type: Antminer S17 Pro
2021-08-07 18:20:11 driver-btm-api.c:807:dump_pcb_bom_version: Chain [2] PCB Version: 0x0101
2021-08-07 18:20:11 driver-btm-api.c:808:dump_pcb_bom_version: Chain [2] BOM Version: 0x0103
2021-08-07 18:20:15 driver-btm-api.c:1877:bitmain_board_init: Fan check passed.
2021-08-07 18:20:26 driver-btm-api.c:309:init_pic: Chain[2] PIC init failed!
2021-08-07 18:20:26 driver-btm-api.c:191:set_miner_status: ERROR_PIC_LOST
2021-08-07 18:20:26 board.c:36:jump_and_app_check_restore_pic: chain[2] PIC jump to app
2021-08-07 18:20:48 board.c:40:jump_and_app_check_restore_pic: Check chain[2] PIC fw version=0xff
2021-08-07 18:20:48 driver-btm-api.c:191:set_miner_status: ERROR_SOC_INIT
2021-08-07 18:20:48 driver-btm-api.c:132:stop_mining: stop mining: soc init failed!
2021-08-07 18:20:48 thread.c:698:cancel_read_nonce_reg_thread: cancel thread
2021-08-07 18:20:48 driver-btm-api.c:118:killall_hashboard: ****power off hashboard****
12  Bitcoin / Mining support / Re: PIC Chip Errors (Again) on: August 07, 2021, 12:36:56 PM
An update: See below after hooking the board up again to MPLAB after trying to boot the miner with the non-stock firmware, I haven't confirmed it will work with stock yet but it seems to revert to errors as thierry4wd has pointed out. Next is to erase this and put the good hex on from the other good board and boot with stock firmware.

Code:
The following memory area(s) will be verified:
program memory: start address = 0x0, end address = 0x2b7f
configuration memory
[ Pgm ] at 0x0, expected 0x00040200, got 0x00ffffff.
You have set the program speed to Normal. The circuit on your board may require you to slow the speed down. Please change the setting in the tool properties to low and try the operation again.
Verify failed
Verify Failed
13  Bitcoin / Mining support / PIC Chip Errors (Again) on: August 07, 2021, 02:01:03 AM
Hello all, I put a new PIC chip on an S17pro board following thierry4wd's informative guide here: https://bitcointalk.org/index.php?topic=5032987.0 and some PIC errors. The hope was to resolve these issues. MPLAB process went well and hopefully, I can put up a quick guide for S17's because there are some nuances.

Although I did get "MPLAB's memory is blank so no programming operation was attempted" and had to switch to manual in the memory settings to Program Memory Range(s)(hex) to 0-2b7f (not sure if this is correct for the dsPIC33EP16) to successfully program from "Let PIC Kit Choose". In the Memory settings tab: Configuration Memory was checked and Program Memory was also checked. Preserve Program Memory was Unchecked and Preserve Program Memory Range(s)(hex) was left blank. So I'm uncertain if that has something to do with the errors below in the kernel log.

Another possibility is thierry said to use only the stock firmware, after MPLAB flash and when booting with the hashboard in question. - I didn't do that because I was using a third party firmware and thought the hex on the good board and transferring it to the new PIC board would be OK since they are all running the firmware. Maybe understanding is off and that the hex information has nothing to do with what firmware you are running (not sure). Can anyone take a look at my steps and the log errors and suggest where this might have gone wrong and a possible solution? Appreciate it!   

Code:
[2021/08/07 01:09:03] INFO: Detected 256 Mb of RAM
[2021/08/07 01:09:03] INFO: Switching to manual fan control (30 %)
[2021/08/07 01:09:03] INFO: Checking fans
[2021/08/07 01:09:04] INFO: fan[0] - OK
[2021/08/07 01:09:04] INFO: fan[1] - OK
[2021/08/07 01:09:04] INFO: fan[2] - OK
[2021/08/07 01:09:04] INFO: fan[3] - OK
[2021/08/07 01:09:10] INFO: Power ON
[2021/08/07 01:09:12] INFO: Starting FPGA queue
[2021/08/07 01:09:12] INFO: Initializing hash boards
[2021/08/07 01:09:12] INFO: chain[2] - Initializing
[2021/08/07 01:09:14] WARN: chain[2] - Failed to reset pic (attempt = 1), resp: 0x00 0x00
[2021/08/07 01:09:16] WARN: chain[2] - Failed to reset pic (attempt = 2), resp: 0x00 0x00
[2021/08/07 01:09:17] WARN: chain[2] - Failed to reset pic (attempt = 3), resp: 0x00 0x00
[2021/08/07 01:09:18] WARN: chain[2] - Failed to start pic app (attempt = 1), resp: 0x00 0x00
[2021/08/07 01:09:19] WARN: chain[2] - Failed to start pic app (attempt = 2), resp: 0x00 0x00
[2021/08/07 01:09:19] WARN: chain[2] - Failed to start pic app (attempt = 3), resp: 0x00 0x00
[2021/08/07 01:09:21] WARN: chain[2] - Failed to reset pic (attempt = 1), resp: 0x00 0x00
[2021/08/07 01:09:22] WARN: chain[2] - Failed to reset pic (attempt = 2), resp: 0x00 0x00
[2021/08/07 01:09:24] WARN: chain[2] - Failed to reset pic (attempt = 3), resp: 0x00 0x00
[2021/08/07 01:09:24] WARN: chain[2] - Failed to start pic app (attempt = 1), resp: 0x00 0x00
[2021/08/07 01:09:25] WARN: chain[2] - Failed to start pic app (attempt = 2), resp: 0x00 0x00
[2021/08/07 01:09:25] WARN: chain[2] - Failed to start pic app (attempt = 3), resp: 0x00 0x00
[2021/08/07 01:09:27] WARN: chain[2] - Failed to reset pic (attempt = 1), resp: 0x00 0x00
[2021/08/07 01:09:28] WARN: chain[2] - Failed to reset pic (attempt = 2), resp: 0x00 0x00
[2021/08/07 01:09:30] WARN: chain[2] - Failed to reset pic (attempt = 3), resp: 0x00 0x00
[2021/08/07 01:09:31] WARN: chain[2] - Failed to start pic app (attempt = 1), resp: 0x00 0x00
[2021/08/07 01:09:31] WARN: chain[2] - Failed to start pic app (attempt = 2), resp: 0x00 0x00
[2021/08/07 01:09:32] WARN: chain[2] - Failed to start pic app (attempt = 3), resp: 0x00 0x00
[2021/08/07 01:09:32] ERROR: driver-btm-chain.c:465 chain[2] - Failed to init pic controller
[2021/08/07 01:09:32] INFO: chain[2] - Shutting down the chain
[2021/08/07 01:09:32] ERROR: driver-btm-base.c:356 chain[2] - Initialization failed
[2021/08/07 01:09:32] ERROR: driver-btm-base.c:2154 Failed to initialize hash boards
[2021/08/07 01:09:32] INFO: Shutting down the miner
[2021/08/07 01:09:32] INFO: Stopping FPGA queue
[2021/08/07 01:09:32] INFO: chain[2] - Shutting down the chain
[2021/08/07 01:09:32] INFO: Power OFF
14  Bitcoin / Hardware / Re: Hacking Antminer S17's and T17's because.... are we up to these already???? on: August 03, 2021, 11:13:01 PM
S17's and such have a nice little extra feature: They have that copper top that has solder on it, remember?

Then take out the board and put the heat sink on. Remember, no pre-heat, put a bit of flux on the center of the heat sink, line up the sink perfectly (the flux will hold it in place) then low flow heat from the air tool to secure the heat sink again.

I'm a bit confused by this. If you put on a new chip and clean the solder off from the bottom of the removed heat sink. You don't need solder paste and just throw the heat sink on with a little tacky flux because that copper on top of the new chip has solder in it?
15  Bitcoin / Mining support / Re: PIC Kit 4 cable for S17 Pro on: August 03, 2021, 02:51:32 AM
The Picture one is pretty clear of that.
Those where the standard cables used for example on arduino boards.
Like that:
https://www.ebay.de/itm/112284236795?hash=item1a24a97bfb:g:Xb8AAOSwA3dYjIas



I see where to plug the male pins into the board. There are 5 circular holes and 1 square hole near the circular capacitors on the S17. The link to the cables is super helpful. Thank you.
16  Bitcoin / Mining support / Re: PIC Kit 4 cable for S17 Pro on: August 01, 2021, 01:09:15 PM
Thanks thierry, Your post was actually the first post I looked at before posting my question here. There looks to be a six PIN cable that plugs into the bottom of the PIC KIT module - then into the board. I couldn't find a mention of it in your thread. Maybe I am overlooking how to connect the PIC Kit to the S17?
17  Bitcoin / Mining support / PIC Kit 4 cable for S17 Pro on: July 31, 2021, 04:35:48 PM
Hi guys, I am circling back on fixing a board with a bad PIC chip. I will be replacing the chip but have no idea what cable will hook into the PIC kit module and the hash boards to be able to extract from one of my good boards then copy that onto this new chip I'll be putting on. Can anyone point me in the right direction?

Thank You!
18  Bitcoin / Mining support / Re: S17 Pro Back from Repairs or Disrepair. on: May 22, 2021, 03:53:23 PM
Success, Thank you.
19  Bitcoin / Mining support / Re: S17 Pro Back from Repairs or Disrepair. on: May 22, 2021, 12:34:24 AM
I can order the 33ohm 0201s in low quantities ok. On the caps, Digi is 10,000 minimum and Mouser is out of stock - is there another reliable source I may be overlooking? Might try the shield, in addition to laying some 3M thermal protective tape down next time. Some make it look so easy.
20  Bitcoin / Mining support / Re: S17 Pro Back from Repairs or Disrepair. on: May 20, 2021, 10:49:00 PM
These are on the imperceptible scale until you put them under the scope.  I had a heat shield surrounding the chip to protect against just this and bumped it - this is the result. I circled the ones missing in red and seem to match the ones you have circled. To confirm, these are 33ohms? I see there is a mix of 16v and 6.3v and .1uf and 1uf I am having referencing your image these are arranged differently than mine. I'm guessing the C86 and C84 are 1uf 6.3v each.  Always, fantastic again helping narrow this down.

https://drive.google.com/file/d/1dTTemJ5p_tO1IKapT-JEEDsAXIpJRPOm/view?usp=sharing
Pages: [1] 2 3 4 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!