SDK : r35.6.0
We have attempted to set up a PXE flashing environment. Verification shows that the QSPI FLASH inside the module cannot be flashed, the reason being that spi@3270000 cannot be recognized after initrd is loaded, which in turn prevents the recognition of the MTD device.However, the external NVMe can be successfully flashed.
Reference link:Flashing Support — NVIDIA Jetson Linux Developer Guide 1 documentation
What should we do to achieve PXE flashing?
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, it appears that you are trying to set up a PXE flashing environment for Jetson Orin NX SDK r3560, but are encountering issues with recognizing the QSPI FLASH inside the module after initrd is loaded.
To achieve PXE flashing, you can refer to the “Configuring a PXE Boot Server for UEFI bootloader on Jetson” section in the provided context. However, since the QSPI FLASH is not being recognized, you may need to use an alternative method.
One possible solution is to use the initrd flash method, which is the official method for flashing Jetson Orin NX series and Jetson Orin Nano series with NVMe as the external storage device. You can use the following command to flash the external NVMe device:
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -p "-c ./bootloader/generic/cfg/flash_t234_qspi.xml" -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit external
This command will flash the external NVMe device, but it will not flash the QSPI FLASH inside the module.
To flash the QSPI FLASH, you may need to use a different method, such as using the flash.sh command with the --no-flash option, which will skip flashing the QSPI FLASH. However, this method is not explicitly mentioned in the provided context, and you may need to refer to additional documentation or resources to determine the correct command and options to use.
In comparison, the initrd flash method is a more straightforward and officially supported method for flashing the external NVMe device, but it may not address the issue with recognizing the QSPI FLASH inside the module. You may need to explore alternative methods or seek additional guidance to resolve this issue.
In summary, to achieve PXE flashing, you can try using the initrd flash method to flash the external NVMe device, but you may need to use a different method to flash the QSPI FLASH inside the module. Additional research and guidance may be necessary to determine the correct approach.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Hi cgf17333031021,
Are you using the devkit or custom board for Orin NX?
QSPI is inside the module and it should work well.
Please share the full flash log from host and the serial console log from device for further check.
Have you set it up correctly on the host?
Both the devkit and the custom board have been tested, and the symptom is the same.
The QSPI driver has also been installed. The initrd for PXE is extracted from boot0.img, which works without issues.
When the system boots into Ubuntu normally, the device tree still fails to detect the spi@3270000 node. You can verify this.
I have tried an alternative method that works, but it does not meet my requirements:
log (2).txt (107.1 KB)
-
Put the devkit into recovery mode.
-
Use the
./tegraflash.pycommand with relevant parameters to start the devkit. -
When the devkit boots to the BIOS, select PXE boot.
-
In this way, after entering PXE, normal flashing can be performed, and the QSPI functions properly.
Therefore, I suspect that the spi@3270000 node is protected in normal mode and only enabled in recovery mode.
So, is there any way to disable this protection?
log.txt (83.7 KB)
This log was obtained by me through the following steps, and it can detect the SPI flash:
-
Put the devkit into recovery mode
-
Run the
./tegraflash.pycommand with relevant parameters to start the devkit
Okat, It seems you’ve found the WAR for your use case.
it is the expected result that the qspi can only be accessed in recovery kernel.
That’s why and how the initrd flash script works.
I load the initrd via PXE, but the QSPI FLASH does not work.
I need to boot by loading the initrd via PXE, and ensure the QSPI FLASH can be accessed. In this way, PXE programming can be realized without USB intervention.
So what should I do to achieve this?
We support PXE boot rather than PXE flash.
Could you elaborate on your requirement and the use case?
It seems you can flash the external NVMe but not for internal QSPI through PXE currently!?
Currently, external NVMe can be programmed via PXE, but internal QSPI Flash cannot.
PXE is mainly used for mass production programming and post-production maintenance.
Can this issue be fed back to your R&D team to explore solutions?
Okay, I’ll check with internal if we support flash with PXE.
As my understanding, we only support using initrd or flash script through USB interface.
Okay, thanks.
I’ve confirmed with internal that we don’t support the use case of PXE flash.
But to answer your questions of not deleting the spi node, you can modify the following part of uefi source code.
edk2-nvidia/Silicon/NVIDIA/Library/DxeDtPlatformDtbLoaderLib/DxeDtPlatformDtbKernelLoaderLib.c at r35.6.2-updates · NVIDIA/edk2-nvidia · GitHub
Got it, I’ll give it a try. Thanks.
Can I add the SPI Flash back in the form of DTBO?
I want to integrate a DTBO into the initrd of my PXE.
I tried it out, and after the system booted up, I found that the path /sys/kernel/config/device-tree does not exist (even though CONFIG_OF_OVERLAY is already enabled).
Could you tell me if the DTBO method is feasible here? And what steps should I take?
I’m not clear about what do you mean about “add the SPI Flash back in the form of DTBO”.
It seems the expected result that I don’t see it on my setup, neither.
Could you check /proc/device-tree instead?
I tried it out, and this method doesn’t work either. For UEFI, it’s not just a matter of removing the qspiflash; it also removes the access rights.
There is no update from you for a period, assuming this is not an issue anymore.
Hence, we are closing this topic. If need further support, please open a new one.
Thanks ~1008
Is this still an issue to support? Any result can be shared?