How to use HIDdev device on Jetson Nano 4GB

Regarding this:

TEGRA_KERNEL_OUT” is an environment variable. It isn’t a symbol and is not part of nconfig. What it does is set up something in the environment as to where to find temporary output (and also the .config temporary input). The “O=...” says the option “O” is to look at the environment variable “TEGRA_KERNEL_OUT” (explained below). An example symbol to search for is:

  • CONFIG_LOCALVERSION
    (it understands the “CONFIG_”, and so you could just search for “LOCALVERSION”)
    (this would normally be “-tegra”)
  • CONFIG_USB_HIDDEV
    (this is the symbol for the USB_HIDDEV; you can search for that or with the CONFIG_ prefix)
    (the “m” key should toggle this to be a module; the “n” key would disable this; the “y” key would enable this, but it would be integrated into the kernel, and not a module…which is not what you want for this case)

About Environment Variables:

Every program on almost every operating system offers options one can pass to the program upon startup. An example on linux, to see the “help” content for “ls” would be “ls --help”. This is a direct method of passing options to a program.

Every program also inherits from its environment. It is up to the program to decide if it wants to use something from that environment. An example would be that when you log in, your home directory is available to any program you run via the “HOME” environment variable. Check this out:
echo $HOME

You can export an environment variable, and then everything you run from that terminal has access to that variable. The “$HOME” variable is an example. You could examine this just for illustration:

echo $CUSTOM
export CUSTOM="hello world"
echo $CUSTOM
unset CUSTOM
echo $CUSTOM

Until you unset the variable, it is available. However, maybe you want to have this environment visible just for one program command. In that case you can leave out export, but use it as a prefix to the command. Try this to see how the variable can have a one-time use:

unset
echo $CUSTOM
CUSTOM=testing echo "hello $CUSTOM"
echo $CUSTOM

When we compile via this command:
make nconfig
…then it executes directly in the source code. In some cases this is what you want, but not in this case. We want to set up a temporary output location so as to avoid polluting the original source code. We’re simply using the environment variable TEGRA_KERNEL_OUT as a kind of bookmark. We first export this to some location we’ve created which is an empty directory. Example:

mkdir ~/temporary
export TEGRA_KERNEL_OUT=~/temporary
make O=$TEGRA_KERNEL_OUT nconfig
# examine what is in "`~/temporary`", possibly using our variable:
cd $TEGRA_KERNEL_OUT
ls

The most use variable is “TOP”, which you have to set up. You go to the kernel source start, where the “Makefile” exists. You can echo the name of this location via “pwd”. You can conveniently set “TOP” to this:

export TOP=`pwd`

From then on you can “cd $TOP” or use “$TOP” in commands. For this:
make O=$TEGRA_KERNEL_OUT nconfig
TEGRA_KERNEL_OUT is not a symbol. It is the environment where we are putting temporary output. It is the “O=” being set to our temporary location by a convenient “bookmark”.

Search for CONFIG_USB_HIDDEV. Enable it as a module with the “m” key.

The basic job that you are doing is:

  • Unpack the kernel source.
  • Find out where the TOP is. Optionally export TOP.
  • If you wish to make sure your kernel source is pristine, then from $TOP:
    sudo make mrproper
  • Create a custom, empty directory. Example:
mkdir ~/out
export TEGRA_KERNEL_OUT=~/out
  • Create an initial configuration which matches the running system. This consists of two parts:
    • make O=$TEGRA_KERNEL_OUT tegra_defconfig
    • Search for symbol “CONFIG_LOCALVERSION”. Set it to “-tegra”. There is actually more than one way to do this. Now your configuration matches (which is useful because now any loadable module you create will be able to plug in or be removed as the kernel runs; this is compatible with the running kernel).
  • Now modify the configuration to also include the symbol (driver’s name in the kernel) that you want. The tool to do so, which is being told to output to the temporary location, when run from $TOP:
    make O=$TEGRA_KERNEL_OUT nconfig
    (then in nconfig search for CONFIG_USB_HIDDEV; or just USB_HIDDEV since search understands CONFIG_)
    (then select with the m key)
  • Now you can build, but be sure to say the temporary location. If we are just building modules, and not Image (I recommend Image as an acid test, but it isn’t mandatory):
make O=$TEGRA_KERNEL_OUT modules_prepare
# The "-j 6" says to use 6 CPU cores:
make O=$TEGRA_KERNEL_OUT -j 6 modules

If that works, then let’s assume you’ve exported a temporary module install location and want to put content there:

mkdir ~/modules
export TEGRA_MODULES_OUT=~/modules
make O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT
cd $TEGRA_MODULES_OUT
 # To see output directory tree (might need to "`sudo apt-get install tree`"):
tree -d | less
# Or to see individual drivers:
find . -type f -name '*.ko'

You’re only interested in the driver created as a result of enabling module symbol CONFIG_USB_HIDDEV. You might find this of interest:
find $TEGRA_MODULES_OUT -type f -iname '*usb*'

Or more narrow:

find $TEGRA_MODULES_OUT -type f -iname '*usb*hid*'

Unfortunately, this is not very clear for me, what do you mean exactly with enable it as a module? I have no clue which line I have to enable as a module, some of the lines are just a link to another menu, n/y/m buttons doesn’t work on them, for some lines only n/y button works on them. Here is a batch of screenshot I’ve selected and the error at the end of compilation.




