TX1 is connected to SimpleBGC (Camera Gimbal Controller) via USB to Serial (e.g. FTDI).
Latest JetPack (version 2.2.1) is installed (4th Sep 2016), which should be running the current latest Ubuntu kernel et al.
When I first try to establish connection to the serial device I was surprised that Ubuntu did not mount the serial device at all (as in there was no /dev/ttyUSB0), even though lsusb lists the device
Bus 001 Device 026: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
After some searching I found advice that recommended a forceful serial mount by writing the vendor and product id to /sys/bus/usb-serial/drivers/ftdi_sio/new_id. In my case my vendor and product id were 10c4 and ea60 respectively (dmesg told me so)
[ 12.857483] usb 1-3.4: New USB device found, idVendor=10c4, idProduct=ea60
[ 12.857505] usb 1-3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 12.857519] usb 1-3.4: Product: CP2102 USB to UART Bridge Controller
[ 12.857530] usb 1-3.4: Manufacturer: Silicon Labs
[ 12.857541] usb 1-3.4: SerialNumber: 0001
At first after performing the above the /dev/ttyUSB0 did appear, however on closer inspection of dmesg reveals that ftdi_sio is having problems initializing.
[ 181.849186] ftdi_sio 1-3.4:1.0: FTDI USB Serial Device converter detected
[ 181.850269] usb 1-3.4: Detected SIO
[ 181.850378] usb 1-3.4: Number of endpoints 2
[ 181.850475] usb 1-3.4: Endpoint 1 MaxPacketSize 64
[ 181.850568] usb 1-3.4: Endpoint 2 MaxPacketSize 64
[ 181.850654] usb 1-3.4: Setting MaxPacketSize 64
[ 186.845754] ftdi_sio ttyUSB0: Unable to read latency timer: -110
[ 186.854349] usb 1-3.4: FTDI USB Serial Device converter now attached to ttyUSB0
[ 194.327623] usb 1-3.3: usbfs: process 3052 (camera_test) did not claim interface 0 before use
[ 194.328310] tegra-xhci tegra-xhci: WARN Event TRB for slot 3 ep 2 with no TDs queued?
[ 194.403789] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
[ 194.417708] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[ 194.426963] ftdi_sio ttyUSB0: urb failed to clear flow control
[ 194.434426] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[ 194.441736] ftdi_sio ttyUSB0: urb failed to clear flow control
[ 194.447887] ftdi_sio ttyUSB0: urb failed to clear flow control
[ 194.473332] hub 1-3:1.0: port 4 disabled by hub (EMI?), re-enabling...
[ 194.479939] usb 1-3.4: USB disconnect, device number 5
[ 194.481397] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 194.481513] ftdi_sio 1-3.4:1.0: device disconnected
[ 195.540313] hub 1-3:1.0: Cannot enable port 4. Maybe the USB cable is bad?
[ 196.449857] hub 1-3:1.0: Cannot enable port 4. Maybe the USB cable is bad?
[ 197.349559] hub 1-3:1.0: Cannot enable port 4. Maybe the USB cable is bad?
[ 198.230217] hub 1-3:1.0: Cannot enable port 4. Maybe the USB cable is bad?
[ 198.237500] hub 1-3:1.0: unable to enumerate USB device on port 4
I’m unsure why ftdi_sio is having such difficulties, I have double checked that the USB cable is not bad, because I have tested the same hardware setup with an Odroid XU4 and Desktop computer both running Ubuntu 14.04, so I believe the problem lies in the software in the TX1.
Incidentally, a USB device can have its naming changed by udev. If there is some generalized concept about what name the serial device should appear as, it won’t necessarily be correct on a different Linux distribution. If the serial UART connects to some other dedicated hardware (i.e., if the UART is hard wired to a gimbal controller and not a general purpose UART which can be disconnected) then it would be reasonable to think the custom drivers or some other class driver shows the USB device as something other than a normal ttyUSB0 type naming syntax. The device could be hiding under a different name.
I have a USB serial UART here which is FTDI and shows up as ttyUSB0 without any special configuration…so I’d expect ordinary FTDI serial USB chips to show up without any special work:
usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
Many USB devices are really multiple devices using a single cable as well…what does “lsusb” show? And if that shows, “lsusb -t”? Is the USB cable and serial UART separate from the camera gimbal controller, or is this cable integrated?
Actually having a closer look at the kernel, I do not believe that the kernel module is compiled by default, I attempted to load the module via modprobe cp210x to no avail:
modprobe: FATAL: Module cp210x not found.
Further, it seems to be the same problem with the TK1:
You could build just the module which is available if you configure the kernel item “USE_SERIAL_CP210X” (“USB CP210x family of UART Bridge Controllers” is in kernel config “Device Drivers → USB support → USB Serial Converter support”).
Is there a reason why one cannot just compile the kernel module on the TARGET instead of the host?
If I remember correctly I came across one of your posts explaining that the kernel was 64 bit and userland can be 32 or 64 bit, therefore to compile the kernel module against the 64bit kernel one has to have a 64bit arm compiler.
But this is the thing, I don’t understand (as per my original question) why can’t I just compile the kernel module on its own with a arm64 compiler? or can I?
Furthermore the compilation hints you linked me lack instructions on how to transfer the zImage and others to the TARGET.
That’s one of the long stories, but it is easier to cross compile in this case (normally native compile would be easier). It has to do with the CPU architecture supporting a native 64-bit and a compatibility/foreign 32-bit instruction set.
If we were talking about a desktop PC you think of that as x86_64 (64-bit), but desktops also support backwards compatible 32-bit i686 code. People think nothing of installing a 32-bit compatibility on those, but the compiler itself integrates both the 64-bit x86_64 and the 32-bit i686 in a single compiler. ARM is new, and the 32-bit armhf/ARMv7 compatibility is a separate compiler from 64-bit ARMv8-a (note the ARMv7 compatibility is actually ARMv8 without the “-a”, but it understands ARMv7). Installing 32-bit ARMv7 as a foreign architecture in addition to ARMv8-a 64-bit native architecture is problematic and new. The code to handle compatibility mode in the kernel must exist regardless of whether software actually goes into compatibility mode or not.