It's crazy, but can be done by those who like to suffer.  The easiest way is an officially supported Windows IDE.  The hardest way is Openocd on Linux.   Both methods require an STM32 demo board.  All the STM32 demo boards have an STLink programmer with an SWD header for external boards.  There's no reason to use the full JTAG interface.  All you need are the SWDIO & SWDCLK pins.

Dev boards for the highest end STM32's now cost little more than the STM32 chip itself, so it's not worth building your own JTAG programmer with a custom driver like the lion kingdom did in 2012, back when there was a severe price difference.  The SWD header on the Nucleo-F767 & probably most other boards is 

pin 1: VDD, SWDCLK, GND, SWDIO, NRST, SWO

On the Nucleo, it connected to the dev board via jumpers on the back.  You have to remove the jumpers.  Connect SWDIO, SWDCLK, & GND to your board.  The command for running openocd for the STM32H7 is

openocd -f interface/stlink.cfg -c "adapter_khz 1000; transport select hla_swd" -f target/stm32h7x.cfg

In another console:

telnet localhost 4444

Normally, the journey begins with a reset halt command.  This currently doesn't work & neither does soft_reset_halt.  You have to invoke the reset & halt in separate commands.  To write the flash:

halt;flash write_image erase program.bin 0x8000000;reset

This normally has to be run once with an error.  Then the chip has to be power cycled & the line run again.  At this point, it's left running a program in SRAM for writing the flash.  You have to power cycle it again to boot into the flash.  The BOOT pin has to be grounded.  The line does something which causes the 1st power cycle to not boot into flash but write successfully & the second power cycle to boot into the flash but not write successfully.  

Since reset halt doesn't work, breakpoints & stepping are useless.  You have to put in infinite loops to iron out those 1st bugs.  After power cycling it, issue a halt command, which gives the wrong program counter.  Step it a few times through the loop to get the real program counter.  The lion kingdom used just the program counter & the symbol table from nm|sort, but a sane human might use gdb.

The 1st task of your program is configuring the clock.  As an extra bonus, the way the STM32H7  calculates its clock speed from a crystal is 

(crystal freq) / PLL_M * PLL_N / PLL_P

Once at 400Mhz, the current consumption rises 30mA.  This is the easiest way to see if your program is running, if you have a bench power supply which the lion kingdom didn't originally have.

The STM32H7 also has a ROM bootloader which allows it to be programmed with only a UART & no SWD pins at all.  It seemed pretty hard to invoke & only applicable to 1 chip.  You need a way to debug it, anyway.