Jetson TX2, flash only kernel Image

Hi,
I’m trying to get the latest stable kernel v4.16.14 running on Jetson TX2. I can successfully build an Image, dtb and rootfs and flash them using Linux_for_Tegra/flash.sh but the sdhci controller fails and I’m stuck at:

...snip...
[    1.820030] sdhci-tegra 3460000.sdhci: clk err
[    1.825034] sdhci-tegra 3440000.sdhci: clk err
...snip...
[    1.843473] Warning: unable to open an initial console.
[    1.848988] Waiting for root device /dev/mmcblk0p1...

I’d like to debug this by making changes to the kernel and flashing a new Image to /boot/Image, so that u-boot loads my new kernel. However, I can only do this by re-running flash.sh which takes about 5 minutes to write the whole system.img + rootfs.

I know I can flash only the kernel partition or /boot/dtb using:

flash.sh -k kernel
flash.sh -k kernel-dtb

But the kernel partition is u-boot and Image is not in /boot/dtb. How can install /boot/Image without rewriting a whole rootfs or access to userland? Is it possible to mount the internal mmc in recovery mode?

From the L4T docs, under “U-boot Customisation > Changing the eMMC partition layout > APP partition”:

The flash.sh script treats the root filesystem-on-IP-network configuration as a special case. It flashes these kernel files in the <APP partition>:/boot directory.

How can I do this without flashing the rest of rootfs.

The kernel never requires flash…it is a simple file copy. The device tree does require flash. Keep in mind that U-Boot’s binary is also a “kernel”…I am not positive, but the “kernel” GPT partition label seems to be U-Boot, not Linux. Your best bet (by far) is to add alternate boot entries in “/boot/extlinux/extlinux.conf”, and then use a serial console at boot time to pick the kernel you want to test (simply copy the kernel to “/boot” with some alternate name, e.g., “Image-test”…if “uname -r” differs add modules to “/lib/modules/$(uname -r)/”).

If flashing the DTB you may be interested in this:
[url]https://devtalk.nvidia.com/default/topic/1036286/jetson-tx1/flashing-just-dtb-on-28-2-and-tx1/post/5264465/#5264465[/url]

Thanks linuxdev, I went with the alternate boot entries using a new extlinux.conf. That way, if my kernel fails, I can boot into a known-working kernel and then copy across a new Image-dev.

$ cat Linux_for_Tegra/rootfs/boot/extlinux/extlinux.conf
TIMEOUT 30
DEFAULT dev

MENU TITLE p2771-0000 eMMC boot options

LABEL dev
      MENU LABEL dev kernel
      LINUX /boot/Image-dev
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

LABEL linux-tegra
      MENU LABEL linux-tegra kernel
      LINUX /boot/Image
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

You’re right about the kernel partition being u-boot, I think the partition name is legacy and now the standard method is to boot u-boot all the time - which has more flexibility on where the actual kernel comes from.

I’ve flashed a dtb using:

sudo ./flash.sh -r -k kernel-dtb jetson-tx1 mmcblk0p1

This seems to sign the DTB (different md5sum) and write it to /boot/dtb, although I’m unsure where this actually lives.

It doesn’t appear when I run mount

$ mount
/dev/mmcblk0p1 on / type ext4 (rw,relatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=7976012k,nr_inodes=1994003,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/debug type cgroup (rw,nosuid,nodev,noexec,relatime,debug)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
tmpfs on /run/user/1001 type tmpfs (rw,nosuid,nodev,relatime,size=804280k,mode=700,uid=1001,gid=1001)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfsd-fuse on /run/user/1001/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)

Is there some other storage where bootloader bins, dtb, and kernel (u-boot) are stored?

I’m trying override the DT with the FDT arg in extlinux.conf, I’ve created a new thread for that here https://devtalk.nvidia.com/default/topic/1036443/jetson-tx2/u-boot-error-when-loading-custom-device-tree-from-boot-with-extlinux-conf/

Device trees are read into memory prior to the kernel loading…the bootloader does this. The bootloader will actually configure a subset of this, and although the Linux kernel may use device tree after boot it does not do the loading. The tree itself is never mounted, it isn’t a readable file system.

There is something close to this though. Explore “/proc/device-tree/”. This is not a separate mount, this is a live pseudo file system in RAM and is output live by the kernel. You can get the current running systems dts via:

dtc -I fs -O dts -o extracted.dts /proc/device-tree

The FDT argument is no longer used. If this does work, then it usually won’t work as expected. Comment added at the other URL, but basically you need to use the flash tool due to a combination of it being signed and being on a partition. This change seems to be because cboot and some earlier boot stages may need slightly different device trees and can merge some of their content into the final device tree prior to Linux taking over.

See:
https://devtalk.nvidia.com/default/topic/1036286/jetson-tx1/flashing-just-dtb-on-28-2-and-tx1/post/5264465/#5264465