Clone all jetson partitions

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi all,

although I have two jetsons with the same APP, kernel-dtb and Image, for some reason I don’t understand I have two different booting sequences.
In one of them I have a kernel cmd line different from the other.

I’m wondering how this is possible since the partitions were cloned and kernel image was copied.

But by the way I think that by cloning all the partitions in one single image from the working Jetson could solve the problem, only I don’t know how to do that since the -k “partition” switch seems to be required from flash.sh when cloning.

Do you have any hints on that?
Thanks,
Andrea

2

It isn’t possible to clone all partitions (it used to be long ago in early TK1 days).

I can’t answer all of this, but consider that the device tree is inherited as part of the kernel command line. This is the “chosen->bootargs” node. On a running system, you can find that content via:
cat /proc/device-tree/chosen/bootargs

If you look in extlinux.conf, carefully examine the “APPEND” key/value parameter. Notice that part of this is inheriting an environment variable, “${cbootargs}”. This environment is from the device tree “chosen->bootargs”. Normally this is an exact match to the device tree, but beware that early boot stages might at times edit this before passing it on in the environment.

If extlinux.conf does not name the device tree with the FDT key/value pair, then the device tree comes from the partition. Similar for the kernel via the LINUX key/value pair.

Note that if secure boot fuses are burned, then the FDT and LINUX values in extlinux.conf are ignored, and that content can only be through the signed partition. I think probably the same is true for INITRD, not sure though.

Normally, if you need non-APP/non-rootfs content to be guaranteed, then you’d need to set that up in your flash content. I ignore that and use the extlinux.conf instead, but none of my Jetsons have security fuses burned, and all have the parameters named in extlinux.conf.

It’s also important to understand that even without security fuses burned, the non-APP partitions must still all be signed before they can be used. However, if no fuses are burned, then it is a NULL key used in signing. To illustrate, if you were to simply use dd to copy binary content into one of those partitions, then boot would fail. Depending on circumstances, it is also possible that if you were to use dd to find partition content on one Jetson (which is signed), and then use dd to put that content onto that partition of a different Jetson, that it might fail due to signatures not matching for that particular Jetson.

3

Hi linuxdev, thanks for all the answers.

I would like to go in depth with my setup so my problem can be better clarified.
Notice that this links to the topic:
Retrieve DTB from partition

Only I was using Jetpack 4.3 at the time and now I’m using 4.6.3.

This is my extlinux:

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/ImageX
      INITRD /boot/initrd
      APPEND ${cbootargs} loglevel=8

Where ImageX is my custom kernel. As you can see, there is no FDT field so the device tree is taken from partition.

These are my custom devtree bootargs:

	chosen {
		bootargs = "root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0  ";
		board-has-eeprom;
		stdout-path = "/serial@3100000";
		nvidia,tegra-joint_xpu_rail;
	};

The resulting command line in “case 1” is:

root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 nv-auto-config  video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt rootfs.slot_suffix= usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 loglevel=8

But in “case 2” I have:

root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 nv-auto-config  video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0x96088000 lut_mem=0x2008@0x96085000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 loglevel=8

So we have the "tegra_fbmem=0x800000@0x96088000 lut_mem=0x2008@0x96085000 " parameters that originated somewhere and the “fbmem” is giving me particular issues because it reserves memory in the middle of an area I would like to reserve for my application.

I noticed that this originates already in cboot (last line):

