Attempting to compile kernel sources as described, make -j4 fails.

I have installed

R21 (release), REVISION: 4.0, GCID: 5650832, BOARD: ardbeg, EABI: hard, DATE: Thu Jun 25 22:38:59 UTC 2015

On my Tegra TK-1 board, using the cross-compile and flash method. The board seems to boot fine.

I want to modify a driver parameter for the USB3 ports, to allow more memory to be allocated for buffers. (this is not my problem, just explaining why I’m doing the following)

In order to do this, I downloaded the kernel sources as follows, on to my tegra TK-1 board:

  1. sudo su
  2. cd /usr/src
  3. #make sure no kernel sources are present
  4. wget
  5. make -j4

and the make command fails due to

kernel/sched/core.c: In function ‘cpu_cgroup_allow_attach’:
kernel/sched/core.c:7811:18: error: invalid operands to binary != (have ‘kuid_t’ and ‘kuid_t’)
cred->euid != tcred->uid && cred->euid != tcred->suid)
kernel/sched/core.c:7811:46: error: invalid operands to binary != (have ‘kuid_t’ and ‘kuid_t’)
cred->euid != tcred->uid && cred->euid != tcred->suid)


fs/proc/base.c: In function ‘oom_adjust_permission’:
fs/proc/base.c:1023:7: error: incompatible types when assigning to type ‘uid_t’ from type ‘kuid_t’
uid = task_uid§;
fs/proc/base.c:1031:28: error: invalid operands to binary == (have ‘kuid_t’ and ‘int’)
if (p && (current_fsuid() == 1000) && (uid >= 1000)) {

I have also repeated the above steps, with a “zcat /proc/config.gz > .config” and the make -j4 fails then as well. I also tried running “menuconfig” after the “zcat” and just exiting without changing anything, saving the result, and make -j4 also fails both ways, with the same errors, but more warnings.

I am compiling on the TK-1 itself. Also, I used this
as a reference for the overall procedure.

Can anyone tell me how to get past this, or give me pointers as to how to proceed to debug it further?

thanks, and best regards,
    Nick Caruso

More info: in general all the errors seem to stem from an issue around kuid_t versus uid_t or int values of uid. Am editing the kernel source according to hints I’ve found from others who’ve run into similar problems.

This comment still seems relevant and true.

I suspect that this is an issue that doesn’t arise when cross compiling, for some reason, but which does when compiling on the tk1 itself.

Well, tried cross-compiling, using same kernel source and the .config from the board, and got the same error. Here’s the make command line I used, in case I fubar’d that:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

If you can, always try natively compiling on Jetson before switching to cross-compile. Second, you mentioned /proc/config.gz, you should always keep an archive copy of this whenever you get a working kernel (I have a reference copy of each from R19.2 through R21.4, plus every variation I’ve used on each).

In your kernel source tree, to get a pristine unconfigured copy, run “make mrproper”. This will even remove the “.config”. Put a new .config in via config.gz, and run “make menuconfig” (may require adding package libncurses5-dev)…inside this adjust the “General setup”->“Local version” if needed. On R21.4 I’d suggest something like “-gdacac96_1” if it will be modified based on the original. Save if needed, and exit. This should make it possible for “make -j4” to work.

With a proper configuration in place, errors will have meaning. Once your basic configuration via an original /proc/config.gz works, adding your own configuration changes can take place. This is when you can post exact errors and we’ll be able to help resolve those. A missing start config known to work is a major source of confusion, as kernels don’t use auto configuration such as autoconf.

Thanks for your help!! I am doing this now. I would ultimately like to be running the “grinch” kernel based on the latest l4t 21.4 sources; can you tell me where to download such a thing from? Currently, I am using the result of


and building that.

OK, I untarred the kernel sources from the wget command in previous comment, then ran

  1. cd /usr/src/kernel
  2. make mrproper
  3. zcat /proc/config.gz > .config
  4. make menuconfig, edited local info, noted that it already said “grinch”, added my own id, then saved and exited.
  5. make -j4

Attached please find the log – it fails as described before. (assuming I can attach the file after posting this…)
build_log.txt (32.1 KB)

What does this print:

gcc --version

And this:

dpkg -l |grep gcc-
root@tegra-ubuntu:/usr/src/kernel# gcc --version
gcc (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO

root@tegra-ubuntu:/usr/src/kernel# dpkg -l | grep gcc-
ii  gcc-4.8                                               4.8.4-2ubuntu1~14.04                                armhf        GNU C compiler
ii  gcc-4.8-base:armhf                                    4.8.4-2ubuntu1~14.04                                armhf        GCC, the GNU Compiler Collection (base package)
ii  gcc-4.9-base:armhf                                    4.9.1-0ubuntu1                                      armhf        GCC, the GNU Compiler Collection (base package)
ii  libgcc-4.8-dev:armhf                                  4.8.4-2ubuntu1~14.04                                armhf        GCC support library (development files)

One thing that catches my attention is the fact that LOCALVERSION already said “grinch”, while you had also said you’re using sources from the R21.4 download. It sounds like the running kernel you are extracting config from is a Grinch kernel, but Grinch config should not be applied to a non-Grinch default kernel. Parts of Grinch include backports of drivers which don’t exist in the default kernel, so config is not completely interchangeable between the two.

Do you have a default kernel you can run and get a /proc/config.gz from that to compile a non-Grinch kernel? If that succeeds it would validate the ability to at least build correctly on that Jetson.

Hm. good point. I think you have isolated the problem.

One thing that I would prefer given my schedule, is to try to download the sources for the grinch kernel, and build against those. Are those available, based on an l4T 21.X release?

I don’t know if these URLs are still good or if Grinch is still out there, but this is my last known list which I saved when making archives of Grinch versions (I considered putting these in the Jetson Links sticky, but it has always been a moving target):

Especially that patch seems to address the original issue in this thread.

is there some defconfig for tk1??


by look at NVIDIA Tegra Linux Driver Package Development Guide , and step by step, I’m successfully to compile the kernel , the default configure file for tk1 is tegra12_defconfig

i hope this will help you

this is my arm-gcc at the host pc

arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.8.2-16ubuntu4) 4.8.2
Copyright © 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

may be you should try it at the host

Those sources compiled, and I did a make modules; make install and make modules-install worked as well.

But the board rebooted into the old kernel. I copied zImage from my build directory into /boot/zImage and then the machine rebooted into the new kernel. Why didn’t make install install the zImage file?

Thanks for all your help, linuxdev et alia!!!

On a desktop there would be standard mechanisms for boot infrastructure. On embedded (with no BIOS and no standard boot loader), this is all specific to one board using one boot loader. Kernel install via make install could work for u-boot with Makefile edits, but only for u-boot; kernel install when using fastboot would fail and could not work from make install (at least not without extraordinary additions to make install). For this hardware, the Makefile has no reliable way to understand which bootloader is in use.

Unless doing something custom, the firmware file tegra124-jetson_tk1-pm375-000-c00-00.dtb won’t need manual install, but this too is subject to requiring manual install if editing firmware files within the kernel source tree.

Recompiling from the sources LinuxDev showed above seems to have worked for me – thanks for your help, everyone!