TK1 have some problems that can not use USB to serial

Hello all,
I have some problems ,While I plug an USB to serial to my TK1. My TK1 can not detect this device,I have tyied to build a custom kernel,but after reboot, My TK1 can not detect my keyboard and mouse.My serial type is CH340.I really do not know how to solve this problem.

Thanks all

You might want to put the old kernel back in for now via ssh or serial console.

Are you plugging the USB side into the Jetson? If so, look at “dmesg” output prior to plugging it in, then plug in the cable, and check “dmesg” again. Post here what the output is of this new text. Also post the output of “lsusb” when the cable is plugged in.

Yes, I plugging the USB side into the Jetson

[ 799.759845] nf_conntrack: automatic helper assignment is deprecated and it will be remove soon. Use the iptables CT target to attach helpers instead.
[ 975.377544] usb 2-1.4: new full -speed USB device number 6 using tegra-ehci
[ 975.392329] usb 2-1.4: New USB device found ,idVendor=1a86,idProduct=7523
[ 975.392347] usb 2-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 975.392359] usb 2-1.4: Product: USB2.0-Serial

This is the new text after dmesg.

Bus 002 Device 006: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

This is the device name after lsusb
I think the problem is the driver was not loaded,but I do not know how to sovle it.

USB is working correctly. Understand that USB is just a pipe for data and commands…it isn’t the final driver. USB drivers support this pipe, but once USB sees a device it broadcasts information about the device, and then it is up to a driver to claim ownership of the device. It is this second driver in the chain of drivers which isn’t loading. Usually this is because there is no driver present for the end device.

This may be a special case because keyboard and mouse are part of a set of standardized generic devices…certain devices which are built to follow a standard interface and function. USB itself usually includes the second driver for the specific device in those cases. Keyboards and mice are part of the Human Interface Device (HID) generic class. Some keyboards and mice have additional features, such as being programmable, and the pipe may support a single wire being multiple devices (the keyboard output would be HID, the programming would require a custom driver).\

Whenever you build a new kernel you should always start by using the config of the running kernel, and only then edit to add or remove features. This config is found in “/proc/config.gz”. In some cases the kernel make target “tegra12_defconfig” (for a TK1 which is a tegra12x SoC series) would be the same, or close, but even then the “/proc/config.gz” is the best starting point.

What configuration did you start with? What changes did you make? Did you set the CONFIG_LOCALVERSION (which says whether the module search location will change or not)?

Thanks your reply
I mean the driver of CH341 was not loaded ,I have tried to build a custom kernel,and during it I set the CONFIG_LOCALVERSION .I was follow this guide http://www.jetsonhacks.com/2016/06/29/build-custom-kernel-nvidia-jetson-tk1/

I compile a kernel today,and use make menuconfig to add the driver of CH341,but I failed to change the version of the kernel. I find there is no grub file under boot even. Could you please tell me how to sovle this problem?
Thanks for your help.

GRUB is only used on a PC motherboard. Jetsons (and many embedded systems) use “U-Boot” instead. The kernel compile is the same, but installing the kernel differs.

If CONFIG_LOCALVERSION results in a match of the “uname -r” output between the older kernel and the new kernel, then the module directory will be found in the same place it was previously. If “uname -r” results in a new name, then the entire module directory must also be created. If a failed module load causes a system failure, then a changed “uname -r” would be the reason…but most of the time modules will not cause a boot to fail completely…mostly missing modules will cause many failures, but the system won’t completely crash.

Note that if you use the “source_sync.sh” script there is a strong chance your “uname -r” will get the plus character ‘+’ appended even if you did not put this here. It is unlikely to cause boot failure though (GUI would fail because of missing a video module).

The kernel produced for a TK1 would be the zImage (or just Image…zImage is smaller/compressed), and an entry in “/boot/extlinux/extlinux.conf” binds this file name to what U-Boot will load (it’s a human readable file you can browse).

I always recommend leaving the original kernel untouched, and adding a new kernel with an alternate name, e.g., “zImage-custom”, and then adding an extra entry in extlinux.conf which is a duplicate of the original entry other than changing the name. Then use the serial console to pick this entry for testing before you commit to making this a default entry. Serial console is required because there is no video driver in U-Boot like what you might find with GRUB in a PC…no video implies no way to see what you are doing…unless you have a serial console which does not rely on a video driver.

