Is it possible mount a FAT formatted ramdisk at a specific address? I am running Linux on the A53 cores on a Zynq Ultrascale and running my own code on the R5’s with the FatFS library mounted as a RAM disk on the R5 side. I can unmount the FAT RAM disk and make the memory available to Linux on the A53 via UIO or shared memory. The memory at that address is identical to a Flash device formatted as a FAT partition. It is fully compliant with the FAT standard. It’s just in RAM. Is there already a driver that I can use to mount it on the Linux side?
#!/bin/bash
# Set the size of the RAM disk (adjust this according to your needs)
ram_disk_size_mb=5120
# Mount point for the RAM disk
mount_point="/mnt/ramdisk"
# Check if the mount point already exists
if [ ! -d "$mount_point" ]; then
mkdir "$mount_point"
fi
# Create the RAM disk with the specified size
mount -t tmpfs -o size="${ram_disk_size_mb}M" tmpfs "$mount_point"
# Format the RAM disk as VFAT (FAT32)
mkfs.vfat "$mount_point"
# Print success message
echo "RAM disk created and formatted as VFAT at $mount_point."
# Set the size of the RAM disk (adjust this according to your needs)
ram_disk_size_mb=5120
# Mount point for the RAM disk
mount_point="/mnt/ramdisk"
# Check if the mount point already exists
if [ ! -d "$mount_point" ]; then
mkdir "$mount_point"
fi
# Create the RAM disk with the specified size
mount -t tmpfs -o size="${ram_disk_size_mb}M" tmpfs "$mount_point"
# Format the RAM disk as VFAT (FAT32)
mkfs.vfat "$mount_point"
# Print success message
echo "RAM disk created and formatted as VFAT at $mount_point."
Last edited:
But how do I specify the address? The point is the R5 formatted a FAT RAM disk at a specific address and I want to mount that FAT RAM disk on the A53 side. I need to specify the address and have it mount without formatting. It’s already formatted and populated.
Assigning a specific RAM address for a RAM disk is generally not a straightforward task, especially in a high-level language like Bash. The memory management and address allocation are usually handled by the operating system, and it's not recommended to manually control RAM addresses for regular user-level applications.
However, if you have a specific use case or hardware requirement that demands assigning a specific RAM address for a RAM disk, you might need to develop a custom kernel module or low-level programming approach, which is beyond the scope of a simple Bash script.
Keep in mind that manually managing memory addresses can be risky and may lead to system instability or crashes if not done correctly. It's crucial to have a good understanding of the underlying hardware and operating system's memory management mechanisms if you intend to pursue such an approach.
In most cases, using a RAM disk without explicitly controlling the RAM address will be sufficient and is considered the standard and safer way to work with RAM disks. The operating system will take care of efficiently utilizing available RAM and managing RAM disk operations.
However, if you have a specific use case or hardware requirement that demands assigning a specific RAM address for a RAM disk, you might need to develop a custom kernel module or low-level programming approach, which is beyond the scope of a simple Bash script.
Keep in mind that manually managing memory addresses can be risky and may lead to system instability or crashes if not done correctly. It's crucial to have a good understanding of the underlying hardware and operating system's memory management mechanisms if you intend to pursue such an approach.
In most cases, using a RAM disk without explicitly controlling the RAM address will be sufficient and is considered the standard and safer way to work with RAM disks. The operating system will take care of efficiently utilizing available RAM and managing RAM disk operations.
RAM can't do that. Every time you turn your computer off or reset, whatever is in RAM gets erased.
There is NVRAM and ROM, but that's a different animal.
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:
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.
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.
Last edited:
