SDK Manager flash to NVMe with flash checkpoint error

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
42

I’m thinking the message:

waiting for target to boot-up

We use our own power management MCU to control the powering up/off, but not identical one with the devkit. May this is the reason?

Thanks.

44

serial@c280000 is correspond to which pins on P3509? Won’t this disable the DEBUG serial port? And which file I need to change? I will give a try.

Thanks.

45

@WayneWWW may you tell me what are expected when it showing “… waiting for target to boot up”? Whether it informed the carrier board to do a power cycle or not? If it indeed toggled some pins such as power down request, system reset, etc to inform the carrier board to do power relative works, then we may need to review our power control schema.

Thanks.

46

Could you attach the dts of your custom board?

47

Yes, the final DTB is attached.

But I’m afraid it has no relation with the DTB. Because even the origin image built by SDKM won’t be flashed successfully.

tegra194-p3668-all-p3509-0000.dtb (223.2 KB)

48

When initrd flash tool prints

waiting for target to boot-up....

this means the tool is waiting for the storage devices attached through the board and waiting for ssh connection through usb. It seems that the board boots ok; but your host does not create the necessary interfaces ( /dev/ nodes through usb cable and ethernet through usb cable) to be able to talk with the initrd flash.

What you can do is trying to use a different host to flash or use another usb cable or you can try to reboot your host.

Or since you are already able to use the official devkit to flash to nvme, you can attach your nvme ssd to the official devkit and flash using command:

sudo nvsdkmanager_flash.sh --storage nvme0n1p1

After the flash process finish, you can detach your ssd and plug into your custom board and then flash you custom board with command to flash its qspi and emmc:

sudo ./flash.sh <custom_board> nvme0n1p1

Note that if you are using this way you might have to replace the dtb file in the /boot/ folder on the nvme ssd to the right file.

49

Thanks for the reply.

I will try the last method. But it’s just some work round. If possible I still want to know where goes wrong with my board. What’s wired is, using same VM (yes, I’m using a virtual machine) I can flash the same SSD with official devkit. But can’t with my custom board. So, the problem may not be caused by the VM. On my custom board, do there are some differences with the devkit. Such as we use our own power management MCU, we attached one TI usb hub on USB 2.0 (sure we leave the recovery port as it is). And we use a DP display but not a HDMI one. May these be the cause?

50

Hi,

Are you able to see /dev/ttyACM0 or ping usb internet interface(192.168.55.1) on your host side?

51

If possible can you check “For an OTG (On-The-Go) Port” section of

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/adaptation_and_bringup_xavier_nx.html#

to see if your custom board is implemented correctly?

52

The recovery port worked well when flash other storage, such as emmc, components.

There is a little difference with the devkit, the ID pin is ESD protected on our board.

image
image951×496 46.5 KB

53

It is not regarding the emmc or the recovery mode. It is regarding the software configuration in kernel.

54

Make it more easier for you to understand

  1. Initrd flash is for flashing the NVMe here and it is different from using flash.sh to flash emmc.

  2. When running flash.sh to flash, the usb port is in recovery mode (device mode) triggered by hardware.

  3. When running initrd flash to flash NVMe, the device is already booting up, in such status, it is the kernel to control the usb functionality.

Thus, it does not matter how correct your hardware is, (3) requires the device tree configuration in kernel to be correct. If devkit can get flashed on your host but your board cannot, then it could be the reason that you didn’t configure device tree or it is not correct.

That was why I asked you whether /dev/ttyACM0 or usb interface is coming up on your host.

56

I see that when it showing “waiting boot up…” the rest is handled to the kernel.

When ‘/dev/ttyACM0’ will show? Must I try to do a NVMe flash to check it? Or I can check it on a flashed board ?

57

If you don’t know what I am talking about, use your devkit, boot up, connect the micro usb port to your host and check your host side /dev.

58

I remember when it showing “waiting boot up…”, the attached USB device when starting flash disappeared from VMware device list.

59

Can you try to use native ubuntu host to check this issue?

60

I can’t get a PC with native Ubuntu now. :(

61

Our initrd flash requires to see NX device as a rndis device and msc device.

That is why I asked whether your host can see the device’s usb ncm interface… If you really don’t know what I am talking about, then I can explain more…

62

In my previous post, I mention some one on the forum mentioned this service, is this?

63

No, not related to this.

If you ever connecting “devkit” to your host, there should be a interface on both side. Host side would have IP 192.168.55.100 and jetson side is 192.168.55.1. These Internet interfaces are based on usb device mode.
If you unplug the micro usb cable, then this interface would be gone.

This interface is needed for initrd flash to run.