Part Number: AM62L


This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: AM62L


Hello, Hong-san.
Thank you for your reply.
Could you please update me on the progress?
Best regards,
Takayuki
Hello Takayuki-san,
For ospi-nor, read performance is generally scalable proportionally with the interface clock, but on write, while you can speed up the command and data transfer phases by increasing the clock frequency, the actual programming time remains constant. This is why NOR flash write performance doesn't scale linearly with clock frequency beyond a certain point.
Are you using the Linux kernel driver on the specific MRAM device? or you're using the generic Linux kernel cadence qspi-nor driver?
If the generic qspi-nor driver is used, kernel drive might poll the busy signal or bit, but MRAM doesn't have busy signal or bit on write. That may explain the MRAM write performance vs the clock frequency you observed on your testing.
Best,
-Hong
Hello Hong-san,
Thank you for the reply.
We're using the modified generic cadence qspi-nor driver.
Is it possible to stop the busy signal or bit polling to reduce the write time?
Best Regards,
Takayuki
Hello Takayuki-san,
We don't have the HW setup connecting the MRAM device with the OSPI controller.
I'd recommend getting in touch with the MRAM device vendor on feasibility & how to adapt spi-cadence-quadspi.c driver to improve the write performance on the MRAM device in response to the scaled clock frequency on your board.
Best,
-Hong