Access RAM data externally (dual port ram)

Access RAM data externally (dual port ram)

[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.


-- 

Thanks and Regards,
Jay

Access RAM data externally (dual port ram)

[kipade]

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.

? 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.
>
>

Access RAM data externally (dual port ram)

[Jay Aurabind]

On 24 August 2017 at 09:37, kipade <kipade@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

Access RAM data externally (dual port ram)

[Yann Droneaud]

Hi,

Le samedi 19 ao?t 2017 ? 16:01 +0530, Jay Aurabind a ?crit :

> 
> 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.
> 
> 

That's sound a lot like InfiniBand / RDMA. Have a look at this
subsystem.

You would have to take care of the "cachability" of the memory you want
to use from Linux and FPGA sides. (Look for "coherent" memory mapping).

Regards.

-- 
Yann Droneaud
OPTEYA