Thank you for your detailed explanation.
I have tried to entried “/boot/extlinux/extlinux.conf” but I dont know what to change to let the U-boot load the kernel that I want.I am not quiet understand how to adding an extra entry in extlinux.conf and how to use the serial console to choose the kernel that I need.I am a green hand and these question may sound simple.
Thank you very much.

As an example here is the entry you will find in a newly flashed TK1 with R21.6:

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/zImage
      FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

Note that the “APPEND” key/value pair is one very long line…line breaks would break the file.

The “LINUX /boot/zImage” is the kernel which would load if this entry is picked. I could add this “nearly exact copy but with zImage change” to get a second entry which does everything the same other than using a new kernel:

LABEL custom
      MENU LABEL custom kernel
      LINUX /boot/zImage-custom
      FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

…for this to work I’d have to create file “/boot/zImage-custom” from some alternate kernel.

Because this would be a second entry, you would be able to pick “1” or “2” during boot, and if you did not pick before a timeout, then “1” would be used (“1” is the DEFAULT).

Note that “MENU LABEL” is something a human will see from a serial console while in U-Boot. The “LABEL” is what the actual boot loader uses.

During boot, in early U-Boot, you can hit any key at the right time and it will drop into the U-Boot shell. From there you could experiment with U-Boot commands (not what you want for this case, but for illustration you could run “help”). This is prior to kernel selection though, and you could continue boot with the “boot” command at the U-Boot prompt. A very short time later you would be offered a chance to pick entry 1 (“primary kernel”) or entry 2 (“custom kernel”). You might have to backspace to get rid of whatever character you used to halt boot there, but then a “2” would load zImage-custom.

If you like the result, then you could edit the “DEFAULT” key/value pair and change it from “primry” to “custom”…after that, unless you select an entry manually, boot will always use “custom”.

It isn’t recommended, but you could just change “DEFAULT” to custom without testing. If it breaks the system, then your only ways to fix it are to use a serial cable or to use a clone/edit/flash. That serial console is an extremely valuable and safe way to test kernels.

Here’s an example extlinux.conf I’d recommend everyone have if planning to experiment:

TIMEOUT 30
DEFAULT primary

MENU TITLE Jetson-TK1 eMMC boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/zImage
      FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

LABEL <b>custom</b>
      MENU LABEL <b>custom kernel</b>
      LINUX /boot/zImage<b>-custom</b>
      FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

LABEL <b>sdcard</b>
      MENU LABEL <b>SD Card primary</b>
      LINUX /boot/zImage
      FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 <b>root=/dev/mmcblk1p1</b> rw rootwait tegraboot=sdmmc gpt

LABEL <b>sda1</b>
      MENU LABEL <b>SDA1</b>
      LINUX /boot/zImage
      FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 <b>root=/dev/sda1</b> rw rootwait tegraboot=sdmmc gpt

Note that the “root=/dev/something” is edited for sda1 or sdcard entries (you have to scroll over the “APPEND” key/value pair to see this). In every case there is a unique “LABEL” and a descriptive “MENU LABEL”. “DEFAULT” is the label which occurs if you don’t intervene during boot with a serial console. This above example leaves entries to boot to an SD card or the first GPT partition of a SATA device should you ever need it. There is no error in having this even if you don’t have a SATA or SD card rootfs because it won’t use this until you select it…but if you ever get in trouble having this before the trouble occurs can be a huge time saver in recovery or just quick rootfs testing.

About serial console: The 9-Pin D-sub connector has a terminal always connected to it as a simple string of bytes. A serial terminal program from another computer provides the display and keyboard software…none of which needs to survive on the Jetson for it to work since the PC is doing that work. Here are some examples of 9-Pin D-Sub to USB serial UARTs which use the FTDI chipset which would work:
https://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=100168426&IsNodeId=1&Description=db9&bop=And&SrchInDesc=ftdi&Page=1&PageSize=36&order=BESTMATCH

Really appreciate your help.
I think I have fully understood what your mean.I bought a RS232 to USB just now.I have finished all things without a serial console.I have a deeper understanding of the kernel with your help.I will inform you in the first time if there is any progress.
Thank you again for your unselfish help.

I have to say I met a problem again…Everything goes well until I choose the custom kernel .Its just stop at Starting kernel…I dont know whats going on…

If it just stops it tends to mean there is an error in finding the kernel file name or location. If the kernel is in a different partition than the other kernels it can find, then it tends to be an issue with the partition (perhaps the wrong partition, perhaps the partition has options U-Boot doesn’t understand…Ubuntu 14.04 and 16.04 hosts will never have those incompatible ext4 options).

