Yes, recovery mode is what puts the Jetson in a mode the flash software can talk to. The mode itself does not change anything unless the flash software runs, and the primary purpose of the flash software is to update QSPI. All “revert” behavior is strictly from the flashing itself since recovery mode itself only temporarily makes some commands available rather than actually causing a change.
One does not normally specifically flash QSPI. One merely flashes, and this by default updates QSPI. On an SD card model a normal flash is essentially a QSPI update.
I do not keep up on which specific file is loaded from where, but in general the theme is that you should log a “normal” flash of your board, and the log will show you exactly what file was used from where. In some cases there are reference files, and one is picked based on the model of board being flashed (JetPack can flash many models), and perhaps placed in the working location of the “Linux_for_Tegra/bootloader/” subdirectory or the “Linux_for_Tegra/kernel/” subdirectory, followed by later copy to the “rootfs/boot/” or similar location (including flash to a partition after signing). The log is the key to finding what goes where. An example:
sudo ./flash.sh jetson-xavier-nx-devkit mmcblk0p1 2>&1 | tee log_of_flash.txt
Incidentally, the actual flash target is the name of one of the “.conf” files with the “.conf” part of the file name removed. If you are in the “Linux_for_Tegra/” directory you will find many such files via “ls *.conf”. Many of these are just symbolic links (aliases) for a conf file which is named after a combination of the SoC number and carrier board number (those two combined determine the device tree and kernel). In some cases, if you are building custom hardware, you might choose to copy a conf file, rename it for your board, edit for something in those files, and then simply use that name as the flash target.