I am working on Jetson TK1 and it used to work perfectly using TV, and now I am trying to work with a smaller HDMI display, I have followed the step in this link to patch a kernel to turn on the display,
but instead my desktop on TV is not working anymore, I am getting a plain screen that does not allow me to do anything, not even the menu bar is showing, moreover I cant shut the jetson down or restart it except by disconnecting it from the power supply which I don’t prefer to do that but I had to.
Do you think that the mistake is to patch the kernel, since I am working on ubuntu 14.04 will that discard all my work in ubuntu? I hope not.
Can someone please help me and tell me how to get my jetson working as before with the desktop shown.
I’ll appreciate your help and be thankful.
thank you in advance.
Noora.
In cases where you need to shut down but cannot do in a normal way, you might be able to use the “magic sysrq” key combinations. On an eMMC you don’t want to be constantly running “sync”, but this combination may be better than cutting power if things are in a bad state:
alt-sysrq-s
alt-sysrq-u
alt-sysrq-b
If sysrq is enabled and part of the kernel responds, then the “-s” runs sync, the “-u” remounts the drive read-only, and the “-b” shuts down. See: https://en.wikipedia.org/wiki/Magic_SysRq_key
Note that if you are worried about experimenting, you can clone your root partition before going further, and the clone is loopback mountable from your host machine: http://elinux.org/Jetson/Cloning
You could clone the image, put the stock kernel back in, and restore by reusing the “fixed” clone if desired.
There are a lot of little details which can go wrong, but which can be fixed if you isolate what went wrong. What was the L4T version at the time of adding this kernel? Did you also add firmware? If you compiled, what was your initial config from? Did you set the CONFIG_LOCALVERSION ("“General setup → Local version”)? If so, what version did you set, and did you put in kernel modules based on that for the location?
hi,
im not sure about all the question except that i have set the initial config and the CONFIG_LOCALVERSEION where the version is 3.10.24-grinch 3.10.40-gdacac96.
unfortunately my friend is the one who did that and doesnt know at which point she has stopped.
Only the suffix to a base kernel version should be used in CONFIG_LOCALVERSION. So basically a valid CONFIG_LOCALVERSION could be one of:
-grinch
-gdacac96
…but could not contain:
3.10.24
3.10.40
…note that 3.10.24 or 3.10.40 is provided by the kernel source itself, and is not manually selected the same way that CONFIG_LOCALVERSION is.
When the command “uname -r” is run, the result is the combination of the base version and the CONFIG_LOCALVERSION, e.g., if kernel is 3.10.40 and CONFIG_LOCALVERSION is “-grinch”, uname -r would show:
3.10.40-grinch
The kernel looks for kernel modules by appending “uname -r” to “/lib/modules”. So if “uname -r” responds “3.10.24-grinch3.10.40-gdacac96” (taken from the original post), then modules must exist in:
/lib/modules/3.10.24-grinch3.10.40-gdacac96/
If that is correct about CONFIG_LOCALVERSION being incorrect, then the boot process will fail anything dependent upon a module. Basically you’ll need to verify that kernel modules are able to load before you can figure out if anything else might be wrong…the nVidia video driver is loaded as a module.
Serial console should be available even without modules and without a video driver, so see what “uname -r” responds as, and whether this is a subdirectory of “/lib/modules”. Once that is done you can move on to other debug possibilities. One specific driver to look for within that module subdirectory is “kernel/drivers/video/tegra/host/vi/nvhost-vi.ko”…this one is specific to video and normally needs to be copied over manually if you change CONFIG_LOCALVERSION (the apply_binaries.sh assumes a default CONFIG_LOCALVERSION when installing that file).
uname -r reposds as 3.10.40-gdacac96 and yes it is a sub-directory of “/lib/modules”
and now i should verify the kernel modules or start debugging? if any, how to do so?
Verify that module nvhost-vi.ko exists at this subdirectory of the module directory listed in “uname -r” you gave above:
kernel/drivers/video/tegra/host/vi/nvhost-vi.ko
Actually, to verify all of the nVidia-specific files, run this command (this should be valid with nvhost-vi.ko since the directory is the standard install directory…had it been in an alternate kernel version module directory this would not be true):
sha1sum -c /etc/nv_tegra_release
If all of that checks out, describe exactly how your kernel build “.config” was initially created, e.g., from “/proc/config.gz”, and exactly what config changes were made.