Much like Petalinux, Vitis is massively underdocumented. So keeping a list of all the random bugs and crap here!

• If a board powers on but shows up with only "dummy_dap_0" it basically means the processor isn't running (it hasn't finished its boot ROM). Xilinx tries to point you in lots of complicated directions, but basically you need to check power supplies and check that the PS clock is running (On an HTG-ZRF and its derivatives, you have to program the clock first before you can boot).

• If you try to load a Hello World program through Vitis (or any program really) and it just hangs at the FSBL (giving a "timeout" or some such) - the DDR settings are probably wrong. If you just try to proceed through the FSBL blindly it'll try to write into the DDR and everything will go to hell because it actually wasn't set up right.

If you don't need to mess with the PL logic, it's faster to just redownload stuff yourself in xsct.

• Select processor using targets command
• rst -processor -clear-registers
• dow <app.elf> (where <app.elf> is the name of the application)

When debugging it's usually easiest to start out with JTAG boot mode forced, because in that mode at power on you can always access the PS easily. Then what you do is force a new boot mode, and reset.

If you search for this, you'll find lots of cryptic random hex character commands that should be entered in xsct (mwr 0xff5e0200 0xe100). "mwr/mrd" are memory write/read commands, and "0xFF5E0200" is BOOT_MODE_USER. The "100" at the bottom sets the "use_alt" bit, and then the "e" above it sets the boot mode. So the magic values here are

• mwr 0xff5e0200 0x0100 : JTAG boot
• mwr 0xff5e0200 0x1100 : 24-bit QSPI (QSPI under 256Mb)
• mwr 0xff5e0200 0x2100 : 32-bit QSPI (QSPI equal or over 256Mb)
• mwr 0xff5e0200 0x3100 : boot from SD0 using SD 2.0
• mwr 0xff5e0200 0x4100 : boot from NAND
• mwr 0xff5e0200 0x5100 : boot from SD1 using SD 2.0
• mwr 0xff5e0200 0x6100 : boot from eMMC
• mwr 0xff5e0200 0x7100 : boot from USB
• mwr 0xff5e0200 0x8100 : boot from dedicated processor JTAG using MIO[29:26]
• mwr 0xff5e0200 0x9100 : boot from dedicated processor JTAG using MIO[15:12]
• mwr 0xff5e0200 0xe100 : boot from SD1 using SD 3.0 with level shifter

Note that "SD1 LS" is not "low speed," it's "level shift."

If you are in a different boot mode other than JTAG, you can still force a new boot mode - however, you need to reset the MultiBoot system first via:

• mwr 0xffca0010 0x0 : reset MultiBoot to ZERO

After running the mwr command(s), rst -system will kick things through the BootROM with the new configuration. Note that xsct wants to be targeting the PSU when it does this, so you connect, then target the PSU.

If your new boot target actually worked, you will see a Reset Catch immediately after rst -system, because the boot process successfully found a configuration and then attempted to start the boot process, triggering the Reset at the debugger. You can then execute con (continue) to have the boot process continue.