Custom kernel without uboot (Solved)

For TX1 and TX2 up to L4T R28.x, custom kernel Image can be put in any location and pointed by extlinux.conf.

For Xavier, uboot is not used, does this means new kernel Image must be flashed to a particular partition (32)? Is kernel Image encrypted? Can “dd” be used to flash kernel Image to kernel partition from Xavier?

Is kernel dtb encrypted?

I have rebuilt kernel on Xavier and would like to know if I can flash it using “dd”.

Thanks in advance.

1 Like

Hi yahoo2016,

Below is a relevant topic. You can also take a look at it.

https://devtalk.nvidia.com/default/topic/1039294/jetson-agx-xavier/custom-kernel-selection-on-xavier/

Hi vickyy,
I have been following that link, but my questions are different.
While it may take a while for Nvidia to support kernel selection, we need to test custom kernels in order to use Xavier for our cameras now.
My questions are if kernel Images and DTBs can be flashed using “dd” from Xavier instead from Ubuntu host through micro USB.
Thanks

I tried using “sudo dd if=Image of=/dev/mmcblk0p32” and bricked my Xavier.

I tried using USB3 cable with Xavier in recovery mode and “sudo ./flash.sh -K Image jetson-xavier mmcblk0p1”, but rootfs was completely re-flashed.

This makes custom kernel development impossible.

Hi yahoo2016,

The Image (kernel partition) on Xavier is on /dev/mmcblk0p29. /dev/mmcblk0p32 is kernel-dtb and hence it might have gotten bricked.

I used gparted to check partitions, I thought it was 32, I do not have access to my Xavier now.
Have you tried dd to partition 29?
Thanks

On my Xavier the primary kernel is in partition 29. I used gdisk -l to list the partitions. The unencrypted primary dtb is in partition 31. I built a kernel and installed it using flash.sh but haven’t yet attempted to dd it.

I was able to update the DTB using dd. I had trouble flashing the DTB using flash.sh. It seems like flash.sh is ignoring the -d option and using the default DTB file.