drivers/built-in.o: In function `wacom_probe':
/home/jetson/Downloads/kernel/kernel-4.9/drivers/hid/wacom_sys.c:2392: undefined reference to `usb_hid_driver'
ld: drivers/built-in.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `usb_hid_driver' which may bind externally can not be used when making a shared object; recompile with -fPIC
/home/jetson/Downloads/kernel/kernel-4.9/drivers/hid/wacom_sys.c:2392:(.text+0x797228): dangerous relocation: unsupported relocation
/home/jetson/Downloads/kernel/kernel-4.9/drivers/hid/wacom_sys.c:2392: undefined reference to `usb_hid_driver'
/home/jetson/Downloads/kernel/kernel-4.9/Makefile:1103: recipe for target 'vmlinux' failed
make[1]: *** [vmlinux] Error 1
make[1]: Leaving directory '/home/jetson/output'
Makefile:171: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

It sounds like this feature is not possible as a module. I’m going to first describe how I would to discover if module build is possible. Then I will add a part about “If this cannot be built as a module”.


To start with, just for understanding (I don’t want you to edit anything like this), look at the “.config” file produced in the “$TEGRA_KERNEL_OUT” after you’ve run this:
make O=$TEGRA_KERNEL_OUT tegra_defconfig
(feel free to delete the temporary location and recreate it, or to use a second temporary location)

To look at that, check this command to examine it:

cd $TEGRA_KERNEL_OUT
less .config

(the “q” key quits)

You’ll see lots of lines with CONFIG_...something.... Some of them “=m”. Those are configured as a module. This is not done directly in that file, but is done while in this program:
make O=$TEGRA_KERNEL_OUT nconfig

Any time you see an item in that nconfig editor in which you can select or deselect it, one of those “CONFIG_...something...” lines will change when saved. There are three possible configurations of those lines:

  • Starting with a “#”, which is neutralized, and is the same as that feature disabled.
  • Ending with an “=y”, which is integrated directly in the kernel. This is not a module feature.
  • If that CONFIG line ends with “=m”, then it means the configuration editor was used to set that feature to enable as a module. This is what you want.

Go through the nconfig until you find the driver (symbol, or CONFIG_...something...) you are interested in. The F8 symbol search can help with that. Eventually you’ll reach that feature. On the left side, if you see an asterisk “*”, then this means “=y” (the feature is integrated directly into the kernel). If you see “M”, then this is enabled as a module (and is what you want for hiddev). I currently see in your last screenshot “*”, which is wrong. If you select that line (use the arrow keys to go down to it), and click the “m” key on the keyboard, then you should see this change to “<M>”. This is what you want.

Not all features can be set up as a module. If you click the “m” key on your keyboard and it won’t toggle, then let me know…this means it is an “integrated only” feature. Very likely this can be built as a module (which will simplify life for you during installation even if compile isn’t much different).

I’ll reiterate that your goal is:

  • Get an empty temporary output location set to “$TEGRA_KERNEL_OUT”. Best done by actually removing the directory if you wish to start over (this removes “hidden” dot files…and “.config” is technically a “hidden dot file”).
  • Build tegra_defconfig with the “O=$TEGRA_KERNEL_OUT”.
  • You can search for CONFIG_LOCALVERSION, and set that to “-tegra”.
  • Now your build is set to be an exact match to the running system (or at least to the default…which is what systems are set to anyway). It is time to edit.
  • Now run “make O=$TEGRA_KERNEL_OUT nconfig”. Search for and find the hiddev feature via the symbol search for CONFIG_USB_HIDDEV (use F8 to search for the symbol). Go there.
  • Once that feature is highlighted, press the “m” key to make it toggle to “<M>”.
  • Verify it is “<M>”, and save. You’re ready to propagate configuration.
  • Propagate via “make O=$TEGRA_KERNEL_OUT modules_prepare”.
  • You can now build:
    make O=$TEGRA_KERNEL_OUT modules
  • You can then place the modules in a new temporary location. Example:
mkdir ~/modules
export TEGRA_MODULES_OUT="~/modules"
make O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT modules_install

…then look for your module within “$TEGRA_MODULES_OUT”.


If This Cannot Be Built As A Module…
(I hope you can build as a module, but it sounds like it is not possible)

Then you will have to build the kernel itself, and all modules. You will need to be careful about installation. We will pick a different CONFIG_LOCALVERSION, one which is different than “-tegra”. An example would be “-usbdev” to describe what you added (the actual name isn’t too important).

Here are the modified build steps, similar to the previous list (and exactly matching in some parts):

  • Get an empty temporary output location set to “$TEGRA_KERNEL_OUT”. Best done by actually removing the directory if you wish to start over (this removes “hidden” dot files…and “.config” is technically a “hidden dot file”).
  • Build tegra_defconfig with the “O=$TEGRA_KERNEL_OUT”.
  • You can search for CONFIG_LOCALVERSION, and customize that to something like “-usbdev”. This step differs from just a module build.
  • Now your build is set to be an exact match to the running system (or at least to the default…which is what systems are set to anyway). It is time to edit.
  • Now run “make O=$TEGRA_KERNEL_OUT nconfig”. Search for and find the hiddev feature via the symbol search for CONFIG_USB_HIDDEV (use F8 to search for the symbol). Go there.
  • Once that feature is highlighted, press the “y” key to make it toggle to “[*]”. This becomes an integrated feature, and is no longer a module.
  • Verify it is “[*]”, and save. You’re ready to propagate configuration.
  • Propagate via “make O=$TEGRA_KERNEL_OUT modules_prepare”. Since we are going to build the Image target, this is technically not required, but it doesn’t hurt.
  • This time you must build the kernel itself (plus modules). To build the kernel itself (I’m assuming use of 6 CPU cores, which is what the “-j 6” is for):
