Flash fails with Error: missing kernel_fs ()

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

I tried directly writing a dtb file to a partition on my Jetson and now am unable to reflash the board. Does anyone know how to recover this, or is my Jetson bricked?

###############################################################################
# L4T BSP Information:
# R32 , REVISION: 3.1
###############################################################################
# Target Board Information:
# Name: B, Board Family: t186ref, SoC: Tegra 186, 
# OpMode: production, Boot Authentication: NS, 
###############################################################################
./tegraflash.py --chip 0x18 --applet "/home/charles/nvidia/nvidia_sdk/JetPack_4.3_Linux_JETSON_TX2/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin" --skipuid --cmd "dump eeprom boardinfo cvm.bin" 
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
 
[   0.0022 ] Generating RCM messages
[   0.0029 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 0 --download rcm /home/charles/nvidia/nvidia_sdk/JetPack_4.3_Linux_JETSON_TX2/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin 0 0
[   0.0034 ] RCM 0 is saved as rcm_0.rcm
[   0.0037 ] RCM 1 is saved as rcm_1.rcm
[   0.0037 ] List of rcm files are saved in rcm_list.xml
[   0.0037 ] 
[   0.0037 ] Signing RCM messages
[   0.0043 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0049 ] Assuming zero filled SBK key
[   0.0075 ] 
[   0.0075 ] Copying signature to RCM mesages
[   0.0081 ] tegrarcm_v2 --chip 0x18 0 --updatesig rcm_list_signed.xml
[   0.0089 ] 
[   0.0089 ] Boot Rom communication
[   0.0094 ] tegrarcm_v2 --chip 0x18 0 --rcm rcm_list_signed.xml --skipuid
[   0.0099 ] RCM version 0X180001
[   0.1091 ] Boot Rom communication completed
[   1.1160 ] 
[   2.1199 ] tegrarcm_v2 --isapplet
[   2.1222 ] Applet version 01.00.0000
[   2.2071 ] 
[   2.2098 ] Retrieving EEPROM data
[   2.2101 ] tegrarcm_v2 --oem platformdetails eeprom cvm /home/charles/nvidia/nvidia_sdk/JetPack_4.3_Linux_JETSON_TX2/Linux_for_Tegra/bootloader/cvm.bin
[   2.2125 ] Applet version 01.00.0000
[   2.2912 ] Saved platform info in /home/charles/nvidia/nvidia_sdk/JetPack_4.3_Linux_JETSON_TX2/Linux_for_Tegra/bootloader/cvm.bin
[   2.3640 ] 
Board ID(3310) version(D00) sku(1000) revision(J.0)
Error: missing kernel_fs ().
2

I’m not sure what’s going on there, but so far as I know simply writing any partition by any method won’t brick it. Odds are something else is going on due to the flash software and/or host PC.

  • Is this a dev kit?
  • Is your host a regular Ubuntu 18.04 PC, or is there anything special, e.g., a VM?
  • Or a different release of Ubuntu?
  • If you flashed on command line, what was your exact command?
  • Were you using the micro-B USB cable which comes with the dev kit?
3

Thanks for your response.
It’s a custom TX2 carrier that I have previously flashed (and ~20 others exactly like it) with the same ubuntu 18.04 host system, cable, etc using Nvidia’s flash.sh.

4

I don’t know enough about what is running in the recovery mode Jetson, but technically that content will not care about what is in the eMMC, and flash should be able to proceed.

Flash can be performed for any carrier board and not care about which carrier board it was actually flashed in…it isn’t until booting that the software has to be adjusted for the carrier board. Do you have another carrier board you can try to flash that same software to it? You’d have to move the module back to the other carrier board for it to correctly boot, but knowing if flash works from a different carrier board would be useful knowledge.

You could in fact use a default flash (without your modifications) on this carrier board or another carrier board just to guarantee the flash process itself. This would not stop you from flashing it again with the software correct for your carrier board, and it would find out if the module flashes under known conditions.

Basically you could find out if the issue follows the module or if perhaps if it follows the flash host software (the flash software itself could be corrupt due to some unknown software change). Even changing the host you flash from to see if the problem follows would be useful.

Trivia: The recovery mode Jetson still requires software to be uploaded to it, such as fastboot, just for flash to succeed, but the software uploaded during the flash is in RAM and goes away upon reboot. That temporary software comes from the flash software.

1 Like
5

It was a broken symlink in my rootfs