In general, yes, you can jtag, since the debugger has absolutely nothing to do with what software you use on this processor. Where you can get into the problem, this is the cache, for example, if you stop the processor, you want to change some instructions in ram and restart, changing instructions in ram is access to data that does not go through the command cache, and data cache, if you have a separate instruction and data cache, they are included, and some of the instructions that you modified are located at the address that is in the command cache, you can quickly get confused with new and outdated instructions that are given to the processor, Linux likes to use caches , if there is.
The second one is mmu, the processor / jtag most likely works on virtual addresses on the mmu processor side, and not on physical addresses, so depending on how the equipment works, for example, if you set a breakpoint at the address in the debug unit in the processor , and the task of the operating system switches to another program / thread in the same address space, you will stop at the wrong program at the right address. If the debugger / processor sets breakpoints by changing the instruction in ram, then you start the cache problem above, if you don't cache, then you break the right instruction in the right thread, but then you have a cache problem.
In fact, if the processor supports jtag-based debugging, which does not change based on any software that you have chosen to run on that processor.