# This takes quite some time:
make O=$TEGRA_KERNEL_OUT -j 6 Image
  • You can now build modules:
    make O=$TEGRA_KERNEL_OUT modules
  • You can then place the modules in a new temporary location. Example:
mkdir ~/modules
export TEGRA_MODULES_OUT="~/modules"
make O=$TEGRA_KERNEL_OUT INSTALL_MOD_PATH=$TEGRA_MODULES_OUT modules_install

…this time you will need all modules within “$TEGRA_MODULES_OUT”. You will also find the file “Image” in “$TEGRA_KERNEL_OUT”. For that:

cd $TEGRA_KERNEL_OUT
find . -type f -name 'Image'

When you find those, then you’ll be ready for the next set of instructions. If you have to build Image, then the installation gets more complicated. The official documents describe putting this in the flash software, and then flashing, but what you’re really in need of is to update the existing system without too much risk and without losing your existing install. If the Image and modules build steps work as expected, then we can move on to that.

This is exactly what is happening, “y” or “n” button works and I can see [*] and [ ] accordingly, but “m” button doesn’t work and I can not set it to [M].

So I’ve done everything as per your instruction and here it is:

jetson@192.168.1.115:~/output$ find . -type f -name 'Image'
./arch/arm64/boot/Image

At the end of modules_install there was some errors, no Idea is it very important or not, below is terminal output with the part where errors started:

INSTALL sound/synth/snd-util-mem.ko
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/tigon/tg3.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/tigon/tg3_tso.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/tigon/tg3_tso5.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/acenic/tg1.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/acenic/tg2.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/bnx2x/bnx2x-e1-6.2.9.0.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/bnx2x/bnx2x-e1h-6.2.9.0.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/bnx2x/bnx2x-e2-6.2.9.0.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/bnx2/bnx2-mips-09-6.2.1a.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/bnx2/bnx2-rv2p-09-6.0.17.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/bnx2/bnx2-rv2p-09ax-6.0.17.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/bnx2/bnx2-mips-06-6.2.1.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/bnx2/bnx2-rv2p-06-6.0.15.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cxgb3/t3b_psram-1.1.0.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cxgb3/t3c_psram-1.1.0.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cxgb3/ael2005_opt_edc.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cxgb3/ael2005_twx_edc.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cxgb3/ael2020_twx_edc.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/e100/d101m_ucode.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/e100/d101s_ucode.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/e100/d102e_ucode.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/yamaha/ds1_ctrl.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/yamaha/ds1_dsp.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/yamaha/ds1e_ctrl.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/3com/typhoon.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/emi26/loader.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/emi26/firmware.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/emi26/bitstream.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/emi62/loader.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/emi62/bitstream.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/emi62/spdif.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/emi62/midi.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/kaweth/new_code.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/kaweth/trigger_code.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/kaweth/new_code_fix.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/kaweth/trigger_code_fix.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cpia2/stv0672_vp4.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/adaptec/starfire_rx.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/adaptec/starfire_tx.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/dsp56k/bootstrap.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/atmsar11.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/sun/cassini.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/matrox/g200_warp.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/matrox/g400_warp.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/r128/r128_cce.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/R100_cp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/R200_cp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/R300_cp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/R420_cp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RS690_cp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RS600_cp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/R520_cp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/R600_pfp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/R600_me.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV610_pfp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV610_me.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV630_pfp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV630_me.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV620_pfp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV620_me.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV635_pfp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV635_me.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV670_pfp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV670_me.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RS780_pfp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RS780_me.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV770_pfp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV770_me.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV730_pfp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV730_me.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV710_pfp.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/radeon/RV710_me.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/av7110/bootcode.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/ttusb-budget/dspbootcode.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/myricom/lanai.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/LA-PCM.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/PCMLM28.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/DP83903.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/NE2K.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/tamarack.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/PE-200.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/PE520.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/3CXEM556.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/3CCFEM556.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/MT5634ZLX.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/RS-COM-2P.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/COMpad2.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/COMpad4.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/SW_555_SER.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/SW_7xx_SER.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/cis/SW_8xx_SER.cis' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/ositech/Xilinx7OD.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/advansys/mcode.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/advansys/38C1600.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/advansys/3550.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/advansys/38C0800.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/qlogic/1040.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/qlogic/1280.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/qlogic/12160.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/qlogic/isp1000.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/qlogic/sd7220.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/korg/k1212.dsp' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/ess/maestro3_assp_kernel.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/ess/maestro3_assp_minisrc.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/sb16/mulaw_main.csp' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/sb16/alaw_main.csp' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/sb16/ima_adpcm_init.csp' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/sb16/ima_adpcm_playback.csp' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/sb16/ima_adpcm_capture.csp' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/yamaha/yss225_registers.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/tehuti/bdx.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/mpr.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa18x.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa19.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa19qi.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa19qw.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa19w.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa28.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa28xa.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa28xb.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa28x.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa49w.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan/usa49wlc.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/ti_3410.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/ti_5052.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/mts_cdma.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/mts_gsm.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/mts_edge.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/edgeport/boot.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/edgeport/boot2.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/edgeport/down.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/edgeport/down2.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/edgeport/down3.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/whiteheat_loader.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/whiteheat.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan_pda/keyspan_pda.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/keyspan_pda/xircom_pgs.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/vicam/firmware.fw' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/yam/1200.bin' doesn't match the target pattern
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:41: target '/home/jetson/modules/lib/firmware/yam/9600.bin' doesn't match the target pattern
  INSTALL /home/jetson/modules/lib/firmware/acenic/tg1.bin
