Access RAM data externally (dual port ram)

[Jay Aurabind]

On 24 August 2017 at 09:37, kipade <kipade at 163.com> wrote:
> I think the linux OS can access all ram devices connected to the SOC
> where linux running on.
> For the ram bank owned by FPGA, the linux OS will reserve it from random
> allocating in
> kernel and user spaces, however, it still can access the reserved memory
> via map operation
> if needed.

Thank you for the response.

Intention is to use a dual port RAM. There is no specific bank I'd
like to separately allocate to FPGA. Whole of the RAM is accessible
physically to both FPGA and CPU. Is this feasible to implement ?

>
> 在 2017/8/19 下午6:31, Jay Aurabind 写道:
>> 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.
>>
>>
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 

Thanks and Regards,
Aurabindo J