Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


IP features2018.12018.22018.32019.12019.22020.12020.2
IP version2.

Streaming Video Formats supported

RGB, RGBA, YUV 4:4:4, YUVA 4:4:4, YUV 4:2:2, YUV 4:2:0
Color Formats supported

Video Formats with per Pixel Alpha (valid only for Framebuffer Read)


Support for 8 bit Video Formats


Support for 10 bit Video Formats

RGBX10, YUVX10, Y_UV10,Y_UV10_420,Y10

Video Formats with per Pixel Alpha (valid only for Framebuffer Read)


Support for 8 bit Video Formats


Support for 10 bit Video Formats

RGBX10, YUVX10, Y_UV10,Y_UV10_420,Y10

Support for 12 bit Video Formats

RGBX12, YUVX12, Y_UV12, Y_UV12_420, Y12

Driver supports only RGBX12.

Support for 16 bit Video Formats

RGB16, YUV16, Y_UV16, Y_UV16_420, Y16.

Driver supports only RGB16

Supports progressive and interlaced video

IP supported both progressive and interlaced

Driver only supported progressive

IP and Driver both support progressive and interlaced video

Maximum and Minimum spatial resolution

Max 8192x4320

Min 64 x 64

Max 10328 x 7760 (Driver tested for standard resolutions up to 8K only)

Min 64 x 64

Pixel per clock1,2,4 ppc

1,2,4 and 8 ppc in IP

Driver supports only 1,2,4

Driver supports 1, 2, 4 and 8 ppc

Missing Features / Known Issues / Limitations in Driver

  • Tested for standard resolutions up to 8K
  • YUV 12 and 16 bpc color formats support added in IP in 2019.1 but are not supported in driver in 2019.1.
  • The first buffer returned by the driver will contain the second frame contents, after this the driver will correctly give the data
  • When DMA operations are initiated by a client, the hardware is placed into "autorestart" mode. When the last buffer has been returned to the client as "completed", if the client does not supply a new write/read buffer location or fails to halt the driver, then the last buffer location written to will continue to be utilized by the driver. In effect, the driver will "spin" on the last location programmed.
  • For 2020.2, the field id reported in the IP register may be incorrect due to bug in IP / Vitis HLS tool.

Kernel Configuration

The driver must be enabled in the kernel by selecting option CONFIG_XILINX_FRMBUF

Device Tree Binding

Complete documentation on the device tree requirements may be found in the Linux source located at xilinx_frmbuf.txt

Testing Procedure

To ensure the Framebuffer Write IP Linux driver has been configured to work properly, a suitable test design will require an input source (i.e. HDMI Rx) connected to the Framebuffer.
Once properly configured, the design can be tested via the tool known as "yavta". yavta may be found here.

To run yavta, data must be streaming into your media pipeline. To verify the status of your media pipleline, run the tool known as "media-ctl":
Code Block
root@hdmi_proj:~# media-ctl -p
Media controller API version 0.1.0
Media device information
driver          xilinx-video
model           Xilinx Video Composite Device
bus info
hw revision     0x0
driver version  0.0.0
Device topology
- entity 1: vcap_hdmi output 0 (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
        pad0: Sink
                <- "a0000000.v_hdmi_rx_ss":0 [ENABLED]
- entity 5: a0000000.v_hdmi_rx_ss (1 pad, 1 link)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
        pad0: Source
                [fmt:UYVY/1920x1080 field:none]
                [dv.caps:BT.656/1120 min:0x0@25000000 max:4096x2160@297000000 stds:CEA-861,DMT,CVT,GTF caps:progressive,reduced-blanking,custom]
                [dv.detect:BT.656/1120 1920x1080p60 (2200x1125) stds:CEA-861 flags:CE-video]
                -> "vcap_hdmi output 0":0 [ENABLED]
In the above example, entity 5 represents the HDMI Rx input source which happens to be receiving YUYV-based media at 1080p resolution. The Video Framebuffer driver is managed/controlled by a V4L2 "client" driver represented by entity 1. The above pipeline is suitable for capturing and writing to memory any of the supported YUV 8-bit formats (e.g. YUYV, NV16 or NV16M).

A frame capture to local binary files can now be performed using the yavta tool:

Code Block
root@hdmi_proj:~# yavta -c10 -f YUYV -s 1920x1080 --skip 7 -F /dev/video0 &&
[2] 2362
Device /dev/video0 opened.
Device `vcap_hdmi output 0' on `platform:vcap_hdmi:0' is a video output (without mplanes) device.
Video format set: YUYV (56595559) 1920x1080 field n[ 1393.139514]
one, 1 planes:
 * Stride 3840, buffer size 4147200
[ 1393.747654] xhdmi_s_stream enable = 0
Captured 10 frames in 0.289203 seconds (34.577689 fps, 0.000000 B/s).
8 buffers released.
[2]-  Done                    yavta -c10 -f YUYV -s 1920x1080 --skip 7 -F /dev/video0
root@hdmi_proj:~# ls
frame-000007.bin  frame-000008.bin  frame-000009.bin
The above command syntax specifies 10 frames to capture (-c10) writing to memory in packed YUYV format (-f YUYV) with 1920x1080 dimensions (-s 1920x1080) and to only write out the last 3 frames captured to a file (--skip 7). These instructions are sent to the file descriptor which represents the V4L2 driver controlling, ulimately, the Video Framebuffer (-F /dev/video0).


  • AR68765 - LogiCORE Video Frame Buffer Write - Release Notes and Known Issues for the Vivado 2017.1 tool and later versions

Change Log



  • Summary
    • Add support 8 ppc
  • Commits
    • bb91ad8 dmaengine: xilinx: frmbuf: Add support for 8 ppc


  • Summary
    • Add support for low latency capture
  • Commits
    • 107831e v4l: xilinx: dma: Use early callback mode for low latency capture
    • 9308da3 Revert "Revert "dma: xilinx: Release buffers before DMA transfer""
    • 4036801 Revert "dma: xilinx: Release buffers before DMA transfer"