Cyclone V Frame Buffer II - problem with device Tree and with understanding the address map

Question

Hi, I’m trying to display something via VGA on linux system without desktop (the final goal is to launch Qt app writing to /dev/fb). I’m confused about how to instantiate Frame Buffer II (alt_vip_cl_vfb) in the device tree, and the main problem is the reg property. This is my qsys project which compiles without errors.

Primarily, I don’t know what the size should be, but I’m not sure about the address too. I assume that it would be something like reg = &lt;0x30000000 correct_size&gt;;. To me, as I’m a newbie, the documentation of Frame Buffer is poor.
The second problem is that I’m confused about mapping FPGA masters connected to FPGA-to-HPS bridge. Is the address 0x30000000 correct, regarding that RAM ranges from 0x0 to 0x40000000 ?
I can’t find any example of using Frame Buffer II on Cyclone V SoC with Linux.I’m asking for help.

aikeu · Answer

Hi JakeJ,You can refer to this document for more details. https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_vip.pdfI cant see your qsys design from the blur pic. Anyway The address of your frame buffer II IP will be based on it's base address in your qsys desgin, it can be manual or auto assigned in platform designer as long as it does not overlapped with the address range used by other IP in the design. The register control address of a particular IP is the offset from it's base address, example base address + offset address.Thanks.Regards,Aik Eu

jakej · Answer

Hi @aikeu , thank you for response. I don't know what's the cause of blurring - the problem doesn't occur on my side and the picture is sharp. Anyway, I made some changes since last time. I connected control registers to lightweight HPS-to-FPGA bridge at offset 0 - so the base address is ff200000 - and I configured framebuffer IP as Frame Reader only.
This is the current qsys project:

the address map:

and the device tree:

The problem is presented below:
[    5.541922] Unable to handle kernel NULL pointer dereference at virtual address 00000160
[    5.550015] pgd = (ptrval)
[    5.552717] [00000160] *pgd=00000000
[    5.556348] Internal error: Oops: 5 [#1] SMP ARM
[    5.560963] Modules linked in: altvipfb2_drv(+) cfbfillrect cfbimgblt cfbcopyarea
[    5.568447] CPU: 0 PID: 87 Comm: udevd Not tainted 5.12.0-altera #1
[    5.574695] Hardware name: Altera SOCFPGA
[    5.578691] PC is at dma_alloc_attrs+0x38/0x128
[    5.583223] LR is at altvipfb2_probe+0x74/0xccc [altvipfb2_drv]
[    5.589145] pc : [&lt;c019a690&gt;]    lr : [&lt;bf0133a8&gt;]    psr: 600d0013
[    5.595387] sp : c1dcbb98  ip : c1dcbbd0  fp : c1dcbbcc
[    5.600592] r10: c1a042ac  r9 : bf015014  r8 : c1a04128
[    5.605795] r7 : c1245c10  r6 : c1245c10  r5 : 00000cc0  r4 : 00000000
[    5.612295] r3 : 00000000  r2 : c1a04128  r1 : 0012c000  r0 : 00000000
[    5.618797] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    5.625917] Control: 10c5387d  Table: 01f4804a  DAC: 00000051
[    5.631663] Process udevd (pid: 87, stack limit = 0x(ptrval))

