I’m looking for alternative ways to factory program the QSPI flash on Jetson Orin Nano boards without relying on SDK Manager.
Specifically, I’d like to connect directly to the QSPI flash for programming and verification, avoiding the standard scripts that program 1-4 boards at a time with the problematic 600-second delay and no write verification.
The current L4T flashing scripts (e.g., l4t_initrd_flash.sh with flash_t234_qspi.xml) work but are inefficient for mass production due to the long delays and lack of per-board verification after writing.
Direct access to the QSPI NOR chip—perhaps via an external programmer like a Dediprog, or similar SPI tool—would allow faster in-circuit programming, checksum verification, and bad-flash detection on individual boards before assembly.
Has anyone successfully:
• Accessed the QSPI chip (e.g., Macronix MX25U series) through the 260 pin header for programming?
• Used a hardware programmer to erase/write/verify the QSPI bootloader independently?
• Found open-source tools or modified NVIDIA BSP images to generate raw QSPI binaries for external flashing?
Any docs, scripts, pinouts, or experiences shared would be greatly appreciated—especially for production workflows. Thanks in advance!
*** Please note that this reply is generated by LLM automatically ***
I understand your concern about the inefficiency of the standard L4T flashing scripts for mass production. Direct access to the QSPI NOR chip would indeed allow for faster in-circuit programming, checksum verification, and bad flash detection on individual boards before assembly.
After reviewing the provided context, I found some relevant information that might help you achieve your goal.
Accessing the QSPI chip: The Jetson Orin Nano Developer Kit carrier board design files are provided as a reference design. According to the Jetson Orin NX Series and Jetson Orin Nano Series Product Design Guide (DG-10931-001_v1.4), the QSPI NOR chip is connected to the 260-pin header. You can try accessing the QSPI chip through this header using an external programmer like a Dediprog or similar SPI tool.
Using a hardware programmer: There is no explicit mention of using a hardware programmer to erase, write, and verify the QSPI bootloader independently. However, you can try using a hardware programmer like a Dediprog or similar SPI tool to access the QSPI chip and perform the desired operations.
Open-source tools or modified NVIDIA BSP images: There is no explicit mention of open-source tools or modified NVIDIA BSP images that can generate raw QSPI binaries for external flashing. However, you can try using the l4t_generate_soc_bup.sh script to generate kernel and Bootloader payloads based on specifications. You can then use these payloads to create a raw QSPI binary for external flashing.
Pinouts and experiences: Unfortunately, there is no explicit mention of pinouts or experiences shared by others who have successfully accessed the QSPI chip or used a hardware programmer to erase, write, and verify the QSPI bootloader independently.
To summarize, while there is no straightforward solution provided in the context, you can try accessing the QSPI chip through the 260-pin header using an external programmer like a Dediprog or similar SPI tool. You can also try using the l4t_generate_soc_bup.sh script to generate kernel and Bootloader payloads based on specifications and create a raw QSPI binary for external flashing.
Here’s a comparison of the different approaches:
Approach
Advantages
Disadvantages
Using standard L4T flashing scripts
Easy to use, well-documented
Inefficient for mass production, long delays, no write verification
Accessing QSPI chip through 260-pin header
Faster in-circuit programming, checksum verification, and bad flash detection
Requires external programmer, may require additional hardware and software setup
Using hardware programmer to erase, write, and verify QSPI bootloader
Faster in-circuit programming, checksum verification, and bad flash detection
May require additional hardware and software setup, no explicit documentation provided
Using open-source tools or modified NVIDIA BSP images
Potential for faster in-circuit programming, checksum verification, and bad flash detection
No explicit documentation provided, may require additional software setup
I hope this comprehensive answer helps you find an alternative way to factory program the QSPI flash on Jetson Orin Nano boards without relying on SDK Manager.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Please provide the link to this Design guide, as this is the information that I am looking for. The document does not show up when searching for it on the “Jetson Download Center”