How to add driver support to kernel with menuconfig [Jetpack 6]?

I have a Jetson Orin Nano running Jetson Linux 5.1.2 and I want to upgrade to JetPack 6.

The drivers for the 5G module compiles on JetPack 5 but throws this error on JetPack 6.

ERROR: modpost: "rmnet_nss_callbacks" [/home/cm_v2/drivers/qmi_wwan_q/qmi_wwan_q.ko] undefined!
ERROR: modpost: "usb_cdc_wdm_register" [/home/cm_v2/drivers/qmi_wwan_q/qmi_wwan_q.ko] undefined!

Is the support to these are not enabled?

I checked the .config and it has


# CONFIG_USB_WDM is not set

Do I need to enable them using menucofig?

if yes, could you please explain me the steps to do so?

Thank you!

Sorry for the late response.
Is this still an issue to support? Any result can be shared?

You always start with a full kernel config that matches your running system. One possibility is by using the default config. For JetPack 6.x/L4T R36.x, that is “mostly” the “defconfig” target. You would also need to set your “CONFIG_LOCALVERSION” (if you are only adding modules, then use “-tegra”; if you are changing integrated features, then you probably need to completely build the kernel and all modules and change the CONFIG_LOCALVERSION to something like “-new”).

Your error is because you have a feature that was built depending on another feature, and the other feature is missing. menuconfig (and nconfig) is designed to understand dependencies. This allows you to do things like add the 5G module and automatically include dependencies.

Are you adding this as a module and keeping the rest the same? Or are you changing the base kernel?

1 Like

Thanks a lot @linuxdev
Now it is making more sense.

I just want to add modules for 5G support and keep the rest of the things same.
We have a custom carrier board, so I want to modify the device tree configuration.

For the kernel then, just reuse the original. Configure to match the running system, keep the -tegra CONFIG_LOCALVERSION.

Note that a running Jetson kernel will also have the config in “/proc/config.gz”. If anything is customized, then this will still reflect the running kernel, whereas defconfig could begin diverging. Just copy config.gz somewhere, gunzip it, and rename to .config. Edit the “CONFIG_LOCALVERSION” to “=-tegra” since you are keeping the original kernel Image. Note that CONFIG_LOCALVERSION is never reflected in the “/proc/config.gz”.

Device tree is not actually part of the kernel, and this probably won’t change unless something in your 5G is not “plug-n-play”. USB devices tend to not use a device tree to upload firmware; similar for PCIe.

Regarding device trees, you can think of those more or less as an argument passed to drivers. One of the biggest uses of device tree is to simply tell a driver what physical address to find a device at when the device cannot self-report. Because each device tree node more or less only applies to a given kernel feature (or symbol), it is convenient to make device tree compile available with the kernel source using the configuration of the kernel you are building. Because the kernel and device tree have a common configuration they are packaged together. You do not normally need to build a device tree though.

Example: USB device gets a new module; or even is integrated into the kernel. No device tree change is needed since USB does the self-reporting work. The udev mechanism is the part of the USB which modifies USB devices for customization, but this would not be a device tree edit.

Example: A network device is added as a module. Network devices very often require firmware due to hardware complying with local regulations needing that firmware for the particular region of the world it runs in. The firmware in this case is not the device tree. This firmware is uploaded into the network device itself, and is agnostic to the host platform’s architecture. Regardless of whether the drivers know where this device is via plug-n-play of USB or PCIe, the device tree won’t change. However, if this is a 5G device wired directly to a bus or memory controller of the board, and there is no plug-n-play mechanism, then you would need a device tree edit. The 5G firmware would not care about the device tree, and would “just work” regardless of whether the device is discovered through self-reporting or device tree.

Is this 5G wired to a bus or memory controller? Or is it using some plug-n-play environment that can find the device just by plugging it in?

1 Like