I have a gray scale video file with resolution of 1920x1080 and want to playback this file at 100Hz. My idea is allocate a bunch of buffer and every 10ms, sequentially assigning the address of the buffer to the dma. The problem with this is that I ran out of memory after creating 250 buffers. I have an external RAM of 4GB and intend to use it to store the frames of the video file. Anyone has any idea of how to modify the xlnk library so that it allocate memory in this external RAM?
Is the external 4GB RAM under control of Linux? i.e. Have you modified the device tree to include that memory space?
Secondly if not is the external RAM addressable from the ARM? i.e is it hooked up to one of the AXI master ports with a configured address range.
Under Linux Control
Add another entry to the device-tree along the lines of the one here adding the external DMA engine’s address pool to the CMA pool. Xlnk will then allocate in both banks. Note that the base overlay assumes that all buffers are in the lower 4G range so this may break parts of the base overlay.
Not Under Linux Control but addressable
You can use the pynq.MMIO class to map the entire external memory range into your process and then use the the .buffer attribute to get access to a Python buffer for the memory. From here you can create your own allocator which takes frame-sized sections of the buffer and returns PynqBuffers which the appropriate physical address and buffer.
Not Under Linux Control and not addressable
You’ll be rolling your own allocator as option 2 but this time you’ll want a custom class that mimics the PynqBuffer so you don’t need to allocate shadow buffers for each frame. You need to provide physical_address. cacheable, and size properties on your custom class.
Alternatively you can use PynqBuffer as above but just create one in-memory frame to act as the backing store for all of your external frames.
Other considerations
Also be aware that are VDMA driver doesn’t handle greater than 32-bit addressing at present so you may need to change how the frame lists are handled here to use 64-bit wide rather than 32-bit registers.
Peter