root@jetson-0422818069360:~# gdisk -l /dev/mmcblk0
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/mmcblk0: 61079552 sectors, 29.1 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 36 entries
Main partition table begins at sector 2 and ends at sector 10
First usable sector is 40, last usable sector is 61079519
Partitions will be aligned on 8-sector boundaries
Total free space is 1 sectors (512 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40        58720295   28.0 GiB    0700  APP
   2        58720296        58721295   500.0 KiB   0700  mts-mce
   3        58721296        58722295   500.0 KiB   0700  mts-mce_b
   4        58722296        58730487   4.0 MiB     0700  mts-proper
   5        58730488        58738679   4.0 MiB     0700  mts-proper_b
   6        58738680        58739703   512.0 KiB   0700  cpu-bootloader
   7        58739704        58740727   512.0 KiB   0700  cpu-bootloader_b
   8        58740728        58741495   384.0 KiB   0700  bootloader-dtb
   9        58741496        58742263   384.0 KiB   0700  bootloader-dtb_b
  10        58742264        58746359   2.0 MiB     0700  secure-os
  11        58746360        58750455   2.0 MiB     0700  secure-os_b
  12        58750456        58750711   128.0 KiB   0700  eks
  13        58750712        58752759   1024.0 KiB  0700  bpmp-fw
  14        58752760        58754807   1024.0 KiB  0700  bpmp-fw_b
  15        58754808        58756855   1024.0 KiB  0700  bpmp-fw-dtb
  16        58756856        58758903   1024.0 KiB  0700  bpmp-fw-dtb_b
  17        58758904        58759415   256.0 KiB   0700  xusb-fw
  18        58759416        58759927   256.0 KiB   0700  xusb-fw_b
  19        58759928        58760951   512.0 KiB   0700  rce-fw
  20        58760952        58761975   512.0 KiB   0700  rce-fw_b
  21        58761976        58770167   4.0 MiB     0700  adsp-fw
  22        58770168        58778359   4.0 MiB     0700  adsp-fw_b
  23        58778360        58779383   512.0 KiB   0700  sce-fw
  24        58779384        58780407   512.0 KiB   0700  sce-fw_b
  25        58780408        58792695   6.0 MiB     0700  sc7
  26        58792696        58804983   6.0 MiB     0700  sc7_b
  27        58804984        59067127   128.0 MiB   0700  BMP
  28        59067128        59329271   128.0 MiB   0700  BMP_b
  29        59329272        59460343   64.0 MiB    0700  kernel
  30        59460344        59591415   64.0 MiB    0700  kernel_b
  31        59591416        59592439   512.0 KiB   0700  kernel-dtb
  32        59592440        59593463   512.0 KiB   0700  kernel-dtb_b
  33        59593464        59595511   1024.0 KiB  0700  CPUBL-CFG
  34        59595512        59611895   8.0 MiB     0700  RP1
  35        59611896        59628279   8.0 MiB     0700  RP2
  36        59628280        61079518   708.6 MiB   0700  UDA

growe,
That’s very helpful. My preference is building kernel/dtb on Xavier and using “dd” to update kernel/dtb.
I’ll try when I get access of my Xavier later today.
Thanks

Hi yahoo2016

If you build dtb then make sure you are using the “signed” version of the dtb to dd it to /dev/mmcblk0p31. Or use flash.sh to flash the kernel-dtb partition (-k kernel-dtb). Just dd’ing the built dtb won’t work.

Anish is correct. Just dding the DTB to partition 31 doesn’t work.

I’ve also encountered a problem with flash.sh in JetPack 4.0 where it is ignoring the DTB specified with -d. I found that I can flash my DTB if I copy it to Linux_for_Tegra/kernel/dtbs prior to attempting to flash.

On Jetson Tx2 I used to dd the encrypted DTB but I don’t know where to find that yet for Xavier.

anish, growe

Thanks for clarifying Xavier dtb, i.e., R31 is similar to R28.2.x.

Some flashing kernel/dtb issues on host side could be resolved by modifying flash.sh/falsh.py and other dependencies.

Unfortunately the signing code is binary without source code and only runs on X86 machines, in order to use “dd” on Xavier, a X86 host must be used to generate signed dtb and copied to Xavier.

This has discouraged us to update to R28.2.x and switch to TX2i.

Just a thought – could you use qemu-x86 on Xavier to sign the DTB? It might be more trouble than it is worth…

qemu-x86 might be useful to run some other X86 code on TX2/Xavier as well. It’s worth is to try if “flash.sh” and it’s dependencies can run under qemu-x86. It’s an option for systems without access to the recover USB port and recover button.

I was able to use “dd” to flash kernel Image to mmcblk0p29 and dtb to mmcblk0p31.

The dtb is unsigned under “bootloader”:
Linux_for_Tegra/bootloader/tegra194-p2888-0001-p2822-0000.dtb

The kernel Image is (signed?) under “bootloader”:
Linux_for_Tegra/bootloader/boot.img

I have decompiled, changed path and data/time, recompiled “tegra194-p2888-0001-p2822-0000.dtb” under bootloader, flashed it to mmcblk0p31 and verified the changes I made.

It appears flash.sh only changed “bootargs” in original dtb in “kernel/dtb”:

in original dtb:
bootargs = “console=ttyTCU0,115200”;

in new dtb:
bootargs = "root=/dev/mmcblk0p1 rw rootwait console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 OS=l4t ";

I found the “boot.img” is not “signed” but with initrd and cmdline appended:

Making Boot image... 
./mkbootimg --kernel /home/ubuntu/jetpack4/Xavier/Linux_for_Tegra/kernel/Image --ramdisk initrd --board mmcblk0p1 --output boot.img --cmdline root=/dev/mmcblk0p1 rw rootwait console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 > /dev/null 2>&1;done.

It’s Android booting style similar to Nvidia Shield Android TV rather than uboot.

for future reference use the -r flag in order to NOT flash all the rootfs