building TX1 kernel from source

I just typed in a long post and got a security error when I hit the reply button. Lost the whole post. Whats up with that? Is there a length limit? A nice working procedure for kernel compile cross or chroot.

Griz

So I rebuilt the kernel from git://nv-tegra.nvidia.com/linux-3.10.git on branch l4t/l4t-r23.1 with the 5.2 GCC toolchain (64 bare-metal & 32) from LINARO.

I got the same two “r7” (-fomit-frame-pointer) and tegra21_clock.c () issues as everyone else in this thread. I tried rebuilding on a fresh install of a 14.04 ubuntu system but had the same problems.

When I installed and rebooted I got the WIFI issue, so I moved the brcm firmware to prevent loading.

Since these issues were reported sometime in Dec and it’s mid-Jan now, I was wondering when the next release will be to resolve these kernel issues.

Hi

I’m building the kernel from the source code(R23.2 release) using the patch given in forums to enable 0v5693 camera.
I’m following the procedure given in the nvidia documents and also this link by David.

Build is success. I changed the contents of kernel folder in rootfs with the newly builded ones(followed David’s link exactly in replacing the kernel folder with new content) and did ./apply_binaries.sh.Then I copied the rootfs from sample file system to sdcard(partitioned to ext4).
Board is booting up with SDcard.

But when i tried sudo modprobe ov5693_v4l2
modprobe: ERROR: 
/libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file ‘/lib/modules/3.10.67-g458d45c/modules.dep.bin’

When i tried sudo insmod /lib/modules/3.10.67-g458d45c-dirty/kernel/drivers/media/i2c/soc_camera/ov5693_v4l2.ko
insmod: ERROR: could not insert module /lib/modules/3.10.67-g458d45c-dirty/kernel/drivers/media/i2c/soc_camera/ov5693_v4l2.ko: Invalid module format

Later by googling I understood some kernel mismatch is the reason for this.

And I checked vermagic in .ko files.
So It turns out that
vermagic=3.10.67-g458d45c-dirty in all .ko files
but my uname -r is 3.10.67-g458d45c

uname -a is
Linux tegra-ubuntu 3.10.67-g458d45c #1 SMP PREEMPT Mon Feb 8 17:44:18 PST 2016 aarch64 aarch64 aarch64 GNU/Linux

Anybody please help me to correct my mistake.

Hello Griz,Please help me out.

If you look at the “.config” file generated via the make tegra210_defconfig (and probably updated via make menuconfig), what is the CONFIG_LOCALVERSION? See:

grep CONFIG_LOCALVERSION .config

It looks like your running kernel has this value as “-g458d45c”, but you installed modules as “-g458d45c-dirty” (the “-dirty” causes the search for modules to be incorrect versus the running kernel). Typically the CONFIG_LOCALVERSION would be changed slightly if a built-in feature of the kernel were changed (and possibly the source code itself).

Hi Thanks for the reply.

when I gave the command:
grep CONFIG_LOCALVERSION .config

CONFIG_LOCALVERSION=“”
CONFIG_LOCALVERSION_AUTO=y

I have one more doubt. There is default OS in the flash memory of board with linux version: 3.10.67-g458d45c.

After building the kernel from source code I opened Image file and checked for linux version. It is 3.10.67-g458d45c-dirty(for R23.2) and 3.10.67-gbaaa7aa-dirty(for R23.2 update-01).

I,m copying rootfs to sdcard and booting the board with sdcard.

So when I type uname -a what should I get??

Should it be linux version: 3.10.67-g458d45c or linux version: 3.10.67-gbaaa7aa-dirty

Is it ok to have one OS in flash and other in sdcard, I mean different versions.

If these doubts are silly, sorry for asking.I’m new to linux.

Without the CONFIG_LOCALVERSION the software you built would have thought modules it requires are for 3.10.67, not 3.10.67-g458d45c or 3.10.67-gbaaa7aa-dirty. You will need to set CONFIG_LOCALVERSION to something consistent among the running kernel and the compile
probably “-g458d45c” for everything. Typically a change to kernel source which alters the integrated features would suggest changing the “-g458d45c” to something else, perhaps this is what the meaning is of “-gbaaa7aa-dirty”
the “gbaaa7aa” for source patches, and the “-dirty” for other configuration change in addition to that.

For a JTX1 on L4T R23.x the kernel format is just “Image”, and you’d want to put a copy of this in your “/boot” with a version in the file name in cases where you’ve decided to install a new kernel and not just additional modules (allows you to keep the old kernel while testing the new one
if they are both “Image” then you just lost one). You “/boot/extlinux/extlinux.conf” would need editing to point at the new kernel, and the modules would need to be installed in the resulting “/lib/modules/$(uname -r)” directory.

You probably will always want to have a default install on eMMC (mmcblk0p1), but extlinux.conf can be edited to use a root file system on SD card (mmcblk1p1) without actually flashing the boot loader to SD card. Once you put config on SD card your eMMC can no longer be used as a root partition source without more setup
the worst issue of this is that your boot loader may require that SD card to be present from then on to chain load to the eMMC (or another SD card set up via the flash process).

Hi alamuru,

Sorry I think I had a typo on the step that deals with the local version by default when you clone the kernel if you add some change in the code - like the patches - it will add the word dirty. I already updated step 8 and 9 so it should work for you now. With the updated steps you should be fine.

-David

Talking about the camera, it is really sad to read in the datasheet that the camera that comes with the module doesn’t give YUV, does anybody knows of someone creating a camera module with other sensor? I would like to buy one so I can prototype bypassing the ISP for the time being.

Thanks @linuxdev and David for the help.

The problem was with extLinux.conf.
I figured it out and now the camera is working.

Still getting that r7 error from the most recent 24.1 source release today. Any advice here ?

bill

I had to build tool chains according to instructions from R24.1. The following post is very helpful:

https://devtalk.nvidia.com/default/topic/936880/jetson-tx1/jetson-tx1-24-1-release-need-help-with-complier-directions-can-not-complie/post/4883622/#4883622

With new tool chain, I did not get the errors for R23.1.

R24.1 is much convenient for me since I can build drivers and apps natively on TX1.