[HowTo] Build own kernel for Jetson TK1

Looks like R21.1, so no flash (it defaults to u-boot not fastboot). You’ll see in /boot kernels in zImage format (ignore outdated references to other formats for u-boot) and a configuration in /boot/extlinux.conf.

You can place your zImage there with an alternative name (like ‘zImage-test’) and create and edit a copy of the “LABEL” through “APPEND” lines (this last line is a huge line, don’t break it up) with a blank line between blocks and modified LABEL/MENU LABEL plus your new zImage name in the LINUX key-value pair. Boot with serial console and hit a key when it briefly shows kernel selection and you can pick which kernel you want to boot. If you don’t want to use serial console you’ll have to make the new entry the “primary”.

It’s been a while since I got this far into messing with Linux, but this seems very familiar with how I used to do things 10+ years ago. I’ll give it a shot.

EDIT: worked fine. Up and running on my new kernel.

using Nvidia R21 do I still need to build a new kernel for Sony PS3 eye camera support.

ie might modprobe be sufficient?

if not could we please have a new clean instruction set…**

~:"

maybe here: Jetson TK1 - eLinux.org

I have the exact same experience as cedar_luo ie



file not found: boot.img

I built as per instructions on brand new Jetson, which I had upgraded successfully to R21.2, my desktop is also ubuntu 14.04, proceeded as expected to this point…

further comments appreciated!

~:"

I added modules for PS3 eyecamera as instructed here:
https://devtalk.nvidia.com/default/topic/766276/guide-playstation-eye-on-jetson-tk1/
no other changes at all.

ie please could we have a slightly more detailed version of the non-flash version?

I am not familiar with what is suggested, so have no picture of what is intended…
even from ten years ago.

tx

~:"

Instructions are in comment #41.

SHORT SUMMARY

After you compile your kernel and modules and then installed the modules, all you have to do is copy the new zImage to /boot, replacing the old zImage, and then reboot.

You might want to make a back-up copy of the original /boot/zImage first in case you want to revert back to it.

ah well that seems easy enough, will give it a spin in the morning and report:

wfm

tx!

~:"

in case of total failure to boot, how to restore arc zImage?
ie is there a way to read, copy and edit eMMC when Jetson is cold?
https://devtalk.nvidia.com/default/topic/802396/embedded-systems/howto-edit-boot-when-jetson-is-off-/

ignore depmod -a and copying modules

when I checked the installed modules by

ls /lib/modules/
3.10.40-gc017b03 3.10.40-testtest

These two modules are installed but there is no zImage in arch/arm/boot/ directory which is very confusing for me
http://postimg.org/image/6mbixmj0z/

If the zimage wasn’t created, you likely have a compiling error that you didn’t see.

Hi all!
I have the same problem with flashing device. Ubuntu 14.04, JetPack 1.2, running flash.sh with command:

./flash.sh -S 12GiB -k 6 jetson-tk1 mmcblk0p1

It hangs while running nvflash:

*** Updating 6:LNX with boot.img ***
./nvflash --download 6 boot.img  --bl fastboot.bin --go
Nvflash 4.13.0000 started
BR_CID: 0x34001001740db08904000000080005c0
rcm version 0X400001
System Information:
   chip name: unknown
   chip id: 0x40 major: 1 minor: 1
   chip sku: 0x0
   chip uid: 0x00000001740db08904000000080005c0
   macrovision: disabled
   hdcp: disabled
   jtag: disabled
   sbk burned: false
   board id: 0
   warranty fuse: 0
   dk burned: false
   boot device: emmc
   operating mode: 3
   device config strap: 0
   device config fuse: 0
   sdram config strap: 0

RCM communication completed
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
sending file: fastboot.bin
- 594363/594363 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
file not found: boot.img
failed executing command 2147483647 NvError 0x4
partition download failed
Failed to flash ardbeg.

-S existence changes nothing: an error still exists.
I run flash.sh from sudo bash, so I think, that the problem is not because of access rights.
If I run ./nvflash --download 6 boot.img --bl fastboot.bin --go standalone (directly from console), I get the same error.