[    5.935027] Backtrace: 
[    5.937469] [&lt;c019a658&gt;] (dma_alloc_attrs) from [&lt;bf0133a8&gt;] (altvipfb2_probe+0x74/0xccc [altvipfb2_drv])
[    5.947030]  r8:f0821000 r7:c1245c10 r6:c1245c10 r5:00000000 r4:c1a04040
[    5.953702] [&lt;bf013334&gt;] (altvipfb2_probe [altvipfb2_drv]) from [&lt;bf013198&gt;] (altvipfb2_plat_probe+0x178/0x23c [altvipfb2_drv])
[    5.965159]  r10:00000004 r9:bf015014 r8:ef7f6d5c r7:00000000 r6:c1245c10 r5:c1245c00
[    5.972954]  r4:c1a04040
[    5.975476] [&lt;bf013020&gt;] (altvipfb2_plat_probe [altvipfb2_drv]) from [&lt;c061b024&gt;] (platform_probe+0x6c/0xc8)
[    5.985290]  r8:00000000 r7:c0dda024 r6:bf015014 r5:c1245c10 r4:00000000
[    5.991962] [&lt;c061afb8&gt;] (platform_probe) from [&lt;c0618520&gt;] (really_probe+0xf4/0x4b8)
[    5.999773]  r7:c0dda024 r6:00000000 r5:c0dda01c r4:c1245c10
[    6.005407] [&lt;c061842c&gt;] (really_probe) from [&lt;c0618950&gt;] (driver_probe_device+0x6c/0xc4)
[    6.013565]  r10:00000024 r9:c1dcbf30 r8:c1e88e48 r7:bf015014 r6:c1245c54 r5:bf015014
[    6.021360]  r4:c1245c10
[    6.023882] [&lt;c06188e4&gt;] (driver_probe_device) from [&lt;c0618fc4&gt;] (device_driver_attach+0xb8/0xc0)
[    6.032727]  r5:00000000 r4:c1245c10
[    6.036286] [&lt;c0618f0c&gt;] (device_driver_attach) from [&lt;c061905c&gt;] (__driver_attach+0x90/0x120)
[    6.044874]  r7:c0d800f0 r6:c1245c10 r5:bf015014 r4:00000000
[    6.050509] [&lt;c0618fcc&gt;] (__driver_attach) from [&lt;c06161a0&gt;] (bus_for_each_dev+0x88/0xd0)
[    6.058663]  r7:c0d800f0 r6:c0618fcc r5:bf015014 r4:00000000
[    6.064298] [&lt;c0616118&gt;] (bus_for_each_dev) from [&lt;c0617dbc&gt;] (driver_attach+0x2c/0x30)
[    6.072278]  r6:00000000 r5:c1e88480 r4:bf015014
[    6.076875] [&lt;c0617d90&gt;] (driver_attach) from [&lt;c061774c&gt;] (bus_add_driver+0x108/0x1f0)
[    6.084854] [&lt;c0617644&gt;] (bus_add_driver) from [&lt;c0619ba4&gt;] (driver_register+0x98/0x128)
[    6.092922]  r7:00000000 r6:ffffe000 r5:00000000 r4:bf015014
[    6.098556] [&lt;c0619b0c&gt;] (driver_register) from [&lt;c061ad28&gt;] (__platform_driver_register+0x2c/0x34)
[    6.107576]  r5:bf018000 r4:c0daed60
[    6.111135] [&lt;c061acfc&gt;] (__platform_driver_register) from [&lt;bf018028&gt;] (altvipfb2_driver_init+0x28/0x1000 [altvipfb2_drv])
[    6.122236] [&lt;bf018000&gt;] (altvipfb2_driver_init [altvipfb2_drv]) from [&lt;c01021bc&gt;] (do_one_initcall+0x68/0x260)
[    6.132301] [&lt;c0102154&gt;] (do_one_initcall) from [&lt;c01c0b80&gt;] (do_init_module+0x70/0x2a4)
[    6.140372]  r7:00000000 r6:00000002 r5:c11dab80 r4:bf015100
[    6.146006] [&lt;c01c0b10&gt;] (do_init_module) from [&lt;c01c3368&gt;] (load_module+0x2498/0x29a4)
[    6.153988]  r6:00000002 r5:c1e88e00 r4:00000002
[    6.158585] [&lt;c01c0ed0&gt;] (load_module) from [&lt;c01c3acc&gt;] (sys_finit_module+0xc8/0x104)
[    6.166483]  r10:0000017b r9:c1dca000 r8:c0100264 r7:0000017b r6:0000000c r5:b6e757ac
[    6.174278]  r4:00000000
[    6.176800] [&lt;c01c3a04&gt;] (sys_finit_module) from [&lt;c0100060&gt;] (ret_fast_syscall+0x0/0x58)
[    6.184951] Exception stack(0xc1dcbfa8 to 0xc1dcbff0)
[    6.189985] bfa0:                   004ce1a0 00000000 0000000c b6e757ac 00000000 004d6e38
[    6.198131] bfc0: 004ce1a0 00000000 00000000 0000017b 00020000 004d6e38 00000000 00000000
[    6.206273] bfe0: becb4d40 becb4d30 b6e6d254 b6df0220
[    6.211305]  r6:00000000 r5:00000000 r4:004ce1a0
[    6.215906] Code: e1a08002 e5933000 e50b3028 e3a03000 (e5946160) 
[    6.222018] ---[ end trace 1b5948a3b2f7d597 ]---
[    6.233084] udevd[82]: worker [87] terminated by signal 11 (Segmentation fault)
[    6.244373] udevd[82]: worker [87] failed while handling '/devices/platform/soc/ff200000.vip'

I have some doubts about Frame buffer memory base address property in IP configuration. I don't know what I should be guided by when adjusting its value.

Thanks.
Regards,
Jake

aikeu · Answer

Hi Jakej,I am using the example design shown in the link below to describe to you regarding how the address works for frame buffer IP:https://fpgacloud.intel.com/devstore/platform/1986/Normally for the frame buffer will get the data from some memory location which determined by the user, example from ddr4 in the qsys design shown in the pic below.The Frame buffer will get the image data from the ddr4, therefore the frame buffer memory base address must follow the based address of the location which stores your image data.The frame buffer IP will not have a base address unless you require to control it's register settings during run time. If there is no requirement to make changes during run time, then set the frame buffer IP settings in the qsys will do for your design.You can enable the Run-time writer control shown in the example pic below. The details of the control handling will relates back to the document regarding frame buffer IP.Hopefully it helps.Thanks.Regards,Aik Eu

aikeu · Answer

Repost previous comments:
Hi Jakej,
 
I am using the example design shown in the link below to describe to you regarding how the address works for frame buffer IP:
https://fpgacloud.intel.com/devstore/platform/1986/
 
Normally for the frame buffer will get the data from some memory location which determined by the user, example from ddr4 in the qsys design shown in the pic below.
The Frame buffer will get the image data from the ddr4, therefore the frame buffer memory base address must follow the based address of the location which stores your image data.

The frame buffer IP will not have a base address unless you require to control it's register settings during run time.
If there is no requirement to make changes during run time, then set the frame buffer IP settings in the qsys will do for your design.
You can enable the Run-time writer control shown in the example pic below. The details of the control handling will relates back to the document regarding frame buffer IP.

Hopefully it helps.
 
Thanks.
Regards,
Aik Eu

aikeu · Answer

Repost previous comments:
Hi Jakej,
 
I am using the example design shown in the link below to describe to you regarding how the address works for frame buffer IP:
https://fpgacloud.intel.com/devstore/platform/1986/
 
Normally for the frame buffer will get the data from some memory location which determined by the user, example from ddr4 in the qsys design shown in the pic below.
The Frame buffer will get the image data from the ddr4, therefore the frame buffer memory base address must follow the based address of the location which stores your image data.

The frame buffer IP will not have a base address unless you require to control it's register settings during run time.
If there is no requirement to make changes during run time, then set the frame buffer IP settings in the qsys will do for your design.
You can enable the Run-time writer control shown in the example pic below. The details of the control handling will relates back to the document regarding frame buffer IP.