Compilation error with R32.1 kernel sources (4.9)


When compiling the kernel sources from public_sources/kernel_src.tbz2 in the R32.1 BSP Sources archive, I ran into the following error:

/usr/src/l4t-sources-32-1/kernel/nvidia/drivers/pinctrl/pinctrl-tegra186-padctl.c:32:10: fatal error: soc/tegra/xusb.h: No such file or directory
#include <soc/tegra/xusb.h>

There is no soc/tegra/xusb.h anywhere in the kernel sources provided. There are three other xusb.h files, but the thing that pinctrl-tegra186-padctl.c apparently wants from the header file is declarations of things like struct tegra_xusb_mbox_msg, and MBOX_CMD_START_HSIC_IDLE, which exist in none of the three (instead they exist inline in xhci-tegra.c).

It also needs something called “struct tegra_xusb_otg_vbus_id”, which is not declared anywhere, including xhci-tegra.c.

BTW, here is a patch which fixed another compilation error:

--- l4t-sources-32-1.bak/kernel/nvidia/include/soc/tegra/tegra_bpmp.h	2019-03-11 07:30:33.000000000 +0100
+++ l4t-sources-32-1/kernel/nvidia/include/soc/tegra/tegra_bpmp.h	2019-04-02 21:43:10.582347648 +0200
@@ -67,7 +67,7 @@
 static inline void tegra_bpmp_free_coherent(size_t size, void *vaddr,
 		dma_addr_t phys) { }
-struct dentry *tegra_bpmp_debugfs_add_file(char *name,
+static inline struct dentry *tegra_bpmp_debugfs_add_file(char *name,
 	umode_t mode, void *data, const struct file_operations *fops)
 { return NULL; }

Have a reference to below link to use 7.3 toolchain.

Hi ShaneCCC.

I am using 7.3. (The TX2 is actually the only one of my systems where I have not switched to 8.x yet. :)

Did you follow below doc to build?

Hi ShaneCCC.

I’m not building tegra_defconfig. I’m using the .config from my current R28.2 kernel, which was based on tegra_defconfig but has lots of upstreams features enabled that I need.

Getting the same “soc/tegra/xusb.h: No such file or directory” error.

Official R32.1 kernel source. Official devkit kernel .config from flashed TX2 devkit:


Linux ubuntu-desktop 4.9.140-tegra #1 SMP PREEMPT Wed Mar 13 00:30:11 PDT 2019 aarch64 aarch64 aarch64 GNU/Linux

Did anyone have a success with 4.9 kernel compilation from source using official TX2 devkit config?

config-4.4.38-tegra_tx2.txt (139 KB)

The kernel version has changed from R28.2 to R32.1. Although many settings will be the same (it is the same major version) you can expect differences where the kernel config of one release is not valid with another release (you shouldn’t directly swap configs across releases when the kernel version changes).

You probably need to start with the default new running system’s “/proc/config.gz” and manually make changes in a config editor (such as “make nconfig”) after comparing against the old R28.2 config customization previously installed. Only edit items which you know are custom (using the config editor implies the editor will automatically make dependency changes…the changes between the R28.x kernels and the R32.1 kernel imply changes to dependencies).

linuxdev - have you tried to reproduce kernel build shipped with R32.1 from sources provided by NVidia?
With "/proc/config.gz, as-is, official, no modifications. To run on Jetson TX2.

I have not yet tried to build this. Right now I’m in the middle of getting my host PC back up (replaced a bad power supply, and then motherboard/CPU upgrade). I’m waiting for a new network card as well, and once that is here I’ll probably start working on it. However, it still remains true that you must first configure, and that it is unlikely the older config can be directly substituted in this particular kernel version…it is just asking for trouble (assuming the config of R28.x is used with R32.1 this is likely to fail).

It was error on my side. reused old config by mistake. with new proc extracted config - no build errors.

Hi DmitriK.

I was able to get rid of the <soc/tegra/xusb.h> compilation error by replacing the CONFIG_PINCTRL_TEGRA186_PADCTL kernel config with CONFIG_PINCTRL_TEGRA186_DPAUX.
I compared the default configs for R28 and R32 and found that there were a lot of configs which had
new names for no apparent reason… FWIW if you want the same set of features you should be able to
reuse the same kernel config even if changing kernel versions, that’s how it works with upstreams

Anyway, after changing a lot of options to better match the new defconfig, I got the kernel to
compile but it did not run. Maybe it’s because it requires a new device tree to be flashed (another
annoyance that happened the last time the kernel version was changed). I haven’t gotten around
to trying that yet - there’s extra work to do there because I need custom changes to the device
tree for KVM to work correctly (although with the new kernel maybe that is not needed anymore?)…


Re: flashing device tree

I was successfully avoiding the dtb “flashing” in past, kept it in rootfs along with kernel. But now it is must have: