Technical Evaluation and Inquiry regarding Mass Deployment
After reviewing the technical documentation and manuals concerning Mass Deployment, I have categorized our application scenarios into the following two stages and would like to clarify several technical implementation details:
I. Application Scenario Definitions
Initial Provisioning (Factory Automation): Booting a temporary Linux environment (RAMOS) via PXE to automatically execute flashing scripts that write the system image to local NVMe/eMMC. The system will shut down automatically upon completion to ensure production line consistency.
Diskless Operation (Station Monitoring): Primarily utilized during the Functional Test (FT) phase. Loading the test system via network boot allows for unified environment management and real-time feedback of test results.
II. Technical Architecture Clarification
Based on my current understanding, the deployment environment involves NFS-mounted RootFS and TFTP-loaded Kernel to achieve diskless booting. Regarding the development and implementation, I have the following points to confirm:
Code Maintenance Strategy: Under the current development framework, is it necessary to maintain a separate codebase (branch) specifically for the provisioning environment? Or is it recommended to switch functionality dynamically by loading different initrd images?
Bootloader Selection: Given our hardware environment, is it preferable to adopt the grubnetaa64.efi.signed (UEFI standard) or utilize the native U-Boot network boot capabilities?
Resource Reusability:
Image & Kernel: Can we directly reuse the existing system kernel for both environments?
initrd Configuration: Does the provisioning initrd require a specialized repackaging with flashing tools? Regarding IP assignment, should we strictly use DHCP to avoid manual physical configuration?
NFS Directory Structure: Are there recommended best practices for the server-side directory structure of nfs_root(e.g., organized by MAC Address or UUID)?
III. Communication Protocol Evaluation
I would also like to discuss the environmental differences between HTTP Boot and PXE Boot. As our current focus is on Initial Provisioning, which protocol is recommended in terms of stability and transmission efficiency—especially considering the high throughput required during large-scale concurrent deployments?
Are you using the devkit or custom board for Orin NX?
What’s the Jetpack version in use?
This is a good fit for the existing UEFI PXE boot (IPv4) flow: UEFI boots grubnetaa64.efi.signed via TFTP, which then loads a kernel + initrd that runs your flashing tools, writes NVMe/eMMC, reports status, and powers off automatically.
Also supported: UEFI PXE → GRUB → kernel with NFS-mounted rootfs for a centrally managed test environment.
Keep a single codebase and reuse the same kernel; switch between provisioning and FT by using different initrds or kernel command lines. Only create a separate branch if the provisioning OS must be very different from production.
On Orin/Thor we recommend UEFI PXE with grubnetaa64.efi.signed because it is the documented and tested path and works with UEFI Secure Boot. U-boot is not supported.
Yes, you can reuse the same kernel image for all boot modes as long as it has the required NIC/PXE/NFS options enabled. Build a custom provisioning initrd with flashing tools and logging, and use DHCP (optionally static leases) to avoid manual per-device IP setup.
There is no strict rule; common practice is a shared read-only base rootfs plus per-device overlays/logs, or per-device rootfs under /nfsroot/<MAC-or-UUID>. Using MAC or UUID in the directory name makes per-device tracking and management easier.
On Jetson today, the officially documented and validated firmware-level network boot is UEFI PXE (TFTP) + optional NFS.
Validation Workflow: Our current priority is AGX Thor. Initial PXE Boot validation will be conducted using the NVIDIA DevKit.
Mass Production (MP): The final production phase will utilize the custom carrier boards we have designed for our clients.
Regarding our current production roadmap, which spans three product lines—Orin NX/Nano, Orin AGX, and AGX Thor—I would like to seek your professional advice on the following deployment strategies:
1. Deployment Independence & Scalability
Maintaining three separate deployment workflows for these platforms seems inefficient regarding maintenance overhead and version control. Are there industry-standard “platform-level” management practices for handling BSP and image versioning across such diverse hardware tiers more effectively?
2. Process Unification
I am considering simplifying MP maintenance into a single, unified workflow using PXE Boot (RAM disk) combined with SSD deployment.
Compatibility Risks: Does a unified PXE-based flow pose any compatibility risks across these cross-generational and cross-tier hardware platforms (specifically for the AGX Thor)?
Best Practices: In the process of implementing automatic hardware identification and corresponding image dispatching, are there any recommended best practices or reference architectures?
I look forward to hearing your insights or practical experience on these matters. Thank you.
I would suggest using the upcoming Jetpack 7.2 which should support for both Orin/Thor series.
Use one shared provisioning pipeline (PXE/NFS/HTTP + image registry/CI) and model each platform (Orin NX/Nano, Orin AGX, AGX Thor) as a separate “target” with its own BSP/image metadata. Industry practice is to centralize versioning in a manifest/DB (platform ID → BSP/image/version) so you reuse the same tools while only the per-platform configuration differs.
A single PXE-booted RAM-disk workflow is fine as long as the provisioning kernel/initrd support all boards and you pick the right BSP (DTB, rootfs, ODMDATA) per platform. Best practice is: provisioning OS reads board/SKU info (e.g. from device tree), sends it to a server, and the server maps that identity to the correct image and config.
Thank you for your previous recommendations. We have decided to standardize our mass production (MP) deployment based on Jetpack 7.2. To align with our production roadmap, could you please provide the Estimated Time of Availability (ETA) or a specific release schedule for this version?
Additionally, we are currently validating the PXE Boot implementation on the Jetson Thor (r38.4.0) platform and have encountered the following issue:
Environment: L4T r38.4.0 / Thor Platform (DevKit)
Symptom: During the network boot process, the system hangs at the “START PXE” prompt with no further response. No DHCP requests or TFTP traffic were observed via packet capture on the server side.
Request: Are there specific implementation guides, reference configurations, or known issues regarding PXE Boot for the Thor platform?
I have attached my current configuration summary below. Could you please help review if there are any misconfigurations or missing parameters specific to this architecture?
I would like to provide an update regarding the network architecture configuration. The fixes and verification are complete, and GRUB is confirmed to be mounting and booting successfully.
However, I am currently encountering a kernel boot anomaly. The debug console (comport) is not displaying any kernel boot messages. I have attached the following files for your reference:
Boot log (up to the GRUB stage)
Image and initrd files (located in the Rootfs folder)
Given the lack of kernel output, do you have any suggestions on the best direction for further debugging and verification?
Thank you for the information regarding the Tegra Combined UART configuration for Jetson Thor. Based on our testing, there is still no log output on the /dev/pts/15 (CCPLEX: 0) terminal.
Regarding the test environment, we have verified that the current image flashes correctly and boots successfully.
Core Resources: Utilizing NVIDIA official pre-built images (L4T R38.4.0), including the Driver Package and Root File System (Rootfs).
Deployment Status: The PXE environment setup has been successfully completed.
Verification Progress: Currently operating under an OOTB (Out-of-the-box) configuration, deploying the official binary images directly.
Test Objective: Validating whether the native boot and deployment workflows function correctly without any source code modifications or kernel recompilation.
This message is not the primary error information; it is the boot log generated when the system automatically falls back to SSD boot after a PXE boot failure.
Regarding the PXE Boot failure, I have updated the T264 (t26x) platform with the DEBUG UEFI firmware. Initial testing indicates that the boot issue persists without improvement.
I am currently auditing the Network Stack and PXE configurations.
Please find the detailed boot logs attached. Could you help verify if any further adjustments to the UEFI DefConfig are required, or suggest alternative debugging strategies?
