Something I noticed from further back worth mentioning is this excerpt related to downloading kernel source:
fatal: read error: Connection reset by peer
…this means your network failed (either a hop along the route, or a proxy or firewall).
The tty devices are probably not what you think they are. No gadget mode (nor special device mode setup) is needed for the ttyACM device. There is an actual serial UART doing that work. In a real serial UART…sometimes over USB, but not via gadget…the USB end of the cable is a device, but only the driver for the ACM would be needed and no special device mode setup. Anything associated with a ttyACM should completely cut gadget mode out of the equation.
Gadget is used when creating a synthetic/fake device using software which looks like hardware. For example, software can emulate an ethernet NIC over USB, or a sound card which doesn’t actually exist (the programming would be clever enough to make the USB look like one of those devices).
A serial UART is hardware which simply converts a parallel set of bits (a byte) into a series of bits using a serial protocol. The UART itself needs a driver. Often no USB is associated with a UART, but sometimes a host computer doesn’t have a serial port integrated and a USB version is handy (compare that to trying to solder a chip to the motherboard or adding a PCI slot card). In the case of USB the UART is not hard wired into the system and the system with the USB end needs that driver.
A ttyACM is one chipset’s naming convention, and a kernel configured to handle that chipset will have feature “CONFIG_USB_ACM” either as a module or integrated with the kernel. There are some other related ACM configs as well. On a Jetson take a look at this to see what is configured:
zcat /proc/config.gz | egrep '(USB.*ACM)'
(note htat the CONFIG_USB_CONFIGFS_ACM and USB_F_ACM probably are not needed for basic serial UART use)
If the driver is present, then the end of the USB cable which is the actual USB connector should “just work” if the port has the correct settings and the port is set up correctly (e.g., speed, parity, stop bits, and flow control settings must match at both ends of the UART).
The serial UART end of the cable does not need a driver of any kind. This other end will talk to another UART. The system which contains the other serial UART is the one which needs a driver for that brand of UART. If it happens that this other end is a Jetson, and that the UART is integrated into the Jetson, then the UART is already set up with a driver. The settings for that UART have to match the other UART for it to work, but no gadget is ever involved.
There is one serial UART already set up on the Jetson as a serial console. This is for sending commands and receiving shell replies. A second serial UART could be used for sending or receiving files. Are you sure you need gadget? What are the actual physical connectors involved and where do they connect specifically on the Jetson side?
As a side note, the content in “/opt/nvidia/” is just an example gadget mode. One of the synthetic devices created is a block storage device…it emulates a USB thumb drive. Another synthetic device created by the gadget code in “/opt/nvidia/” is an ethernet card over USB. These do probably interfere with any gadget code you might add. However, I suspect you can leave all the gadget code behind and completely ignore it since a UART is not a gadget (gadgets are fake devices, UARTs are real devices).