Issue while flashing Xavier NX with initrd and linux kernel compiled, L4T 34.1.1

We use a Xavier NX 8GB production module with a custom board and want to flash to ssd and to boot directly from the ssd. To make things easier in this request I only use the defaults for the dev kit not special dtb, cfg etc. for our custom board. We’ve tested this with L4T 34.1.1.

When we use initrd_flash with following command and WITHOUT compiling the kernel (all to default for DevKit) everthing works as expected.

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_external.xml --showlogs jetson-xavier-nx-devkit-emmc nvme0n1p1

But now to the problem: When we compile the linux kernel (even with all in default) and copy all files as described in developer guide the same procedure fails.

This is the error we get:

With serial console (uart) from Xavier NX we get this:

[0062.898] I> Reset to recovery mode
ÿâ
[0280.468] W> RATCHET: MB1 binary ratchet value 4 is larger than ratchet level 2 from HW fuses.
[0280.476] I> MB1 (prd-version: 2.2.0.0-t194-41334769-3540ffaa)
[0280.482] I> Boot-mode: RCM
[0280.484] I> Platform: Silicon
[0280.487] I> Chip revision : A02P
[0280.490] I> Bootrom patch version : 15 (correctly patched)
[0280.496] I> ATE fuse revision : 0x200
[0280.499] I> Ram repair fuse : 0x0
[0280.502] I> Ram Code : 0x0
[0280.505] I> rst_source: 0xb, rst_level: 0x1
[0280.510] I> USB configuration success
[0282.652] I> bct_bootrom image downloaded
[0282.707] W> PROD_CONFIG: device prod data is empty in MB1 BCT.
[0282.715] I> Temperature = 30000
[0282.718] W> Skipping boost for clk: BPMP_CPU_NIC
[0282.722] W> Skipping boost for clk: BPMP_APB
[0282.726] W> Skipping boost for clk: AXI_CBB
[0282.730] W> Skipping boost for clk: AON_CPU_NIC
[0282.734] W> Skipping boost for clk: CAN1
[0282.738] W> Skipping boost for clk: CAN2
[0282.742] I> Boot-device: QSPI (instance: 0)
[0282.746] I> Qspi flash params source = mb1bct
[0282.750] I> bct_mb1 image downloaded
[0282.804] I> Non-ECC region[0]: Start:0x80000000, End:0x100000000
[0282.812] W> Thermal config not found in BCT
[0282.820] W> MEMIO rail config not found in BCT
[0282.830] I> bct_mem image downloaded
[0283.523] E> RCM carveout size is smaller than blob size:0x40e1dcb
[0283.529] E> NV3P_SERVER: Failed to get load address for image blob from nv3p helper.

What could be the problem here? Is it because RCM carveout size is to small, but why? And how to increase this?

As we have found the “blob_boot0.img” has increased in size from 55031808 bytes to 61487104 bytes (marked in red). I don’t know why!? Maybe this could be a problem. So the questions here is why this size has increased (Kernel ‘Image’ files are almost same in size, what else is included in blob_boot0.img?). If this is okay , how could we handle with that.

This is the log at this point from flashing without compiling before:

Attached you find the complete logs for flashing with and without compiling kernel.

Thank you for any help in advance.

flash_WITHOUT_compile_kernel.log (94.8 KB)
flash_WITH_compile_kernel.log (23.2 KB)

Could you also validate whether that was working fine on rel-32.x release? Just want to know if this is rel-34.1.1 issue.

Hi Wayne,
thank you for fast reply.

Unfortunately we don’t have tested this with initrd_flash before on any 32.x releases (we used normal flash before).

I can do a test but it would take a while.

Let me list out some unknown factor

  1. rel-34.1.1 is still a developer preview. I am sorry to say that it may have bug. So using rel-32.x would be help to clarify the following points

  2. You are using a custom board, which has chance to make initrd flash not to work. We do see this kind of cases before.

  3. We are not sure if this nvme can be flashed without problem. Maybe only happened to this nvme but won’t happen if you replace to another brand.

Thank you for these points.

For points 2. and 3. I can say that initrd flash works with our custom board and 34.1.1 and with our dtb and cfg changes and with our SSD we use. The problem occures as we compile the linux kernel (we want to do some changes in the future) and we want to flash with initrd flash.

For point 1. : I will test this with 32.7.1. Unfortunately we need a newer kernel for our application, so the old kernel that comes with 32.7.1 could not be used in our project.

Okay, I’m back, I’ve tested the same with 32.7.2
There it works independently if the kernel is compiled or not compiled!

before compiling the kernel:

after compiling the kernel:

There the blob_boot0.img is 54878208 or 54943744 bytes that is pretty the same.

So for me it seems that 34.1.1 has a problem here. There this blob_boot0.img increases to >61MB (see above). Maybe you can ask a developer there this file “blob_boot0.img” is generated and what files are included? I haven’t found that. Maybe then I can search for differences in there.

Many thanks in advance.

Hi Daniele223, can you follow these steps:

  1. Make a copy of the original Linux_for_Tegra folder

  2. Run this command on the Linux_for_Tegra with the modified kernel:
    sudo ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_external.xml --showlogs jetson-xavier-nx-devkit-emmc nvme0n1p1

  3. Remove existing Linux_for_Tegra_original_kernel/tools/kernel_flash/images folder if neccessary and
    Copy Linux_for_Tegra_modified_kernel/tools/kernel_flash/images to Linux_for_Tegra_original_kernel/tools/kernel_flash

4.In Linux_for_Tegra with original kernel run:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --use-backup-images --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_external.xml --showlogs jetson-xavier-nx-devkit-emmc nvme0n1p1

Hi lhoang,
thank you for this info. Sorry for delay, I didn’t get an info for this reply.

I will test this and give a report.

Hi lhoang,

your workaround works! (but I had to change “–use-backup-images” to “–use-backup-image”)

The file blob_boot0.img has now a size like before and this works.

Can you give some more details what the problem is and if this will be fixed in the future?

It is a bit cumbersome to do this workaround all the time.

Thank you in advance!

This is because the blob_boot0.img is the initrd that is used for initrd flashing. THis initrd is generated by the kernel “Image”. It also contains the qspi payload to be flash. I think to reduce the size, maybe you could add “–network usb0”? That should remove the qspi payload from initrd because it will transfer the qspi content through NFS protocol.

We will plan to fix this in future releases

1 Like

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