Any ideas?

The only idea is to create boot.img manually, because

nvflash --help
...
--download          : used to download filename into a partition
...

So, somewhere there has to exist boot.img, but it doesn’t!
In bootloader dir there is mkbootimg command. But it has the following syntax:

usage: mkbootimg
       --kernel <filename>
       --ramdisk <filename>

–kernel - zImage, --ramdisk - ???

Understand that the -k parameter works only with fastboot.bin as the boot loader, telling where to store the kernel. Under the entire R21.x series u-boot is the boot loader, and this uses /boot rather than a separate partition. You could reduce eMMC size from this, but try this as a test without the -k parameter:

sudo flash.sh -S 14580MiB jetson-tk1 mmcblk0p1

Keep in mind that many permission issues have nothing to do with running flash.sh as root, but instead occur before this as early as unpacking the sample rootfs. Non-root is not allowed to do many operations on device special files, and so unpack may fail as non-root without much indication. There have even been a couple of people lately that have some form of virus scanner on linux and this alters their unpack and causes mysterious failures.

Thanks for the guide. Much appreciated.

thanks

Yes, that was the problem - I tried to flash fastboot instead of u-boot.
So, simple flash.sh jetson-tk1 mmcblk0p1 works ok.
Thank you!

But I met the next strange problem: I try to rebuild kernel with LPAE enabled. I used nvidia default config, and added CONFIG_ARM_LPAE enabled.
But if I enable this option, I loose network (eth0)! If I disable it, my own kernel works ok. If I enable it, everything boots ok, but eth device is down.
If I say

ifconfig eth0 up

it responses:

SIOCSIFFLAGS: Cannot allocate memory

I rebuilded modules, but it seems to me, that it uses compiled-in eth driver.

Any ideas?

Is LPAE valid on ARMv7?

Jetson has CortexA15, and according [url]Tegra - Wikipedia it supports up to 8Gb memory with LPAE.

Anyone got any idea what the state of the CSI-2 interface is on the latest kernel? I’ve been compiling my own kernel, but found out in this post that I have been missing the extra modules from nvidia. I wonder if any of those could affect said interface.

When running with u-boot you don’t need to reflash at all? When done with 1e, just do “cp arch/arm/boot/zImage /boot/zImage” and then reboot?

U-boot is the default in R21.x and up. fastboot put the kernel into an unformatted partition as raw binary data, u-boot puts the kernel in /boot where it is browsable like any other file. So it is correct that under u-boot you can simply copy zImage to /boot. Creating a raw binary data partition requires flash, a browsable file only requires copy of the file.

It’s advised during kernel compile to set CONFIG_LOCALVERSION to a slightly altered version of the existing kernel’s name suffix so as to not overwrite the original and to allow an alternate extlinux.conf boot entry and alternate module subdirectory. For example, if “uname -r” gives “3.10.40-gdacac96”, then the running kernel had its CONFIG_LOCALVERSION as “-gdacac96” when it was compiled, which could be changed during compile of a custom kernel to “-gdacac96_1”. Then the /boot/extlinux/extlinux.conf could be edited while leaving the original image there.

Modules also depend on CONFIG_LOCALVERSION, and if you set this to “-gdacac96_1” then a 3.10.40 kernel will look for modules at “/lib/modules/3.10.40-gdacac96_1” without overwriting the original “/lib/modules/3.10.40-gdacac96” (this example is the R21.4 module location). Subdirectory “/lib/modules/3.10.40-gdacac96/extra/” could be copied over to “/lib/modules/3.10.40-gdacac96_1” to make the nVidia-supplied modules available to the new kernel and avoid overwriting the original kernel’s modules.

Yep. I had that under control, but thought I should save people who didn’t the job of going through the flashing as well.

Glad I asked, cause your reply is really useful for understanding the way it works :)

Wouldn’t just copying the modules cause a problem?
As far as I recall, insmod will check the module version (hardcoded with CONFIG_LOCAVERSION of the build) against the version of the running kernel and will not load to module when there is a mismatch.