What frame buffer address should I use for the vip framebuffer II parameter?

BMart12 · ‎07-16-2019

I instantiated the vip framebuffer II with the default address of 0x00000000. I am using the Tearsic DE10-Standard development board and Quartus 18.1 standard. I wrote a test program for Linux to exercise an LCD. I connected the framebuffer to the clocked video output IP block. I am wondering if the parameter buffer address is replaced by the frame address I set at run time. The screen goes black when the program presents the address to the framebuffer core.

CheePin_C_Intel · ‎07-17-2019

Hi Ben, As I understand it, you seems to have some inquiries related to the Frame Buffer addressing. Sorry, would you mind to further elaborate on your issue observation? Probably some screenshots and details on the address writing procedure will be helpful. Mind share with me the high level VIP system setup of yours? ie TPG -> FB II -> CVO? Just would like to check with you if you have had a chance to perform a Modelsim simulation with your VIP design to isolate any functional issue prior to hardware testing? Not sure if this is relevant to your case, specific to Qsys system addressing, each of the component in the Qsys system will have its own base address. To access the specific component ie Frame Buffer, you will need to check the base address in the system. Please let me know if there is any concern. Thank you. Best regards, Chee Pin

BMart12 · ‎07-17-2019

Hi Chee, Thank you for responding. I provide you with the background leading up to my questions: I am using the Terasic DE10-Standard development board. I am trying to implement an LCD display which is what will be used in our target board. Here is what I have done so far: I used the sample project from the CD located at DE10-Standard_v.1.2.8_SystemCD\Demonstration\SoC_FPGA\ControlPanel\Quartus. I updated the IP to 18.1 since that is the version of Quartus I am using. I implemented a QSYS/Platform Designer test case using the VIP test pattern generator and the clocked video output to validate the connection to the LCD hardware. The LCD is 640 x 480 x 3 bytes per pixel running at 25.2 MHz. This implementation generates the color bars as expected. Next I replaced the test pattern generator with a copy of the alt_vip_vfr the is used for the VGA display. I connected the second instance to the clocked video output block I previously used to generate the color bars. After generating the HDL and compiling the project I produced the rbf and the dtb from this project. I installed these files in the FAT section of the micro SD. On booting Linux, the following messages appear: altvipfb ff231000.vip: fb0: altvipfb frame buffer device at 0x2e800000+0x300000 altvipfb ff202000.vip: fb1: altvipfb frame buffer device at 0x2e400000+0x12c000 On entering ls /dev/fb* at the command line I see that there are two framebuffer devices: /dev/fb0 and /dev/fb1. I wrote a test program to generate color bars to /dev/fb1. The program is able to access and display the contents of the fb_var_screeninfo and fb_fix_screeninfo structures. These structures show the attributes associated with the LCD display, including the address and length of the framebuffer for the device. The program uses mmap to get a virtual pointer to the framebuffer address. The LCD does not light up when I copy the test pattern to the framebuffer. I made an xorg.conf file defining the configuration for the VGA monitor and the LCD display. When I run the test program, the LCD does not light up. I tested the program by using /dev/fb0 instead of /dev/fb1. The program works as expected. I next switched to using VFB II. On instantiating VFB II one of the parameters the editor presents in the screen buffer address. As you requested, I provide you with the screen shot of the VFB II dialog box. I accept the default address of 0x00000000, but I think that is not a good address. My questions are: If I use the legacy VFB, how do I get the display to light up? If I use VFB II, does it copy the screen data to the address specified in the instantiation? My project is the development of an embedded instrument that will use the LCD display for the user interface. I am developing the application on Linux, using XCB, Cairo and Pango. I will eventually have to make Linux and X aware of the display. Since I am working on the development board building the underlying infrastructure, I have no problem providing you with the QSYS project if you need to see it. Please let me know. Thank you for your assistance. Ben Martinez NDT Systems, Inc

CheePin_C_Intel · ‎07-18-2019

Hi Ben,

Thanks for your update. As I understand it, when you use the example design from Terasic, there is no issue with the LCD display. Sorry as I am not really familiar with embedded area and also I am unable to comment on design implementation. However I will try my best to assist from the VIP perspective. Hope you could understand it.

Just would like to check with you on the following:

1. Just wonder if you if you have had a chance to try with a simple test design with Test Pattern Gen II -> Frame Buffer II -> CVO II -> LCD to see if there is any valid display on LCD? This would be helpful to ensure the FB II and CVO II IPs are working correctly prior to replacing the video source.

2. If #1 is working, you may start to replace the test pattern generator with your video source. This would help to narrow down the issue to video source if there is any issue observed.

3. You may also cross check your video data with the one from the Test Pattern Generator if #2 is not working. You may use signaltap to monitor the video data for cross checking.

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

BMart12 · ‎07-18-2019

Hi Chee, The good news is that I finally got my test program to work. I determined that the framebuffer address parameter in the VFB II block is apparently ignored. I used an arbitrary address of 0x20000000 as the framebuffer. I mapped this physical address to my program’s virtual space. I then set the frame start address with this address. I infer that the VFB II uses the address presented in this register and the base address defined in the component editor is ignored. As I wrote you yesterday, I had already instantiated Test Pattern Gen II -> CVO II -> LCD and verified that hardware connection to the LCD worked. After I replaced TPG II with VFB II, I figured the only issue was how to make the VFB II logic work. My test program showed the control port was as expected from the documentation. I am wondering, based on your comments today; it seems you did not receive the email I sent you yesterday. Did you get it? Ben

CheePin_C_Intel · ‎07-19-2019

Hi Ben,

Thanks for your update. Glad to hear that you have managed to get the FB II working by configuring the memory base address to a value other than 0x0.

Sorry if there is any confusion. Regarding your previous post, yes, I have receive the email. I understand that you have tested with TPG II -> CVO II. Thus, I am suggesting to test by adding FBII in between, ie TPG II -> FB II -> CVO II. Get the FB II up and running, then only remove the TPG II from the system. However, since you have managed to root cause the issue, it would be great for you to continue using your resolution to avoid gating your progress.

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

CheePin_C_Intel · ‎07-23-2019

Hi Ben,

Just would like to follow up with you if there is any further concern. Please feel free to let me know if there is any concern so that we could further assist you. Thank you.

Best regards,

Chee Pin

CheePin_C_Intel · ‎07-24-2019

Hi Ben,

As I understand it, it has been some time since I last heard from you. I would set this case to closed at this moment. Feel free to file a new case if you have any further question related to this request. Thank you for your understanding.

Best regards,

Chee Pin

BMart12 · ‎08-05-2019

Hi Chee, I was out on vacation for the last two weeks. Evidently my Outlook notice did not work in response to your emails. As I understand from your background you are knowledgeable about the VIP suite. I expect I will have questions about the framebuffer reader later on. Regarding the issue with address to use for the framebuffer, I am confirming that you can close it. Thank you for your help. Ben

CheePin_C_Intel · ‎08-06-2019

Hi,

Thanks lot for your update. I will set this case to close-pending. Please feel free to open a new case in future should you have any further inquiries.

Thank you.