Kernel command line for Jetson-TK1 with grinch

Autonomous Machines Jetson & Embedded Systems Jetson TK1
1

I am using grinch 19.3.6 with fastboot. I need to modify the kernel command line, and found something promising in jetson-tk1.conf:

CMDLINE_ADD="fbcon=map:1"

I added my additional option there, but I am not sure what needs to be regenerated and flashed here. Sure, I could reflash everything, but that takes 30 minutes and is surely not necessary.

  1. Is this the correct way to add to the kernel command line?
  2. What do I need to run to generate the files that need uploading?
  3. How do I upload only what is necessary for the change?
2

Here is what I have tried:

  1. Create a new boot.img:
    sudo ./mkbootimg --kernel …/kernel/zImage --ramdisk initrd --board jetson-tk1 --output boot_w_usb_memory_mb.img --cmdline “fbcon=map:1 usbcore.usbfs_memory_mb=1000”

I could verify with grep what usbcore.usbfs_memory_mb was in the new boot_w_usb_memory_mb.img.
Then I couldn’t understand how to flash only this, even after reading through flash.sh

  1. Add the parameter to jetson-tk1.conf and run the regular ./apply_binaries.sh and ./flash.sh.
    Check on if it worked on target with:
    $ cat /sys/modules/usb/parameters/usbfs_memory_mb
    if the value no longer is the default or the one I set in the conf file, and bingo. The new value is in there.

Now I need to reinstall quite much, since I reflashed the whole thing.
That’s why I’d appreciate to know how I could have flashed only boot.img.

3

I haven’t flashed with fastboot, I went to u-boot (where you can simply edit /boot/extlinux.conf to change kernel command line). However, part of the answer if sticking to fastboot is this…

  1. Fastboot is in bootloader/fastboot.bin for the default. So flash.sh option "-L bootloader/fastboot.bin", provided fastboot.bin has your change.
  2. Kernel is in partition 6, so flash.sh "-k 6" option.
  3. The flash.sh "-C" option lets you hard wire a kernel command line, with these options to command line overriding others.
  4. Should you decide to switch to u-boot, don't forget to copy a zImage kernel to /boot of system.img or the sample rootfs, and edit /boot/extlinux.conf command line (fastboot uses partition -k 6, u-boot uses partition /boot).

What I’d suggest for your situation though is this…the boot script generates bootloader/system.img when flashing all of Jetson. If you have an existing system.img, rsync your Jetson to this mounted on loopback, then flash all while using “-r” option to flash.sh to re-use an existing system.img that was updated to copy your current Jetson. Having a clone of your live Jetson on a system.img means complete freedom to wipe Jetson and restore it at any time…just keep an updated system.img in a safe place. A large part of the time to flash is from generating system.img, so a backup removes that time once created.

If you need to create a system.img and do not already have one, I wrote a modified flash.sh which does nothing but create system.img (renamed system2.img). See thread:
https://devtalk.nvidia.com/default/topic/769691/embedded-systems/working-with-img-files-with-the-jetson
generateSystemImage.sh:
http://filebin.ca/1Y5aDfGAIoZc
…this script takes the same arguments as flash.sh…it was cut from flash.sh, and keeps parts used to generate system.img but removed parts which actually flash.

system.img can be loopback mounted via “mount -o loop -t ext4 system.img /mnt/somewhere”.

rsync preserving permissions for /home would be something like this from Jetson:
sudo rsync -acvrz --delete-before /boot root@host:/mnt/somewhere

You would need to rsync all the “real” file directories, and “/dev” would not hurt although parts are auto generated as needed. So make sure nothing else is mounted to the Jetson, and rsync these:
/bin, /boot, /dev/, /etc, /home, /lib, /media, /mnt, /opt, /root, /sbin, /srv, /usr, /var

I mentioned some directories which probably have nothing in them because it doesn’t hurt to sync directory structure, and I don’t know what you have in them. You’ll need to rsync to a host with root permissions.

4

Yes, I have the rsync and loopback mounting done, thanks to your help in another thread. However, what takes most time for me while flashing is “sending file: system.img”.
Now that I have a working modified kernel command line I need to either rsync back my system.img to the jetson, or apply the changes again manually.

Applying the changes manually once more has its value this early in development (still learning a lot, repetition is good). The correct way to do it though is not to do it again nor to restore from a backup, but to only flash what needs flashing: the kernel command line. Possibly the boot.img. That is what I am trying to do.

The -C option is a possibility, if flash.sh does not try then to upload system.img. Also I want to add to the command line, without removing anything else.

5

You can always keep a second system.img which is a backup for reference, and use a default system.img for practice. FYI, if you have a system.img which is an rsync backup from Jetson, using it during flash via -r option means you don’t have to rsync back to Jetson…your initial flash will be an exact copy of your prior Jetson (except for boot loader and -k 6 kernel partition).

It does take a lot of time to download the system.img to Jetson, but cutting out create time for system.img is a huge savings as well. Unfortunately, the eMMC is not going to accept full flash quickly.

If you believe you will need to experiment with kernel command line, u-boot is still a better choice…no flashes required once u-boot is installed; just copy the extlinux.conf entry for an existing kernel to a new label and edit command line and reboot…select the kernel/options you want at the boot prompt. I’ve been doing this with kernel debug options.

6

So, no way to flash boot.img without flashing the entire file system and kernel?
Interesting information otherwise.

7

Likely you can flash just a kernel, but I don’t know of a “safe” way to find out (thus the extra info on system.img/rsync backup). Seems like there are several default arguments, so just leaving an argument out of the flash.sh script won’t necessarily stop some part of it from executing. If you back up via rsync to a loopback mounted system.img though, and keep that image safe, it won’t hurt to fail.

If I were to try just adding a kernel and fastboot, I’d configure and build a new fastboot.bin (or take a chance on the -C option for command line), place it in the bootloader directory, and similar for kernel zImage to kernel directory, then run:
sudo flash.sh -k 6 jetson-tk1 mmcblk0p1

In the command listed above, the boot loader default is:
-L bootloader/fastboot.bin

You could use an alternate fastboot name, but I think the scripts pick up on different names and change what happens. Similar that kernel zImage is able to be renamed, but this might also trigger some script changes.

It just seems like one full flash changing to u-boot saves a lot of unknowns, especially since from that point on (using u-boot) you can upgrade/change the kernels and/or kernel command lines with a simple editor and not even require a host flash app.

8

Add that I have a little experience with u-boot, I think you just convinced me to switch.