From: Neil M. <ne...@gu...> - 2011-01-28 22:56:48
|
Thanks for the instructions! This would make a great addition to the user wiki. On 11-01-28 02:30 PM, jlclemon wrote: > Everyone, > > I spent some time getting the openGL demos working and figured I would post > my steps on the mailing list in case any other beginner needs to get it > going. These steps worked on a Fedora 13 64 bit machine and a Ubuntu 10.10 > 64 bit machine. This is really just a aggregate of various threads and > solutions. I did not discover anything new here but am putting it in one > place for future rookies. This worked with a git pull from the repository > on Jan 26th, 2011. Note that my install location is not in my home > directory (~/overo-oe/) but is instead /x/gumstix/overo-oe/. > > Instructions: > Edit the bitbake image file of the linux you want > $ gedit > /x/gumstix/overo-oe/org.openembedded.dev/recipes/images/omap3-console-image.bb > -uncomment libgles-omap3 line > -add libgles-omap3-rawdemos (These demos can run but take over the whole > screen and thus can cause problems when run with x > -Add task-native-sdk (if you want build tools like gcc and g++ on the > gumstix) > > > $ gedit /x/gumstix/overo-oe/org.openembedded.dev/recipes/images/ > omap3-desktop-image.bb > -uncomment libgles-omap3-x11demos (these play nice with the desktop > > > Un comment the machine extras recommendations in overo.conf > $ gedit /x/gumstix/overo-oe/org.openembedded.dev/conf/machine/overo.conf > MACHINE_EXTRA_RRECOMMENDS += " omap3-sgx-modules" > > > <<These steps seem optional because the bitbake recipe seems to go get them > anyway but I did them just in case. They are from another person's post>> > Get the latest SGX drivers from TI (if you have an account) > http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/ > > http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS.html > > > Copy them to > /x/gumstix/overo-oe/org.openembedded.dev/recipes/powervr-drivers/libgles-omap3 > and to > /x/gumstix/overo-oe/org.openembedded.dev/recipes/powervr-drivers/omap3-sgx-modules > $ cp > /x/gumstix/overo-oe/openglDrivers/Graphics_SDK_setuplinux_4_00_00_01.bin > /x/gumstix/overo-oe/org.openembedded.dev/recipes/powervr-drivers/libgles-omap3/Graphics_SDK_setuplinux_4_00_00_01.bin > $ cp > /x/gumstix/overo-oe/openglDrivers/Graphics_SDK_setuplinux_4_00_00_01.bin > /x/gumstix/overo-oe/org.openembedded.dev/recipes/powervr-drivers/omap3-sgx-modules/Graphics_SDK_setuplinux_4_00_00_01.bin > > Change the permissions on the drivers to make them executable > $ chmod a+x > /x/gumstix/overo-oe/org.openembedded.dev/recipes/powervr-drivers/libgles-omap3/Graphics_SDK_setuplinux_4_00_00_01.bin > $ chmod a+x > /x/gumstix/overo-oe/org.openembedded.dev/recipes/powervr-drivers/omap3-sgx-modules/Graphics_SDK_setuplinux_4_00_00_01.bin > > > > Modify the bitbake file for the sgx module to make sure you get the file > from the right place > For example in omap3-sgx-modules_1.4.14.2514.bb if you are using 3.01.00.02 > for the SDK version: > Change : > #SRC_URI = > "http://install.source.dir.local/OMAP35x_Graphics_SDK_setuplinux_${SGXPV}.bin > \ > # file://0001-Compile-fixes-for-recent-kernels.patch \ > #" > > To: > SRC_URI = "file://OMAP35x_Graphics_SDK_setuplinux_${SGXPV}.bin \ > file://0001-Compile-fixes-for-recent-kernels.patch \ > " > > > Create the md5 Check sum for each one > $ md5sum OMAP35x_Graphics_SDK_setuplinux_4_00_00_01.bin> > OMAP35x_Graphics_SDK_setuplinux_4_00_00_01.bin.md5 > > > <<End Possibly Optional part>> > > > > Modify the bitbake files in > /x/gumstix/overo-oe/org.openembedded.dev/recipes/powervr-drivers/ to use the > same version of the sdk if needed. > For example: > modify the DEFAULT_PREFERENCE in omap3-sgx-modules_1.4.14.2616.bb to make > the kernel modules use 4.00.00.01 of the Graphics SDK > From: > DEFAULT_PREFERENCE = "-1" > > To: > DEFAULT_PREFERENCE = "1" > Add the default preference line to libgles-omap3_4_00_00_01.bb to make the > libgles use 4.00.00.01 of the Graphics SDK > Add: > DEFAULT_PREFERENCE = "1" > > > > > > Build linux > $ bitbake omap3-console-image (I found making the console image first and > the desktop worked although I know the desktop builds the console anyway) > $ bitbake omap3-desktop-image > > Build the MLO file > $ bitbake x-load > > Build the U-boot file > $ bitbake u-boot-omap3 > > > Install to SD card and enjoy! > > Thanks, > > jlclemons |
From: bhamadicharef <bha...@ho...> - 2012-10-02 03:47:52
|
anyone managed to replicate this ? Brahim -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4965536.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: ktpi <kpi...@in...> - 2012-10-02 18:19:35
|
I have been trying to get these demos running on an Overo Fire and an Overo FireSTORM with a Tobi board. I am using the omap3-desktop-image and the 3.2.0 kernel image. I followed the above instructions to get all the right libraries and do the open embedded build. I can see the demos on my desktop, but something peculiar happens when I try to run them, and I get different results for Fire vs Firestorm when using the same SD card: Overo Fire: When I try to run the X11 demos from the desktop, a blank window comes up and the screen freezes and I have to reboot. When trying to run the raw demos from the command line, I get the following message before it hangs: PVRShell: EGL 1.4 initialized. When I boot, I can tell the PVR init sequence has run because the kernel modules pvrsrvkm, omaplfb, and bufferclass_ti are all inserted. Overo FireSTORM: As it finishes booting up, I see the following message on the screen: No SGX hardware, not starting PVR. When I attempt to open the X11 demos from the desktop, a window comes up and closes itself before anything can be seen. When I try to run demos from the console, I get this: Can't open remote control input device (/dev/ttyS1) Exit message has been set to: "PVRShell: Unable to initialise EGL". PVRShell: EGL Error (EGL_BAD_ALLOC) InitAPI failed! PVRShell: Unable to initialise EGL Any ideas? I have been searching the mailing list and Google to try to find a solution but haven't come up with anything that works. -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4965549.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bhamadicharef <bha...@ho...> - 2012-10-04 00:46:33
|
Thank you ktpi for sharing your experience. I will try myself soon, obviously there Are some SGX driver mismatch somewhere along ... Have your overo have the same version of SGX ? Will update when i manage to get something work. It is a long trial and error process ... as for many things ! Brahim -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4965584.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bhamadicharef <bha...@ho...> - 2012-10-04 00:50:05
|
Maybe jlclemons could give us more details on his/her configuration. What overo model ? Which kernel ? Which SGX silicon on the TI chip OMAP3530 ? DM3730 ? Others ... ? Brahim -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4965585.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: ktpi <kpi...@in...> - 2012-10-04 13:22:33
|
I'm still working on it--the Overo Fire has the OMAP 3530 processor, while the FireSTORM has the DM 3730 processor, but both are supposed to have the OpenGL/PowerVR capability. I do think it may be some kind of driver/kernel mismatch, because on closer inspection of dmesg and a few other things, I have seen some problems with the kernel module bufferclass_ti that is associated with the PowerVR driver: bufferclass_ti: Unknown symbol PVRGetBufferClassJTable (err 0) -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4965594.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: ktpi <kpi...@in...> - 2012-10-12 19:56:50
|
overo_panic.txt <http://gumstix.8.n6.nabble.com/file/n4965695/overo_panic.txt> I'm trying to see if I can get the demos at least working on the Fire since the driver loads as mentioned above. For some reason before, the console on my host wasn't displaying what was going on when the demos would freeze, but today I've seen the attached kernel panic message. Any ideas? -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4965695.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: ktpi <kpi...@in...> - 2012-10-25 18:48:29
|
If anyone is interested, I did get the OpenGL demos to work on the Overo Fire doing a few bibtake clean -c's, using the 2.6.39 kernel. The driver version for omap3-sgx-modules was 1.6.16.3977. I'm still working on getting it working on the FireSTORM, which uses the DaVinci processor, however recently found this acknowledgement from TI of the "No SGX Hardware" issue: http://e2e.ti.com/support/embedded/linux/f/354/t/139392.aspx#502148 I'm working on getting my u-boot rebuilt with this patch currently. -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4965808.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: jumpnowdev <sc...@ju...> - 2012-10-25 20:46:38
|
The SGX cores are the same, but there is a version difference between the OMAP35xx and DM37xx. Look at the first table on this page. http://processors.wiki.ti.com/index.php/Graphics_SDK_Quick_installation_and_user_guide#Build_and_install_instructions And in the SDK there are different PowerVR drivers for the different gpus. So there might be a problem to build for both OMAP35xx and DM37xx at the same time. When you build the kernel modules with the SDK you have to specify the ES version. It's easy enough to build both, but the resulting modules are not the same. If I try to load the es3.x kernel drivers on the DM3730 (FireStorm), the system crashes. If I load the es5.x kernel drivers everything works fine. When configuring Qt, you have to point some of the Qt make paths at the appropriate es3.x or es5.x directory to build the powervr plugin. It could be the headers Qt is using are the same in both directories and it doesn't matter for this. I didn't check. And maybe OE/Yocto can handle all this with some bitbake voodoo. That would be cool. FWIW, I did get it working for kernel 3.2, TI Graphics SDK 4.06.00.02, Qt embedded 4.8.3. The Qt opengl demos run with -qws. I've only tried a DM37xx (FireStorm) COM so far. -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4965809.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bhamadicharef <bha...@ho...> - 2012-10-27 02:47:19
|
Excellent news Scott ! Looking forward to be able To replicate such install from scratch and demonstrate What such combination can do in terms of performance. Brahim -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4965822.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: jumpnowdev <sc...@ju...> - 2012-11-29 19:10:26
|
If anyone is interested, I wrote up some notes on the process we are using to get the SGX drivers and Qt embedded working on the Overos. https://github.com/Pansenti/sgx-qt-build The notes are for 3.2 kernels. Our target is an environment for OpenGL/Qt embedded applications. This might not be interesting if those aren't your requirements. I took a quick look and it appears the DSS drivers in 3.6 have changed enough that the kernel patch from Robert Nelson we are using will be hard to migrate. So we are sticking with 3.2 for now. We use either touchscreens or more often alternative input devices, something other then a mouse. There is no mouse cursor support in the qt-configure step and no X11. You could easily add X11 support. We use both OMAP3 and DM37xx boards, though mostly Storms. Either works. We cross-compile our Qt apps. Use the QMAKEQTE variable from the yocto-cross-env.sh for the qmake to generate Makefiles. The instructions are long-winded, but you can script it all pretty easily. Recent changes to Yocto broke the TSLIB stuff for the Qt build. There was a shuffling under sysroots. I modified the yocto-cross-env.sh for the kernel dir move, but didn't fix the TSLIB stuff yet. You can work around it by finding the correct paths in your OE TMPDIR. Ask if interested. Or you can just remove it from the qt-configure.sh if you don't need TS support. It's only been tested on a few of our build machines, so there may be some assumptions I failed to document. -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4966193.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: bhamadicharef <bha...@ho...> - 2012-11-30 05:39:58
|
Great ! Thank you for sharing ! Brahim -- View this message in context: http://gumstix.8.n6.nabble.com/OpenGL-demos-on-Gumstix-instructions-tp641163p4966198.html Sent from the Gumstix mailing list archive at Nabble.com. |