install: missing destination file operand after '/home/jetson/modules/lib/firmware/acenic/tg1.bin'
Try 'install --help' for more information.
/home/jetson/Downloads/kernel/kernel-4.9/scripts/Makefile.fwinst:42: recipe for target '/home/jetson/modules/lib/firmware/acenic/tg1.bin' failed
make[2]: *** [/home/jetson/modules/lib/firmware/acenic/tg1.bin] Error 1
/home/jetson/Downloads/kernel/kernel-4.9/Makefile:1402: recipe for target '_modinst_post' failed
make[1]: *** [_modinst_post] Error 2
make[1]: Leaving directory '/home/jetson/output'
Makefile:171: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

You don’t need to worry about firmware. I was not expecting that command to worry about it either, but it might be worth explaining this just for curiosity’s sake.

There is also a build target for firmware (basically device tree). That target is “dtbs”. The firmware goes to somewhere under “/lib/firmware”, which is where the missing files are complained about (and you don’t care about that, you’re not using the firmware). One could specify the firmware install path option similar to the location of the modules_install via “INSTALL_FW_PATH=...somewhere...”. You’ve specified for INSTALL_MOD_PATH=...somewhere..., so it is apparently thinking you want to install firmware content.

You don’t need to know this, but some trivia you might be interested in related to firmware: Firmware tends to be uploaded directly into some device, and it changes the device; conversely, a driver is what talks to the device, and is loaded into the operating system. The two halves make the whole. Most of the time firmware is not needed unless there is some sort of configuration required. The device tree in part helps to find hardware which is not plug-n-play for content which is directly wired to the carrier board. Firmware tends to not change with driver revisions unless the driver or hardware have undergone significant revision. If we make minor changes to a kernel we probably also rebuild the driver, but don’t bother rebuilding the device tree (or other firmware…the hardware is still located in the same place).

Is it correct that this content is directly accessible on your Nano? This makes it easier. To prepare, before actual install (there is some risk for installing a full kernel which is mostly risk-free if just installing a module), here are some steps:

  • Write down the result of the command “uname -r” (which happens to be the current running kernel responding).
  • Write down the new CONFIG_LOCALVERSION. For example, state if you used the suggested “-usbdev”, or something else.
  • Attach a copy of your “/boot/extlinux/extlinux.conf”. I’ll explain how to edit that.
  • Make sure you have a working serial console. Picking alternate boot entries is via serial console, and making optional boot entries is how you take the risk out of testing a new kernel.

You can install without a serial console, but risk goes up significantly. I’ll explain what to do for install steps once you post your extlinux.conf (you could paste it into the thread, and then mark it as a code block to preserve formatting, but it can be easier to just attach the file; if attaching, not sure if you’ll need to rename the file extension to “.txt”).

Yes, that is correct it is Nvidia Jetson Nano 4GB Developer Kit board, a test unit that can be formatted etc. It is not an issue to lose anything.

jetson@192.168.1.115:~$ uname -r
4.9.299-tegra
CONFIG_LOCALVERSION="-usbdev"

extlinux.conf (845 Bytes)

Unfortunately, this is not possible, I do not have any machine with RS-232 port and appropriate serial cable. I can access Jetson Nano via SSH network connection and physically via monitor/keyboard/mouse.

This does not use an RS-232 port. You’re thinking of a DB-9 connector. The protocol is the same, but the physical specification differs. It is a serial UART, but one end has a USB connector. That USB connector goes to the host PC, and the other end (with either 3 wires or 6 wires) goes to the Jetson pins. You’d use the ground, TX, and RX pins (a 6 wire USB UART cable works too, you’d just ignore the other wires).

Here are some example cables:

Some are much less expensive than others. The key here is that you need three loose wires (6 wires works, but you don’t need that), and the voltage must be a TTL level of 3.3V. Same protocol, but no DB-9 connector. USB at the host PC end, wire pins at the Jetson end.

The name of the device special file which appears on your host PC will differ depending on the manufacturer of the chipset inside of the serial UART cable. Most of them won’t need any extra driver. You must have this if the information I’m posting below is to have full value. It is possible to add a second entry as described below, and set that entry as first/default, and it would just use that instead of the original, but if something went wrong, then you’d either have to edit the entry or have a UART cable. One normally is advised to test a new kernel with an alternate entry and only make that entry default once tested.


Here is an edited version of your extlinux.conf:

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 

LABEL usbdev
      MENU LABEL usbdev
      LINUX /boot/Image-usbdev
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 

      
# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To do this:
#
# 1, Make a backup of the original kernel
#      sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot

# LABEL backup
#    MENU LABEL backup kernel
#    LINUX /boot/Image.backup
#    INITRD /boot/initrd
#    APPEND ${cbootargs}4.9.299-

Notice that it now has two entries (starting with “LABEL”). I changed the LABEL and I changed the “MENU LABEL” in the added entry. For debugging purposes, I also removed the “quiet” from the command line (the “APPEND” adds to the kernel command line). I recommend removing quiet from the first APPEND as well.

You can make the edits above and it would not change anything in the actual boot unless the second entry is selected via serial UART during boot. This makes it safe because the original kernel and boot entry are still there. More below if you want to give up the safety.

The part which makes this second entry useful is that it has a new file name for the “LINUX” (kernel) file: It is “Image-usb” instead of “Image”. The first step is to copy your new Image file as name “Image-usbdev” to “/boot” (e.g., if you are where Image is in the newly built kernel content, then “sudo cp Image /boot/Image-usbdev”). You’ll need to also add modules to a new location.

The modules you are adding will go in “/lib/modules/4.9.299-usbdev/kernel”. Remember when, during compile, you used “make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=$TEGRA_MODULES_OUT”? Do this:

  • cd $TEGRA_MODULES_OUT
    (you might have to set TEGRA_MODULES_OUT again, or just remember what it was)
  • cd lib/modules
  • ls -ld 4.9.299-usbdev
    (just to verify)
  • sudo cp -adPr 4.9.299-usbdev /lib/modules
    (I added more archive options to cp than is needed; this copies the “4.9.299-usbdev” to the actual location it’ll be used if you built this on the Jetson itself)
  • cd /lib/modules
  • ls
    (verify there is now a “4.9.299-dev/” subdirectory)

When booting, you will get the option to run the usbdev label.


It is a bad idea to not have the serial USB UART cable. However, if you really are ok with it, then make this alternate set of boot entries (a slightly different edit to extlinux.conf):

TIMEOUT 30
DEFAULT usbdev

MENU TITLE L4T boot options

LABEL usbdev
      MENU LABEL usbdev
      LINUX /boot/Image-usbdev
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 

      
# When testing a custom kernel, it is recommended that you create a backup of
# the original kernel and add a new entry to this file so that the device can
# fallback to the original kernel. To dprimaryo this:
#
# 1, Make a backup of the original kernel
#      sudo cp /boot/Image /boot/Image.backup
#
# 2, Copy your custom kernel into /boot/Image
#
# 3, Uncomment below menu setting lines for the original kernel
#
# 4, Reboot

# LABEL backup
#    MENU LABEL backup kernel
#    LINUX /boot/Image.backup
#    INITRD /boot/initrd
#    APPEND ${cbootargs}

Note that in this second version of extlinux.conf that the default “LABEL” is now “usbdev”, and that this is the first entry. The recovery via the original entry is still there, but now the usbdev is what you get if you don’t interrupt boot with serial console and pick it.

Being that this is an SD card model it isn’t all that dangerous anyway since the original content is all there. You could pull the SD card from the Jetson and plug it in to a Linux host PC, and then edit the extlinux.conf again if something went wrong.

Not much is likely to go wrong, but sometimes the initrd would need a change too. I doubt it does in this case, but I could be wrong.

Once you’ve booted up, verify that “uname -r” has changed to “4.9.299-usbdev” (it used to be “4.9.299-tegra”).

I am able to use only option 2, without USB UART serial cable.
Unfortunately, your suggested extlinux.conf file changes didn’t boot into new kernel 4.9.299-usbdev, but always to current 4.9.299-tegra, so since it is just a test unit of Jetson Nano, I just removed LABEL primary part and left only the part with new LABEL usbdev kernel boot, as a result, it started to boot, NVIDIA logo, then black screen, OS do not want to load GUI, it is just stopped on some point during the load with black screen, then I connected to Jetson via SSH network connection and here is the outcome:

jetson@192.168.1.115:/dev$ uname -r
4.9.299-usbdev
jetson@192.168.1.115:/dev$ zcat /proc/config.gz | grep 'CONFIG_USB_HIDDEV'
CONFIG_USB_HIDDEV=y

We can see new compiled kernel and HIDDEV supported, but USB Dongle doesn’t work anyway. The SDK that communicates with USB Dongle does return can not find device as previously.

Here is CompareIt! report to see the difference between Jetson Nano 4GB and Raspberry Pi4 when I insert USB Dongle into USB port:
report.html (4.8 KB)

As you can see, RPI does load some USB HID driver, when Jetson Nano doesn’t:

usbcore: registered new interface driver usbhid
 	7	usbhid: USB HID core driver

Is it possible to contact Nvidia team who compiled the latest image and ask why USB HID devices won’t load driver?

It is odd that it now shows “CONFIG_USB_HIDDEV=y”, but did not before, even though you are running on the old kernel. The old kernel would respond to uname -r as “4.9.299-tegra”, but I’d expect the new one to respond as “4.9.299-usbdev” (I expect that because the “CONFIG_LOCALVERSION=-usbdev”).

Did you add the new Image file with this name and location:
/boot/Image-usbdev

Did you use this extlinux.conf edit?

