Accessing mmc memory on imx8ulp from the m33 core

[Velin]

Hi everyone,
I’ve run into the need to store and read some data non-volatilely on the M33 core of the i.MX8ULP. If I understand correctly, this can be done using eMMC memory. On the A35 core I checked and found about 8 GB of memory, of which only around 1 GB is used.
How I checked available memory:

root@fsimx8ulp:/sys/block# fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 7456 MB, 7818182656 bytes, 15269888 sectors
119296 cylinders, 4 heads, 32 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/mmcblk0p1 * 128,0,1 1023,3,32 16384 186775 170392 83.1M c Win95 FAT32 (LBA)
/dev/mmcblk0p2 1023,3,32 1023,3,32 196608 1917045 1720438 840M 83 Linux
root@fsimx8ulp:/sys/block#

How can I write something into this free space from the M33 when the A35 core is in suspend-to-RAM mode or not running at all? Are there any examples?
Or is there another mechanism for non-volatile data storage without relying on external devices?

Thanks in advance for any advice.

[Bio_TICFSL]

Hello,

Based on your inquiry about accessing eMMC memory from the M33 core on the i.MX8ULP, I can provide the following guidance:

For non-volatile storage access from the M33 core when the A35 is in suspend-to-RAM mode or not running, you have several options:

1. The i.MX8ULP does not support direct eMMC access from the M33 core. The eMMC is primarily accessible through uSDHC0 and is designed to be controlled by the A35 core.

2. For data exchange between cores, you can implement communication using the RPMsg (Remote Processor Messaging) framework. This allows the M33 core to request data from the A35 core, which can access the eMMC storage.

3. If you need direct non-volatile storage for the M33 without relying on the A35 core, consider these alternatives:
- Use internal on-chip memory that's available to the M33
- Connect external non-volatile memory to an interface accessible by the M33 (like SPI flash)

4. For your specific use case, if the A35 core is in suspend-to-RAM mode, the M33 core has the capability to wake up the A35 when needed to access eMMC storage. This approach is documented in the reference manual and would maintain your power optimization goals.

The remoteproc framework is recommended for implementing the communication between the M33 and A35 cores. You can find examples of this implementation in the MCUXpresso SDK examples repository.

Regards

[Velin]

Thanks for the quick response.
I’ve looked into using RPMsg, but it’s not quite what I’m aiming for. As you mentioned, it would require waking up the A35 core from sleep mode, and I’d prefer to avoid that if possible—based on my measurements, this process takes about half a second, which is too long for my use case. The third option you suggested seems the most promising. Could you share more details about the on-chip memory that's available to the M33? What mechanisms are available for interacting with it?