0001.408] I> Welcome to Cboot
[0001.411] I> Cboot Version: t186-cf8d3df5
[0001.414] I> CPU-BL Params @ 0x275800000
[0001.418] I>  0) Base:0x00000000 Size:0x00000000
[0001.423] I>  1) Base:0x277f00000 Size:0x00100000
[0001.427] I>  2) Base:0x277e00000 Size:0x00100000
[0001.432] I>  3) Base:0x277d00000 Size:0x00100000
[0001.436] I>  4) Base:0x277c00000 Size:0x00100000
[0001.441] I>  5) Base:0x277b00000 Size:0x00100000
[0001.445] I>  6) Base:0x277800000 Size:0x00200000
[0001.450] I>  7) Base:0x277400000 Size:0x00400000
[0001.454] I>  8) Base:0x277a00000 Size:0x00100000
[0001.459] I>  9) Base:0x277300000 Size:0x00100000
[0001.463] I> 10) Base:0x276800000 Size:0x00800000
[0001.468] I> 11) Base:0x30000000 Size:0x00040000
[0001.472] I> 12) Base:0xf0000000 Size:0x00100000
[0001.477] I> 13) Base:0x30040000 Size:0x00001000
[0001.481] I> 14) Base:0x30048000 Size:0x00001000
[0001.485] I> 15) Base:0x30049000 Size:0x00001000
[0001.490] I> 16) Base:0x3004a000 Size:0x00001000
[0001.494] I> 17) Base:0x3004b000 Size:0x00001000
[0001.499] I> 18) Base:0x3004c000 Size:0x00001000
[0001.503] I> 19) Base:0x3004d000 Size:0x00001000
[0001.508] I> 20) Base:0x3004e000 Size:0x00001000
[0001.512] I> 21) Base:0x3004f000 Size:0x00001000
[0001.516] I> 22) Base:0x00000000 Size:0x00000000
[0001.521] I> 23) Base:0xf0100000 Size:0x00010000
[0001.525] I> 24) Base:0x00000000 Size:0x00000000
[0001.530] I> 25) Base:0x00000000 Size:0x00000000
[0001.534] I> 26) Base:0x00000000 Size:0x00000000
[0001.539] I> 27) Base:0x00000000 Size:0x00000000
[0001.543] I> 28) Base:0x84400000 Size:0x00400000
[0001.547] I> 29) Base:0x30000000 Size:0x00010000
[0001.552] I> 30) Base:0x278000000 Size:0x08000000
[0001.556] I> 31) Base:0x00000000 Size:0x00000000
[0001.561] I> 32) Base:0x276000000 Size:0x00600000
[0001.565] I> 33) Base:0x80000000 Size:0x70000000
[0001.570] I> 34) Base:0xf0110000 Size:0x1856f0000
[0001.574] I> 35) Base:0x00000000 Size:0x00000000
[0001.579] I> 36) Base:0x00000000 Size:0x00000000
[0001.583] I> 37) Base:0x2772e0000 Size:0x00020000
[0001.588] I> 38) Base:0x84000000 Size:0x00400000
[0001.592] I> 39) Base:0x96000000 Size:0x02000000
[0001.597] I> 40) Base:0x85000000 Size:0x01200000
[0001.601] I> 41) Base:0x275800000 Size:0x00500000
[0001.606] I> 42) Base:0x00000000 Size:0x00000000
[0001.610] I> 43) Base:0x00000000 Size:0x00000000
[0001.614] GIC-SPI Target CPU: 4
[0001.618] Interrupts Init done
[0001.621] calling constructors
[0001.624] initializing heap
[0001.627] initializing threads
[0001.630] initializing timers
[0001.633] creating bootstrap completion thread
[0001.638] top of bootstrap2()
[0001.641] CPU: ARM Cortex A57
[0001.644] CPU: MIDR: 0x411FD073, MPIDR: 0x80000100
[0001.649] initializing platform
[0001.652] I> Bl_dtb @0x85205400
[0001.655] I> gpio framework initialized
[0001.662] I> tegrabl_gpio_driver_register: register 'nvidia,tegra186-gpio' driver
[0001.672] I> tegrabl_gpio_driver_register: register 'nvidia,tegra186-gpio-aon' driver
[0001.679] I> GPIO framework and drivers are initialized.
[0001.685] I> Boot-device: eMMC
[0001.692] I> sdmmc bdev is already initialized
[0001.722] I> Found 19 partitions in SDMMC_BOOT (instance 3)
[0001.740] I> Found 33 partitions in SDMMC_USER (instance 3)
[0001.746] W> opt-in fuse is not set, skip fuse_burning
[0001.751] I> Reserved memory at 0xfbe00000 for U-Boot relocation
[0001.756] W> No valid slot number is found in scratch register
[0001.762] W> Return default slot: _a
[0001.771] I> A/B: bin_type (21) slot 0
[0001.775] I> Loading kernel-dtb from partition
[0001.779] I> Loading partition kernel-dtb at 0x80000000 from device(0x1)
[0001.797] I> Kernel_dtb @0x80000000
[0001.800] I> tegrabl_tca9539_init: i2c bus: 0, slave addr: 0xee
[0001.811] I> tegrabl_gpio_driver_register: register 'tca9539_gpio_driver' driver
[0001.818] I> tegrabl_tca9539_init: i2c bus: 0, slave addr: 0xe8
[0001.827] I> tegrabl_gpio_driver_register: register 'tca9539_gpio_driver' driver
[0001.837] I> fixed regulator driver initialized
[0001.870] I> register 'maxim' power off handle
[0001.876] I> virtual i2c enabled
[0001.879] I> registered 'maxim,max77620' pmic
[0001.883] I> tegrabl_gpio_driver_register: register 'max77620-gpio' driver
[0001.897] E> failed to read label property for node 319808: 13
[0001.906] E> failed to read reg property for node 319904: 13
[0001.914] E> failed to read reg property for node 319956: 13
[0001.922] E> failed to read label property for node 320040: 13
[0001.930] E> failed to read label property for node 320108: 13
[0001.939] E> failed to read reg property for node 320176: 13
[0001.947] E> failed to read reg property for node 320248: 13
[0001.957] I> Find /i2c@c250000's alias i2c7
[0001.961] I> Reading eeprom i2c=7 address=0x50
[0001.991] I> Device at /i2c@c250000:0x50
[0001.994] I> Reading eeprom i2c=7 address=0x57
[0002.023] I> Device at /i2c@c250000:0x57
[0002.027] I> Find /i2c@c240000's alias i2c1
[0002.031] I> Reading eeprom i2c=1 address=0x51
[0002.037] E> I2C: slave not found in slaves.
[0002.041] E> I2C: Could not write 0 bytes to slave: 0x00a2 with repeat start true.
[0002.048] E> I2C_DEV: Failed to send register address 0x00000000.
[0002.054] E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xa2 at 0x00000000 via instance 1.
[0002.064] E> eeprom: Retry to read I2C slave device.
[0002.069] E> I2C: slave not found in slaves.
[0002.073] E> I2C: Could not write 0 bytes to slave: 0x00a2 with repeat start true.
[0002.080] E> I2C_DEV: Failed to send register address 0x00000000.
[0002.086] E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xa2 at 0x00000000 via instance 1.
[0002.096] E> eeprom: Failed to read I2C slave device
[0002.101] I> Eeprom read failed 0x3526070d
[0002.105] I> Find /i2c@3160000's alias i2c0
[0002.109] I> Reading eeprom i2c=0 address=0x50
[0002.113] E> I2C: slave not found in slaves.
[0002.118] E> I2C: Could not write 0 bytes to slave: 0x00a0 with repeat start true.
[0002.125] E> I2C_DEV: Failed to send register address 0x00000000.
[0002.131] E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xa0 at 0x00000000 via instance 0.
[0002.141] E> eeprom: Failed to read I2C slave device
[0002.145] I> Eeprom read failed 0x3526070d
[0002.150] I> Find /i2c@3180000's alias i2c2
[0002.154] I> Reading eeprom i2c=2 address=0x54
[0002.158] I> Enabling gpio chip_id = 2, gpio pin = 9
[0002.165] E> I2C: slave not found in slaves.
[0002.169] E> I2C: Could not write 0 bytes to slave: 0x00a8 with repeat start true.
[0002.177] E> I2C_DEV: Failed to send register address 0x00000000.
[0002.183] E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xa8 at 0x00000000 via instance 2.
[0002.192] E> eeprom: Failed to read I2C slave device
[0002.197] I> Disabling gpio chip_id = 2, gpio pin = 9
[0002.202] I> Eeprom read failed 0x00000000
[0002.206] I> Reading eeprom i2c=2 address=0x57
[0002.210] I> Enabling gpio chip_id = 2, gpio pin = 9
[0002.216] E> I2C: slave not found in slaves.
[0002.220] E> I2C: Could not write 0 bytes to slave: 0x00ae with repeat start true.
[0002.228] E> I2C_DEV: Failed to send register address 0x00000000.
[0002.233] E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xae at 0x00000000 via instance 2.
[0002.243] E> eeprom: Failed to read I2C slave device
[0002.248] I> Disabling gpio chip_id = 2, gpio pin = 9
[0002.253] I> Eeprom read failed 0x00000000
[0002.257] I> create_pm_ids: id: 3310-1000-D00-K, len: 15
[0002.262] I> config: mem-type:00,power-config:00,misc-config:00,modem-config:00,touch-config:00,display-config:00,, len: 93
[0002.273] I> create_pm_ids: id: 2597-0000-900-E, len: 15
[0002.278] I> config: mem-type:00,power-config:00,misc-config:00,modem-config:00,touch-config:00,display-config:00,, len: 93
[0002.318] I> hdmi cable connected
[0002.327] I> setting 'vdd-pex-1v00' regulator to 1000000 micro volts
[0002.339] I> setting 'vdd-1v8' regulator to 1800000 micro volts
[0002.344] I> retrieved tmds range from prod_list_hdmi_soc
[0002.352] E> cannot find any other nvdisp nodes
[0002.363] E> I2C: Timeout while polling for bus clear. Last value 0x00000000.
[0002.370] E> I2C: Failed to clear bus for instance 5.
[0002.375] E> I2C: Failed to clear bus for instance 5.
[0002.380] E> I2C_DEV: Failed to initialize instance 5.
[0002.385] E> read_edid, invalid i2c handle
[0002.393] I> hdmi_enable, starting HDMI initialisation
[0002.401] I> hdmi_enable, HDMI initialisation complete
[0002.414] initializing target
[0002.417] calling apps_init()
[0002.420] starting app kernel_boot_app
[0002.442] I> found decompressor handler: lz4-legacy
[0002.447] I> decompressing BMP blob ...
[0002.519] I> Kernel type = Normal
[0002.522] I> ########## Fixed storage boot ##########
[0002.527] I> Loading kernel-bootctrl from partition
[0002.531] I> Loading partition kernel-bootctrl at 0xa8000000 from device(0x1)
[0002.546] W> tegrabl_get_kernel_bootctrl: magic number(0x00000000) is invalid
[0002.553] W> tegrabl_get_kernel_bootctrl: use default dummy boot control data
[0002.560] W> No valid slot number is found in scratch register
[0002.565] W> Return default slot: _a
[0002.569] I> A/B: bin_type (24) slot 0
[0002.584] I> Boot image size read from image header: 990e5
[0002.590] I> Boot image load address: 0x80400000
[0002.594] I> Loading kernel from partition
[0002.598] I> Loading partition kernel at 0x80400000 from device(0x1)
[0003.540] I> Validate kernel ...
[0003.543] I> T18x: Authenticate kernel (bin_type 24), max size 0x4000000
[0003.551] I> Decrypt the buffer ... [0003.554] W> tegrabl_decrypt_block: fuse (0x0) is not burnt to do encryption (0x4); skip decryption.
[0003.563] I> done
[0003.565] I> Checking boot.img header magic ... [0003.569] I> [OK]
[0003.571] I> kernel-dtb is already loaded
[0003.575] I> Validate kernel-dtb ...
[0003.578] I> T18x: Authenticate kernel-dtb (bin_type 21), max size 0x100000
[0003.586] I> Decrypt the buffer ... [0003.589] W> tegrabl_decrypt_block: fuse (0x0) is not burnt to do encryption (0x4); skip decryption.
[0003.598] I> done
[0003.600] I> Kernel hdr @0x80400000
[0003.603] I> Kernel dtb @0x80000000
[0003.606] I> decompressor handler not found
[0003.610] I> Copying kernel image (626917 bytes) from 0x80400800 to 0x80600000 ... [0003.618] I> Done
[0003.620] I> Move ramdisk (len: 0) from 0x8049a000 to 0x947d0000
[0003.627] I> Updated bpmp info to DTB
[0003.633] I> Ramdisk: Base: 0x947d0000; Size: 0x0
[0003.638] I> Updated initrd info to DTB
[0003.641] W> WARN: Fail to override "console=none" in commandline
[0003.647] I> Active rootfs suffix: 
[0003.651] W> tegrabl_linuxboot_add_disp_param, du 1 failed to get display params
[0003.658] W> tegrabl_linuxboot_add_disp_param, du 1 failed to get display params
[0003.665] I> disabled_core_mask: 0xffffff0c
[0003.669] W> No valid slot number is found in scratch register
[0003.675] W> Return default slot: _a
[0003.678] I> Active slot suffix: 
[0003.681] I> add_boot_slot_suffix: slot_suffix = 
[0003.686] I> Linux Cmdline: root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0
 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 nv-auto-config
  video=tegrafb earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0x96088000 l
