Flashing Jetson nano emmc fails

Hello,

At first the board worked fine with preinstalled Ubuntu, but when i tried to flash Jetson nano production module ,eMMC [setup has custom carrier board from seeds studio Jetson-10-1A0), doesn’t worked with the virtual-box as host Ubuntu, as there was issue with the USB device access inside Virtual box.

Now i am trying with different computer running ubuntu18.04 , but it gets stuck in the the middle (see the command line output attached at the end of this topic)

.

Board:
Jetson Nano
P3448-0002 module
P3449-0000 carrier board

With Command-line method I am trying to flash NVIDIA L4T 32.6.1.

Here is the command line log i get::

~/Desktop/L4T_Drivers/Linux_for_Tegra$ sudo ./flash.sh jetson-nano-emmc mmcblk0p1
**[sudo] password for krishna: **
###############################################################################
# L4T BSP Information:
# R32 , REVISION: 6.1
###############################################################################
# Target Board Information:
**# Name: jetson-nano-emmc, Board Family: t210ref, SoC: Tegra 210, **
**# OpMode: production, Boot Authentication: , **
# Disk encryption: disabled ,
###############################################################################
**./tegraflash.py --chip 0x21 --applet “/home/krishna/Desktop/L4T_Drivers/Linux_for_Tegra/bootloader/nvtboot_recovery.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.0021 ] Generating RCM messages
[ 0.0041 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 0 --download rcm /home/krishna/Desktop/L4T_Drivers/Linux_for_Tegra/bootloader/nvtboot_recovery.bin 0 0
[ 0.0047 ] RCM 0 is saved as rcm_0.rcm
[ 0.0058 ] RCM 1 is saved as rcm_1.rcm
[ 0.0058 ] List of rcm files are saved in rcm_list.xml
**[ 0.0058 ] **
[ 0.0058 ] Signing RCM messages
[ 0.0082 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0088 ] Assuming zero filled SBK key
**[ 0.0174 ] **
[ 0.0174 ] Copying signature to RCM mesages
[ 0.0195 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
**[ 0.0208 ] **
[ 0.0209 ] Boot Rom communication
[ 0.0229 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml --skipuid
[ 0.0237 ] RCM version 0X210001
[ 0.1214 ] Boot Rom communication completed
**[ 1.1290 ] **
[ 1.1292 ] dump EEPROM info
[ 1.1338 ] tegrarcm --oem platformdetails eeprom /home/krishna/Desktop/L4T_Drivers/Linux_for_Tegra/bootloader/cvm.bin

Is this still carrier board or the devkit?

Its carrier board (nearly the same design as Jetson Nano 2GB Developer Kit’s carrier board) with Jetson Nano production module.

Then why do you say p3449? What is the exact carrier board you are using? Why do you keep changing the statement?

That is the device info i get in SDK manager

So you are using a custom board? Which is followin "nano 2gb board?

yes,exactly

I checked the logs on UART , there nothing on the terminal while flashing.

Although flash would most likely technically still work with a custom carrier board and the default JetPack/SDK Manager, you would still end up with non-functioning parts since the device tree would need customization. To that extent the manufacturer of custom carrier boards will provide its own flash software (mostly a minor edit of the dev kit JetPack/SDK Manager software). So you will probably want to first see if the manufacturer has its own instructions and software.

FYI, the numbering you see in a flash is in part (A) naming the module (if it is the same module), and in other part (B), naming the carrier board. The module portion won’t differ among carrier board manufacturer’s software, but the carrier board portion will change.

I check with manufacture (seedstudio) of custom carrier board, they confirmed the same procedure and JetPack works for flashing there are no modification in device tree.

Should I try with the latest JetPack and see if it works?

Is your board still able to boot up? If so, could you boot up and share me both the uart and kernel log?

Then JetPack probably is ok if they have the same device tree. However, are you still using a VM? A VM can cause flash failure if the USB pass-through is not functioning 100% correct.

No, board dose not boot up, The uart log is empty.

Now I am using separate computer with Ubuntu18.04 as host , Not VM.

The serial UART (not dmesg) has no output? That’s a more serious hardware issue (assuming the right UART is being used). Normally the serial port would be from the dev kit’s micro-OTG USB port. Is that the serial UART port you are using? On the host PC, if you run “dmesg --follow”, and watch as the serial cable (via the micro-OTG port) is plugged in, what do you see?

Yes, I agree with what @linuxdev is saying.

Are you sure your host machine is able to read the “uart” log on the same board before? Not the log from micro usb port .

It is unlikely that this board just cannot boot and log is empty. If your emmc was never flashed successfully, and that board was “working fine” before, the there should be at least something coming out from the uart. I mean the boot process may not be successful, but the log shall still show something.

Yes , i am sure , Its ttyUSB0, with 115200 8N1 setting and sudo permission.

dmesg --follow … show ttyUSB0

What is the exact dmesg content?

I agree that there should be something on uart, even I feel there is something wrong with the hardware.
As we soldered the SD card holder(Not to flash the image in SD , but to use as storage) on Jetson Nano Production Module, before starting the flashing process. I will check if there is anything wrong in soldering.

This is the output of dmesg --follow after disconnecting and connecting again the FTDI serial module

[27836.850237] usb 3-10.1.1: USB disconnect, device number 30
[28403.492901] usb 3-9: USB disconnect, device number 19
[28403.493767] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[28403.493809] ftdi_sio 3-9:1.0: device disconnected
[28656.462968] usb 3-9: new full-speed USB device number 31 using xhci_hcd
[28656.617035] usb 3-9: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[28656.617039] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[28656.617041] usb 3-9: Product: UMFT234XF
[28656.617043] usb 3-9: Manufacturer: FTDI
[28656.617045] usb 3-9: SerialNumber: FT4MDM3O
[28656.620302] ftdi_sio 3-9:1.0: FTDI USB Serial Device converter detected
[28656.620356] usb 3-9: Detected FT-X
[28656.621076] usb 3-9: FTDI USB Serial Device converter now attached to ttyUSB0