TIMEOUT 30
DEFAULT usbdev

MENU TITLE L4T boot options

LABEL usbdev
      MENU LABEL usbdev
      LINUX /boot/Image-usbdev
      INITRD /boot/initrd
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 

That variant would indeed load the new Image-usbdev. This would in fact show “CONFIG_USB_HIDDEV=y”. It definitely should not respond to uname -r as “4.9.299-tegra”. The implication would be that either you are using the old kernel, and that kernel already has CONFIG_USB_HIDDEV, or else you are using the new kernel with the wrong CONFIG_LOCALVERSION (which means it is also using the wrong modules).

Please read my answer once again, 4.9.299-usbdev has been booted, kernel is properly compiled, HIDDEV is enabled.

It can not be true, otherwise how old kernel did it? In the old kernel there was # CONFIG_USB_HIDDEV is not set, it is provided in my previous posts.

I did everything as per your instructions. Or please send me the screenshot what exactly I have to change in nconfig just to verify I did set all modules correctly.

So, are there any Nvidia employee available on this forum at all? How they provide support for their products?

I saw this:

Unfortunately, your suggested extlinux.conf file changes didn’t boot into new kernel 4.9.299-usbdev, but always to current 4.9.299-tegra

I interpreted your previous content to think that the “uname -r” still included the “-tegra” suffix. My mistake. Are all of your modules now found at here in addition to uname -r being “4.9.299-usbdev”?
/lib/modules/4.9.299-usbdev/kernel

If so, then this part is present. That means the HIDDEV is present and supported. The only step after that is for the device plugin to associate with the driver. This might imply a need for a udev trigger (udev is part of announcing USB devices to the hotplug mechanism, and can also customize associations or device names).

Does the working system have any software added to it for that device? On the working system can you post the output of:

cd /etc/udev
tree

(you might need to “sudo apt-get install tree”)

NVIDIA did not compile Ubuntu. They added drivers and boot content. Being that this is an embedded system with limited resources, there is a lot of content a PC would just add which is not added by default for reasons of limited resources. So it is a question of finding what content that device requires. The kernel itself now supports HIDDEV, so it becomes possible for the device to associate to the driver. I’m trying to find out on the working system if some file is associated with the device in its udev directory.

You are right, one file must be copied into /etc/udev folder, I did it and USB Dongle is working now. File content just add user access rights

#Enable user access to USB dongle
ATTRS{idVendor}=="1bc0", ATTRS{idProduct}=="8101", MODE:="0666"

The only issue now is that GUI is not loading anymore on compiled 4.9.299-usbdev kernel, I can access device only via network SSH connection. Where can I find boot log on Jetson Nano to show it here?

There is an NVIDIA GUI kernel module that needs to load. This is the parent directory in the old kernel:
/lib/modules/4.9.299-tegra/kernel/drivers/gpu/nvgpu/

This is the new parent directory:
/lib/modules/4.9.299-usbdev/kernel/drivers/gpu/nvgpu/

The file name is “nvgpu.ko”.

Before I say more I need to emphasize something about why we had to build a whole kernel and the modules, such that we did not reuse existing modules…

Whenever we load a module there is a mechanism by which a module’s signature is installed at some offset address. If we have two kernel which have the same integrated/base features (the “=y” features), then we can always add more modules and they’ll work with that kernel. In the case of deleting or adding a feature which is integrated, the loading of the modules might change. This can cause failure or odd behavior by inserting a module from one kernel’s (base feature set of “=y”) expectations of how to load and instead inserting to a different kernel. This is why we built not only the new kernel Image file, but also the modules (despite needing the same modules).

It sounds like (and this is common) you didn’t get the new nvgpu.ko file. If you check the old content:

cd /lib/modules/4.9.299-tegra/kernel/drivers/gpu/nvgpu/
ls

…you’ll find there is a version of nvgpu.ko. If you go to the new module location, it is very likely missing:

cd /lib/modules/4.9.299-usbdev/kernel/drivers/gpu/nvgpu/
ls

Do you still have your kernel source temporary output directory? You should be able to go to either the kernel output location, or the modules output location, and find nvgpu.ko. Using our previous abbreviations which we had set to environment variables (you’ll have to know where that is, they don’t save across boots or across command line terminals), you could go to one of these:

cd $TEGRA_KERNEL_OUT
cd drivers/gpu/nvgpu
ls
# Or you could:
cd $TEGRA_MODULES_OUT
cd lib/modules/4.9.299-usbdev
cd drivers/gpu/nvgpu
ls

Do you see “nvgpu.ko” in either of those locations? The $TEGRA_KERNEL_OUT would also have some intermediate .o files, while the subdirectory in $TEGRA_MODULES_OUT will just be the .ko file. If you have either of those, then copy it (the version built with “-usbdev”) to:
/lib/modules/4.9.299-usbdev/kenrel/drivers/gpu/nvgpu/nvgpu.ko

If not, then maybe we missed something in the configuration.

Both folders does contain nvgpu.ko file:

jetson@192.168.1.115:/lib/modules/4.9.299-tegra/kernel/drivers/gpu/nvgpu$ ls
nvgpu.ko

jetson@192.168.1.115:/lib/modules/4.9.299-usbdev/kernel/drivers/gpu/nvgpu$ ls
nvgpu.ko

nvgpu.ko in all three folders does have same size:

# System Folder
jetson@192.168.1.115:/lib/modules/4.9.299-usbdev/kernel/drivers/gpu/nvgpu$ ls -l nvgpu.ko
-rw-rw-r-- 1 jetson jetson 89684200 nvgpu.ko

# $TEGRA_KERNEL_OUT
jetson@192.168.1.115:~/output/drivers/gpu/nvgpu$ ls -l nvgpu.ko
-rw-rw-r-- 1 jetson jetson 89684200 nvgpu.ko

# $TEGRA_MODULES_OUT
jetson@192.168.1.115:~/modules/lib/modules/4.9.299-usbdev/kernel/drivers/gpu/nvgpu$ ls -l nvgpu.ko
-rw-rw-r-- 1 jetson jetson 89684200 nvgpu.ko

Maybe this information will be helpful for you:

jetson@192.168.1.115:~$ systemctl status proc-sys-fs-binfmt_misc.mount
● proc-sys-fs-binfmt_misc.mount - Arbitrary Executable File Formats File System
   Loaded: loaded (/lib/systemd/system/proc-sys-fs-binfmt_misc.mount; static; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2023-06-13 11:13:22 EEST; 34min ago
    Where: /proc/sys/fs/binfmt_misc
     What: binfmt_misc
     Docs: https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
           https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
  Process: 4933 ExecMount=/bin/mount binfmt_misc /proc/sys/fs/binfmt_misc -t binfmt_misc (code=exited, status=32)

jūn 13 11:13:22 JETSON4GB systemd[1]: Mounting Arbitrary Executable File Formats File System...
jūn 13 11:13:22 JETSON4GB mount[4933]: mount: /proc/sys/fs/binfmt_misc: unknown filesystem type 'binfmt_misc'.
jūn 13 11:13:22 JETSON4GB systemd[1]: proc-sys-fs-binfmt_misc.mount: Mount process exited, code=exited status=32
jūn 13 11:13:22 JETSON4GB systemd[1]: proc-sys-fs-binfmt_misc.mount: Failed with result 'exit-code'.
jūn 13 11:13:22 JETSON4GB systemd[1]: Failed to mount Arbitrary Executable File Formats File System.
jūn 13 11:13:22 JETSON4GB systemd[1]: proc-sys-fs-binfmt_misc.mount: Start request repeated too quickly.
jūn 13 11:13:22 JETSON4GB systemd[1]: proc-sys-fs-binfmt_misc.mount: Failed with result 'exit-code'.
jūn 13 11:13:22 JETSON4GB systemd[1]: Failed to mount Arbitrary Executable File Formats File System.

I don’t think that matters, at least not for now. If you run “lsmod”, do you see “nvgpu”? If not, what do you see from using insmod on it (you might need to use the full path)? If the module is already loaded, then graphical mode should work; if not, and if the module can load, then it might just be a case of needing to run “sudo depmod -A” or “depmod -a”. If that module loads, then it is possible for graphics to succeed.

Should it need more debugging for the GUI, we’ll want this:

  • A new full serial console boot log.
  • A copy of the Xorg log. If you run this command it’ll tell you which log that is:
    ls -ltr /var/log/Xorg.*.log | tail -n 1

Noup, nothing:

jetson@192.168.1.115:~$ lsmod
Module                  Size  Used by

Here is the output:

jetson@192.168.1.115:~$ insmod /lib/modules/4.9.299-usbdev/kernel/drivers/gpu/nvgpu/nvgpu.ko
insmod: ERROR: could not insert module /lib/modules/4.9.299-usbdev/kernel/drivers/gpu/nvgpu/nvgpu.ko: Operation not permitted
jetson@192.168.1.115:~$ sudo depmod -A
depmod: ERROR: could not fstatat(/lib/modules/4.9.299-usbdev, modules.dep): No such file or directory

I do not have USB UART serial cable, are there any other way how to save this boot log?

Please see attached below:
Xorg.0.log (7.6 KB)

This requires using sudo. Was your user root?

You can first run “sudo -s” to drop into a root shell, or you can prefix with:

sudo insmod /lib/modules/4.9.299-usbdev/kernel/drivers/gpu/nvgpu/nvgpu.ko

(be sure to monitor “dmesg --follow” prior to this to see messages in case it does succeed)

This did the trick, you are true Linux GURU, Jetson Nano GUI is loaded now and USB Dongle is working as required.

Thank you a lot for your huge effort to find solution for this case. Very last question, is it the only way how to get it working, compile new kernel with USB HID support and boot from it? There is no option to extract driver now from working system and install them on another Jetson Nano like I can do it on Windows OS?

P.S. Please drop me PM with some crypto wallet address or other way I can donate you some beer or whatever you like for your help! :)

No donation required, I’d get bored if I didn’t do this, but the thought is appreciated. What follows isn’t a “rant”, but it’ll look like it. The long explanation below is more or less about how and why PCs and embedded systems differ on Linux as to what you find by default, and a comparison of both the cost and benefit of Windows for driver developers.


Windows is doing exactly what you just did. Their database is just better.

Just to illustrate, on your desktop PC, look what you have here, which is for a number of network cards:

# The $(uname -r) syntax will self-substitute...it'll fill that in for you:
cd /lib/modules/$(uname -r)/kernel/drivers/net/ethernet
ls