Example cases:

  • Full path to kernel is wrong. Perhaps the "entry" simply didn't correctly add the "LINUX /boot/zImage-custom" correctly...you would have had to have renamed the "zImage" of the build to "zImage-custom" and placed it in the correct "/boot" directory.
  • You have more then one disk or partition involved...there may be a "/boot" on different devices...perhaps you put the "zImage-custom" on the wrong device's "/boot". Example: Normally one flashes to mmcblk0p1, the eMMC...if this is the extlinux.conf device, the "zImage-custom" goes there....if you flashed directly to an SD card (mmcblk1p1), then the kernel goes there...if you flashed to go directly to sda1, then the "/boot" is there (I believe you used eMMC, mmcblk0p1, not sda1, so likely your kernel needs to be on eMMC even when booting to sda1 rootfs). Most of the time the extlinux.conf to edit is on eMMC (mmcblk0p1)...this means this is where the kernel file must exist and all other "/boot" content is ignored.
  • Sometimes the kernel will be on an external device (such as SD card) when boot options are properly set up (not recommended). The partition would have been formatted from the host computer instead of the Jetson. If the host computer uses ext4 64-bit extensions, then the partition won't be readable because of U-Boot limitations. If the SD card was never formatted it might have a file system type U-Boot does not recognize...this would be exactly the same result as 64-bit extensions...U-Boot couldn't find the kernel in such a partition.

So look at the partition containing the extlinux.conf where the custom entry was added. Look at the full path of the file name from the kernel image key/value pair, e.g.:

LABEL custom
      MENU LABEL custom kernel
      LINUX <b>/boot/zImage-custom</b>
...

Somewhere is a device which can’t be read (low probability since you saw your custom entry), or the kernel is on the wrong partition or using the wrong name relative to the custom entry (high probability).

There may be options in kernel build which cause the kernel to never start at all, but this would be very low probability. Seeing some sort of kernel attempt to start is very very likely…seeing none at all is very very unlikely.

If for some reason there is an initrd file being used (this was never the case in the TK1 unless you manually added it), then the file naming in extlinux.conf is the final authority as to which kernel and file system is loaded.

Thank your reply
I am sorry to reply you so late.I was very busy and dont have time for TK1 recently.In fact there is no condition for me to use TK1.I have putted my source code in /usr/src.But my zImage-custom is under the /boot directory.And I did not add any SD card.I think the source code and zImage-custom are both under the / directory.I will try add a more detail address in extlinux.conf and see would this work.
Thank you by my heart.

The zImage-custom file in “/boot” should work on a TK1. During the kernel build you would have had a file “.config” generated. What was the resulting “CONFIG_LOCALVERSION” shown in this file? This wouldn’t stop all output (boot wouldn’t stop at kernel load), but it might be a clue to other configuration issues.

What was the entry you used in extliux.conf?

I just copy the original code and put it behind the original code and change primary into custom.
like this:

DEFAULT primary

MENU LABLE primary kernel
LINUX /boot/zImage
FDT /boot......



DEFAULT custom

MENU LABLE custom kernel
LINUX /boot/zImage-custom
........

You should have only one DEFAULT. Choose the one you want it to boot when no choice is made from serial console after timeout.

You also have typos ‘MENU LABEL’.

I have only one default.My problem is the new kernel can not start…

What have you modified? Did the kernel change, but the name is the same? Did both the kernel and the name change? Do you have a serial console…if so, can you attach a log of the boot up until the point it fails? Can you show a copy of the extlinux.conf?

TIMEOUT 30
DEFAULT custom

MENU TITLE Jetson-TK1 eMMC boot options

LABEL custom
      MENU LABEL custom kernel
      LINUX /boot/zImage-custom
      FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/zImage
      FDT /boot/tegra124-jetson_tk1-pm375-000-c00-00.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 mem=2015M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 board_info=0x0177:0x0000:0x02:0x43:0x00 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

This is the copy of my exlinux.conf.I have a serial console,but I dont know how to attach a log of the boot up…

Oh I have load the driver of ch341,but I cannot find the ch341 in the /dev.I mean I dont know which device name I should use. Because there is no change after the ch341 is plugged in /dev file.I am tying to use ttyTHS* to find the device.After I use “lsmod” ,its shows ch341,but the Used by is 0.

Thank you very much
With your help I finally finished this problem.I really appreciate your patient reply.
Thank you again.