January 19, 2025

Antminer S9 board - JTAG and SD card booting

So I placed a BOOT.BIN onto and SD card and try booting it in the Antminer. No results. I check the boot mode jumpers, then decide to pull out the JTAG. After repairing/replacing the JTAG cable, I am ready to go using my unit "A" for these tests. I plug in the Segger: 
Jan 19 16:55:37 trona kernel: usb 4-1.6: new full-speed USB device number 4 using ehci-pci
Jan 19 16:55:37 trona kernel: usb 4-1.6: New USB device found, idVendor=1366, idProduct=0101, bcdDevice= 1.00
Jan 19 16:55:37 trona kernel: usb 4-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 19 16:55:37 trona kernel: usb 4-1.6: Product: J-Link
Jan 19 16:55:37 trona kernel: usb 4-1.6: Manufacturer: SEGGER
Jan 19 16:55:37 trona kernel: usb 4-1.6: SerialNumber: 001631096578
This looks promising. This is my cheap Ebay Segger clone.

I have some files in /u1/Projects/OpenOCD -- I do this: 

cd /u1/Projects/OpenOCD
openocd -f ebaz.cfg
Then in another window: 
telnet localhost 4444
targets
    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0  zynq.cpu0          cortex_a   little zynq.cpu           running
 1* zynq.cpu1          cortex_a   little zynq.cpu           running
It is a good thing I have some old notes to follow. We don't care about target 1 (the second core), so we switch back to target 0 (the first core), and halt the processor. 
> targets zynq.cpu0
> targets
    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* zynq.cpu0          cortex_a   little zynq.cpu           running
 1  zynq.cpu1          cortex_a   little zynq.cpu           running
 halt
 zynq.cpu0: MPIDR level2 0, cluster 0, core 0, multi core, no SMT
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x200001df pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> arm disassemble 0 32
0x00000000  0000 0000	andeq	r0, r0, r0
0x00000004  0000 0000	andeq	r0, r0, r0
0x00000008  0000 0000	andeq	r0, r0, r0
0x0000000c  0000 0000	andeq	r0, r0, r0
You can just type "target 0". It will work, but it will scold you.

It doesn't look like anything got loaded into OCM at address 0 like it should have. And when we look at the region around where the CPU is running, we see: 

> arm disassemble 0xffffff00 64
0xffffff00  0004 f800	.byte	0x04, 0x00, 0x00, 0xf8
0xffffff04  767b 0000	andeq	r7, r0, fp, ror r6
0xffffff08  0000 0000	andeq	r0, r0, r0
0xffffff0c  0000 0000	andeq	r0, r0, r0
0xffffff10  0000 0000	andeq	r0, r0, r0
0xffffff14  0000 0000	andeq	r0, r0, r0
0xffffff18  0005 0000	andeq	r0, r0, r5
0xffffff1c  0000 0000	andeq	r0, r0, r0
0xffffff20  f04f f57f	dsb	sy
0xffffff24  f002 e320	wfe
0xffffff28  fffc eaff	b	#0xffffff20
0xffffff2c  f04f f57f	dsb	sy
0xffffff30  f002 e320	wfe
0xffffff34  000f e3e0	mvn	r0, #0xf
0xffffff38  e000 e590	ldr	lr, [r0]
0xffffff3c  00d4 e37e	cmn	lr, #0xd4
0xffffff40  fff9 0aff	beq	#0xffffff2c
0xffffff44  0f15 ee07	mcr	p15, #0, r0, c7, c5, #0
0xffffff48  0fd5 ee07	mcr	p15, #0, r0, c7, c5, #6
0xffffff4c  0f17 ee08	mcr	p15, #0, r0, c8, c7, #0
0xffffff50  4000 e3a0	mov	r4, #0
0xffffff54  4f10 ee01	mcr	p15, #0, r4, c1, c0, #0
0xffffff58  ff1e e12f	bx	lr
0xffffff5c  0000 0000	andeq	r0, r0, r0
0xffffff60  0000 0000	andeq	r0, r0, r0
And for the record I still get this when I try to reset the processor: 
> reset halt
JTAG tap: zynq_pl.bs tap/device found: 0x13722093 (mfg: 0x049 (Xilinx), part: 0x3722, ver: 0x1)
JTAG tap: zynq.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
zynq.cpu0: how to reset?
This is either a bug or (more likely) I need to configure something so it knows how to do a reset.

Two sanity checks

First, I fired up my hot air rework station and moved the resistor (shunt) to configure button S1 on my Antminer board "A" as a reset button.

Second, I grabbed a working SD card, the one I use to boot up Kyu over the network, found BOOT.bin on that card, copied it to BOOT.BIN on the card I am using for test and tried it. It put it into board A, hit the reset button, and voila! It boots U-boot. This confirms that there isn't something pathological about this particular SD card and that I haven't screwed up the settings of those boot jumpers. I can also try some experiments using this BOOT.bin image.

Third, I hex dumped my two BOOT.BIN images, the one that worked (from my Kyu network boot) and the one built with my tool. I compared entries in the header and found a stupid mistake. I had the image size set to zero. Once I fixed this everything worked.

So I didn't need JTAG to sort this out, but it was interesting to get it all set up again. Now I see: 

> halt
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x200001df pc: 0x0000018c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org