ut_mem=0x2008@0x96085000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 no_console_suspend boot.slot_suffix= boot.ratchetvalues=0
.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1

I could of course overwrite the bootargs with your method but this would be rather a temporary solution, while I would like to understand what is causing these arguments to pop up.

Thanks a lot for your attention.
Regards,
Andrea

4

Before going into more detail, for ImageX, what was your setting for “CONFIG_LOCALVERSION”? If this is not correct, then modules won’t be found. Also, how did you install that kernel? Was it from file copy (I’m guessing it is)? Can we verify that secure boot is not enabled?

Was any sup-component of flash performed other than a complete flash?

5

We built the custom kernel using “nvbuild.sh”, which in turns define the variable

LOCALVERSION="-tegra"

but that seems to be appended to “${CONFIG_LOCALVERSION}” later in the build.
I do not know however how to retrieve that value (do you have hints?), but I did not change anything about it.

Yes we installed the kernel through file copy.

I guess secure-boot is not enabled because we are sure the kernel is being loaded correctly (it prints our modified printk).

For flashing, I performed a complete flash from Nvidia SDK Manager to update to Jetpack 4.6.3 in both my devices.
Then, I flashed the modified device-trees in both cases, and while still achieving the same results (one presents the “fbmem” line and one doesn’t), I cloned the APP and kernel-dtb partition from the one that does not have those lines to the one that has them.
But that didn’t solve anything.

