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.
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…
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.
-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:
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.
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.
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.
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.
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.