Access RAM data externally (dual port ram)

Jay Aurabind jay.aurabind at gmail.com
Sat Aug 19 06:31:17 EDT 2017


Hi,

For a learning experiment, I'd like to access data in the RAM from an
external interface. Please advise me how to accomplish this in Linux.

The SoC is connected to external RAM that has two ports. Only one port
is connected to the SoC. The other port is connected to an FPGA which
is used as a hardware accelerator. FPGA has a high bandwidth access
directly to the SoC as well.

Once the SoC triggers an operation on the FPGA (via I/O mapped
memory), it is expected to read the input data from the RAM, process
it and write back the results data to RAM. Prior to triggering the
task, SoC will have to tell in advance where in the RAM the required
input data is (data's physical address in RAM). This is done so that
the latency can be avoided in copying the input data around (RAM <->
SoC <-> FPGA) because the input data may come via network or from a
local peripheral to the RAM. I'd like to reduce the latency by not
making the data go back to SoC and then to FPGA. Because even after
reaching FPGA, I might need to copy this data to FPGA's RAM. This will
unnecessarily increase the latency to trigger operations on FPGA. This
unnecessary copy overhead can be avoided if FPGA can directly read the
SoC's RAM and if both FPGA and SoC are using the same physical RAM.

When the userspace application runs (responsible for triggering the
operation), it will pass the address if input data to the kernel
driver which converts process's virtual address to physical address
(address in the RAM) and pass this information to FPGA. The FPGA can
then directly read the physical RAM address and start its job. Once
done, FPGA writes the results directly to RAM and notifies the SoC
about the location of the result in RAM, which is through the kernel
driver which converts RAM's physical address converted to virtual and
mapped to the process address space. I guess this sounds reasonable
when the input data is in the heap. If its in the stack, I'd have to
copy it to the heap I suppose.

I've learned that memory mappings for userspace processes may change,
so the physical address may not be valid indefinitely. But the
solution of using mlock() sounds reasonable to me.

I'd like to know the feasibility of the idea, and security implications, if any.


-- 

Thanks and Regards,
Jay



More information about the Kernelnewbies mailing list