Shared QSPI on i.Mx7-ULP

[quentincabrol]

Hello NXP team,

I had a question regarding the shared access to the QSPI memory on i.Mx7-ULP platform.

For this architecture, QSPI is used to store the M4 firmware that is loaded at startup.

The QSPI is flashed from u-boot or Linux runtime on A7 and then program is loaded by M4 upon restart.

What we would like is to use an address space of the qspi as a log (512ko or so) with the M4 writing to it in a circular buffer fashion and the A7 retrieving this log at Linux runtime. This is to avoid the overhead of having the A7 interrogating the M4 to retrieve the last logged data via eRPC.

qspi and sema42 examples are provided for the M4 side, so having the core writing at the end of the QSPI space shall hopefully not be too difficult.

Though, I could not find information regarding how this is handled from the Yocto side.

- Is it possible to lock/free that resource so to access read/write to a defined QSPI addresses space from both core in a secure fashion?

- How does the A7 handles the SEMA42 within Yocto ? 

- ... Or shall that be arbitrated via the RDC instead ?

Thank you in advance for your help.

[CarlosCasillas · Accepted solution]

Hi Quentin,

I have internally escalated your request, and below you could find what AE team has replied until now:

You can split QSPI memory region in two, and use one region to boot and other shared (accessible) by both cores. xRDC is the way you can do it. Boot region will be read-only and the other part will be RW. 

The issue here is if customer will execute code from Flash. In this case i.MX7ULP will do XiP (execute in place). This work for read access and it is the fastest way one can access flash. For this mode, accordingly with Validation team, there is no real way to use this same flash in RW access due to memory speed limitation. Validation team tested a lot of memory, which are supposed to allow concurrent mode (R + RW) and none of them are were able to work in concurrent mode with i.MX7ULP. It seems that even with fast memories the write routine will never access the memory (RW will use normal AIPS access, that is slow and lower priority). 

One possible solution here (it was not validated) is to have two memory ICs, one for RO and other for RW. 

Another solution is to execute code from TCM, or in case it is too short, customer can try to run at least the log routine via TCM.

I don't know how big and how often this log will be updated, but customer can try also a shared DDR region or RPMsging. Depends on application it can be viable. 

Hope this will be useful for you.
Best regards!
/Carlos
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

-------------------------------------------------------------------------------