There is a patch for openocd for the rt1021 iirc but as of now I am using NXP's redlink as gdbserver in pipe mode, i.e., via something like this gdb parameter:
-ex "target extended-remote | \
/usr/local/LinkServer/binaries/crt_emu_cm_redlink \
-x <search dir>... \
-p MIMXRT1021 \
--rtos on \
-g \
--no-packed \
--connectscript RT1020_connect.scp"
redlink needs an xml file describing the overall memory map and the connect script - thus the search dirs that usually would point to the generated memory map (mcuxpresso creates them) and to /usr/local/LinkServer/binaries/Scripts for the latter. The third alternative (and the only one somewhat "supported" by nxp is to use LinkServer directly as gdbserver. However, that has to be launched as a separate process which complicates launching and cleaning up gdb sessions (although I still could not make it completely reliable with redlink either). If I'd have to start over I would definitely try to use openocd!
For the SDK I'd recommend against using the SDK builder and using the github repo instead:
https://github.com/nxp-mcuxpresso/mcux-sdk/It uses zephyr's west tool instead of ordinary submodules which is quite annoying. Also, the documentation in html-form is only available via sdk builder. However, I don't think there is anything in addition to the doxygen that are visible in the SDK's sources anyway.
HTH as starting point. the journey was quite winding and full of pain... be aware, there be dragons too.
