the USB communications on TX2

Hello,everyone!
I am doing a program on TX2(R27.1 versions) that transfering the datas received by the RJ45 port to USB port(J19 on TX2) througn RJ45 to USB interface.
How do I compile the kernel? Which library functions will be used in USB communication?
Thank you very much if can you any ideas!

The “Documentation” download has a customization section talking about building a kernel (it uses cross compile on a PC host). See:
https://developer.nvidia.com/embedded/linux-tegra
(assumes you are using the current L4T release)

Of interest:
https://elinux.org/Jetson_TX2
http://www.jetsonhacks.com/2017/03/25/build-kernel-and-modules-nvidia-jetson-tx2/

Keep in mind that some procedures differ depending on the L4T release so watch in any docs which release is being described.

The USB question is a bit vague. If you want the micro-B USB port to cause the TX2 to appear to be a device then you’d be interested in the Linux kernel “gadget” framework. There are many USB standard device classes…which one works would depend on your data. In some cases you might need to write your own driver from scratch. See:
https://www.kernel.org/doc/Documentation/usb/gadget_configfs.txt
http://www.linux-usb.org/gadget/
(keep in mind currently Linux kernel series 4.x is being used…some documents out in the wild might be for a previous generation of kernel)

Thank you for your help!I am a amateur to TX2 and Linux.So the solution you gave may be understood for some days.
 And I also want ask that what function libraries or struct may be used in USB communications in Linux?

That’s a very big topic. There are kernel drivers involved, and possibly user space libraries. In part it depends on what class of device you are looking at. Are you familiar with the USB standards for device classes (e.g., isochronous, HID, bulk storage, interrupt, so on)?

In general (this isn’t expected to answer any particular question…it may show you how to look) when a USB device connects the internals of the kernel will query the device and the device will respond with a description about itself. It is up to the hot plug layer to announce this and for a driver to decide it can handle this and assume ownership of the device.

If you are talking about a host getting a device plugged in, then you are talking about the driver which would take ownership as hot plug announces it.

If you are talking about a device being queried by a host upon plugin, then you are talking about the response to describe itself upon plugin.

One end of the USB pipe is always a host, and the other end is always a device. There are no exceptions, although the OTG connector allows either type of connector (but there is an ID pin to tell which type…newer type-C have a similar mechanism).

USB does have some standard classes to simplify life, but USB does also allow custom devices with custom drivers. Good examples of standard classes are for a keyboard or mouse…an example of a custom device would be the interface to program a programmable keyboard or mouse (one USB cable can contain many physical or logical USB devices…the program interface would be a different response upon plugin versus the actual mouse or keyboard function…all would respond upon query).