This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I am new to Linux and display drivers.
I have the Omap 3530 eval kit designed by Mistral for TI.
I am using the general purpose expansion connector P7 to wire to a smart display, the connection map below shows where I have made the connections.P7 OursDSS_DO to DSS_D7 D0 to D7DSS_ HSYNC (B41) CST2_GPIO.1 (B6) ResetDSS_ACBIAS (B38) AddressDSS_VSYNC (B40) WriteDSS_PCLK (B39) ReadIt is using a parallel interface to communicate to the display. I know that the files that are used for the current display aredrivers/video/omap/omap_disp_out.cdrivers/video/omap/omap_fb.carch/arm/plat-omap/display.cand that they use the 51 pin LCD connector on top of the main PCB. Any help you can provide to help me get this display up and running would be greatly appreciated.
The format I am looking at doing is getting a driver that will allow me to open the device, allow me to read and write to the device and then be able to close the device.
It's hard to read the map you are using and also there is some information missing from the display you are using to know how to properly connect the system. It seems to me you have a parallel RGB screen, and you need to put the Display subsystem on LCD by-pass mode (MIPI DPI protocol), but depending on your screen specification you may need to adjust the wiring.
If you send me the information on the screen I can give you a hand on figuring out the right connection and will be up to you to modify the driver to properly drive the configuration. Our company offers driver development services for OMAP so if you are interested we can do the driver modification for you, or provide you support services if you are a Linux beginner.
The driver for screen is a standard framebuffer driver for Linux, which means you have a /dev/fb0 file that you can open,close,read,write with standard linux calls, but that's a bit too low for most graphic applications and you may want to use some other stack like DirectFB.
We would be glad to help you as you go through the process of driver development, it sounds like you are off to a fine start. My initial suggestion would be to start with the existing LCD drivers that are included with the and start making modifications to them to fit your particular display as you suggest. Using a third party like RidgeRun above can also be helpful particularly if you are new to driver development. Feel free to post any particular questions you have during the process.
As Diego suggested, a standard Linux frame buffer driver is provided. Since you mentioned you are somewhat new to drivers and Linux, I just wanted to make sure that you understand that most drivers provided in OMAP (such as frame buffer driver for video display) are based on standard Linux APIs. I have not installed the OMAP DVSDK yet, but there is usually a 'docs' or 'documents' folder in the root kernel directory that has documentation on most of the standard Linux APIs.
However, as Diego also suggested, drivers are only part of the software stack; in addition, at the user level, there are Linux standardized graphics libraries, window manager, desktop environments.... that can allow a user to program complex GUI applications in a simple manner as opposed to interfacing with drivers directly. All these software components have their own APIs which you can program to depending how low or high in the software stack you like to program at; Linux gives users this flexibility.
Anyway, I hope this helps and feel free to post additional questions.
In reply to Juan Gonzales:
Thanks for the quick response, but this has only confused me a little bit more. I am use to using small micro's where you say write porte value. If I understand correctly, the kernal should have the functions available for me to open the new display, and write the configuration data to the new display, and this should be able to be done in a user program, with out having to change the frame buffer driver?
As mentioned previously the chart for wiring should have looked like this
DSS_DO to DSS_D7 D0 to D7
DSS_ HSYNC (B41) CS
T2_GPIO.1 (B6) Reset
DSS_ACBIAS (B38) Address
DSS_VSYNC (B40) Write
DSS_PCLK (B39) Read
Currently I am only trying to turn the display on and get the pixel color to change. Once I have accomplished that then I will look at getting more complex.
In reply to JeremyKapp:
Your interpretation is correct that you can write a small user program to accomplish the task you described (no need to change driver), but please keep in mind that these parts are much more complex (and powerful) than the small micros you may have worked with in the past; this means the software required to manage the extra resources in the OMAP family of parts also increases in complexity. At the user interface level, details such as pixel clock, vynsc, hsync.... are hidden from you. You basically make calls like open() to open handle to driver, ioctl to send request to driver, and close to close handle to driver. If you look at the demos folder included with the DVSDK installation, you should get a good feel of what a user application should look like (although you can probably write a simpler app to do your task).
So I have written a test program that opens the frame buffer, is there anyway to upload the program to the EVM without having to recompile the kernel, currently I am not connected to the ethernet port, is this required or can I use a different method?
The ethernet port is probably the easiest method (via NFS you can share a directory with your host PC), but there are other options, such as if you have a SD card, or if you have a USB adapter you could use a USB flash drive or even a USB hard drive. Note that the drive has to have a filesystem the kernel supports, or you will have to rebuild the kernel to support the file system you choose.
If you have written a user level program such as the demos included with DVSDK, you do not need to recompile the kernel. With regards to copying your program over, NFS mount via ethernet is probably the best way to go.
Normally, during development phase, you want to use NFS mount and/or TFTP (if working with kernel); this allow user to quickly make changes and recompile in the more powerful host and quickly test on the target; you could theoretically write your program and recompile on the target side as well, but this will be much slower (not ideal for development phase).
Omap 3530 eval kit designed by Mistral for TI. i need those shematics is any one having
In reply to thiyagu:
The schematics for the OMAP35x EVM are available by registering at http://www.mistralsolutions.com.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.