Forum Discussion
CheepinC_altera
Regular Contributor
6 years agoHi 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
- BMart126 years ago
Occasional Contributor
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