Hi, what is the necessary setup to be able to access the QSPI flash on the Orin NX from Linux? I see it’s available as /dev/mtd0 in the initrd used for flashing, but later on when logging in Ubuntu it’s no longer available. I tried loading the qspi_mdt and mtd modules with modprobe because I’ve seen them loaded in the flashing initrd but it’s still not showing up. Are there some module params that need to be set? How can I access the qspi as mtd block?
Thank you
It is not possible to access it in Linux anymore due to some security update after rel-35.2.1.
@WayneWWW I need to access it for development purposes. Is there any way or workaround for me to do this?
May I ask what kind of usecase that is required here? I may need to check with internal team so want to clarify this first.
@WayneWWW I’m working on adding support for the Orin NX on balenaOS
We’re using the Yocto meta-tegra layer as a base and we use a custom OTA update process for devices which implies updating the uefi firmware based on our platform requirements and specifications. We’re also using custom builds of the Tegra kernel and uefi firmware.
Thank you
I am not sure if that helps, but currently the OTA upgrade on jetson AGX Orin has been moved to UEFI.
https://docs.nvidia.com/jetson/archives/r35.2.1/DeveloperGuide/text/SD/Bootloader/UpdateAndRedundancy.html?highlight=capsule#generating-the-capsule-update-payload
However, Orin NX does not support OTA yet, so above method is not applicable to ONX for now.
Thanks @WayneWWW , unfortunately it’s not of much help because we need to perform the update of QSPI from Linux. Since it’s available when booting the Kernel initrd in RCM-boot I guess there has to be a way to expose at runtime as well, like on the rest of the Jetson modules. Could you please check internally and let me know?
Thank you
Ok. Will confirm and come back.
Just want to clarify agian… this is not specific to jetson Orin or Orin NX. It is software update on rel-35.2.1. Every device that has QSPI won’t be able to get accessed from Linux by default, even Jetson Xavier NX.
I see, thanks for the heads up!
In this case we’ll need a way to access them on ALL Xavier AGX and Xavier NX modules and as well as on the AGX Orin because all these devices are supported in balenaOS and are used by many customers. The inability to update the QSPI flash from Linux thus affects the update process for our users. Thanks again and looking forward to your reply
Hi,
Could you clarify why your usecase must access QSPI from kernel side? As our internal discussion, this could not be done because we have firewall setting. Which means even if you enable driver to let /dev/mtd node generated, you will still hit error when trying to access it.
Hi @WayneWWW , our use-case is updating /dev/mtd or /dev/mmcblk0boot0 using flash_erase and dd. We generate the QSPI blob at build time in yocto and our cloud OTA scripts update the qspi using ‘dd’ when a customer triggers the update from balena-cloud. All this needs to happen in Linux for us and has been working very well until access to the QSPI flash has been restricted in L4T 35.2.1.
How can we change this firewall setting and allow /dev/mtd0 to be accessed and updated from Linux?
Sorry that it is not allowed to change this.
Hello @WayneWWW
Is there any description about the firewall settings in the documentation for the Jetson Linux 35.2.1? I am curious to know which other devices are also barred from accessing from the Linux like mtd is now.
There is no document for this. Sorry.
The initial flashing-over-USB process on Orin NX uses /dev/mtd0 and flash_erase. Clearly, to be able do this, it has read-write access to the QSPI, from Linux. However, whether (and how) the flashing process boots up the board with a different firewall configuration to allow for this, I do not know…
The difference is initrd flash is running RCM boot. mtd is available in this setup only.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.