Hi everyone, my board is a Jetson Orin Nano Developer Kit 8GB version 36.4.3 with an external nvme ssd I followed the steps mentioned in this document https://docs.nvidia.com/jetson/archives/r36.4.3/spe/md__home_ jenkins_workspace_Utilities_rt_aux_cpu_demo_fsp_docs_work_rt_aux_cpu_demo_fsp_doc_spi_app.html#autotoc_md39
Modified my kit as a spi host and flashed the spi partitions separately After flashing the spi my board rebooted and got stuck like this
then I used this command again to complete step 5 Reflash all partitions to ensure that the pinmux and firewall settings are updated on the board. I was prompted for timeout during the reflash process, is there any error in my process and why is it happening?
Hello,
Most probably, the SPE firmware flashed to device fails.
SPE firmware will run quite early, and if it hangs, device may fail to flash or boot.
My suggestion is to test that step by step.
You can build SPE firmware, without any change, or only add some print. Make sure that the basic operations, like firmware compile, flash, etc., are good.
Then start from existing samples, and follow the guide, to enable demos, and check whether it can work as expected. Note, if pinmux/firewall changes are involved, it’s better to re-flash the whole device. All existing demos are verified.
If you want to bring your own changes, be careful and just add them by small clips. and reverse the change if it fails. once you get familiar with the system, you can do more aggressive updates.
Do not bring up private tasks right after firmware init. A better way is to trigger tasks from CCPLEX. That may make the firmware debug/programming easier.
Thanks for your prompt reply, firstly what code should I use to flush the whole partition, I tried sudo BOARDID=3767 BOARDSKU=0005 FAB=TS4 . /tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p ‘-c bootloader/ generic/cfg/flash_t234_qspi.xml’ --showlogs --network usb0 jetson-orin-nano-devkit internal and sudo . /flash.sh jetson-orin-nano-devkit-nvme internal do not work!
Secondly, after my testing, there might be a problem in step 4 of the guide
For SPI Master app, In soc/t23x/target_specific.mk, set ENABLE_SPI_APP := 1 and rebuild the application. Copy the output to ${L4T}/bootloader/spe_t234.bin.
If I use the original spe_t234.bin file suite it boots fine, but after setting ENABLE_SPI_APP := 1 and making bin_t23x using the new /out//spe.bin file suite it doesn’t startup
If device is in RCM and connected with host through USB, you can skip the hardware info like BOARDID, BOARDSKU, etc. Flash utils will get the information online.
Following command works well in my side. (full flash)
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 nvme0n1p1
That means there’s something’s wrong with updated SPE firmware. Have you ever followed every instruction in SPI doc? Let me know if it still fails.
I just used these commands to update the different partitions in order and then finally update the spe firmware and it worked, does this mean that I have to update the dtb partitions before updating the spe instead of the order in the guide “update the spe before updating all partitions”?
Here are my commands: sudo ./flash.sh -k BCT jetson-orin-nano-devkit-nvme internal sudo ./flash.sh -k A_mb1 jetson-orin-nano-devkit-nvme internal sudo ./flash.sh -k A_MB1_BCT jetson-orin-nano-devkit-nvme internal sudo ./flash.sh -k A_spe-fw jetson-orin-nano-devkit-nvme internal
I only have one jetson orin nano devkit right now and I’m wondering how to test that my spi-app is ready to use on the master device can I see the information in the logs? Just now I searched the boot logs and searched for spi_test but didn’t see SPI test successfull, after I restarted the jetson I couldn’t even see spi_test. I noticed the guide says I need to short miso and mosi but I don’t want to make changes to the hardware right now
For flash part, my first suggestion is to flash the full device. Once you get familiar with SPE development, you can update the single partition as desired.
For SPI part,
For SPI function, you can check the SPI pins with scope, to confirm they have output waveforms once SPI transfer is ongoing.
You can check the SPI test code, and without shorting miso and mosi, you will not see the test success logs. Anyway, you can start with print/signal probe first.
instructions and edited the following files
/bootloader/generic/BCT/tegra234-mb1-bct-pinmux-p3701-0000-a04.dtsi. and /bootloader/tegra234-mb1-bct-gpio-p3701-0000-a04.dtsi and / bootloader/tegra234-mb2-bct-scr-p3701-0000-override.dts,which specific partitions should I flash?
Hello,
that’s the problem. some partitions are independent, like some firmware, kernel image, kernel dtb, etc.
But for some other partitions, they are dependent, which means they cannot be flashed individually. Also, flash commands vary from version to version, and I cannot give a positive confirm without a full verification in specified BSP version.
My suggestion still persists.
with those config changes, like pinmux, SCR, etc., it’s better to flash the full device. As you can see from file name, some are from MB1 BCT, but some others may lie in DTB.
