I've spent the last 6+ years doing Windows kernel debugging on ARM64 server systems, the Marvell ThunderX2/ThunderX3 cpus for almost 3 years, and since 2021 the Ampere Computing ARM64 cpus. I haven't done any significant work on the Snapdragon chips. As was already mentioned the Snapdragon has a magic USB virtual Ethernet way a to do kernel debugging. Let me do a brain dump about Windows ARM64 debugging on UEFI systems.
The rumors are we may see ARM processors from a number of companies in the next year. Ampere has been selling ARM processors for years now, and NVidia Grace may be shipping too. You can run Windows ARM in a VM on an ARM Mac too. You can buy ARM server motherboards and systems now, although I haven't heard if Microsoft is productizing Windows ARM server. For some workstation users, running desktop Windows on a many core ARM cpu would be very attractive. A big limitation currently is very limited driver support on ARM Windows, like no GPU drivers.
For the non-Snapdragon ARM64 chips there are at least 4 kernel debugger options. These have been UEFI systems with PCIe busses. I've extensively used the ethernet windbg transport, on certain Mellanox PCIe cards (ConnextX-5). It's also possible to use some flavors of Intel NICs, even though the OS has no Intel NIC driver support, the windbg debug stub does. Last I knew (3 years ago) the PCIe Realtek NICs partially work for windbg, but when I tried them didn't correctly reset the NIC hardware unless you did a hard power cycle. The standby power pins keep the Realtek NIC set to a non-power on state, which windbg chokes on after a reboot unless the standby power rail goes off). A bonus of enabling an Intel NIC for windbg is it will tunnel non-windbg traffic over the Intel NIC, so you get things like remote desktop even if your system has no NDIS drivers, although network performance is not appropriate for production workloads. Windows ARM also supports USB NICs, but those don't work as a kernel debug target (except the Snapdragon special case).
The systems I've worked on also had serial ports, which work for windbg like you would expect. The serial ports I've seen have all been 3.3V logic levels, not RS-232 levs, so you need appropriate serial to USB interfaces. If the serial port is connected to a network serial server, there is also a magic windbg command line to get windbg to connect to the serial server TCP port but using the serial protocol instead of the network windbg protocol. This is also useful for connecting to QEMU serial ports and things like serial ports in assorted hardware emulators. I submitted a documentation bug report a couple years ago but Microsoft declined to fix the docs as it's not an officially supported feature. For things like Verilog emulators, windbg over serial is problematic as time runs at like 1:3000 speed in the emulated machine, but runs at normal speed in the windbg machine, so the protocol timeouts get really screwed up. MSFT should add a windbg option to allow adjusting the windbg serial and dbgnet protocol timeouts. Serial windbg also works on things like the Rapberry PI (4/5).
You can also boot ARM Windows under QEMU and configure serial ports or Intel NICs, and do kernel debugging. This works both when emulating ARM on a x64 system and when you are running QUMU on a an ARM processor (like running ARM Linux). If you are doing pure software emulation in QEMU on a x64 box, it helps to change the remote desktop connection timeout, as making the connection while emulated often exceeds the default timeout so RDT does not seem to work. The x64 emulated version has the interesting property you can go hack the QEMU emulation mechanism if needed, so you can alter the behavior of the "machine". Like for example you can write a virtual device driver for your device so you can work on driver development long before you have actual silicon or even FPGA prototypes. You often don't have to precisely emulate your device, you may just need it to work well enough to get partial functionality allowing time overlap between the driver and hardware development. When doing CPU development, being able to add debugging behaviors and instrumentation has been pretty useful to debug hardware errata and such. It's way more fun to test your error handing code when you can just flip a software switch and make some rare error condition reproduce on demand. QEMU can also generate a bunch of useful traces, and you can run gdb on the VM for things that windbg can't debug, like say stepping through the OS interrupt handling.
You can also debug ARM Windows over JTAG. You enable the EXDI to windbg protocol interface (comes with windbg now) which connects to a gdb server over TCP. This works with the Lauterbach JTAG debugger, but unfortunately last I knew does not work correctly using openocd. Lauterback is pretty expensive (thousands), openocd is free. The EXDI library has specific support for Lauterback, and openocd gdb server does not have some commands needed by windbg over EXDI (like writing breakpoint instructions to read-only pages of code). You can connect the windbg EXDI interface to the gdb server built into QEMU, which works very well. As I remember this windbg->EXDI->QEMU(gdb server) also works fine on x64 QEMU.
These windbg transports also work for hypervisor debugging if you set the right options, but since there are no symbols, hypervisor debugging is painful.
The Lauterbach JTAG debugger also knows how to load Windows symbol files (not very automatically). Note there used to be an intermittent bug in Lauterback when loading Windows symbols, which crashes the Lauterback debugger with a memory fault. For really deep debugging, you can use Lauterback together with EXDI+Windbg, you can do things like step into firmware calls and debug the firmware with the Lauterback debugger, which continues to run with the EXDI connection from windbg. You can also run Lauterback JTAG+EXDI/windbg+windbg (over an Intel NIC). This allows the most flexibility as you can symbolically debug user-mode and EL1 kernel code with windbg(NIC) and use the windbg (over EXDI) for tricky kernel debugging, and the Lauterback debugger for EL3 firmware or really deep hardware examination (like cache state). Running three debuggers at once is painful, but can be useful on occasion.
Note that ARM64 processors have control over permissions for many kinds of debugging, so the systems normally available may not allow JTAG EL3 debugging for example. These debug permissions are often controlled by the cpu vendor. A plus of debugging under QEMU is there are no permission limits.