I have been trying to do OTA BSP update (from L4T 35.2.1 to 35.3.1) on my AGX Orin but always been stopped at the same place during OTA process when execute the “sudo ./nv_ota_start.sh /ota/ota_payload_package.tar.gz” command.
The attached file is the log file retrieved from the /ota_logs/ folder.
I followed the exact steps in here to generate and trigger the payload and I didn’t enable the A/B partitioning feature.
Let me know if I need to provide other information.
Thanks for the help.
Are you using the devkit or custom board for AGX Orin?
Does other procedure run w/o error? Do you fail at the 8th step on Jetson device?
dd if=/tmp/var_tmp.bin of=L4TDefaultBootMode-781e084c-a330-417c-b678-38e696380cb9 bs=8
Failed to write /tmp/var_tmp.bin to L4TDefaultBootMode-781e084c-a330-417c-b678-38e696380cb9
Could you help to share the result of the following command on your board?
I copied your provided commands into a bash script and it seemed like it was going to reboot the device but it couldn’t. The screen was blackout and unreponsive.
Few minutes later, I tried to reset the devices by using the physical power button, but the device is currently not getting booted anymore. The LED is on and the NVIDIA logo shows for a sec and then everything goes black. Does it mean I have to flash the device to save it?
There is one thing I noticed that might cause the error execution at the 8th step but I couln’t understand how if it was the case.
Actually during the weekend I did successfully update the BSP by transfering the payload and your OTA toolkit to the edge device and executing all the steps LOCALLY on the terminal. Which should validate that the payload is generated properly and the what I did on the edge devices are correct as well.
But the experiments I had done that bumped into troubles at 8th step, since I aim to do this over-the-air, the procedures (Step 1~8) were put into a script and executed by a remote command to fork a process to then handle the script execution in the background. But it stopped at the 8th step as we saw in the log.
The only difference I can see between these two ways to trigger the payload to update, is I was not giving it a stdout/stderr interface when I executed the steps in the background. But how does that make sense?
It seems you could update the BSP by running it step-by-step manually on the terminal, but it would fail at Step8 if you are using a script to run the update procedures instead.
Is that correct?
Do you make sure your script having permission or run it with sudo?
And yes, I did run the script with root permission. Actually I have used the same way to operate OTA BSP Update with other L4T versions on different target devices many times and they all succeeded. I may fairly say I am quite familiar with the procedures but this is the first time I see this error on this specific L4T 35.2.1 to 35.3.1 @ AGX Orin.
It seemed like it needs stdout/stderr interface just like executing it in local terminal. And I really don’t understand why because it could always work with other versions on other devices without adding that argument.
I tried removing “set -e” in my original script (i.e. I didn’t add sudo at the 8th step or make privilege permission to the script itself) and it worked. Does that mean the 8th step did complete with some errors but they could be ignored?
I am insecure about not adding “set -e” in the shell script but I guess that’s the current workaround (or I add stdout/stderr at the end of the execution command).
I still feel something is not making sense and just would like to mention that:
That issue didn’t happen on other versions and devices I had been working with.
Still wondering why my original script can work as long as there is a output file to catch the log while NV OTA Toolkit has its log mechanism already.
Yes, it seems could be ignored.
If you still have concern about it, maybe you could try comparing the logs for the detail of errors causing it is stopped in step8.