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 = <0x30000000 correct_size>;. 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.
Link Copied
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 : [<c019a690>] lr : [<bf0133a8>] 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] [<c019a658>] (dma_alloc_attrs) from [<bf0133a8>] (altvipfb2_probe+0x74/0xccc [altvipfb2_drv])
[ 5.947030] r8:f0821000 r7:c1245c10 r6:c1245c10 r5:00000000 r4:c1a04040
[ 5.953702] [<bf013334>] (altvipfb2_probe [altvipfb2_drv]) from [<bf013198>] (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] [<bf013020>] (altvipfb2_plat_probe [altvipfb2_drv]) from [<c061b024>] (platform_probe+0x6c/0xc8)
[ 5.985290] r8:00000000 r7:c0dda024 r6:bf015014 r5:c1245c10 r4:00000000
[ 5.991962] [<c061afb8>] (platform_probe) from [<c0618520>] (really_probe+0xf4/0x4b8)
[ 5.999773] r7:c0dda024 r6:00000000 r5:c0dda01c r4:c1245c10
[ 6.005407] [<c061842c>] (really_probe) from [<c0618950>] (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] [<c06188e4>] (driver_probe_device) from [<c0618fc4>] (device_driver_attach+0xb8/0xc0)
[ 6.032727] r5:00000000 r4:c1245c10
[ 6.036286] [<c0618f0c>] (device_driver_attach) from [<c061905c>] (__driver_attach+0x90/0x120)
[ 6.044874] r7:c0d800f0 r6:c1245c10 r5:bf015014 r4:00000000
[ 6.050509] [<c0618fcc>] (__driver_attach) from [<c06161a0>] (bus_for_each_dev+0x88/0xd0)
[ 6.058663] r7:c0d800f0 r6:c0618fcc r5:bf015014 r4:00000000
[ 6.064298] [<c0616118>] (bus_for_each_dev) from [<c0617dbc>] (driver_attach+0x2c/0x30)
[ 6.072278] r6:00000000 r5:c1e88480 r4:bf015014
[ 6.076875] [<c0617d90>] (driver_attach) from [<c061774c>] (bus_add_driver+0x108/0x1f0)
[ 6.084854] [<c0617644>] (bus_add_driver) from [<c0619ba4>] (driver_register+0x98/0x128)
[ 6.092922] r7:00000000 r6:ffffe000 r5:00000000 r4:bf015014
[ 6.098556] [<c0619b0c>] (driver_register) from [<c061ad28>] (__platform_driver_register+0x2c/0x34)
[ 6.107576] r5:bf018000 r4:c0daed60
[ 6.111135] [<c061acfc>] (__platform_driver_register) from [<bf018028>] (altvipfb2_driver_init+0x28/0x1000 [altvipfb2_drv])
[ 6.122236] [<bf018000>] (altvipfb2_driver_init [altvipfb2_drv]) from [<c01021bc>] (do_one_initcall+0x68/0x260)
[ 6.132301] [<c0102154>] (do_one_initcall) from [<c01c0b80>] (do_init_module+0x70/0x2a4)
[ 6.140372] r7:00000000 r6:00000002 r5:c11dab80 r4:bf015100
[ 6.146006] [<c01c0b10>] (do_init_module) from [<c01c3368>] (load_module+0x2498/0x29a4)
[ 6.153988] r6:00000002 r5:c1e88e00 r4:00000002
[ 6.158585] [<c01c0ed0>] (load_module) from [<c01c3acc>] (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] [<c01c3a04>] (sys_finit_module) from [<c0100060>] (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
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
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
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
Add in missing pic:
Hi @aikeu
I finally got it working. The problem presented previously (with memory allocation during kernel module initialization) disappeared when I switched to linux 5.4-lts version - I had been using 5.12 or 5.11 before. Then I read IP's documentation more carefully and I realized that another blocks are needed. Now I have to generate SDK for Qt in Yocto and try to write some app.
Current Platform Designer project looks like this (maybe it will help someone):
Thanks.
Regards,
Jake
