With a new batch of TX2i modules, the flashing procedure hangs at the “tegrarcm_v2 --isapplet” stage.
The modules concerned have a “311” version.
Our carrier board is specific and several hundred boards have previously been produced without any problem.
Our software is based on L4T 32.3.1, and we use the “flash.sh -r jetson-tx2i mmcblk0p1” script for flashing.
below is the log return from flash.sh :
log_flash-TX2i311.txt (20.8 KB)
please share the uart log during flash failure.
also, if possible, test it on nv devkit instead of your board.
Previous log provided from flash.sh, was with L4T 32.3.1 with an overlay for PCN208460 provided by our NVIDIA contact in France.
With this software, there is no data send by module on UART0.
With the “original” L4T 32.3.1 software, data log from UART0 is limited to:
[0035.274] E> Waypoint-0.5 ACK pending: 0x8
[0035.278] C> MTS error (2) : dram alias check failure
[0035.283] C> cpu waypoint 0.5 failed
[0035.286] C> ERROR: Highest Layer Module = 0x32, Lowest Layer Module = 0x32,
Aux Info = 0x1, Reason = 0x6
I also test it on devkit with the same behaviour.
Could you put the module on devkit, flash with rel-32.7.4 and provide the uart log?
I used sdk manager to flash jetpack 4.6.4 (which includes L4T 32.7.4) on devkit.
It works and here is the logs from sdk manager terminal and from module uart:
flash_sdk_manager_jetpack4-6-4.txt (123.9 KB)
tegra_uart_debug_jetpack4-6-4.txt (31.5 KB)
Could you try to share the sdkmanager log from the beginning but not some progress bar info? I only saw a 0% to 100% progress bar from your sdkm log…
Sorry for the incomplete log…
Here is a new log (using extract log button) from SDK and associated log from module uart:
SDKM_logs_JetPack_4.6.4_Linux_for_Jetson_TX2_modules_2023-10-09_08-46-47.zip (208.7 KB)
uart_log_sdk_2023-10-09.txt (31.3 KB)
Our Nvidia contact told us that you successfully apply the overlay on release 32.3.1, with module flashing working.
So, I’ve tried to regenerate my software from scratch with your overlay and unfortunately the result is still the same: I can’t flash the module.
When I compare the start of the debug provided by flash.sh before freezing, it seems to me that some of the overlay files are taken into account:
These files are passed as parameters during a flash.sh step:
« ./tegraflash.py --bl nvtboot_recovery_cpu.bin --sdram_config P3489_A00_8GB_Samsung_8GB_lpddr4_204Mhz_P134_A02_ECC_en_l4t.cfg --odmdata 0x1090000 --applet mb1_recovery_prod.bin --cmd “flash; reboot” --cfg flash.xml --chip 0x18 --misc_config tegra186-mb1-bct-misc-si-l4t-storm.cfg --pinmux_config tegra186-mb1-bct-pinmux-quill-p3489-1000-a00.cfg --pmic_config tegra186-mb1-bct-pmic-quill-p3489-1000-a00.cfg --pmc_config tegra186-mb1-bct-pad-quill-p3489-1000-a00.cfg --prod_config tegra186-mb1-bct-prod-storm-p3489-1000-a00.cfg --scr_config minimal_scr.cfg --scr_cold_boot_config mobile_scr.cfg --br_cmd_config tegra186-mb1-bct-bootrom-quill-p3489-1000-a00.cfg --dev_params emmc.cfg --bins “mb2_bootloader nvtboot_recovery.bin; mts_preboot preboot_d15_prod_cr.bin; mts_bootpack mce_mts_d15_prod_cr.bin; bpmp_fw bpmp.bin; bpmp_fw_dtb tegra186-a02-bpmp-storm-p3489-a00-00-ta795sa-ucm1.dtb; tlk tos-trusty.img; eks eks.img; bootloader_dtb tegra186-quill-p3489-1000-a00-00-ucm1.dtb” »
Can you confirm that the overlay contains all the necessary files? There is only dtb files and sdram config file inside it.
PCN208460_TX2i_r32.3.1_overlay.tar.zip (91.8 KB)
I also attached all the sequence we used to generate our image and the associated scripts, please, can you have a look at my software generation, maybe I’m missing some stage….
generation_cmd_sequence.txt (1.2 KB)
scripts_generation.zip (17.0 KB)
and finally, perhaps our problem is not linked to PCN208460, are there other PCNs on the Jetson TX2i module since release 32.3.1 that leads to flashing issues?
You can try to share the serial number of your module.
That is the fastest way to tell if your issue is related to PCN208460 or not…
Also, to avoid all the noises here, Please just use devkit to test the overlay first.
I don’t know your script or what customization you added. That does not matter.
Use the devkit as baseline.
Do you have devkit to test the module? This module should be related to PCN 208460.
Yes, I have a devkit.
I compiled jetpack4.3 (with L4T R32.3.1) with sdkmanager and tried to flash it: as expected it doesn’t work.
I then integrated the PCN208460_TX2i_r32.3.1 overlay, ran the apply_binaries.sh script again and tried to flash the module with the flash.sh script: it succeeded!
The fact that it doesn’t work with my application may therefore be down to the way I integrate the overlay.
My application uses redundancy mode for software updates: can this have an impact on the application of the overlay?
I don’t know what does that mean you use redundancy mode.
Please try to figure out it by yourself. For example, check the flash log when it is using NV official tool with that thing customization by you.
It could be that the files got flashed are different.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.