June 22, 2024

Antminer S9 board - NAND memory -- analysis of my bricked unit

My board C is now "bricked". It will launch the FSBL, but it fails to launch U-Boot. What I did to cause this disaster was: 
zynq-uboot> saveenv
Saving Environment to NAND...
Erasing NAND...
Erasing at 0xe0000 -- 100% complete.
Writing to NAND... OK

Read the NAND image

I have an SD card now in this system that does run U-Boot. I am also pleased to find that it has NAND support. So, I get to the U-boot prompt and do this: 
nand read 0 0
set ipaddr 192.168.0.144
tftpput 0 2000000 192.168.0.5:bricked
And just that easy, I now have a 32M file on my linux system that I can dump and study.

I look at the announced address 0xe0000 and what do I see: 

000e0000 e97932ea 64756162 65746172 3531313d    2y baudrate=115
000e0010 00303032 73746962 61657274 6d695f6d   200 bitstream_im
000e0020 3d656761 74737973 622e6d65 622e7469   age=system.bit.b
000e0030 62006e69 5f746f6f 67616d69 4f423d65   in boot_image=BO
000e0040 622e544f 62006e69 5f746f6f 3d75796b   OT.bin boot_kyu=
000e0050 6f686365 6f6f4220 676e6974 75794b20   echo Booting Kyu
000e0060 61697620 63686420 66742f70 203b7074    via dhcp/tftp;
000e0070 70636864 6f67203b 627b2420 61746f6f   dhcp; go ${boota
000e0080 7d726464 6f6f6200 69735f74 303d657a   ddr} boot_size=0
000e0090 30304678 00303030 746f6f62 7466745f   xF00000 boot_tft
000e00a0 63653d70 42206f68 69746f6f 4b20676e   p=echo Booting K
000e00b0 76207579 74206169 20707466 6674203b   yu via tftp ; tf
000e00c0 6f627074 2420746f 6f6f627b 64646174   tpboot ${bootadd
000e00d0 62207d72 6f637469 622e6e69 3b206e69   r} bitcoin.bin ;
000e00e0 206f6720 6f627b24 6461746f 007d7264    go ${bootaddr}
000e00f0 746f6f62 72646461 3278303d 30303030   bootaddr=0x20000
000e0100 00303030 746f6f62 73677261 696f6e3d   000 bootargs=noi
000e0110 7274696e 656d2064 39343d6d 63204d36   nitrd mem=496M c
......
......
000e0d90 646d6172 5f6b7369 67616d69 26207d65   ramdisk_image} &
000e0da0 6f622026 206d746f 30337830 30303030   & bootm 0x300000
000e0db0 78302030 30303032 20303030 41327830   0 0x2000000 0x2A
000e0dc0 30303030 66203b30 6f7a0069 7a3d6b72   00000; fi zork=z
000e0dd0 7a007061 6d3d327a 6d617465 6870726f   ap zz2=metamorph
000e0de0 7a006369 613d7a7a 67696c6c 726f7461   ic zzz=alligator
000e0df0 00000000 00000000 00000000 00000000
Based on what I see in my reference image, this should all be zeros. It should not be that hard to use the same U-boot on the SD card that I used to dump this out and make this zeros again and then see if the system is "all better". Just for the record 0xdf0 is 3568 bytes -- a bit under 7*512
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org