Thanks for your support.
Regards,
Andrea

6

As long as the script defines “LOCALVERSION=-tegra” it is ok.

Can we verify which of “case 1” or “case 2” boots, and which case fails?

One thing to note is that the boot stage environment itself is not dependent upon the root filesystem image. In the log which stops, it stops upon loading of the Linux kernel, so regardless of differences in boot stages, it still loads the kernel. However, this does not mean that the environment inherited by the Linux kernel is the same; this can change whether or not Linux itself will function correctly.

I’m just making notes as I go, and what follows is a comparison of kernel arguments. I don’t know yet if it matters or not (most arguments can be used multiple times, and only the last argument matters; serial console and regular console arguments both matter, but are unrelated to this). I separated the arguments into separate lines of two different files, sorted them, and then ran diff. This just verifies what you already noted.

Notes on case 1 compared to case 2:

  • Case 2 has the following, but is missing in case 1:
    lut_mem=0x2008@0x96085000
    (I don’t know if this would harm anything or not)

  • Case 2 has the following, but is missing in case 1:
    tegra_fbmem=0x800000@0x96088000
    (I don’t know if this would harm anything or not)

You only showed one “chosen->bootargs” case. Is this the same on both Jetsons? I think you were saying that both Jetsons had the same device tree, but I don’t see the “case 2” extra arguments in that device tree. This implies that the bootargs are from extlinux.conf’s “APPEND”. You gave only one extlinux.conf; are both really the same? If they are, then I am confused that the extlinux.conf is also the same. I’m wondering if perhaps the device tree you expect isn’t really the one used, or if perhaps the extlinux.conf has other arguments; if this is not the case, then it is possible for boot stages to edit device tree arguments prior to passing on to the Linux environment.

