Build specific kernel and upgrade it

Hi All,

The Jestion TK1’s latest version is 3.10.40, but I would like to upgrade it to 3.13.14 at least.
Do any one has experience or demonstration that can be provided to me ?
Appreciate any ideas. Thank you.

Regards

Upgrading an entire kernel could result in losing direct hardware access from the nVidia-specific files of the “apply_binaries.sh” step. If you need a particular driver or kernel feature, you may be better off back-porting that driver (which would also be less complicated than back-porting an entire kernel). If it happens to be a WiFi driver, the Grinch kernel might already have this. What part of the 3.13.14 kernel do you need?

Hi linuxdev,

yes, it is complicated to upgrade entire kernel ourselves, besides, it might have system stability or performance …etc problems.
Because I would like to use 3D sensor in Jetson TK1 and its requirement is 3.13.14 at least.
And the sensor can work well on my desktop (ubuntu 14.04, kernel : 3.16 ), however, it don’t work on TK1. The difference between desktop and TK1 is kernel verison, so I guess the problem is kernel is too old. what part of the kernel I need maybe is UVC driver. Could you please give me some advises ?

Thanks
Regards

The problem I see is that it isn’t known which driver that 3D sensor uses…that’s a very generic description. Desktops quite often have available all kinds of modules which are never used. E.G., my desktop has a fingerprint security device scanner driver module and a hardware random number generator driver module…but I do not have either device and no need for the driver.

Your Jetson is a storage-space-limited device, and as such only puts in necessary devices. It may be nothing more than compiling the driver module and dropping it in to solve the issue…it may not have anything to do with the kernel version. Thus, can you give more information on what drivers are used in your desktop when the device is used, along with an exact model of the device? lsmod during or after the device is in use would mention kernel features which are in module format, and probably the driver is a module, so that list might help. Even if that driver does not exist in the current kernel, it would make it possible to know which device driver would have to be back-ported (versus an entire kernel).

Hi linuxdev,

The 3D sensor doesn’t need any specific driver, it support UVC driver. And I need to apologize for bad expressing, the sensor can work on TK1, but it would break down soon after it is opened. I compare module list before and after the device be plugged, thus, these modules might be used :

Module Size Used by
uvcvideo 81022 0
videobuf2_vmalloc 13216 1 uvcvideo
videobuf2_memops 13362 1 videobuf2_vmalloc
videobuf2_core 59104 1 uvcvideo
v4l2_common 15681 1 videobuf2_core
videodev 153793 3 uvcvideo,v4l2_common,videobuf2_core
media 21903 2 uvcvideo,videodev

Thanks
Regards

This all falls under video4linux, or video4linux2 (not sure about versioning). But it sounds like you have all of those modules under JTK1, but is it correct that there is a reliability issue? Can you describe how your sensor works up until the point it fails, and then describe the failure?

If you are using a particular program with the sensor, one which works momentarily and then fails, which program is it?

Hi linuxdev,

I found out the reason is usb hub, because I plug usb2.0 device (keyboard & mouse) and usb3.0 sensor (it also support usb2.0 )on it. However, the OS treats it as usb2.0 device. Thus, the bandwidth is not enough to transmit data, then the sensor will crash soon.

I can see how other devices on the HUB could cause such an issue. If USB is working correctly though, it should still remain USB3 speeds during the moment that sensor is running. USB listing in tree mode (“lsusb -t”) should indicate the sensor as 5000M (versus 480M) regardless of what else is going on. Unfortunately, only one device truly gets to send data at any one moment…even short bursts of use by other devices means bursts of time in which the sensor cannot send.