If you are creating an exact duplicate of wiring layout versus the development kit carrier board, then the default device tree will work. If ports have stopped working, and if the wiring has changed, or if the the device tree is incorrect, then the module will have an incorrect idea of the wiring layout. Is your carrier board truly an an exact duplicate of the wiring layout of the dev kit carrier board? Are you using the default device tree?
Also, if you’ve installed various items of software which are in the non-rootfs partition, and not used the provided flash software to do the install (e.g., you used “dd”), then a failure might be expected due to missing a valid signature on those partitions.
If you are able to put the board into recovery mode, and have the device mode port available to connect to the host PC, and can see the device with “lspci” from the host, then you’ve proven that at least some of the wiring is correct. That particular port, if failing once booted, may be indicative of an incorrect device tree. If you see any serial console output at all from that port during boot it would probably be useful.
FYI, the default serial console is 115200 8N1 without CTS/RTS flow control (I think software flow control works as expected). Serial console starts providing some output even prior to the Linux kernel loading. For the Xaviers you would likely see pre-Linux content switch to Linux content at the line which says something similar to this:
[0003.726] I> Linux Cmdline: root=/dev/mmcblk0p1 rw rootwait console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 OS=l4t video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt tegra_fbmem=0x140000@0xa0791000 lut_mem=0x2008@0xa078e000 usbcore.old_scheme_first=1 tegraid=126.96.36.199.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues=0.2.2 sdhci_tegra.en_boot_part_access=1