Custom board use l4t_initrd_flash.sh fail with Waiting for target to boot-up

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
,
1

Hi nv team,
I use our custom-made board because our hardware design differs from the devkit. Therefore, we have made some modifications to the device tree, as shown in the diagram below.

image
image1080×1037 40.8 KB

I can confirm that in this scenario, using the flash.sh script allows us to flash our board with the program. This is because when we enter recovery mode and run lsusb, we can see the NVIDIA device on host computer. In fact, we’ve been using this method for over a year.

Recently, I wanted to research moving the rootfs to an SSD. So, I followed a link and tried it, but encountered a timeout issue just as follow
Error flashing SSD: /Linux_for_Tegra/bootloader/signed/flash.idx is not found - Jetson & Embedded Systems / Jetson AGX Orin - NVIDIA Developer Forums

image

I’m wondering if I’m just unable to usel4t_initrd_flash.sh, so I tried using a command to flash the eMMC

sudo ./tools/kernel_flash/l4t_initrd_flash.sh jetson-agx-orin-devkit mmcblk0p1

but encountered the same waiting error.

Through forums, I found another link where someone had the same issue. With my custom system, I can’t see the acm0 device, but with the devkit system, I can see acm0.

Ssd boot on custom board with AGX SoM - Jetson & Embedded Systems / Jetson AGX Xavier - NVIDIA Developer Forums

So, my questions are:

  1. Is it because of the modifications I made to the device tree that I can’t see the acm0 device, which in turn prevents me from using the l4t_initrd_flash.sh script?
  2. If the answer to question 1 is yes, do I still have a way to flash my rootfs to an SSD?

Looking forward to your reply.

2

Hi,
Please check the quick start in developer guide and make sure you follow the steps one by one:
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/IN/QuickStart.html
If the device still cannot be flashed/booted, please refer to the page to get uart log from the device:
https://elinux.org/Jetson/General_debug
If you are using custom board, you can compare uart log of developer kit and custom board to get more information.

Thanks!

4

Hi mmcly,

What’s the current Jetpack version in use?

For the timeout issue during flash, please check the serial console log.
It may be caused from the boot issue.

Please check with your HW team about if the debug UART port is available on your custom board.
For the devkit, debug Uart can be accessed through micro-USB port on the board with /dev/ttyACM0 recognized on the host.

For the custom board, you should have a custom board config and related changes according to your design.

5

ok，I will try it

6

we are using Jetpack5.1.2

ok， I will try it

but according to other topic from forums.
No Known UDC device found in massflash - Jetson & Embedded Systems / Jetson AGX Orin - NVIDIA Developer Forums

I think I’m facing the same problem。

ok， I will share the log as soon as possible.

yes for our custom board, we have some modify on flash usb type c. so we change the dts file disable xudc

7

initrd flash needs usb device mode so you cannot disable xudc…

8

so, that’s the key point. our hardware design do not support device mode. if I set okay to the xudc, the log will say, “bad usb wire”

9

You can follow Xaiver NX device tree for usb2-0 setting first and it shall let you be able to pass the flash process.

Please try this first.

10

before trying your method, I find this

Flashing Support — Jetson Linux Developer Guide documentation (nvidia.com)

so I put the ssd on the host computer and run as follow.

sudo BOARDID=3701 BOARDSKU=0000 FAB=TS4 ./tools/kernel_flash/l4t_initrd_flash.sh -c tools/kernel_flash/flash_l4t_external.xml --external-device nvme0n1p1 --direct sda jetson-agx-orin-devkit external

I didn’t modify anything, and it flash to the ssd sucessfully. after that, I plug in the ssd on my custom board. after the system boot, I modify the /boot/extlinux/extlinux.conf.

- root=/dev/mmcblk0p1
+ root=/dev/nvme0n1p1

after a second reboot I can see the root is mount on /dev/nvme0n1p1
image

so it works right?

11

yes, such method would work too. If you accept that (must plug the drive to host ), then we are done here.

12

Well, I just mention a way to get the rootfs run on the ssd as I mentioned above.

and now I have encounter another question. that is some time it well block on the specific step just as the pic I posted.

image
image1711×839 154 KB

it will block on the step for more than an hour.

I don’t know if this is caused by an issue with my SSD read device. Or is it that the method of connecting the SSD to the host computer for flashing is inherently unstable?

13

Hi guys, I have confirmed that it’s my fault that I used a bad USB part. So, let’s go further, if I have some confusion on flash.

14

dd command may take time to complete, which depends on the size of your partition.

It seems you’ve managed to get it work.
May I know what’s your current issue about flash?

15

actually, no special issue, just as @WayneWWW said to try use " Xaiver NX device tree", and I haven’t try this method.

17

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