m-labs / artiq

A leading-edge control system for quantum information experiments
https://m-labs.hk/artiq
GNU Lesser General Public License v3.0
425 stars 196 forks source link

kasli-soc remote reset #2250

Closed jbqubit closed 11 months ago

jbqubit commented 11 months ago

The existing script for loading firmware.bin and top.bit onto kasli-soc over JTAG+ethernet works fine from a cold start. However, once the uP is running firmware.bin it no longer works with artiq_netboot. A natural solution would be to reset kasli-soc over USB-JTAG however it looks like that's not supported by openocd. The result is that reflashing requires cycling the power. This isn't great as some systems may be remote or difficult to physically access.

Error: timed out while waiting for target halted
TARGET: zynq.cpu.0 - Not halted

I tried several openocd scripts with variants on reset but they fail with the same error (above).

sbourdeauducq commented 11 months ago

You need to pulse POR using the provided script.

sbourdeauducq commented 11 months ago

Xilinx hardware bug without other solution that I know of.

jbqubit commented 11 months ago

What does "pulse POR" mean?

jbqubit commented 11 months ago

I've looked at all the scripts and see no reference to POR or any other openocd commands.

sbourdeauducq commented 11 months ago

https://git.m-labs.hk/M-Labs/zynq-rs/src/branch/master/kasli_soc_por.py

You need to run this before each time you use JTAG.

jbqubit commented 11 months ago

Thanks, but your script doesn't work on my system. Perhaps our ftdi URLs differ? I'll check... Yours is ftdi://ftdi:4232h/0. Here's what it looks like on my system.

$ ftdi_urls.py 
Available interfaces:
  ftdi://ftdi:4232:1:54/1      (Quad RS232-HS)
  ftdi://ftdi:4232:1:54/2      (Quad RS232-HS)
  ftdi://ftdi:4232:1:54/3      (Quad RS232-HS)
  ftdi://ftdi:4232:1:54/4      (Quad RS232-HS)

None of these nor ftdi://ftdi:4232:1:54/0 permit flashing.

(base) britton@brittonlabbuild:~/m-labs/artiq-zynq$ ./flash.sh 
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Zynq CPU1.
Info : clock speed 1000 kHz
Info : JTAG tap: zynq.tap tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: zynq.dap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Info : zynq.cpu.0: hardware has 6 breakpoints, 4 watchpoints
Info : zynq.cpu.1: hardware has 6 breakpoints, 4 watchpoints
Info : zynq.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : zynq.cpu.1: MPIDR level2 0, cluster 0, core 1, multi core, no SMT
Info : starting gdb server for zynq.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
Info : JTAG tap: zynq.tap tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: zynq.dap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Warn : zynq.cpu.0: ran after reset and before halt ...
Info : zynq.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
Error: timeout waiting for DSCR bit change
Error: Error waiting for halt
Spaqin commented 11 months ago

Is a jumper installed on your Kasli-SoC - near the FPGA there's 4 pins, 2 of them are marked "PS_POR_B"?

If it's missing the POR script will do nothing (and also report nothing) and you still won't be able to flash.

jbqubit commented 11 months ago

Confirmed that this works! Thanks @sbourdeauducq and @Spaqin.

So, what do the two jumpers do on the PCB?

jbqubit commented 11 months ago

I've updated the wiki.