Do both Jetsons boot correctly if you don’t have those two extra arguments? How are those arguments being added to case 2? I don’t know if you are saying you don’t know where those are introduced, but it also sounds like you might have experimented with address reservation (either in the kernel or in arguments; it is important to know if the failed case kernel had any changes which might be related to reserved memory); anything you can tell about kernel changes related to the memory addresses might matter.

Do note that if boot stages edit a device tree prior to passing on, that this could be from environment scripting, or it could be from actual code. I don’t know which.

7

First, you guessed right: we are dealing with reserved memory (we would like to reserve ~1GB of space with cma) and the fact that fbmem is allocated somewhere in the middle of free space causes our reservation to fail.

I showed just one extlinux.conf and chosen->bootargs
because I am flashing the same dtb, and same APP partition in both cases.

I don’t know if that wasn’t clear but the serial output listed above was stopped at Linux Cmdline because I thought that was the interesting part, once inherited from there the parameters remain the same on the following boot process.

We did a little research and we found out that the fbmem allocation appears in the cboot code under cboot-186-l4t-32.7.3/cboot_src_t18x/bootloader/partner/common/lib/graphics/tegrabl_surface.c :

tegrabl_error_t tegrabl_surface_setup(struct tegrabl_surface *surf){
[cut..]
	/* This buffer is not freed */
	base = (uintptr_t)tegrabl_malloc(surf->size + surf->alignment - 1);
	if ((void *)base == NULL) {
		pr_debug("allocation for framebuffer failed\n");
		err = TEGRABL_ERR_NO_MEMORY;
		goto fail;
	}
[cut..]
}

the base address is written in the DTB in fb0_carveout->reg.
This function is activated if the preprocessor variable CONFIG_ENABLE_DISPLAY is true.

We don’t know about “case 1” but for sure in “case 2” this function gets called.

The output of the kernel in “case 2” is:

[    0.000000] OF: fdt:** node fb0_carveout len 32 t_len 16 nomap 1
[    0.000000] OF: fdt:** base ffffff800a153e50 size 0x800000 first 1
[    0.000000] OF: fdt:Reserved memory: reserved region for node 'fb0_carveout': base 0x0000000096088000, size 8 MiB
[    0.000000] OF: fdt:** base ffffff800a153e50 size 0x2008 first 0
[    0.000000] OF: fdt:Reserved memory: reserved region for node 'fb0_carveout': base 0x0000000096085000, size 0 MiB

while in “case 1” those lines are not present at all.

In the end I really can’t explain why two same devices that underwent the same flashing procedure with an official Jetpack show different results.
Even after flashing custom kernel and dtb, if those are the same, I should get the same result.

8

A little update from the end of the day.

We tried to overwrite the partitions:

  • bootloader-dtb
  • cpu-bootloader

with the ones cloned from the working one.
The result keeps being the same.

we also tried to give to chosen->bootargs in the DTB the fbmem address we would like to have, and we filled fb0_carveout size and address with our values.
The result keeps being the same.

I am attaching the cboot/uboot logging until the kernel starts in the two cases.

jetson_wrong.txt (23.6 KB)
jetson_good.txt (22.2 KB)

the extlinux.conf is, in both cases:

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/ImageX
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet

It seems that the two cboot are loading different FDts in the two cases, since one fails to set some display parameters (tegrabl_display_get_pdata, failed to parse dtb settings) and that one
-doesn’t add the tegra_fbmem to cmdline
-doesn’t modify the FDT passed to kernel with fb0_carveout size and address.

Our aim is just to make the cboot read the same FDTs.

Thanks a lot for your support and patience.
Best regards,
Andrea

9

I do not have any ability to answer questions specific to memory regions. Sometimes hardware which is integrated into the system must use a particular physical address, and I cannot answer whether the “interfering” region can actually be moved. This is one NVIDIA will have to answer.

Would anyone from NVIDIA be able to comment on JetPack 4.x, making these modifications succeed?

  • lut_mem=0x2008@0x96085000
  • tegra_fbmem=0x800000@0x96088000

I personally do not know anything about what is previously in those address regions, nor whether they can be moved.

FYI, this is not really a cloning question.

10

Right, thanks for your answers.

I think this is still a cloning question because I want to have 2 identical systems and cannot manage to do that…

If anybody from Nvidia could answer this it would be great.

Is there a list of partitions that needs to be cloned to have 2 identical systems?
Do I really need all 30 partitions?

Regards,
Andrea

11

You might be interested in this:
https://forums.developer.nvidia.com/t/custom-initrd-for-nx/232508/15

Also, understand that all partitions (other than rootfs) are signed. The default is to use a NULL key. Possibly a clone would fail if the signature is not handled correctly, but basically I don’t think it is practical to clone them. There might be a way to trim the signature off, and then replace the file in the flash software such that that content is used during the next flash. However, I have doubts that this would help, e.g., there is also EEPROM memory on dev kits which might contain part of what you want. Really I think someone must be able to find out first what those addresses correspond to.

1 Like
12

Hi linuxdev,

Thanks for all your answers.

We decided in the end to modify cboot code and flash our own version which doesn’t allocate that memory space for the Nvidia Display.

I would still like to receive a feedback from anyone from Nvidia.

Kind regards,
Andrea

14

Hi andrea.capirchio,

Are you using JP4.x for AGX Xavier?

The cloning always refers to “APP” partition, which is also known as system.img.
You could just refer to the following instruction to clone it.
NVIDIA Jetson Linux Developer Guide : Flashing and Booting the Target Device | NVIDIA Docs
-r parameter is used to specify that you want to use existed Linux_for_Tegra/bootloader/system.img, -k is used to specify the APP partition.

15

Hi KevinFFF,

no actually I am using Jetpack 4.6.3 for Jetson Tx2.

All right, I understand that “cloning” only refers to APP partition, but then how can I make an exact copy of all the partitions from one Jetson to another?

Regards,
Andrea

16

I’ve helped you to move the topic to Jetson TX2.

You could refer to To back up and restore a Jetson device in NVIDIA Jetson Linux Developer Guide : Flashing and Booting the Target Device | NVIDIA Docs.

Backing up a Jetson device differs from cloning one (see To clone a Jetson device and flash) because a backup image includes every partition in the device’s internal eMMC and QSPI memory, while a clone contains only the APP file system partition.

18

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.