Hi：
We have a special requirement: after the file system is booted and the normal system is entered, can we program the QSPI flash via /dev/mtd0?
Are there any relevant methods?
Hi pengyang1,
/dev/mtd0 can only be accessed in recovery kernel.
Could you try to boot into recovery kernel through UEFI menu?
KevinFFF:
Current phenomenon：
During normal boot, mtd_debug can be used to erase and write data, but cannot read data correctly.
Only when booting the initrd system in RCM (0955:7026) mode, data can be read via mtd_debug.
Does this align with our design expectations?
Yes, these behaviors should be expected.
If you want to access the QSPI, please boot into RCM.
Got it.
So Can we understand it this way:
normal system is running: Data can be correctly written to the SPI flash, but not be read
RCM mode: Reading and writing operations can both be performed normally.
It is correct.
It may be incorrect.
There may be no /dev/mtd0 in normal boot. How did you verify this?
on our board:
mi@tegra-ubuntu-mos:~$ ls /dev/mtd0
/dev/mtd0
mi@tegra-ubuntu-mos:~$ ls /sys/class/mtd/
mtd0 mtd0ro
mi@tegra-ubuntu-mos:~$ cat /proc/mtd
dev: size erasesize name
mtd0: 04000000 00001000 “spi5.0”
mi@tegra-ubuntu-mos:~$
In the normal system, I use mtd_debug erase/write to write to a certain partition, then use mtd_debug read to read it back. Each time the read content is different and not the value that was written. Therefore, I judge that mtd_debug read cannot be used in the normal system.
However, in the RCM system, when I use mtd_debug read, the value read is exactly what was written via mtd_debug erase/write in the normal system.
So I conclude that the normal system allows writing, but not reading.
Does this verification align with our design?
Thanks.
I would suggest do not perform the QSPI read/write in “normal system”.
Please always do that in RCM boot.
KevinFFF:
Are there any restrictions on the QSPI flash? Or is it possible to lift such restrictions? We indeed need to read and write the QSPI flash in the normal system.
Most partitions on QSPI are used for the booting.
May I know what do you want to read/write the content on QSPI in normal system?
Could you elaborate on your use case and the exact data you want to update on QSPI?
Because we want to update the content on the QSPI partitions via OTA while the system is running (e.g., UEFI, bootloader, etc.).
Background: When updating the Bootloader in UEFI, it takes too long (about 5 minutes), and our system has no external display. Therefore, users cannot see any output from the system.For this reason, we want to adopt the solution used in the previous Orin project: updating the Bootloader via OTA during system runtime using the nv_update_engine method.
I’ve raised another question： Does the Thor platform support updating the bootloader via nv_update_engine?
It seems we do not officially support this use case.
Do you mean that you have implemented it on Orin?
To update the bootloader, we suggest and support using capsule update.
The actual bootloader update happens in UEFI.
Kevin:
If the official side does not support nv_update_engine and the upgrade can only be performed via the CAP file in UEFI,
can our team support the read and write operations of /dev/mtd0 in the normal system? At present, we can already write to it in the normal system, but the data read out is incorrect.
Could you please provide support for this issue, or should I create a new topic for it?
No, when it boots to fs, /dev/mtd0 is disable in UEFI.
I’ve checked this with internal team.
Direct QSPI access is unsafe because the hardware is concurrently shared with the UEFI Secure World, leading to potential conflicts with the OS. Additionally, leaving the QSPI exposed to the system undermines security and makes the bootloader vulnerable to corruption.
As a result, please do it in RCM mode instead.
In addition, may I know what’s your use case to access QSPI in runtime?
Kevin:
Our objective is to directly flash the QSPI flash in the normal system, instead of performing OTA updates via CAP packages. This is a custom function we have implemented.
Currently, we have indeed achieved the ability to write to /dev/mtd0 in the normal system (we can read the QSPI flash in RCM mode, and the data is correct). However, we are still unable to read from it in the normal system. Setting aside the various risks you mentioned earlier, could you help us clarify whether it is possible to read the QSPI flash in the normal system?
This feature research is great importance to us.
Looking forward to your response. Thank you very much.
What’s your customization to get this node(i.e. /sys/class/mtd/mtd0) as I don’t see this node on the Thor devkit?
It seems a feature request to us.
Please share the full changes and steps that you’ve implemented before.
We have not made any modifications on our side（ I need to check this again.）— the device node already exists on our board.
We then used the mtd_debug command to verify read and write operations, and found that we can perform write operations, but cannot perform read operations.
I’ve checked again that I don’t get /sys/class/mtd/mtd0 on the Thor devkit flashed with Jetpack 7.0GA(r38.2.1).
Please check why this node exists in your case.
Alright, I am currently investigating why this device node exists.
Given the urgency of the project, could we work on this in parallel and grant us the read and write permissions for this node?
I think you have some customization in UEFI to get that node appears.
Okay, I’m also checking with internal team if there’s possible method to access and update QSPI in runtime.