I can’t answer most of this, but are the involved Xaviers on the development kit carrier board?
FYI, the device tree determines routing of serial devices, or what function a GPIO will take. If you change carrier boards, then the drivers would remain the same in Linux, but the device tree would change to reflect the new hardware surrounding the Xavier module. That device tree is part of the board support package, and will be custom to each carrier board. All of which is under Linux, I have no idea about QNX.
Additionally, note that the serial UARTs in the Xavier have compatibility modes. When the driver which runs the UART behaves as an older 8250 it is using the standard driver which comes with the kernel and is fairly universal. There is also a possible “high speed” UART driver, and this driver acts exactly the same as the legacy driver, but is capable of DMA. Two drivers are possible on each integrated UART, but only one should run at a given time.
In the device tree you will see a base address numeric entry, e.g., “serial@12345678”, where the number is a hexadecimal physical address for that UART controller. Within this will be a “compatible” entry, and this contains a comma delimited entry of drivers. The “hs” driver is the “high speed” driver. You could leave one of the drivers out, but just because the UART is listed with two compatible drivers does not mean both are loaded and running simultaneously…this only makes it possible to use those drivers, and so you don’t really need to eliminate one unless you really want to guarantee the other never loads.
The legacy driver uses the syntax “/dev/ttyS0” (or other number), while the high speed DMA-capable driver (the Tegra High Speed driver) uses a naming convention such as “/dev/ttyTHS1”. “ttyS0” and “ttyTHS0” are the same hardware, but different drivers. “ttyTHS1” and “ttyS1” are the same UART hardware, but different drivers.
Serial console is a special case where earlier boot stages may need the UART to run, and the DMA-capable THS driver is not available outside of Linux. To maintain continuity of services as earlier boot stages load the kernel you will find serial console demanding the legacy driver (had the THS driver been used in Linux the UART would have become unusable during the brief time the new driver took over).
You only looked at dmesg for UARTs loading during boot of Linux. To see all drivers:
ls -l /dev/ttyS* /dev/ttyTHS*
Not all of those devices are necessarily connected to something. To see the UARTs which are generally available (but which something might already be attached to, so it doesn’t necessarily mean you can use it) look for the “group” name of “dialout” in the “ls -l” output from above.
Note that there is also a “/dev/ttyTCU0”. This is the serial UART used with the serial console and routed to the micro-OTG port (and a micro-B cable connected to this will see the serial console).
On custom boards nobody except the manufacturer of the carrier board will be able to tell you correct device tree content even with the supported Linux. Other people here can give you more details of which UARTs are available, especially for custom carrier boards, but you may need to figure out the device tree for a given UART within the Xavier module (not the carrier board…the device tree will act as a kind of “adapter” between module naming convention and carrier board routing and naming).
I am not saying there are other UARTs available, but if during boot you see only certain serial tty devices in dmesg, and if there are other UARTs available, then probably you need a device tree entry for the serial@address with the “compatible” naming legacy and/or THS drivers (just look at your current tree for an example).
You can extract the current tree a running system has via:
# Maybe need to install dtc:
sudo apt-get install device-tree-compiler
dtc -I fs -O dts -o extracted.dts /proc/device-tree
# Or to just get an idea without dtc. Note that "find" doesn't cross filesystems,
# so a "cd" there first helps:
cd /proc/device-tree
find . -name 'serial@*'
# Then examine files within a particular controller.
As for QNX I don’t know of anyone supporting this. I can tell you though that the GPU driver within Linux is essentially a dynamically loadable module used by the X server. Much of CUDA uses the X server as a way to call up the GPU functionality. People who want to run headless tend to have to install a virtual server rather than completely removing X (one doesn’t need a desktop like Gnome to use CUDA, but one does need a buffer which behaves in a certain way). The GPU driver is provided in binary format and is specific to a given Xorg X11 ABI release. Unless you match that ABI the GPU driver won’t load. Even if you run QNX, unless you get the Xorg server with the right ABI you probably have lost CUDA.
Someone else will need to answer questions on specific UART pins. For anyone to answer you’ll also need to give information about which carrier board you use and which L4T release (on the Linux version) you are using (see “head -n 1 /etc/nv_tegra_release”).