I’m not explaining myself well apparently. Yes, I know that RAM is volatile and the contents are lost when I lose power. I’m not intending to use RAM as a non-voltage storage mechanism. That wouldn‘t make any sense. I’m trying to use the RAM disk as an IPC method to occasionally exchange file data between AMP CPU cores. The fact that it’s formatted FAT makes the metadata inherently ABI agnostic.
I have already written software that creates a RAM disk and formats it as a FAT partition. This runs on the ARM R5. Bare metal code. Not Linux. This is not hypothetical and I’m not asking how to do this. I’ve already written this and it already works. I’ve been using it for the past two years. I use the FatFS library so the contents are compliant to the FAT standard. I can “uncount“ the RAM disk and “remount” it again without formatting it and my file data is still there. Yes. Obviously, if I power it down, data is lost. I’m just saying that I can programmatically release all handles and stop accessing it, and come back to it later if I need to.
If you haven’t used FatFS, it’s a popular library in embedded systems for flash storage, but also supports RAM disk modes. The RAM disk is eventually a bit-for-bit copy of a FAT partition that you might see on a NOR flash device.
I’m running Linux on the ARM A53. The two CPU cores run in AMP mode so they are independent from one another. Both CPU cores share the same DDR controller but memory is partitioned such that they each have their own regions of memory, except for shared regions with a custom IPC method for data exchange. I also have software running on the A53 side with the two software packages communicating via the shared regions. For the most part, Linux is not aware of my code running on the R5 side And my R5 code is unaware of the Linux on the A53 side.
Again, the RAM disk already exists and is provided by the FatFS library. This RAM disk is fixed in physical memory. This is currently totally isolated to the R5. However, I COULD add an entry to the device tree and the Linux kernel to expose this memory where the RAM disk is to the A53 as a UIO memory region. If I did, the A53 COULD access the memory where the RAM disk actually is. Yes. The R5 creates that RAM disk LONG before Linux boots up on the A53.
So, to reiterate:
- A53 and R5 share the same DDR controller
- Linux runs on A53
- Bare metal running on R5
- RAM disk created by the R5 at a fixed physical memory address
- RAM disk memory address COULD be exposed to the A53
What I intend to do is add code to allow me to command the R5 to close all files and unmount the RAM disk, and trigger the A53 to mount the same RAM disk. It would be great if I could just add a device tree entry to expose the memory address such that Linux would expose it as a block device, then I could mount the device as a FAT file system. Then, after I’ve moved my large file data off the partition, I would command the A53 to uncounted it, and the R5 to remount it back again.
if there isn’t already a way to do this, I know I could write a driver myself to do this. I just don’t want to reinvent the wheel if somebody else has already done this. I’m an embedded systems engineer, not really a Linux kernel developer. What I would probably do, is use the same FatFS library in my user space code on the A53 Linux side to “mount” the RAM disk. That would work and I would be able to access the RAM disk from the A53, but only from my user space code. Having Linux mount it itself would be much more flexible. If I could just specify the RAM disk address rather than allocating the memory from heap, the FAT a file system would already be there, with the file data created by the R5.