The orin module shipped from the original factory must be re burned before it can be started

I have a question, the orin nano was burned into SSD. After replacing it with the same module that was not burned from the original factory, the board did not start successfully and needs to be re burned based on the new module before it can start. Our client currently has too many ORIN boards in their hands and does not want to burn them again. May I ask if this process has burned anything to the EEPROM of the core board, or why the original module cannot be started?

Only dev kits have any software on them from the factory. Even those should be flashed once after receiving them. The separately purchased modules have nothing on them.

Note that if what is flashed to the Jetson boot and start content (from before Linux loads) is a major release difference, then boot would still fail if the rootfs is from a different major release.

Can I understand that there are loader and other bootloader programs in the core module? Will I also burn the modified information to the original factory core board when I re burn it to SSD?

你們單買module、不是DevKit版本的話就一定要燒過QSPI(存UEFI bootloader的地方)才能用

Understood, what the customer cares about is that the process of burning each core board during bulk shipment is too slow. The entire burning process of the instructions we are currently using takes about twenty minutes or more. I remember in the past, NX boards could integrate burning packages, but now we haven’t found this part based on the Orin series. Is there a way to save burning time?

This is the burning command we are currently using:
sudo ./tools/kernel_flash/ --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p " -c bootloader/t186ref/cfg/flash_t234_qspi.xml" --showlogs --network usb0 p3509-a02+p3767-0000 internal

後者的話可以用這個指令單獨燒QSPI bootloader

sudo ./ --no-systemimg -c bootloader/t186ref/cfg/flash_t234_qspi.xml <device> <root dev>

FYI, the bulk of flash time is (A) generating a rootfs image, and (B) flashing that image. All of the steps up to that point are rather fast. You might find that if your SSD is already set up correctly and flashing just QSPI is enough.

Cloning SSDs can be a separate step if you have a proper image, but beware that things like UUID of filesystem and serial numbers and perhaps checksums or user names and passwords, could have their own issue if they need to be unique. There are times when a Wi-Fi udev rule might depend on the MAC address, in which case a pure clone also would not be sufficient without edit, However, if you have a stack of SSDs which are cloned from each other, then even if you must script something to set up minor edits, then this would be faster than generating a new image every flash. QSPI does not contain the rootfs, so you have some flexibility, but it depends greatly on exactly what your topology is.

1 Like

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