Look at all of those ethernet card drivers! Then look at the same location on a Jetson. The Jetson still has a lot of drivers, but not as many as the desktop PC. To see what package something belongs to, I’ll illustrate with the Intel e100 driver (this driver has been around a very long time):
dpkg -S /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/intel/e100.ko
(Intel has several models, but this is for the specific chipset NIC)

Check the package on both the Jetson and the PC. You’ll find it shows up for the PC, but not the Jetson. It doesn’t mean the Jetson one does not exist.

Before more description, remember these details about building the driver:

  • You had to correctly set up the configuration to match the running system if you were to add a module. When you change the base integrated kernel Image, then you were relegated to rebuilding the entire kernel and all modules. Otherwise the module might not load.
  • You had to use the same kernel source code version to build a module which would load into an existing running kernel. We’re talking “kernel space” drivers, not user space programs.
  • Desktop PCs have a fixed amd64/x86_64 architecture. So they can easily use the mainline kernel source for all of those. You have modified kernel source because the hardware is unique. Look at other files on your system, e.g., look at commands in “/usr/bin/*”. You’ll see those all have a standard package on both the Jetson and the PC. We’re talking “user space” applications, not drivers.
  • User space has a more or less “generic” architecture to build against. Any arm64/aarch64 user space Linux program can run on any other arm64/aarch64 user space computer so long as drivers are present for access to the hardware. A PC’s user space program can be compiled and used interchangeably with any other PC of the amd64/x86_64 architecture, provided the drivers to access the hardware are present.
  • The key to really understand this is realizing that it is the kernel which provides the generic user space environment whereby it is easy for anyone to compile a program and get it it run in user space. However, the kernel itself inherits its environment on bare metal, without any help, and must inherit from what boot code sets up. All of that boot code is custom not only to the hardware drivers, but also to their physical address and other electrical layout setup. If you have a BIOS, like a PC, then it presents a uniform boot environment which makes it possible to standardize the kernel itself for packaging; if you do not have a BIOS, such as Jetsons, then a custom hardware bring-up on bare metal will also mean you need to customize some details of the kernel when compiling it. Both the source code for hardware and the layout differ on custom devices. So the modules are not interchangeable, and the carrier board hardware bare metal during boot which the kernel depends on demands the kernel itself be customized.

NVIDIA could have added all of the drivers you see on a desktop PC. There are 100 Gb/s (not Mb/s, but Gigabit) backbone network cards the Internet itself might use, costing thousands of dollars (maybe even tens of thousands or hundreds of thousands), which could have been added, but you’ll never use them. There are odd and relatively known hardware devices which PCs have inherited since the 1990s, and which were never removed, while 64-bit ARM first started life near 2015. The list for ARM 64-bit of inherited drivers is smaller. That in itself is not conclusive of anything, but it sets the stage.

You have a tiny computer on the Jetson. Because of the customizations and no BIOS, every driver might need custom setup. They’re all available on the kernel source you have, but to use them you must compile them against this custom source (if you remove part of the integrated configuration, or add new things to that configuration, then the interchangeable modules no longer guarantee the ability to interchange). But someone has to do it before you can load the module or build a new Image for the integrated kernel.

Windows for desktop PCs has drivers which are all built by them or their customers who paid money to Microsoft. Each kernel patch release for Windows is the same source code (Microsoft doesn’t exactly make all of their source code freely available the way Linux does, so Microsoft has to be the one to do most of this work). You have the kernel source for the Linux kernel, see what happens when you ask Microsoft for their kernel source. If you want to design and build a custom piece of hardware to run with Windows which does not have a BIOS, and which is to be minimal for an embedded tiny device, see what happens when you tell Microsoft you want them to build custom boot code for you. You won’t like the answer, although if you are a really big corporation and need a barrier to entry for people who don’t have a lot of money, then you might possibly like this.

The reality is that Microsoft controls the hardware requirements and is able to build all of the drivers for their kernel source in a standard environment. Linux for PCs does this too, although the kernel source is available and anyone can customize it. The user space part of custom devices can be uniform as well even on custom Linux devices. NVIDIA is the one which provides (configures and builds) a lot of device drivers in the kernel they ship, and many of those drivers you’ll never use. They’re the most popular drivers. NVIDIA makes that source and the base configuration available so you can build any driver they did not add.

Building drivers on Linux has an initial learning curve, but it isn’t actually all that bad. The Kconfig system does a lot to make it easier. You do have to understand some basics, e.g., knowing what your initial configuration is and matching that prior to making modifications, but once you’ve done it a couple of times it becomes trivial. This is kind of expected in the Linux community if you go beyond “standard” hardware, and sometimes even then. It lets you do things with odd hardware you cannot do with Windows unless you sign an NDA with Microsoft and pay a huge fee for access to their internals. It makes their “standardized” environment more user friendly for end users, at least when using common hardware or when working with big companies which have the money to develop drivers on Windows. As soon as you step into the custom hardware, you’re screwed on Windows as either a small company or a hobbyist.

As any company which wants to be able to audit code and find weaknesses and fix them, Linux is way ahead, Working in Windows either requires you to reverse engineer or pay lots of money and NDA (so you couldn’t fix bugs or flaws for everyone, just for you), or let Microsoft do all the work for something they might not care about because not enough people are suffering from the flaw.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.