[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Charles Krinke]

This is probably a question for Prabu and Spenser as I undestand a
buildroot patch is on the near horizon for Qt5 and OpenGL.

I have downloaded last nights nightly build of buildroot and built Qt5
for ARM for the TI AM3517 as we try to move from Qt-4.8.2 to Qt-5.0.2
and am looking at three features that are currently disabled.

These are support for Neon, OpenGL & EGLFS.

I was able to add QMAKE_INCDIR_OPENGL_ES2, QMAKE_LIBDIR_OPENGL_ES2 &
QMAKE_LIBS_OPENGL_ES2 to the mkspec patch this week using last weeks
buildroot-20130529 and get OpenGL to compile pointing to my external
TI Graphics_SDK, but then get into trouble with EGLFS and later on
with VERSION in qt_module.prf. So, I think there is a bit more to the
problem then just adding constants to the mkspecs patch.

Can someone possibly describe more of what needs to be done in a
dialect of techno-babble that I understand to get these three features
supported for the AM3517, please?

-- 
Charles Krinke

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Wojciech Sleńska]

Hello Charles,

I already have full OpenGL ES support on my TI AM3517 in QT5 using eglfs plugin.

I use following half-manual procedure to made this:
1. I build kernel modules using TI Graphics_SDK_4_09_00_01 package,
downloaded from TI page
2. I made some changes in qt5 build scripts (check attachment) in
buildroot and add path to ti libs

As compiler I use arago-2011.09 with following flags -march=armv7-a
-mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp

3. When build is finished. I copy some files from
Graphics_SDK_4_09_00_01/gfx_rel_es3.x/ directory to target rootfs.
4. Now I can run ./hellogl_es2 -platform eglfs

I hope that this solution will help You.

Best Regards
Wojciech Slenska

2013/6/5 Charles Krinke <charles.krinke@gmail.com>:
> This is probably a question for Prabu and Spenser as I undestand a
> buildroot patch is on the near horizon for Qt5 and OpenGL.
>
> I have downloaded last nights nightly build of buildroot and built Qt5
> for ARM for the TI AM3517 as we try to move from Qt-4.8.2 to Qt-5.0.2
> and am looking at three features that are currently disabled.
>
> These are support for Neon, OpenGL & EGLFS.
>
> I was able to add QMAKE_INCDIR_OPENGL_ES2, QMAKE_LIBDIR_OPENGL_ES2 &
> QMAKE_LIBS_OPENGL_ES2 to the mkspec patch this week using last weeks
> buildroot-20130529 and get OpenGL to compile pointing to my external
> TI Graphics_SDK, but then get into trouble with EGLFS and later on
> with VERSION in qt_module.prf. So, I think there is a bit more to the
> problem then just adding constants to the mkspecs patch.
>
> Can someone possibly describe more of what needs to be done in a
> dialect of techno-babble that I understand to get these three features
> supported for the AM3517, please?
>
> --
> Charles Krinke
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-qt5-OMAP-EGLFS-enable-dirty-fix.patch
Type: application/octet-stream
Size: 7723 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130605/3e72b324/attachment.obj>

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Charles Krinke]

Dear Wojciech:

Thank you very much.

I look at your patch and it is addressing the things I have been
struggling with and then some. I need to test and understand what it
is doing, but I think it is certainly going in the right direction.

I also am using a seperate tree for the Graphics_SDK, so this recipe
is consistent. I am using the CodeSourcery 2011.09 that is part of
buildroot with similar flags, but will double check the flags.

You give me hope that the light at the end of the tunnel I am
currently in is daylight and not an approaching express train.

Charles

On 6/5/13, Wojciech Sle?ska <wojciech.slenska@gmail.com> wrote:
> Hello Charles,
>
> I already have full OpenGL ES support on my TI AM3517 in QT5 using eglfs
> plugin.
>
> I use following half-manual procedure to made this:
> 1. I build kernel modules using TI Graphics_SDK_4_09_00_01 package,
> downloaded from TI page
> 2. I made some changes in qt5 build scripts (check attachment) in
> buildroot and add path to ti libs
>
> As compiler I use arago-2011.09 with following flags -march=armv7-a
> -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
>
> 3. When build is finished. I copy some files from
> Graphics_SDK_4_09_00_01/gfx_rel_es3.x/ directory to target rootfs.
> 4. Now I can run ./hellogl_es2 -platform eglfs
>
> I hope that this solution will help You.
>
> Best Regards
> Wojciech Slenska
>
> 2013/6/5 Charles Krinke <charles.krinke@gmail.com>:
>> This is probably a question for Prabu and Spenser as I undestand a
>> buildroot patch is on the near horizon for Qt5 and OpenGL.
>>
>> I have downloaded last nights nightly build of buildroot and built Qt5
>> for ARM for the TI AM3517 as we try to move from Qt-4.8.2 to Qt-5.0.2
>> and am looking at three features that are currently disabled.
>>
>> These are support for Neon, OpenGL & EGLFS.
>>
>> I was able to add QMAKE_INCDIR_OPENGL_ES2, QMAKE_LIBDIR_OPENGL_ES2 &
>> QMAKE_LIBS_OPENGL_ES2 to the mkspec patch this week using last weeks
>> buildroot-20130529 and get OpenGL to compile pointing to my external
>> TI Graphics_SDK, but then get into trouble with EGLFS and later on
>> with VERSION in qt_module.prf. So, I think there is a bit more to the
>> problem then just adding constants to the mkspecs patch.
>>
>> Can someone possibly describe more of what needs to be done in a
>> dialect of techno-babble that I understand to get these three features
>> supported for the AM3517, please?
>>
>> --
>> Charles Krinke
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>


-- 
Charles Krinke

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Charles Krinke]

Dear Wojciech:

I have been working with your patch but seem to have gotten myself
into another "pickle" in that when I compile, I get the sequence
below. I will start again fresh in the morning with the original patch
and the nightly build from buildroot, which will be
buildroot-20130606.tgz.

Question, I presume the patch should apply against tonights buildroot?
If not, is there a nightly build you would recommend for applying to
patch to?

If you have a suggestion on the errors, that would be appreciated.

Hopefully you, Spenser or Prabu can get this and any remaining logic
into buildroot so Neon, OpenGl and EGLFS support becomes part of the
buildroot trunk, soon.

>>> qt5base 5.0.2 Extracting
xzcat /home/ckrinke/buildroot-20130605/dl/qtbase-opensource-src-5.0.2.tar.xz
| tar --strip-components=1 -C
/home/ckrinke/buildroot-20130605/output/build/qt5base-5.0.2  -xf -
>>> qt5base 5.0.2 Patching package/qt5//qt5base

Applying qt5base-mkspecs-files.patch using patch:
patching file mkspecs/devices/linux-buildroot-g++/qmake.conf
patching file mkspecs/devices/linux-buildroot-g++/qplatformdefs.h

Applying qt5base-uclibc-no-lfs.patch using patch:
patching file mkspecs/common/posix/qplatformdefs.h
>>> libgles undefined Configuring
>>> libgles undefined Building
>>> libgles undefined Installing to target
>>> libegl undefined Extracting
>>> libegl undefined Patching package/opengl//libegl
>>> libegl undefined Configuring
echo "No libEGL implementation selected. Configuration error."
No libEGL implementation selected. Configuration error.

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Wojciech Sleńska]

Hello Charles,

I didn't check this patch for current version of buildroot. It was
created some time before 2013.05. Sorry for that.

I noticed that there was some changes in libgles configuration in new
versions of buildroot.
In attachment you can find patch for buildroot 2013.05 and my .config file.

In config I used arago compiler, because I had some problems in past
with others compilers ? maybe just for sure use arago. You can find it
here: http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/index_FDS.html

Few minutes ago I made build and test this solution on my TI AM3517
and it is working.

Best Regards
Wojciech Slenska


2013/6/6 Charles Krinke <charles.krinke@gmail.com>:
> Dear Wojciech:
>
> I have been working with your patch but seem to have gotten myself
> into another "pickle" in that when I compile, I get the sequence
> below. I will start again fresh in the morning with the original patch
> and the nightly build from buildroot, which will be
> buildroot-20130606.tgz.
>
> Question, I presume the patch should apply against tonights buildroot?
> If not, is there a nightly build you would recommend for applying to
> patch to?
>
> If you have a suggestion on the errors, that would be appreciated.
>
> Hopefully you, Spenser or Prabu can get this and any remaining logic
> into buildroot so Neon, OpenGl and EGLFS support becomes part of the
> buildroot trunk, soon.
>
>>>> qt5base 5.0.2 Extracting
> xzcat /home/ckrinke/buildroot-20130605/dl/qtbase-opensource-src-5.0.2.tar.xz
> | tar --strip-components=1 -C
> /home/ckrinke/buildroot-20130605/output/build/qt5base-5.0.2  -xf -
>>>> qt5base 5.0.2 Patching package/qt5//qt5base
>
> Applying qt5base-mkspecs-files.patch using patch:
> patching file mkspecs/devices/linux-buildroot-g++/qmake.conf
> patching file mkspecs/devices/linux-buildroot-g++/qplatformdefs.h
>
> Applying qt5base-uclibc-no-lfs.patch using patch:
> patching file mkspecs/common/posix/qplatformdefs.h
>>>> libgles undefined Configuring
>>>> libgles undefined Building
>>>> libgles undefined Installing to target
>>>> libegl undefined Extracting
>>>> libegl undefined Patching package/opengl//libegl
>>>> libegl undefined Configuring
> echo "No libEGL implementation selected. Configuration error."
> No libEGL implementation selected. Configuration error.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/octet-stream
Size: 29255 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130606/13941175/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Qt5-EGL-for-OMAP-dirty-patch-for-builroot-2013.05.patch
Type: application/octet-stream
Size: 8785 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130606/13941175/attachment-0003.obj>

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Charles Krinke]

Dear Wojceich:

Your new patch looks like the only difference is the line changing
package/opengl/libgles/libgles.mk from

-ifeq ($(LIBGLES_DEPENDENCIES),)
+ifeq ($(LIBGLES_DEPENDENCIES),y)

I still get the same error when compiling Qt and that is:

patching file mkspecs/common/posix/qplatformdefs.h
>>> libgles undefined Configuring
>>> libgles undefined Building
>>> libgles undefined Installing to target
>>> libegl undefined Extracting
>>> libegl undefined Patching package/opengl//libegl
>>> libegl undefined Configuring
echo "No libEGL implementation selected. Configuration error."

So, from this, I am assuming there is some mis-configuration on my end
that is causing buildroot to go into the package/opengl/libgles
directory when perhaps it should be going to either somewhere in Qt
(QtOpenGl perhaps) or somewhere in Graphics_SDK_XXX. I am searching
more into that.

Perhaps one way to converge this would be to get your patch committed
to the buildroot repository. The only parts that appear to be missing
are the QMAKE_LIBS_INCDIR_OPENGL* ^ BR2_PACKAGE_QT_OMAP_LIB_PATH from
night before last build on the buildroot server.

If we could get the logic that pertains to the external TI
Graphics_SDK committed into buildroot then those folks that wish to
use QtDeclarative or another option that needs the Graphics_SDK, then
we could be a bit further along for all.

Charles


On 6/6/13, Wojciech Sle?ska <wojciech.slenska@gmail.com> wrote:
> Hello Charles,
>
> I didn't check this patch for current version of buildroot. It was
> created some time before 2013.05. Sorry for that.
>
> I noticed that there was some changes in libgles configuration in new
> versions of buildroot.
> In attachment you can find patch for buildroot 2013.05 and my .config file.
>
> In config I used arago compiler, because I had some problems in past
> with others compilers ? maybe just for sure use arago. You can find it
> here:
> http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/index_FDS.html
>
> Few minutes ago I made build and test this solution on my TI AM3517
> and it is working.
>
> Best Regards
> Wojciech Slenska
>
>
> 2013/6/6 Charles Krinke <charles.krinke@gmail.com>:
>> Dear Wojciech:
>>
>> I have been working with your patch but seem to have gotten myself
>> into another "pickle" in that when I compile, I get the sequence
>> below. I will start again fresh in the morning with the original patch
>> and the nightly build from buildroot, which will be
>> buildroot-20130606.tgz.
>>
>> Question, I presume the patch should apply against tonights buildroot?
>> If not, is there a nightly build you would recommend for applying to
>> patch to?
>>
>> If you have a suggestion on the errors, that would be appreciated.
>>
>> Hopefully you, Spenser or Prabu can get this and any remaining logic
>> into buildroot so Neon, OpenGl and EGLFS support becomes part of the
>> buildroot trunk, soon.
>>
>>>>> qt5base 5.0.2 Extracting
>> xzcat
>> /home/ckrinke/buildroot-20130605/dl/qtbase-opensource-src-5.0.2.tar.xz
>> | tar --strip-components=1 -C
>> /home/ckrinke/buildroot-20130605/output/build/qt5base-5.0.2  -xf -
>>>>> qt5base 5.0.2 Patching package/qt5//qt5base
>>
>> Applying qt5base-mkspecs-files.patch using patch:
>> patching file mkspecs/devices/linux-buildroot-g++/qmake.conf
>> patching file mkspecs/devices/linux-buildroot-g++/qplatformdefs.h
>>
>> Applying qt5base-uclibc-no-lfs.patch using patch:
>> patching file mkspecs/common/posix/qplatformdefs.h
>>>>> libgles undefined Configuring
>>>>> libgles undefined Building
>>>>> libgles undefined Installing to target
>>>>> libegl undefined Extracting
>>>>> libegl undefined Patching package/opengl//libegl
>>>>> libegl undefined Configuring
>> echo "No libEGL implementation selected. Configuration error."
>> No libEGL implementation selected. Configuration error.
>


-- 
Charles Krinke

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Charles Krinke]

Ahh, I think I see what is happening.

When I use your .config, Wojciech, I see that QtDeclarative is not checked.

Try checking QtDeclarative and I suspect you will get to a similar
place I am at with your patch.

I originally started with QtDeclarative unchecked and buildroot built
lots of Qt libraries that loaded onto the AM3517 target and life was
good. But, .... then one of the Qt engineers said "Hey, we need
QtDeclarative" and once I checked that, I have been in a world of
"dunt work"

Charles

On 6/6/13, Charles Krinke <charles.krinke@gmail.com> wrote:
> Dear Wojceich:
>
> Your new patch looks like the only difference is the line changing
> package/opengl/libgles/libgles.mk from
>
> -ifeq ($(LIBGLES_DEPENDENCIES),)
> +ifeq ($(LIBGLES_DEPENDENCIES),y)
>
> I still get the same error when compiling Qt and that is:
>
> patching file mkspecs/common/posix/qplatformdefs.h
>>>> libgles undefined Configuring
>>>> libgles undefined Building
>>>> libgles undefined Installing to target
>>>> libegl undefined Extracting
>>>> libegl undefined Patching package/opengl//libegl
>>>> libegl undefined Configuring
> echo "No libEGL implementation selected. Configuration error."
>
> So, from this, I am assuming there is some mis-configuration on my end
> that is causing buildroot to go into the package/opengl/libgles
> directory when perhaps it should be going to either somewhere in Qt
> (QtOpenGl perhaps) or somewhere in Graphics_SDK_XXX. I am searching
> more into that.
>
> Perhaps one way to converge this would be to get your patch committed
> to the buildroot repository. The only parts that appear to be missing
> are the QMAKE_LIBS_INCDIR_OPENGL* ^ BR2_PACKAGE_QT_OMAP_LIB_PATH from
> night before last build on the buildroot server.
>
> If we could get the logic that pertains to the external TI
> Graphics_SDK committed into buildroot then those folks that wish to
> use QtDeclarative or another option that needs the Graphics_SDK, then
> we could be a bit further along for all.
>
> Charles
>
>
> On 6/6/13, Wojciech Sle?ska <wojciech.slenska@gmail.com> wrote:
>> Hello Charles,
>>
>> I didn't check this patch for current version of buildroot. It was
>> created some time before 2013.05. Sorry for that.
>>
>> I noticed that there was some changes in libgles configuration in new
>> versions of buildroot.
>> In attachment you can find patch for buildroot 2013.05 and my .config
>> file.
>>
>> In config I used arago compiler, because I had some problems in past
>> with others compilers ? maybe just for sure use arago. You can find it
>> here:
>> http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/index_FDS.html
>>
>> Few minutes ago I made build and test this solution on my TI AM3517
>> and it is working.
>>
>> Best Regards
>> Wojciech Slenska
>>
>>
>> 2013/6/6 Charles Krinke <charles.krinke@gmail.com>:
>>> Dear Wojciech:
>>>
>>> I have been working with your patch but seem to have gotten myself
>>> into another "pickle" in that when I compile, I get the sequence
>>> below. I will start again fresh in the morning with the original patch
>>> and the nightly build from buildroot, which will be
>>> buildroot-20130606.tgz.
>>>
>>> Question, I presume the patch should apply against tonights buildroot?
>>> If not, is there a nightly build you would recommend for applying to
>>> patch to?
>>>
>>> If you have a suggestion on the errors, that would be appreciated.
>>>
>>> Hopefully you, Spenser or Prabu can get this and any remaining logic
>>> into buildroot so Neon, OpenGl and EGLFS support becomes part of the
>>> buildroot trunk, soon.
>>>
>>>>>> qt5base 5.0.2 Extracting
>>> xzcat
>>> /home/ckrinke/buildroot-20130605/dl/qtbase-opensource-src-5.0.2.tar.xz
>>> | tar --strip-components=1 -C
>>> /home/ckrinke/buildroot-20130605/output/build/qt5base-5.0.2  -xf -
>>>>>> qt5base 5.0.2 Patching package/qt5//qt5base
>>>
>>> Applying qt5base-mkspecs-files.patch using patch:
>>> patching file mkspecs/devices/linux-buildroot-g++/qmake.conf
>>> patching file mkspecs/devices/linux-buildroot-g++/qplatformdefs.h
>>>
>>> Applying qt5base-uclibc-no-lfs.patch using patch:
>>> patching file mkspecs/common/posix/qplatformdefs.h
>>>>>> libgles undefined Configuring
>>>>>> libgles undefined Building
>>>>>> libgles undefined Installing to target
>>>>>> libegl undefined Extracting
>>>>>> libegl undefined Patching package/opengl//libegl
>>>>>> libegl undefined Configuring
>>> echo "No libEGL implementation selected. Configuration error."
>>> No libEGL implementation selected. Configuration error.
>>
>
>
> --
> Charles Krinke
>


-- 
Charles Krinke

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Wojciech Sleńska]

Hello,

I checked qt5declarative in my .config and everything is working ok. I
can run qml application on my target.

After build I have in output/target/usr/lib following files

wojtek at wojtek-laptop:~/arm/buildroot-2013.05/output/target/usr/lib$ ls
fonts                  libQt5Concurrent.so.5.0    libQt5Qml.so.5
          libQt5V8.so.5.0.2
libpcre16.so           libQt5Concurrent.so.5.0.2  libQt5Qml.so.5.0
          libQt5Widgets.so.5
libpcre16.so.0         libQt5Core.so.5            libQt5Qml.so.5.0.2
          libQt5Widgets.so.5.0
libpcre16.so.0.2.0     libQt5Core.so.5.0
libQt5QuickParticles.so.5      libQt5Widgets.so.5.0.2
libpcrecpp.so          libQt5Core.so.5.0.2
libQt5QuickParticles.so.5.0    libQt5XmlPatterns.so.5
libpcrecpp.so.0        libQt5Gui.so.5
libQt5QuickParticles.so.5.0.2  libQt5XmlPatterns.so.5.0
libpcrecpp.so.0.0.0    libQt5Gui.so.5.0           libQt5Quick.so.5
          libQt5XmlPatterns.so.5.0.2
libpcreposix.so        libQt5Gui.so.5.0.2         libQt5Quick.so.5.0
          libstdc++.so.6
libpcreposix.so.0      libQt5Network.so.5         libQt5Quick.so.5.0.2
          libstdc++.so.6.0.14
libpcreposix.so.0.0.1  libQt5Network.so.5.0       libQt5QuickTest.so.5
          libstdc++.so.6.0.14-gdb.py
libpcre.so             libQt5Network.so.5.0.2
libQt5QuickTest.so.5.0         libz.so
libpcre.so.1           libQt5OpenGL.so.5
libQt5QuickTest.so.5.0.2       libz.so.1
libpcre.so.1.2.0       libQt5OpenGL.so.5.0        libQt5V8.so.5
          libz.so.1.2.7
libQt5Concurrent.so.5  libQt5OpenGL.so.5.0.2      libQt5V8.so.5.0

I don't have idea what is wrong in your configuration.

I made test using buildroot-2013.05.tar.bz2 downloaded from buildroot
page. I applied my patch, run make menuconfig and make.

BR
Wojciech Slenska

2013/6/6 Charles Krinke <charles.krinke@gmail.com>:
> Ahh, I think I see what is happening.
>
> When I use your .config, Wojciech, I see that QtDeclarative is not checked.
>
> Try checking QtDeclarative and I suspect you will get to a similar
> place I am at with your patch.
>
> I originally started with QtDeclarative unchecked and buildroot built
> lots of Qt libraries that loaded onto the AM3517 target and life was
> good. But, .... then one of the Qt engineers said "Hey, we need
> QtDeclarative" and once I checked that, I have been in a world of
> "dunt work"
>
> Charles
>
> On 6/6/13, Charles Krinke <charles.krinke@gmail.com> wrote:
>> Dear Wojceich:
>>
>> Your new patch looks like the only difference is the line changing
>> package/opengl/libgles/libgles.mk from
>>
>> -ifeq ($(LIBGLES_DEPENDENCIES),)
>> +ifeq ($(LIBGLES_DEPENDENCIES),y)
>>
>> I still get the same error when compiling Qt and that is:
>>
>> patching file mkspecs/common/posix/qplatformdefs.h
>>>>> libgles undefined Configuring
>>>>> libgles undefined Building
>>>>> libgles undefined Installing to target
>>>>> libegl undefined Extracting
>>>>> libegl undefined Patching package/opengl//libegl
>>>>> libegl undefined Configuring
>> echo "No libEGL implementation selected. Configuration error."
>>
>> So, from this, I am assuming there is some mis-configuration on my end
>> that is causing buildroot to go into the package/opengl/libgles
>> directory when perhaps it should be going to either somewhere in Qt
>> (QtOpenGl perhaps) or somewhere in Graphics_SDK_XXX. I am searching
>> more into that.
>>
>> Perhaps one way to converge this would be to get your patch committed
>> to the buildroot repository. The only parts that appear to be missing
>> are the QMAKE_LIBS_INCDIR_OPENGL* ^ BR2_PACKAGE_QT_OMAP_LIB_PATH from
>> night before last build on the buildroot server.
>>
>> If we could get the logic that pertains to the external TI
>> Graphics_SDK committed into buildroot then those folks that wish to
>> use QtDeclarative or another option that needs the Graphics_SDK, then
>> we could be a bit further along for all.
>>
>> Charles
>>
>>
>> On 6/6/13, Wojciech Sle?ska <wojciech.slenska@gmail.com> wrote:
>>> Hello Charles,
>>>
>>> I didn't check this patch for current version of buildroot. It was
>>> created some time before 2013.05. Sorry for that.
>>>
>>> I noticed that there was some changes in libgles configuration in new
>>> versions of buildroot.
>>> In attachment you can find patch for buildroot 2013.05 and my .config
>>> file.
>>>
>>> In config I used arago compiler, because I had some problems in past
>>> with others compilers - maybe just for sure use arago. You can find it
>>> here:
>>> http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/index_FDS.html
>>>
>>> Few minutes ago I made build and test this solution on my TI AM3517
>>> and it is working.
>>>
>>> Best Regards
>>> Wojciech Slenska
>>>
>>>
>>> 2013/6/6 Charles Krinke <charles.krinke@gmail.com>:
>>>> Dear Wojciech:
>>>>
>>>> I have been working with your patch but seem to have gotten myself
>>>> into another "pickle" in that when I compile, I get the sequence
>>>> below. I will start again fresh in the morning with the original patch
>>>> and the nightly build from buildroot, which will be
>>>> buildroot-20130606.tgz.
>>>>
>>>> Question, I presume the patch should apply against tonights buildroot?
>>>> If not, is there a nightly build you would recommend for applying to
>>>> patch to?
>>>>
>>>> If you have a suggestion on the errors, that would be appreciated.
>>>>
>>>> Hopefully you, Spenser or Prabu can get this and any remaining logic
>>>> into buildroot so Neon, OpenGl and EGLFS support becomes part of the
>>>> buildroot trunk, soon.
>>>>
>>>>>>> qt5base 5.0.2 Extracting
>>>> xzcat
>>>> /home/ckrinke/buildroot-20130605/dl/qtbase-opensource-src-5.0.2.tar.xz
>>>> | tar --strip-components=1 -C
>>>> /home/ckrinke/buildroot-20130605/output/build/qt5base-5.0.2  -xf -
>>>>>>> qt5base 5.0.2 Patching package/qt5//qt5base
>>>>
>>>> Applying qt5base-mkspecs-files.patch using patch:
>>>> patching file mkspecs/devices/linux-buildroot-g++/qmake.conf
>>>> patching file mkspecs/devices/linux-buildroot-g++/qplatformdefs.h
>>>>
>>>> Applying qt5base-uclibc-no-lfs.patch using patch:
>>>> patching file mkspecs/common/posix/qplatformdefs.h
>>>>>>> libgles undefined Configuring
>>>>>>> libgles undefined Building
>>>>>>> libgles undefined Installing to target
>>>>>>> libegl undefined Extracting
>>>>>>> libegl undefined Patching package/opengl//libegl
>>>>>>> libegl undefined Configuring
>>>> echo "No libEGL implementation selected. Configuration error."
>>>> No libEGL implementation selected. Configuration error.
>>>
>>
>>
>> --
>> Charles Krinke
>>
>
>
> --
> Charles Krinke

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Thomas Petazzoni]

Dear Charles Krinke,

On Thu, 6 Jun 2013 11:20:05 -0700, Charles Krinke wrote:

> Your new patch looks like the only difference is the line changing
> package/opengl/libgles/libgles.mk from
> 
> -ifeq ($(LIBGLES_DEPENDENCIES),)
> +ifeq ($(LIBGLES_DEPENDENCIES),y)

The first line is the correct one. The second line was the one
originally introduced, but it was a bug. The idea here is that if
LIBGLES has no dependencies, then it means that no OpenGL
implementation was selected.

> I still get the same error when compiling Qt and that is:
> 
> patching file mkspecs/common/posix/qplatformdefs.h
> >>> libgles undefined Configuring
> >>> libgles undefined Building
> >>> libgles undefined Installing to target
> >>> libegl undefined Extracting
> >>> libegl undefined Patching package/opengl//libegl
> >>> libegl undefined Configuring
> echo "No libEGL implementation selected. Configuration error."

This happens when no package provides a libEGL implementation, i.e
LIBEGL_DEPENDENCIES is empty.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Charles Krinke]

Thank you both Thomas and Wojciech:

I can seem to get past this error by enabling "rpi-userland" which
does define LIBGLES_DEPENDENCIES, but this seems like the wrong answer
to me. Perhaps there is a different configuration setting somewhere
else that defines sufficient configuration for the AM3517 that I have
missed?

I just did a make clean && make after defining "rpi-userland" and the
compilation completed with a libQt5OpenGL.so.5.0.2 about 300KBytes in
size, so something seems to have worked.

Would it be correct that LIBGLES_DEPENDENCIES may just have to be
defined to "anything" so we could put into qt5base/qt5.mk a line that
says

LIBGLES_DEPENDENCIES += any_string_will_do

and expect success?

On 6/7/13, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Dear Charles Krinke,
>
> On Thu, 6 Jun 2013 11:20:05 -0700, Charles Krinke wrote:
>
>> Your new patch looks like the only difference is the line changing
>> package/opengl/libgles/libgles.mk from
>>
>> -ifeq ($(LIBGLES_DEPENDENCIES),)
>> +ifeq ($(LIBGLES_DEPENDENCIES),y)
>
> The first line is the correct one. The second line was the one
> originally introduced, but it was a bug. The idea here is that if
> LIBGLES has no dependencies, then it means that no OpenGL
> implementation was selected.
>
>> I still get the same error when compiling Qt and that is:
>>
>> patching file mkspecs/common/posix/qplatformdefs.h
>> >>> libgles undefined Configuring
>> >>> libgles undefined Building
>> >>> libgles undefined Installing to target
>> >>> libegl undefined Extracting
>> >>> libegl undefined Patching package/opengl//libegl
>> >>> libegl undefined Configuring
>> echo "No libEGL implementation selected. Configuration error."
>
> This happens when no package provides a libEGL implementation, i.e
> LIBEGL_DEPENDENCIES is empty.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>


-- 
Charles Krinke

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Thomas Petazzoni]

Dear Charles Krinke,

On Fri, 7 Jun 2013 07:44:09 -0700, Charles Krinke wrote:

> I can seem to get past this error by enabling "rpi-userland" which
> does define LIBGLES_DEPENDENCIES, but this seems like the wrong answer
> to me.

Enabling rpi-userland provides an EGL implementation that works on the
RasberryPi, so obviously, this isn't going to work for you.

> Perhaps there is a different configuration setting somewhere
> else that defines sufficient configuration for the AM3517 that I have
> missed?

Spenser is creating a Buildroot package that properly packages the
OpenGL/EGL implementation for OMAP/AM3xxx. I hope he can post that soon.

> I just did a make clean && make after defining "rpi-userland" and the
> compilation completed with a libQt5OpenGL.so.5.0.2 about 300KBytes in
> size, so something seems to have worked.
> 
> Would it be correct that LIBGLES_DEPENDENCIES may just have to be
> defined to "anything" so we could put into qt5base/qt5.mk a line that
> says
> 
> LIBGLES_DEPENDENCIES += any_string_will_do
> 
> and expect success?

Well, if you install manually your OpenGL and EGL libraries, maybe. But
that's ugly. The libegl and libopengl packages are virtual packages,
and one package is supposed to provide one EGL and one OpenGL
implementation for your specific SoC.

Spenser, can you update us on your patches? Even if there's not fully
ready, posting them with a RFC tag would allow Charles and Wojchiech to
experiment with them.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Charles Krinke]

Dear Thomas:

You touch on the key piece of understanding I am seeking.
Unfortunately some of this understanding is obfuscated by similar
terms used by different groups.

In the AM3517, there is a source tree called the "Graphics_SDK". And
it contains, I believe, EGL and OpenGL implementations for the AM3517
and other SoC from TI. Wojciech patch does define several variables
which include headers and libraries for Qt.

I *think* we are 99% there and the missing part is this library
constant from Raspberry Pi, but, ... because all the alphabet soup is
different between Ti, Qt, and the rest of the opensource community, we
get to deal with ambiguity a bit.



On 6/7/13, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Dear Charles Krinke,
>
> On Fri, 7 Jun 2013 07:44:09 -0700, Charles Krinke wrote:
>
>> I can seem to get past this error by enabling "rpi-userland" which
>> does define LIBGLES_DEPENDENCIES, but this seems like the wrong answer
>> to me.
>
> Enabling rpi-userland provides an EGL implementation that works on the
> RasberryPi, so obviously, this isn't going to work for you.
>
>> Perhaps there is a different configuration setting somewhere
>> else that defines sufficient configuration for the AM3517 that I have
>> missed?
>
> Spenser is creating a Buildroot package that properly packages the
> OpenGL/EGL implementation for OMAP/AM3xxx. I hope he can post that soon.
>
>> I just did a make clean && make after defining "rpi-userland" and the
>> compilation completed with a libQt5OpenGL.so.5.0.2 about 300KBytes in
>> size, so something seems to have worked.
>>
>> Would it be correct that LIBGLES_DEPENDENCIES may just have to be
>> defined to "anything" so we could put into qt5base/qt5.mk a line that
>> says
>>
>> LIBGLES_DEPENDENCIES += any_string_will_do
>>
>> and expect success?
>
> Well, if you install manually your OpenGL and EGL libraries, maybe. But
> that's ugly. The libegl and libopengl packages are virtual packages,
> and one package is supposed to provide one EGL and one OpenGL
> implementation for your specific SoC.
>
> Spenser, can you update us on your patches? Even if there's not fully
> ready, posting them with a RFC tag would allow Charles and Wojchiech to
> experiment with them.
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>


-- 
Charles Krinke

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Thomas Petazzoni]

Dear Charles Krinke,

On Fri, 7 Jun 2013 08:40:40 -0700, Charles Krinke wrote:

> You touch on the key piece of understanding I am seeking.
> Unfortunately some of this understanding is obfuscated by similar
> terms used by different groups.
> 
> In the AM3517, there is a source tree called the "Graphics_SDK". And
> it contains, I believe, EGL and OpenGL implementations for the AM3517
> and other SoC from TI. Wojciech patch does define several variables
> which include headers and libraries for Qt.
> 
> I *think* we are 99% there and the missing part is this library
> constant from Raspberry Pi, but, ... because all the alphabet soup is
> different between Ti, Qt, and the rest of the opensource community, we
> get to deal with ambiguity a bit.

I am not sure what is confusing you here. OpenGL, EGL, OpenVG and so on
are APIs. Those APIs are provided by different implementations,
depending on which SoC you're using. Those implementations are
generally provided by libraries given by the SoC vendor. So in
Buildroot, a package that needs OpenGL doesn't depend directly on a
specific OpenGL implementation. Instead, it depends on 'libgles',
which is a virtual package that guarantees that *one* OpenGLES
implementation has been selected in the system.

The rpi-userland is currently the only OpenGL implementation that we
support in Buildroot (but more are coming!). So what the rpi-userland
package does in its Config.in is:

        select BR2_PACKAGE_HAS_OPENGL_EGL
        select BR2_PACKAGE_HAS_OPENGL_ES
        select BR2_PACKAGE_HAS_OPENVG
        select BR2_PACKAGE_HAS_OPENMAX

This "announces" to packages like Qt that an OpenGLES, an EGL, an
OpenVG and an OpenMAX implementation is available. Therefore, packages
like Qt are allowed to depend on virtual packages libgles, libegl,
libopenvg and libopenmax.

In turn, those virtual packages do the following:

ifeq ($(BR2_PACKAGE_RPI_USERLAND),y)
LIBGLES_DEPENDENCIES += rpi-userland
endif

ifeq ($(LIBGLES_DEPENDENCIES),)
define LIBGLES_CONFIGURE_CMDS
        echo "No libGLES implementation selected. Configuration error."
        exit 1
endef
endif

This allows to make the virtual package 'libgles' depend on
'rpi-userland' is this package is selected. However, if no dependency
exists of libgles, it means that no OpenGL implementation was selected,
which is an error: some packages (Qt for example) uses the libgles
dependency, but no OpenGLES implementation has been enabled in the
Buildroot configuration.

Again, just wait for Spenser to post his patches, it should make OpenGL
work out-of-the-box for AM3xxx.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] AM3517 Neon, OpenGL & EGLFS support

[Charles Krinke]

Thank you kindly, Thomas for your kind explanation.

I can move forward for now and test the libraries that the Qt5 does
generate, including libQtOpenGL and see if I can get the helloworld or
other example to display somethine while waiting for Spenser to do his
thing.

Charles

On 6/7/13, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Dear Charles Krinke,
>
> On Fri, 7 Jun 2013 08:40:40 -0700, Charles Krinke wrote:
>
>> You touch on the key piece of understanding I am seeking.
>> Unfortunately some of this understanding is obfuscated by similar
>> terms used by different groups.
>>
>> In the AM3517, there is a source tree called the "Graphics_SDK". And
>> it contains, I believe, EGL and OpenGL implementations for the AM3517
>> and other SoC from TI. Wojciech patch does define several variables
>> which include headers and libraries for Qt.
>>
>> I *think* we are 99% there and the missing part is this library
>> constant from Raspberry Pi, but, ... because all the alphabet soup is
>> different between Ti, Qt, and the rest of the opensource community, we
>> get to deal with ambiguity a bit.
>
> I am not sure what is confusing you here. OpenGL, EGL, OpenVG and so on
> are APIs. Those APIs are provided by different implementations,
> depending on which SoC you're using. Those implementations are
> generally provided by libraries given by the SoC vendor. So in
> Buildroot, a package that needs OpenGL doesn't depend directly on a
> specific OpenGL implementation. Instead, it depends on 'libgles',
> which is a virtual package that guarantees that *one* OpenGLES
> implementation has been selected in the system.
>
> The rpi-userland is currently the only OpenGL implementation that we
> support in Buildroot (but more are coming!). So what the rpi-userland
> package does in its Config.in is:
>
>         select BR2_PACKAGE_HAS_OPENGL_EGL
>         select BR2_PACKAGE_HAS_OPENGL_ES
>         select BR2_PACKAGE_HAS_OPENVG
>         select BR2_PACKAGE_HAS_OPENMAX
>
> This "announces" to packages like Qt that an OpenGLES, an EGL, an
> OpenVG and an OpenMAX implementation is available. Therefore, packages
> like Qt are allowed to depend on virtual packages libgles, libegl,
> libopenvg and libopenmax.
>
> In turn, those virtual packages do the following:
>
> ifeq ($(BR2_PACKAGE_RPI_USERLAND),y)
> LIBGLES_DEPENDENCIES += rpi-userland
> endif
>
> ifeq ($(LIBGLES_DEPENDENCIES),)
> define LIBGLES_CONFIGURE_CMDS
>         echo "No libGLES implementation selected. Configuration error."
>         exit 1
> endef
> endif
>
> This allows to make the virtual package 'libgles' depend on
> 'rpi-userland' is this package is selected. However, if no dependency
> exists of libgles, it means that no OpenGL implementation was selected,
> which is an error: some packages (Qt for example) uses the libgles
> dependency, but no OpenGLES implementation has been enabled in the
> Buildroot configuration.
>
> Again, just wait for Spenser to post his patches, it should make OpenGL
> work out-of-the-box for AM3xxx.
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>


-- 
Charles Krinke

[Buildroot] [RFC] ti-gfx: add new package

[Spenser Gilliland]

This is WIP of adding the TI Graphics SDK to buildroot.

TODO:
   Install startup files for sgx core.
   Install khronos gles/egl/vg libraries.
   Create .pc files to simplfy additional packaging.
   Testing, lots of testing.

---
 package/Config.in                              |    1 +
 package/opengl/libegl/libegl.mk                |    4 +
 package/opengl/libgles/libgles.mk              |    4 +
 package/opengl/libopenvg/libopenvg.mk          |    4 +
 package/ti-gfx/Config.in                       |   54 ++++++++++++++++++
 package/ti-gfx/ti-gfx-km_install_modules.patch |   14 +++++
 package/ti-gfx/ti-gfx-newclkapi.patch          |   55 ++++++++++++++++++
 package/ti-gfx/ti-gfx.mk                       |   71 ++++++++++++++++++++++++
 8 files changed, 207 insertions(+), 0 deletions(-)
 create mode 100644 package/ti-gfx/Config.in
 create mode 100644 package/ti-gfx/ti-gfx-km_install_modules.patch
 create mode 100644 package/ti-gfx/ti-gfx-newclkapi.patch
 create mode 100644 package/ti-gfx/ti-gfx.mk

diff --git a/package/Config.in b/package/Config.in
index ce82e99..8c40b56 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -290,6 +290,7 @@ source "package/snowball-hdmiservice/Config.in"
 source "package/sredird/Config.in"
 source "package/statserial/Config.in"
 source "package/sysstat/Config.in"
+source "package/ti-gfx/Config.in"
 source "package/ti-utils/Config.in"
 source "package/uboot-tools/Config.in"
 source "package/udev/Config.in"
diff --git a/package/opengl/libegl/libegl.mk b/package/opengl/libegl/libegl.mk
index bd8040d..00e1f19 100644
--- a/package/opengl/libegl/libegl.mk
+++ b/package/opengl/libegl/libegl.mk
@@ -10,6 +10,10 @@ ifeq ($(BR2_PACKAGE_RPI_USERLAND),y)
 LIBEGL_DEPENDENCIES += rpi-userland
 endif
 
+ifeq ($(BR2_PACKAGE_TI_GFX),y)
+LIBEGL_DEPENDENCIES += ti-gfx
+endif
+
 ifeq ($(LIBEGL_DEPENDENCIES),)
 define LIBEGL_CONFIGURE_CMDS
 	echo "No libEGL implementation selected. Configuration error."
diff --git a/package/opengl/libgles/libgles.mk b/package/opengl/libgles/libgles.mk
index a0048a7..d2fe11b 100644
--- a/package/opengl/libgles/libgles.mk
+++ b/package/opengl/libgles/libgles.mk
@@ -10,6 +10,10 @@ ifeq ($(BR2_PACKAGE_RPI_USERLAND),y)
 LIBGLES_DEPENDENCIES += rpi-userland
 endif
 
+ifeq ($(BR2_PACKAGE_TI_GFX),y)
+LIBGLES_DEPENDENCIES += ti-gfx
+endif
+
 ifeq ($(LIBGLES_DEPENDENCIES),)
 define LIBGLES_CONFIGURE_CMDS
 	echo "No libGLES implementation selected. Configuration error."
diff --git a/package/opengl/libopenvg/libopenvg.mk b/package/opengl/libopenvg/libopenvg.mk
index 03f59ba..118ae7f 100644
--- a/package/opengl/libopenvg/libopenvg.mk
+++ b/package/opengl/libopenvg/libopenvg.mk
@@ -10,6 +10,10 @@ ifeq ($(BR2_PACKAGE_RPI_USERLAND),y)
 LIBOPENVG_DEPENDENCIES += rpi-userland
 endif
 
+ifeq ($(BR2_PACKAGE_TI_GFX),y)
+LIBOPENVG_DEPENDENCIES += ti-gfx
+endif
+
 ifeq ($(LIBOPENVG_DEPENDENCIES),)
 define LIBOPENVG_CONFIGURE_CMDS
 	echo "No libOpenVG implementation selected. Configuration error."
diff --git a/package/ti-gfx/Config.in b/package/ti-gfx/Config.in
new file mode 100644
index 0000000..c3ac984
--- /dev/null
+++ b/package/ti-gfx/Config.in
@@ -0,0 +1,54 @@
+config BR2_PACKAGE_TI_GFX
+	bool "ti-gfx"
+	select BR2_LINUX_KERNEL
+	select BR2_PACKAGE_DEVMEM2
+	select BR2_PACKAGE_HAS_OPENGL_EGL
+	select BR2_PACKAGE_HAS_OPENGL_ES
+	depends on BR2_TOOLCHAIN_EXTERNAL_GLIBC || BR2_TOOLCHAIN_CTNG_eglibc || BR2_TOOLCHAIN_CTNG_glibc
+	help
+	  Graphics libraries for TI boards.
+
+	  http://downloads.ti.com/dsps/dsps_public_sw/gfxsdk/
+
+if BR2_PACKAGE_TI_GFX
+
+config BR2_PACKAGE_TI_GFX_DEBUG
+	bool "enable debug support"
+	help
+	  Turn on debugging in kernel module and install libraries built with
+	  debugging enabled
+
+choice
+	prompt "Target"
+	default BR2_PACKAGE_TI_GFX_OMAP3
+	help
+	  Select the SOC for which you would like to install drivers. Please 
+	  use the chart at
+	  http://processors.wiki.ti.com/index.php/OMAP35x_Graphics_SDK_Getting_Started_Guide
+
+config BR2_PACKAGE_TI_GFX_ES3
+	bool "es3.x"
+	help
+	 OMAP35xx, AM35xx Rev 3.1+ 
+
+config BR2_PACKAGE_TI_GFX_ES5
+	bool "es5.x"
+	help
+	  AM37xx, DM37xx
+
+config BR2_PACKAGE_TI_GFX_ES6
+	bool "es6.x"
+	help
+	  AM387x, C6A814x, AM389x, C6A816x
+
+config BR2_PACKAGE_TI_GFX_ES8
+	bool "es8.x"
+	help
+	  AM335x
+
+endchoice
+
+endif
+
+comment "requires an external eglibc/glibc based toolchain"
+	depends on !(BR2_TOOLCHAIN_EXTERNAL_GLIBC || BR2_TOOLCHAIN_CTNG_eglibc || BR2_TOOLCHAIN_CTNG_glibc)
diff --git a/package/ti-gfx/ti-gfx-km_install_modules.patch b/package/ti-gfx/ti-gfx-km_install_modules.patch
new file mode 100644
index 0000000..63bfd19
--- /dev/null
+++ b/package/ti-gfx/ti-gfx-km_install_modules.patch
@@ -0,0 +1,14 @@
+Index: ti-gfx-4_09_00_01/GFX_Linux_KM/Makefile
+===================================================================
+--- ti-gfx-4_09_00_01.orig/GFX_Linux_KM/Makefile	2013-03-07 11:00:11.000000000 -0600
++++ ti-gfx-4_09_00_01/GFX_Linux_KM/Makefile	2013-05-23 01:36:29.356676281 -0500
+@@ -479,6 +479,9 @@
+ all:
+ 	$(MAKE) -C $(KERNELDIR) M=`pwd` $*
+ 
++install:
++	$(MAKE) -C $(KERNELDIR) M=`pwd` modules_install
++
+ clean:
+ 	@find . -name "*.o" -exec rm -r {} \;
+ 	@find . -name "*.ko" -exec rm -r {} \;
diff --git a/package/ti-gfx/ti-gfx-newclkapi.patch b/package/ti-gfx/ti-gfx-newclkapi.patch
new file mode 100644
index 0000000..b35ac31
--- /dev/null
+++ b/package/ti-gfx/ti-gfx-newclkapi.patch
@@ -0,0 +1,55 @@
+Index: ti-gfx-4_09_00_01/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c
+===================================================================
+--- ti-gfx-4_09_00_01.orig/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c	2013-03-04 08:41:35.000000000 -0600
++++ ti-gfx-4_09_00_01/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c	2013-06-05 12:00:08.778605221 -0500
+@@ -166,11 +166,27 @@
+ 	}
+ 
+ 	PVR_DPF((PVR_DBG_MESSAGE, "EnableSGXClocks: Enabling SGX Clocks"));
+-	
++   res=clk_prepare(psSysSpecData->psSGX_FCK);
++	if (res < 0)
++        {
++                PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable SGX functional clock (%d)", res));
++                clk_unprepare(psSysSpecData->psSGX_FCK);
++                return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
++        }
++
+ 	res=clk_enable(psSysSpecData->psSGX_FCK);
+ 	if (res < 0)
+         {
+                 PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable SGX functional clock (%d)", res));
++                clk_unprepare(psSysSpecData->psSGX_FCK);
++                return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
++        }
++
++	res=clk_prepare(psSysSpecData->psSGX_ICK);
++	if(res < 0)
++        {
++                PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable SGX functional clock (%d)", res));
++                clk_unprepare(psSysSpecData->psSGX_FCK);
+                 return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
+         }
+ 
+@@ -178,8 +194,9 @@
+         if (res < 0)
+         {
+                 PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable SGX interface clock (%d)", res));
+-
++                clk_unprepare(psSysSpecData->psSGX_ICK);
+                 clk_disable(psSysSpecData->psSGX_FCK);
++                clk_unprepare(psSysSpecData->psSGX_FCK);
+                 return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
+         }
+ 
+@@ -247,8 +264,9 @@
+ 	PVR_DPF((PVR_DBG_MESSAGE, "DisableSGXClocks: Disabling SGX Clocks"));
+ 	
+ 	clk_disable(psSysSpecData->psSGX_FCK);
+-
++	clk_unprepare(psSysSpecData->psSGX_FCK);
+ 	clk_disable(psSysSpecData->psSGX_ICK);
++	clk_unprepare(psSysSpecData->psSGX_ICK);
+ 
+ //	SysDisableSGXInterrupts(psSysData);
+ 
diff --git a/package/ti-gfx/ti-gfx.mk b/package/ti-gfx/ti-gfx.mk
new file mode 100644
index 0000000..154c792
--- /dev/null
+++ b/package/ti-gfx/ti-gfx.mk
@@ -0,0 +1,71 @@
+###############################################################################
+#
+# ti-gfx 
+#
+###############################################################################
+
+TI_GFX_VERSION = 4_09_00_01
+TI_GFX_SOURCE = Graphics_SDK_setuplinux_$(TI_GFX_VERSION)_minimal_demos.bin
+TI_GFX_SITE = http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/$(TI_GFX_VERSION)/exports/
+TI_GFX_LICENSE = TSPA
+TI_GFX_LICENSE_FILES = TSPA.txt
+TI_GFX_INSTALL_STAGING = YES
+
+TI_GFX_DEPENDENCIES = linux
+
+ifeq ($(BR2_PACKAGE_TI_GFX_ES3),y)
+TI_GFX_OMAPES = 3.x
+TI_GFX_PLATFORM = omap3
+endif
+ifeq ($(BR2_PACKAGE_TI_GFX_ES5),y)
+TI_GFX_OMAPES = 5.x
+TI_GFX_PLATFORM = omap3630 
+endif
+ifeq ($(BR2_PACKAGE_TI_GFX_ES6),y)
+TI_GFX_OMPAES = 6.x
+TI_GFX_PLATFORM = ti81xx 
+endif
+ifeq ($(BR2_PACKAGE_TI_GFX_ES8),y)
+TI_GFX_OMAPES = 8.x
+TI_GFX_PLATFORM = ti335x
+endif
+
+define TI_GFX_EXTRACT_CMDS 
+	$(RM) -rf $(TI_GFX_DIR)
+	chmod +x $(DL_DIR)/$(TI_GFX_SOURCE)
+	printf "Y\nY\n qY\n\n" | $(DL_DIR)/$(TI_GFX_SOURCE) \
+		--prefix $(TI_GFX_DIR) \
+		--mode console
+endef
+
+define TI_GFX_CONFIGURE_CMDS
+	echo "no configure required binary only package"
+endef
+
+TI_GFX_MAKE_CMD = cd $(TI_GFX_SRCDIR)/GFX_Linux_KM && \
+		$(MAKE) $(LINUX_MAKE_FLAGS) \
+			BUILD=$(BR2_PACKAGE_TI_GFX_DEBUG) \
+			TI_PLATFORM=$(TI_GFX_PLATFORM) \
+			OMAPES=$(TI_GFX_OMAPES) \
+			SUPPORT_XORG=0 \
+			KERNELDIR=$(LINUX_DIR)
+
+define TI_GFX_BUILD_CMDS
+	( $(TI_GFX_MAKE_CMD) clean && \
+	  $(TI_GFX_MAKE_CMD) all )
+endef
+
+define TI_GFX_INSTALL_STAGING_CMDS
+	
+endef
+
+define TI_GFX_INSTALL_TARGET_CMDS
+	( $(TI_GFX_MAKE_CMD) install ) || \
+		echo "Your kernel configuration must include FB_DA8XX"
+endef
+
+define TI_GFX_CLEAN_CMDS
+	( $(TI_GFX_MAKE_CMD) clean )
+endef
+
+$(eval $(generic-package))
-- 
1.7.1

[Buildroot] [RFC] ti-gfx: add new package

[Charles Krinke]

Dear Spenser:

I believe including a kernel compile with this patch is a problem for
several reasons.

The first is that the TI defconfig for AM3517_evm never made it into
the Linux kernel along with all the supporting changes, so the build
fails.

The second is that folks are using various versions of Graphics_SDK
from 4_05_xx through 4_09_xx. These same folks generally build the
Graphics_SDK once externally to buildroot to avoid carrying a 135MB
file in the dl/ directory. This doesnt make sense for buildroot for
two kernel .ko modules where 135MByte is larger then any other
package.

Perhaps you can consider making Graphics_SDK an external reference in
your patch to make things go more smoothly?

On 6/7/13, Spenser Gilliland <spenser@gillilanding.com> wrote:
> This is WIP of adding the TI Graphics SDK to buildroot.
>
> TODO:
>    Install startup files for sgx core.
>    Install khronos gles/egl/vg libraries.
>    Create .pc files to simplfy additional packaging.
>    Testing, lots of testing.
>
> ---
>  package/Config.in                              |    1 +
>  package/opengl/libegl/libegl.mk                |    4 +
>  package/opengl/libgles/libgles.mk              |    4 +
>  package/opengl/libopenvg/libopenvg.mk          |    4 +
>  package/ti-gfx/Config.in                       |   54 ++++++++++++++++++
>  package/ti-gfx/ti-gfx-km_install_modules.patch |   14 +++++
>  package/ti-gfx/ti-gfx-newclkapi.patch          |   55 ++++++++++++++++++
>  package/ti-gfx/ti-gfx.mk                       |   71
> ++++++++++++++++++++++++
>  8 files changed, 207 insertions(+), 0 deletions(-)
>  create mode 100644 package/ti-gfx/Config.in
>  create mode 100644 package/ti-gfx/ti-gfx-km_install_modules.patch
>  create mode 100644 package/ti-gfx/ti-gfx-newclkapi.patch
>  create mode 100644 package/ti-gfx/ti-gfx.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index ce82e99..8c40b56 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -290,6 +290,7 @@ source "package/snowball-hdmiservice/Config.in"
>  source "package/sredird/Config.in"
>  source "package/statserial/Config.in"
>  source "package/sysstat/Config.in"
> +source "package/ti-gfx/Config.in"
>  source "package/ti-utils/Config.in"
>  source "package/uboot-tools/Config.in"
>  source "package/udev/Config.in"
> diff --git a/package/opengl/libegl/libegl.mk
> b/package/opengl/libegl/libegl.mk
> index bd8040d..00e1f19 100644
> --- a/package/opengl/libegl/libegl.mk
> +++ b/package/opengl/libegl/libegl.mk
> @@ -10,6 +10,10 @@ ifeq ($(BR2_PACKAGE_RPI_USERLAND),y)
>  LIBEGL_DEPENDENCIES += rpi-userland
>  endif
>
> +ifeq ($(BR2_PACKAGE_TI_GFX),y)
> +LIBEGL_DEPENDENCIES += ti-gfx
> +endif
> +
>  ifeq ($(LIBEGL_DEPENDENCIES),)
>  define LIBEGL_CONFIGURE_CMDS
>  	echo "No libEGL implementation selected. Configuration error."
> diff --git a/package/opengl/libgles/libgles.mk
> b/package/opengl/libgles/libgles.mk
> index a0048a7..d2fe11b 100644
> --- a/package/opengl/libgles/libgles.mk
> +++ b/package/opengl/libgles/libgles.mk
> @@ -10,6 +10,10 @@ ifeq ($(BR2_PACKAGE_RPI_USERLAND),y)
>  LIBGLES_DEPENDENCIES += rpi-userland
>  endif
>
> +ifeq ($(BR2_PACKAGE_TI_GFX),y)
> +LIBGLES_DEPENDENCIES += ti-gfx
> +endif
> +
>  ifeq ($(LIBGLES_DEPENDENCIES),)
>  define LIBGLES_CONFIGURE_CMDS
>  	echo "No libGLES implementation selected. Configuration error."
> diff --git a/package/opengl/libopenvg/libopenvg.mk
> b/package/opengl/libopenvg/libopenvg.mk
> index 03f59ba..118ae7f 100644
> --- a/package/opengl/libopenvg/libopenvg.mk
> +++ b/package/opengl/libopenvg/libopenvg.mk
> @@ -10,6 +10,10 @@ ifeq ($(BR2_PACKAGE_RPI_USERLAND),y)
>  LIBOPENVG_DEPENDENCIES += rpi-userland
>  endif
>
> +ifeq ($(BR2_PACKAGE_TI_GFX),y)
> +LIBOPENVG_DEPENDENCIES += ti-gfx
> +endif
> +
>  ifeq ($(LIBOPENVG_DEPENDENCIES),)
>  define LIBOPENVG_CONFIGURE_CMDS
>  	echo "No libOpenVG implementation selected. Configuration error."
> diff --git a/package/ti-gfx/Config.in b/package/ti-gfx/Config.in
> new file mode 100644
> index 0000000..c3ac984
> --- /dev/null
> +++ b/package/ti-gfx/Config.in
> @@ -0,0 +1,54 @@
> +config BR2_PACKAGE_TI_GFX
> +	bool "ti-gfx"
> +	select BR2_LINUX_KERNEL
> +	select BR2_PACKAGE_DEVMEM2
> +	select BR2_PACKAGE_HAS_OPENGL_EGL
> +	select BR2_PACKAGE_HAS_OPENGL_ES
> +	depends on BR2_TOOLCHAIN_EXTERNAL_GLIBC || BR2_TOOLCHAIN_CTNG_eglibc ||
> BR2_TOOLCHAIN_CTNG_glibc
> +	help
> +	  Graphics libraries for TI boards.
> +
> +	  http://downloads.ti.com/dsps/dsps_public_sw/gfxsdk/
> +
> +if BR2_PACKAGE_TI_GFX
> +
> +config BR2_PACKAGE_TI_GFX_DEBUG
> +	bool "enable debug support"
> +	help
> +	  Turn on debugging in kernel module and install libraries built with
> +	  debugging enabled
> +
> +choice
> +	prompt "Target"
> +	default BR2_PACKAGE_TI_GFX_OMAP3
> +	help
> +	  Select the SOC for which you would like to install drivers. Please
> +	  use the chart at
> +	
> http://processors.wiki.ti.com/index.php/OMAP35x_Graphics_SDK_Getting_Started_Guide
> +
> +config BR2_PACKAGE_TI_GFX_ES3
> +	bool "es3.x"
> +	help
> +	 OMAP35xx, AM35xx Rev 3.1+
> +
> +config BR2_PACKAGE_TI_GFX_ES5
> +	bool "es5.x"
> +	help
> +	  AM37xx, DM37xx
> +
> +config BR2_PACKAGE_TI_GFX_ES6
> +	bool "es6.x"
> +	help
> +	  AM387x, C6A814x, AM389x, C6A816x
> +
> +config BR2_PACKAGE_TI_GFX_ES8
> +	bool "es8.x"
> +	help
> +	  AM335x
> +
> +endchoice
> +
> +endif
> +
> +comment "requires an external eglibc/glibc based toolchain"
> +	depends on !(BR2_TOOLCHAIN_EXTERNAL_GLIBC || BR2_TOOLCHAIN_CTNG_eglibc ||
> BR2_TOOLCHAIN_CTNG_glibc)
> diff --git a/package/ti-gfx/ti-gfx-km_install_modules.patch
> b/package/ti-gfx/ti-gfx-km_install_modules.patch
> new file mode 100644
> index 0000000..63bfd19
> --- /dev/null
> +++ b/package/ti-gfx/ti-gfx-km_install_modules.patch
> @@ -0,0 +1,14 @@
> +Index: ti-gfx-4_09_00_01/GFX_Linux_KM/Makefile
> +===================================================================
> +--- ti-gfx-4_09_00_01.orig/GFX_Linux_KM/Makefile	2013-03-07
> 11:00:11.000000000 -0600
> ++++ ti-gfx-4_09_00_01/GFX_Linux_KM/Makefile	2013-05-23 01:36:29.356676281
> -0500
> +@@ -479,6 +479,9 @@
> + all:
> + 	$(MAKE) -C $(KERNELDIR) M=`pwd` $*
> +
> ++install:
> ++	$(MAKE) -C $(KERNELDIR) M=`pwd` modules_install
> ++
> + clean:
> + 	@find . -name "*.o" -exec rm -r {} \;
> + 	@find . -name "*.ko" -exec rm -r {} \;
> diff --git a/package/ti-gfx/ti-gfx-newclkapi.patch
> b/package/ti-gfx/ti-gfx-newclkapi.patch
> new file mode 100644
> index 0000000..b35ac31
> --- /dev/null
> +++ b/package/ti-gfx/ti-gfx-newclkapi.patch
> @@ -0,0 +1,55 @@
> +Index:
> ti-gfx-4_09_00_01/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c
> +===================================================================
> +---
> ti-gfx-4_09_00_01.orig/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c	2013-03-04
> 08:41:35.000000000 -0600
> ++++
> ti-gfx-4_09_00_01/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c	2013-06-05
> 12:00:08.778605221 -0500
> +@@ -166,11 +166,27 @@
> + 	}
> +
> + 	PVR_DPF((PVR_DBG_MESSAGE, "EnableSGXClocks: Enabling SGX Clocks"));
> +-	
> ++   res=clk_prepare(psSysSpecData->psSGX_FCK);
> ++	if (res < 0)
> ++        {
> ++                PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable
> SGX functional clock (%d)", res));
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> ++                return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> ++        }
> ++
> + 	res=clk_enable(psSysSpecData->psSGX_FCK);
> + 	if (res < 0)
> +         {
> +                 PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable
> SGX functional clock (%d)", res));
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> ++                return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> ++        }
> ++
> ++	res=clk_prepare(psSysSpecData->psSGX_ICK);
> ++	if(res < 0)
> ++        {
> ++                PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable
> SGX functional clock (%d)", res));
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> +                 return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> +         }
> +
> +@@ -178,8 +194,9 @@
> +         if (res < 0)
> +         {
> +                 PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable
> SGX interface clock (%d)", res));
> +-
> ++                clk_unprepare(psSysSpecData->psSGX_ICK);
> +                 clk_disable(psSysSpecData->psSGX_FCK);
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> +                 return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> +         }
> +
> +@@ -247,8 +264,9 @@
> + 	PVR_DPF((PVR_DBG_MESSAGE, "DisableSGXClocks: Disabling SGX Clocks"));
> + 	
> + 	clk_disable(psSysSpecData->psSGX_FCK);
> +-
> ++	clk_unprepare(psSysSpecData->psSGX_FCK);
> + 	clk_disable(psSysSpecData->psSGX_ICK);
> ++	clk_unprepare(psSysSpecData->psSGX_ICK);
> +
> + //	SysDisableSGXInterrupts(psSysData);
> +
> diff --git a/package/ti-gfx/ti-gfx.mk b/package/ti-gfx/ti-gfx.mk
> new file mode 100644
> index 0000000..154c792
> --- /dev/null
> +++ b/package/ti-gfx/ti-gfx.mk
> @@ -0,0 +1,71 @@
> +###############################################################################
> +#
> +# ti-gfx
> +#
> +###############################################################################
> +
> +TI_GFX_VERSION = 4_09_00_01
> +TI_GFX_SOURCE =
> Graphics_SDK_setuplinux_$(TI_GFX_VERSION)_minimal_demos.bin
> +TI_GFX_SITE =
> http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/$(TI_GFX_VERSION)/exports/
> +TI_GFX_LICENSE = TSPA
> +TI_GFX_LICENSE_FILES = TSPA.txt
> +TI_GFX_INSTALL_STAGING = YES
> +
> +TI_GFX_DEPENDENCIES = linux
> +
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES3),y)
> +TI_GFX_OMAPES = 3.x
> +TI_GFX_PLATFORM = omap3
> +endif
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES5),y)
> +TI_GFX_OMAPES = 5.x
> +TI_GFX_PLATFORM = omap3630
> +endif
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES6),y)
> +TI_GFX_OMPAES = 6.x
> +TI_GFX_PLATFORM = ti81xx
> +endif
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES8),y)
> +TI_GFX_OMAPES = 8.x
> +TI_GFX_PLATFORM = ti335x
> +endif
> +
> +define TI_GFX_EXTRACT_CMDS
> +	$(RM) -rf $(TI_GFX_DIR)
> +	chmod +x $(DL_DIR)/$(TI_GFX_SOURCE)
> +	printf "Y\nY\n qY\n\n" | $(DL_DIR)/$(TI_GFX_SOURCE) \
> +		--prefix $(TI_GFX_DIR) \
> +		--mode console
> +endef
> +
> +define TI_GFX_CONFIGURE_CMDS
> +	echo "no configure required binary only package"
> +endef
> +
> +TI_GFX_MAKE_CMD = cd $(TI_GFX_SRCDIR)/GFX_Linux_KM && \
> +		$(MAKE) $(LINUX_MAKE_FLAGS) \
> +			BUILD=$(BR2_PACKAGE_TI_GFX_DEBUG) \
> +			TI_PLATFORM=$(TI_GFX_PLATFORM) \
> +			OMAPES=$(TI_GFX_OMAPES) \
> +			SUPPORT_XORG=0 \
> +			KERNELDIR=$(LINUX_DIR)
> +
> +define TI_GFX_BUILD_CMDS
> +	( $(TI_GFX_MAKE_CMD) clean && \
> +	  $(TI_GFX_MAKE_CMD) all )
> +endef
> +
> +define TI_GFX_INSTALL_STAGING_CMDS
> +	
> +endef
> +
> +define TI_GFX_INSTALL_TARGET_CMDS
> +	( $(TI_GFX_MAKE_CMD) install ) || \
> +		echo "Your kernel configuration must include FB_DA8XX"
> +endef
> +
> +define TI_GFX_CLEAN_CMDS
> +	( $(TI_GFX_MAKE_CMD) clean )
> +endef
> +
> +$(eval $(generic-package))
> --
> 1.7.1
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>


-- 
Charles Krinke

[Buildroot] [RFC] ti-gfx: add new package

[Spenser Gilliland]

Charles,


> I believe including a kernel compile with this patch is a problem for
> several reasons.

There is no kernel compile in this patch.   Only the sgx kernel modules are
built.  The make KERNELDIR=path/to/sgx/dir modules only builds the modules
in the current directory.

> The first is that the TI defconfig for AM3517_evm never made it into
> the Linux kernel along with all the supporting changes, so the build
> fails.

You can use any kernel you would like and are not bound to mainline
kernels.  If the ti kernel has the needed patches, you may use it.  The
only requirement is that the kernel is specified in the kernel
configuration section.

> The second is that folks are using various versions of Graphics_SDK
> from 4_05_xx through 4_09_xx. These same folks generally build the
> Graphics_SDK once externally to buildroot to avoid carrying a 135MB
> file in the dl/ directory. This doesnt make sense for buildroot for
> two kernel .ko modules where 135MByte is larger then any other
> package.

It has to be downloaded anyways and as long as you don't distclean often;
it will only be downloaded once.  It may make sense to provide an option to
select which version of the gfx sdk but there's no need if they maintain
backwards compatibility.

> Perhaps you can consider making Graphics_SDK an external reference in
> your patch to make things go more smoothly?

IMHO. This would complicate the process.   The method presented would allow
people with no ti-gfx experience to quickly get up and running.

Thanks,

Spenser
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130612/d2a5ab3e/attachment.html>

[Buildroot] [RFC] ti-gfx: add new package

[Charles Krinke]

Unfortunately, the patch triggers a kernel build. The current issue is
a defconfig for this kernel compile. For am AM3517, one would expect
to use AM3517_evm_defconfig which does not exist in the mainline
kernel, so the rootfs cannot be built with the patch.

Perhaps some words on *how* make it get past errors might help use
this patch, sir?


On 6/12/13, Spenser Gilliland <spenser@gillilanding.com> wrote:
> Charles,
>
>
>> I believe including a kernel compile with this patch is a problem for
>> several reasons.
>
> There is no kernel compile in this patch.   Only the sgx kernel modules are
> built.  The make KERNELDIR=path/to/sgx/dir modules only builds the modules
> in the current directory.
>
>> The first is that the TI defconfig for AM3517_evm never made it into
>> the Linux kernel along with all the supporting changes, so the build
>> fails.
>
> You can use any kernel you would like and are not bound to mainline
> kernels.  If the ti kernel has the needed patches, you may use it.  The
> only requirement is that the kernel is specified in the kernel
> configuration section.
>
>> The second is that folks are using various versions of Graphics_SDK
>> from 4_05_xx through 4_09_xx. These same folks generally build the
>> Graphics_SDK once externally to buildroot to avoid carrying a 135MB
>> file in the dl/ directory. This doesnt make sense for buildroot for
>> two kernel .ko modules where 135MByte is larger then any other
>> package.
>
> It has to be downloaded anyways and as long as you don't distclean often;
> it will only be downloaded once.  It may make sense to provide an option to
> select which version of the gfx sdk but there's no need if they maintain
> backwards compatibility.
>
>> Perhaps you can consider making Graphics_SDK an external reference in
>> your patch to make things go more smoothly?
>
> IMHO. This would complicate the process.   The method presented would allow
> people with no ti-gfx experience to quickly get up and running.
>
> Thanks,
>
> Spenser
>


-- 
Charles Krinke

[Buildroot] [RFC] ti-gfx: add new package

[Spenser Gilliland]

On Wed, Jun 12, 2013 at 12:55 PM, Charles Krinke
<charles.krinke@gmail.com> wrote:
> Unfortunately, the patch triggers a kernel build. The current issue is
> a defconfig for this kernel compile. For am AM3517, one would expect
> to use AM3517_evm_defconfig which does not exist in the mainline
> kernel, so the rootfs cannot be built with the patch.
>
> Perhaps some words on *how* make it get past errors might help use
> this patch, sir?
>
>
> On 6/12/13, Spenser Gilliland <spenser@gillilanding.com> wrote:
>> Charles,
>>
>>
>>> I believe including a kernel compile with this patch is a problem for
>>> several reasons.
>>
>> There is no kernel compile in this patch.   Only the sgx kernel modules are
>> built.  The make KERNELDIR=path/to/sgx/dir modules only builds the modules
>> in the current directory.
>>
>>> The first is that the TI defconfig for AM3517_evm never made it into
>>> the Linux kernel along with all the supporting changes, so the build
>>> fails.
>>
>> You can use any kernel you would like and are not bound to mainline
>> kernels.  If the ti kernel has the needed patches, you may use it.  The
>> only requirement is that the kernel is specified in the kernel
>> configuration section.
>>
>>> The second is that folks are using various versions of Graphics_SDK
>>> from 4_05_xx through 4_09_xx. These same folks generally build the
>>> Graphics_SDK once externally to buildroot to avoid carrying a 135MB
>>> file in the dl/ directory. This doesnt make sense for buildroot for
>>> two kernel .ko modules where 135MByte is larger then any other
>>> package.
>>
>> It has to be downloaded anyways and as long as you don't distclean often;
>> it will only be downloaded once.  It may make sense to provide an option to
>> select which version of the gfx sdk but there's no need if they maintain
>> backwards compatibility.
>>
>>> Perhaps you can consider making Graphics_SDK an external reference in
>>> your patch to make things go more smoothly?
>>
>> IMHO. This would complicate the process.   The method presented would allow
>> people with no ti-gfx experience to quickly get up and running.
>>
>> Thanks,
>>
>> Spenser
>>
>
>
> --
> Charles Krinke

Charles,

In mainline I believe AM35xx is covered by the omap2plus defconfig but
I'm not completely certain. You can also use a custom kernel location
with
LINUX_OVERRIDE_SRCDIR=/path/to/your/kernel/tree or If you obtained it
from git or a tarball, please tell me the source of your kernel and I
can help you setup the BR2_LINUX_KERNEL sections.

Thanks,
Spenser

--
Spenser Gilliland
Computer Engineer
Doctoral Candidate

[Buildroot] [RFC] ti-gfx: add new package

[Naumann Andreas]

Hi,

I'm happily jumping on integrating the egl stuff in buildroot (and qt), thanks for you start Spenser. 
As for Charles concerns, I too see the kernel build being triggered by ti-gfx, but that's natural since the modules depend on it. I have no problems with that. However, since I'm using a 3.1 kernel, the newclkapi patch broke the ti-gfx build for me. I just removed it, but maybe this can be solved better.

To go further with the qt support, I have added staging headers and libs, see patch below. I can now build qt5 with the gui module (which needs the eglfs support). However, when preparing an out of tree qt-project with buildroots qmake, the subsequent make step says it's got nothing to do. Looking into it, the SOURCES from the .pro file did not get picked up, but I have no idea why. Maybe this is another post though.

Here's my patch:


Betreff: [PATCH] ti-gfx: Install headers and libs to staging.

This enables the qt5 packages to successfully build with OpenGL / EGL support.

---
 package/ti-gfx/ti-gfx.mk | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/package/ti-gfx/ti-gfx.mk b/package/ti-gfx/ti-gfx.mk
index 154c792..1446fe5 100644
--- a/package/ti-gfx/ti-gfx.mk
+++ b/package/ti-gfx/ti-gfx.mk
@@ -30,6 +30,12 @@ TI_GFX_OMAPES = 8.x
 TI_GFX_PLATFORM = ti335x
 endif
 
+ifeq ($(BR2_PACKAGE_TI_GFX_DEBUG),y)
+TI_GFX_RELDBG = rel
+else
+TI_GFX_RELDBG = dbg
+endif
+
 define TI_GFX_EXTRACT_CMDS 
 	$(RM) -rf $(TI_GFX_DIR)
 	chmod +x $(DL_DIR)/$(TI_GFX_SOURCE)
@@ -50,13 +56,20 @@ TI_GFX_MAKE_CMD = cd $(TI_GFX_SRCDIR)/GFX_Linux_KM && \
 			SUPPORT_XORG=0 \
 			KERNELDIR=$(LINUX_DIR)
 
+TI_GFX_BIN_PATH = gfx_$(TI_GFX_RELDBG)_es$(TI_GFX_OMAPES)
+
 define TI_GFX_BUILD_CMDS
 	( $(TI_GFX_MAKE_CMD) clean && \
 	  $(TI_GFX_MAKE_CMD) all )
 endef
 
+SUB_FOLDER = EGL EWS GLES2 KHR
 define TI_GFX_INSTALL_STAGING_CMDS
-	
+	for folder in $(SUB_FOLDER); do \
+		$(INSTALL) -d $(STAGING_DIR)/usr/include/$$folder ; \
+		$(INSTALL) -D -m 0644 $(@D)/include/OGLES2/$$folder/*.h $(STAGING_DIR)/usr/include/$$folder ; \
+	done
+	$(INSTALL) -D -m 0644 $(@D)/$(TI_GFX_BIN_PATH)/*.so $(STAGING_DIR)/usr/lib
 endef
 
 define TI_GFX_INSTALL_TARGET_CMDS
-- 
1.8.2.3




------------------------------------------------------------------------------
Dipl.-Ing. (FH)
Andreas Naumann
Embedded Software
T +49 8105 77839-363
F +49 8105 77839-850
ANaumann at ultratronik.de
www.ultratronik.de
Dornierstra?e 9
82205 Gilching
ULTRATRONIK
L?SUNGEN F?R IHREN ERFOLG - SOLUTIONS FOR YOUR SUCCESS

------------------------------------------------------------------------------ 
Gesch?ftsf?hrer: Dipl.-Ing. Wolfgang Sorg, Dipl.-Kfm. Alexander Sorg
Sitz der Gesellschaft: Gilching
Registergericht M?nchen HRB 49567 (Ultratronik Vertriebs GmbH)
Registergericht M?nchen HRB 55584 (Ultratronik GmbH)

------------------------------------------------------------------------------ 



________________________________________

Von: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Im Auftrag von Spenser Gilliland
Gesendet: Mittwoch, 12. Juni 2013 19:33
An: Charles Krinke
Cc: buildroot
Betreff: Re: [Buildroot] [RFC] ti-gfx: add new package

Charles,

> I believe including a kernel compile with this patch is a problem for
> several reasons.
There is no kernel compile in this patch.   Only the sgx kernel modules are built.  The make KERNELDIR=path/to/sgx/dir modules only builds the modules in the current directory.
> The first is that the TI defconfig for AM3517_evm never made it into
> the Linux kernel along with all the supporting changes, so the build
> fails.
You can use any kernel you would like and are not bound to mainline kernels.  If the ti kernel has the needed patches, you may use it.  The only requirement is that the kernel is specified in the kernel configuration section.
> The second is that folks are using various versions of Graphics_SDK
> from 4_05_xx through 4_09_xx. These same folks generally build the
> Graphics_SDK once externally to buildroot to avoid carrying a 135MB
> file in the dl/ directory. This doesnt make sense for buildroot for
> two kernel .ko modules where 135MByte is larger then any other
> package.
It has to be downloaded anyways and as long as you don't distclean often; it will only be downloaded once.  It may make sense to provide an option to select which version of the gfx sdk but there's no need if they maintain backwards compatibility. 
> Perhaps you can consider making Graphics_SDK an external reference in
> your patch to make things go more smoothly?
IMHO. This would complicate the process.   The method presented would allow people with no ti-gfx experience to quickly get up and running.
Thanks,
Spenser

[Buildroot] [RFC] ti-gfx: add new package

[Charles Krinke]

Dear Naumann:

If you select QtQuick, you should find that the build fails on copying
qmlview in the qt5quick package make file. In looking at this, it
looks like qmlview is not part of Qt5, so it seems commenting out that
line in the package .mk file is reasonable. Perhaps you could confirm
this when you have a chance.

On Spenser's patch, my comments to the RFC remain the same and those
are 1) Graphics_SDK should not be a part of buildroot and 2) A kernel
build should be independent of the root file system.

Charles

On 6/13/13, Naumann Andreas <ANaumann@ultratronik.de> wrote:
> Hi,
>
> I'm happily jumping on integrating the egl stuff in buildroot (and qt),
> thanks for you start Spenser.
> As for Charles concerns, I too see the kernel build being triggered by
> ti-gfx, but that's natural since the modules depend on it. I have no
> problems with that. However, since I'm using a 3.1 kernel, the newclkapi
> patch broke the ti-gfx build for me. I just removed it, but maybe this can
> be solved better.
>
> To go further with the qt support, I have added staging headers and libs,
> see patch below. I can now build qt5 with the gui module (which needs the
> eglfs support). However, when preparing an out of tree qt-project with
> buildroots qmake, the subsequent make step says it's got nothing to do.
> Looking into it, the SOURCES from the .pro file did not get picked up, but I
> have no idea why. Maybe this is another post though.
>
> Here's my patch:
>
>
> Betreff: [PATCH] ti-gfx: Install headers and libs to staging.
>
> This enables the qt5 packages to successfully build with OpenGL / EGL
> support.
>
> ---
>  package/ti-gfx/ti-gfx.mk | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/package/ti-gfx/ti-gfx.mk b/package/ti-gfx/ti-gfx.mk
> index 154c792..1446fe5 100644
> --- a/package/ti-gfx/ti-gfx.mk
> +++ b/package/ti-gfx/ti-gfx.mk
> @@ -30,6 +30,12 @@ TI_GFX_OMAPES = 8.x
>  TI_GFX_PLATFORM = ti335x
>  endif
>
> +ifeq ($(BR2_PACKAGE_TI_GFX_DEBUG),y)
> +TI_GFX_RELDBG = rel
> +else
> +TI_GFX_RELDBG = dbg
> +endif
> +
>  define TI_GFX_EXTRACT_CMDS
>  	$(RM) -rf $(TI_GFX_DIR)
>  	chmod +x $(DL_DIR)/$(TI_GFX_SOURCE)
> @@ -50,13 +56,20 @@ TI_GFX_MAKE_CMD = cd $(TI_GFX_SRCDIR)/GFX_Linux_KM && \
>  			SUPPORT_XORG=0 \
>  			KERNELDIR=$(LINUX_DIR)
>
> +TI_GFX_BIN_PATH = gfx_$(TI_GFX_RELDBG)_es$(TI_GFX_OMAPES)
> +
>  define TI_GFX_BUILD_CMDS
>  	( $(TI_GFX_MAKE_CMD) clean && \
>  	  $(TI_GFX_MAKE_CMD) all )
>  endef
>
> +SUB_FOLDER = EGL EWS GLES2 KHR
>  define TI_GFX_INSTALL_STAGING_CMDS
> -	
> +	for folder in $(SUB_FOLDER); do \
> +		$(INSTALL) -d $(STAGING_DIR)/usr/include/$$folder ; \
> +		$(INSTALL) -D -m 0644 $(@D)/include/OGLES2/$$folder/*.h
> $(STAGING_DIR)/usr/include/$$folder ; \
> +	done
> +	$(INSTALL) -D -m 0644 $(@D)/$(TI_GFX_BIN_PATH)/*.so
> $(STAGING_DIR)/usr/lib
>  endef
>
>  define TI_GFX_INSTALL_TARGET_CMDS
> --
> 1.8.2.3
>
>
>
>
> ------------------------------------------------------------------------------
> Dipl.-Ing. (FH)
> Andreas Naumann
> Embedded Software
> T +49 8105 77839-363
> F +49 8105 77839-850
> ANaumann at ultratronik.de
> www.ultratronik.de
> Dornierstra?e 9
> 82205 Gilching
> ULTRATRONIK
> L?SUNGEN F?R IHREN ERFOLG - SOLUTIONS FOR YOUR SUCCESS
>
> ------------------------------------------------------------------------------
>
> Gesch?ftsf?hrer: Dipl.-Ing. Wolfgang Sorg, Dipl.-Kfm. Alexander Sorg
> Sitz der Gesellschaft: Gilching
> Registergericht M?nchen HRB 49567 (Ultratronik Vertriebs GmbH)
> Registergericht M?nchen HRB 55584 (Ultratronik GmbH)
>
> ------------------------------------------------------------------------------
>
>
>
>
> ________________________________________
>
> Von: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Im
> Auftrag von Spenser Gilliland
> Gesendet: Mittwoch, 12. Juni 2013 19:33
> An: Charles Krinke
> Cc: buildroot
> Betreff: Re: [Buildroot] [RFC] ti-gfx: add new package
>
> Charles,
>
>> I believe including a kernel compile with this patch is a problem for
>> several reasons.
> There is no kernel compile in this patch.   Only the sgx kernel modules are
> built.  The make KERNELDIR=path/to/sgx/dir modules only builds the modules
> in the current directory.
>> The first is that the TI defconfig for AM3517_evm never made it into
>> the Linux kernel along with all the supporting changes, so the build
>> fails.
> You can use any kernel you would like and are not bound to mainline kernels.
>  If the ti kernel has the needed patches, you may use it.  The only
> requirement is that the kernel is specified in the kernel configuration
> section.
>> The second is that folks are using various versions of Graphics_SDK
>> from 4_05_xx through 4_09_xx. These same folks generally build the
>> Graphics_SDK once externally to buildroot to avoid carrying a 135MB
>> file in the dl/ directory. This doesnt make sense for buildroot for
>> two kernel .ko modules where 135MByte is larger then any other
>> package.
> It has to be downloaded anyways and as long as you don't distclean often; it
> will only be downloaded once.  It may make sense to provide an option to
> select which version of the gfx sdk but there's no need if they maintain
> backwards compatibility.
>> Perhaps you can consider making Graphics_SDK an external reference in
>> your patch to make things go more smoothly?
> IMHO. This would complicate the process.   The method presented would allow
> people with no ti-gfx experience to quickly get up and running.
> Thanks,
> Spenser
>


-- 
Charles Krinke

[Buildroot] [RFC] ti-gfx: add new package

[Thomas Petazzoni]

Dear Charles Krinke,

On Thu, 13 Jun 2013 07:11:18 -0700, Charles Krinke wrote:

> On Spenser's patch, my comments to the RFC remain the same and those
> are 1) Graphics_SDK should not be a part of buildroot and 2) A kernel
> build should be independent of the root file system.

Sorry, but you're wrong on both points I believe:

 (1) The whole point of the ti-gfx package that Spenser is doing, and
     the whole point of the GSoC project Spenser is working on is
     *precisely* to create Buildroot packages for many binary blobs /
     special kernel modules that are needed to enable OpenGL, EGL and
     other similar technologies on ARM SoCs. So, we definitely want
     such packages to automatically download, extract, configure, build
     and install whatever is necessary to enable the usage of such
     technologies, and this, without requiring special intervention
     from the Buildroot user. Just like all the other packages we have.

     The fact that the Graphics_SDK thing is pretty huge to download is
     just due to the poor TI practices in terms of packaging and
     releases, and there's not much we can do about it. And anyway,
     Buildroot users willing to enable complex technologies such as
     OpenGL are most likely ready to download fairly large packages.

 (2) The Graphics_SDK contains some kernel modules. They have to be
     built against a Linux kernel tree that has been configured and
     built. The only way to do that in Buildroot is to depend on the
     'linux' package, which triggers a build of the Linux kernel. This
     is completely normal, and I really don't see how it could be done
     otherwise. That's already what we do for a number of other
     packages that contain kernel modules, such as linux-fusion,
     lttng-modules or rtai.

     So the build of the root filesystem (which contains kernel
     modules) cannot be fully independent from the build of the kernel.

It would be interesting if you could expand on why (1) or (2) are
causing problems for you, in the light of the above explanations.

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [RFC] ti-gfx: add new package

[Charles Krinke]

Dear Thomas:

Behind my comments is the issue of TI's practices and I hope we dont
make it worse by tweaking buildroot in an unusual direction, but I
will, as usual, follow your lead.

My perspective is from working with the TI AM3517_evm for the last
year. One of the issues is the fact that TI supplies their kernel
source out-of-tree as a distribution release. As a consequence no one
cannot expect kernel.org kernels to work properly for at least this
reference design.  That is, the TI kernel modifications never made it
into the mainline kernel, so we have a non-kernel.org situation to
start with. This should cause buildroot to tread carefully unless we
also get the patches from TI that change a standard kernel into a
TI-special kernel.

On the Graphics_SDK, since this is a product that TI releases along
with their kernel from time-to-time. Since this is also not an
opensource project, I have some angst with patching the released
Graphics_SDK. This doesnt make any sense to me since this product
along with the kernel are releases from TI.

So, I guess the key issue is mixing distribution releases from a
vendor with traditional, well-known opensource projects and how
buildroot can best move forward.



On 6/14/13, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Dear Charles Krinke,
>
> On Thu, 13 Jun 2013 07:11:18 -0700, Charles Krinke wrote:
>
>> On Spenser's patch, my comments to the RFC remain the same and those
>> are 1) Graphics_SDK should not be a part of buildroot and 2) A kernel
>> build should be independent of the root file system.
>
> Sorry, but you're wrong on both points I believe:
>
>  (1) The whole point of the ti-gfx package that Spenser is doing, and
>      the whole point of the GSoC project Spenser is working on is
>      *precisely* to create Buildroot packages for many binary blobs /
>      special kernel modules that are needed to enable OpenGL, EGL and
>      other similar technologies on ARM SoCs. So, we definitely want
>      such packages to automatically download, extract, configure, build
>      and install whatever is necessary to enable the usage of such
>      technologies, and this, without requiring special intervention
>      from the Buildroot user. Just like all the other packages we have.
>
>      The fact that the Graphics_SDK thing is pretty huge to download is
>      just due to the poor TI practices in terms of packaging and
>      releases, and there's not much we can do about it. And anyway,
>      Buildroot users willing to enable complex technologies such as
>      OpenGL are most likely ready to download fairly large packages.
>
>  (2) The Graphics_SDK contains some kernel modules. They have to be
>      built against a Linux kernel tree that has been configured and
>      built. The only way to do that in Buildroot is to depend on the
>      'linux' package, which triggers a build of the Linux kernel. This
>      is completely normal, and I really don't see how it could be done
>      otherwise. That's already what we do for a number of other
>      packages that contain kernel modules, such as linux-fusion,
>      lttng-modules or rtai.
>
>      So the build of the root filesystem (which contains kernel
>      modules) cannot be fully independent from the build of the kernel.
>
> It would be interesting if you could expand on why (1) or (2) are
> causing problems for you, in the light of the above explanations.
>
> Best regards,
>
> Thomas Petazzoni
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>


-- 
Charles Krinke

[Buildroot] [RFC] ti-gfx: add new package

[Yann E. MORIN]

Charles, All,

On 2013-06-14 13:58 -0700, Charles Krinke spake thusly:
> Behind my comments is the issue of TI's practices and I hope we dont
> make it worse by tweaking buildroot in an unusual direction, but I
> will, as usual, follow your lead.

Hmm. I guess we *do* want to hear opinions like yours. That's what in
the end shapes what Buildroot is, and where it goes.

Then, any enhancement should be done in a way that follows the Buildroot
"philosophy" (which is rather not-so-well defined, although the great
lines revolves around KISS, basically, and easiness for the user).

> My perspective is from working with the TI AM3517_evm for the last
> year.

Getting input from people that have experience on the topic is very good
to have. Thank you! :-)

> One of the issues is the fact that TI supplies their kernel
> source out-of-tree as a distribution release. As a consequence no one
> cannot expect kernel.org kernels to work properly for at least this
> reference design.

There has never been such expectation expressed.

Also, we already have some defconfig for some boards where the kernel is
not retrieved from k.org, but from a third-party. For example, the
RaspberryPi defconfig points to the github clone/fork that has RPi
support, and not to k.org.

I can't see a reason not to provide such a defconfig for other boards.

Unless it is no possible to easily retrieve the kernel from that TI
packaging /mess/.

> That is, the TI kernel modifications never made it
> into the mainline kernel, so we have a non-kernel.org situation to
> start with. This should cause buildroot to tread carefully unless we
> also get the patches from TI that change a standard kernel into a
> TI-special kernel.

There is no way Buildroot carries such patches, indeed. Either the user
starts up with the defconfig, or is versed enough to point Buildroot to
use a TI-ready kernel.

> On the Graphics_SDK, since this is a product that TI releases along
> with their kernel from time-to-time. Since this is also not an
> opensource project, I have some angst with patching the released
> Graphics_SDK. This doesnt make any sense to me since this product
> along with the kernel are releases from TI.

Buildroot has a very good infrastructure for declaring licensing
information per-package, and preparing a manifest of such licensing
terms for the user to *review* (and not trust blindly), and decide
whether the licenses combination is valid for him, in his jurisdiction,
for his use-case, and so on...

The Graphics_SDK will *not* be bundled in Buildroot; it's only the user's
actions that will trigger a download/build/install of the Graphics_SDK
source code and binary blobs to his rootfs.

> So, I guess the key issue is mixing distribution releases from a
> vendor with traditional, well-known opensource projects and how
> buildroot can best move forward.

Licensing infrastrucuture, my friend! :-)

    make legal-info

Regards,
Yann E. MORIN

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC] ti-gfx: add new package

[Thomas Petazzoni]

Dear Charles Krinke,

On Fri, 14 Jun 2013 13:58:57 -0700, Charles Krinke wrote:

> Behind my comments is the issue of TI's practices and I hope we dont
> make it worse by tweaking buildroot in an unusual direction, but I
> will, as usual, follow your lead.
> 
> My perspective is from working with the TI AM3517_evm for the last
> year. One of the issues is the fact that TI supplies their kernel
> source out-of-tree as a distribution release. As a consequence no one
> cannot expect kernel.org kernels to work properly for at least this
> reference design.  That is, the TI kernel modifications never made it
> into the mainline kernel, so we have a non-kernel.org situation to
> start with. This should cause buildroot to tread carefully unless we
> also get the patches from TI that change a standard kernel into a
> TI-special kernel.

As Yann already highlighted, we already have in Buildroot several cases
where we're using other kernels than the mainline one: the
rpi_defconfig, phy3250_defconfig, nitrogen6x_defconfig,
gnublin_defconfig, ea3250_defconfig, fdi3250_defconfig,
beaglebone_defconfig, arm_foundationv8_defconfig. All of these default
configurations are using special kernel trees from custom Git trees. I
believe we clearly would all prefer the support for those platforms to
be available in the mainline Linux kernel, but on the other hand, when
one has an embedded Linux project to make, one isn't necessarily given
the time required to mainline the entire kernel support for the
hardware platform.

Another example are the Freescale specific libraries packaged in
package/freescale-imx/. From package/freescale-imx/imx-lib/Config.in:

comment "imx-lib needs an imx-specific kernel to be built"
        depends on BR2_arm && !BR2_LINUX_KERNEL

config BR2_PACKAGE_IMX_LIB
        bool "imx-lib"
        depends on BR2_LINUX_KERNEL
        depends on BR2_arm # Only relevant for i.MX
        help
          Library of userspace helpers specific for the Freescale i.MX
          platform. It wraps the kernel interfaces for some i.MX platform
          specific drivers. It requires a kernel that includes the i.MX
          specific headers to be built.

          This library is provided by Freescale as-is and doesn't have
          an upstream.

The TI-specific kernel modules needed to enable graphics features fall
in exactly the same category, and I don't see why we wouldn't support
them in Buildroot.

Again, having fully open-source and mainline support for those graphics
features would be a lot better, but we also have for now to live with
what exists, and allow Buildroot users to easily enable OpenGL and
similar technologies when they do AM3xxx or OMAP3 based projects.

> On the Graphics_SDK, since this is a product that TI releases along
> with their kernel from time-to-time. Since this is also not an
> opensource project, I have some angst with patching the released
> Graphics_SDK. This doesnt make any sense to me since this product
> along with the kernel are releases from TI.

I'm still not sure to understand your concerns. Is it a licensing
concern? A Buildroot packaging complexity concern? Something else?

> So, I guess the key issue is mixing distribution releases from a
> vendor with traditional, well-known opensource projects and how
> buildroot can best move forward.

My vision is that Buildroot already has pretty good support for many of
the well-known opensource projects used in embedded systems, and the
community has been very good at maintaining and increasing a large
number of such packages. However, one area where I believe Buildroot is
lacking is in supporting the multimedia features of many ARM SoCs, and
even though today such features are generally supported through
specific kernels and binary-only libraries, having support for such
features in Buildroot is important if we want Buildroot to remain
relevant for embedded systems where those features are needed.

Of course, I'm all open to listen to your concerns, and I'm interested
in understanding in more details what your concerns are.

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [RFC] ti-gfx: add new package

[Sundareson, Prabindh]

Hello Thomas, Spenser,

You can try the installer package without any demos (I saw that the recipe is using the package with minimaldemos), and it should reduce size by another 30 MB. The reason for the larger size is due to the fact that the SDK has to support different cores that customers might have on the chipsets they use.

>>     The fact that the Graphics_SDK thing is pretty huge to download is      just due to the poor TI practices in terms of packaging and      releases, and there's not much we can do about it.

regards,
Prabu


-----Original Message-----
From: buildroot-bounces@busybox.net [mailto:buildroot-bounces at busybox.net] On Behalf Of Thomas Petazzoni
Sent: Saturday, June 15, 2013 1:53 AM
To: Charles Krinke
Cc: buildroot
Subject: Re: [Buildroot] [RFC] ti-gfx: add new package

Dear Charles Krinke,

On Thu, 13 Jun 2013 07:11:18 -0700, Charles Krinke wrote:

> On Spenser's patch, my comments to the RFC remain the same and those 
> are 1) Graphics_SDK should not be a part of buildroot and 2) A kernel 
> build should be independent of the root file system.

Sorry, but you're wrong on both points I believe:

 (1) The whole point of the ti-gfx package that Spenser is doing, and
     the whole point of the GSoC project Spenser is working on is
     *precisely* to create Buildroot packages for many binary blobs /
     special kernel modules that are needed to enable OpenGL, EGL and
     other similar technologies on ARM SoCs. So, we definitely want
     such packages to automatically download, extract, configure, build
     and install whatever is necessary to enable the usage of such
     technologies, and this, without requiring special intervention
     from the Buildroot user. Just like all the other packages we have.

     The fact that the Graphics_SDK thing is pretty huge to download is
     just due to the poor TI practices in terms of packaging and
     releases, and there's not much we can do about it. And anyway,
     Buildroot users willing to enable complex technologies such as
     OpenGL are most likely ready to download fairly large packages.

 (2) The Graphics_SDK contains some kernel modules. They have to be
     built against a Linux kernel tree that has been configured and
     built. The only way to do that in Buildroot is to depend on the
     'linux' package, which triggers a build of the Linux kernel. This
     is completely normal, and I really don't see how it could be done
     otherwise. That's already what we do for a number of other
     packages that contain kernel modules, such as linux-fusion,
     lttng-modules or rtai.

     So the build of the root filesystem (which contains kernel
     modules) cannot be fully independent from the build of the kernel.

It would be interesting if you could expand on why (1) or (2) are causing problems for you, in the light of the above explanations.

Best regards,

Thomas Petazzoni
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [RFC] ti-gfx: add new package

[Spenser Gilliland]

Hi Naumann,

Thanks for working on this patch.  Hopefully, this cleaned up and
included in the next release.

> I'm happily jumping on integrating the egl stuff in buildroot (and qt), thanks for you start Spenser.
> As for Charles concerns, I too see the kernel build being triggered by ti-gfx, but that's natural since the modules depend on it. I have no problems with that. However, since I'm using a 3.1 kernel, the newclkapi patch broke the ti-gfx build for me. I just removed it, but maybe this can be solved better.

To solve this problem, an ifdef on the kernel version should be done.
I'll try to figure out which version incorporated the clock changes
and add this to the patch.

> To go further with the qt support, I have added staging headers and libs, see patch below. I can now build qt5 with the gui module (which needs the eglfs support). However, when preparing an out of tree qt-project with buildroots qmake, the subsequent make step says it's got nothing to do. Looking into it, the SOURCES from the .pro file did not get picked up, but I have no idea why. Maybe this is another post though.

I'll leave this one for someone more experience in QT and I agree that
this issue does seem external to the inclusion of the ti-gfx package.

The patch below looks good to me.  I'm hoping to get some run time
testing on a couple of boards (Beagleboard xM/Beaglebone Black) done
by next week.  Then, this patch should be ready for inclusion or at
least moving to a proper patch review.

Thanks,

Spenser

--
Spenser Gilliland
Computer Engineer
Doctoral Candidate

[Buildroot] [RFC] ti-gfx: add new package

[Andreas Naumann]

Hi Spenser,

Am 13.06.2013 16:58, schrieb Spenser Gilliland:
> Hi Naumann,
>
> Thanks for working on this patch.  Hopefully, this cleaned up and
> included in the next release.
>
>> I'm happily jumping on integrating the egl stuff in buildroot (and qt), thanks for you start Spenser.
>> As for Charles concerns, I too see the kernel build being triggered by ti-gfx, but that's natural since the modules depend on it. I have no problems with that. However, since I'm using a 3.1 kernel, the newclkapi patch broke the ti-gfx build for me. I just removed it, but maybe this can be solved better.
>
> To solve this problem, an ifdef on the kernel version should be done.
> I'll try to figure out which version incorporated the clock changes
> and add this to the patch.

It came in in 3.2.

>
>> To go further with the qt support, I have added staging headers and libs, see patch below. I can now build qt5 with the gui module (which needs the eglfs support). However, when preparing an out of tree qt-project with buildroots qmake, the subsequent make step says it's got nothing to do. Looking into it, the SOURCES from the .pro file did not get picked up, but I have no idea why. Maybe this is another post though.
>
> I'll leave this one for someone more experience in QT and I agree that
> this issue does seem external to the inclusion of the ti-gfx package.
>
> The patch below looks good to me.  I'm hoping to get some run time
> testing on a couple of boards (Beagleboard xM/Beaglebone Black) done
> by next week.  Then, this patch should be ready for inclusion or at
> least moving to a proper patch review.

I'm a little on hold until I get further with the qmake issue, but I'm 
thinking about further integrating the target install step. How can we 
work together on this? I mean, in case you (or I) want to incorporate 
Arnouts comments and then go further?

cheers,
Andreas


>
> Thanks,
>
> Spenser
>
> --
> Spenser Gilliland
> Computer Engineer
> Doctoral Candidate
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>

[Buildroot] [RFC] ti-gfx: add new package

[Spenser Gilliland]

Naumann,

>> To solve this problem, an ifdef on the kernel version should be done.
>> I'll try to figure out which version incorporated the clock changes
>> and add this to the patch.
>
>
> It came in in 3.2.

Great.  I'll add this to the patch.

>
> I'm a little on hold until I get further with the qmake issue, but I'm
> thinking about further integrating the target install step. How can we work
> together on this? I mean, in case you (or I) want to incorporate Arnouts
> comments and then go further?

I'm usually much more on top of things.  Last week I had to get a
paper done so I had to put this project on the back burner.  I'm going
to incoporate all the changes suggested and hopefully have a new patch
out by this afternoon (CST). Everything will be available from the
beaglxm branch of my github repo at
http://github.com/Spenser309/buildroot and the new patch will be sent
to the list.

Spenser

--
Spenser Gilliland
Computer Engineer
Doctoral Candidate

[Buildroot] [RFC] ti-gfx: add new package

[Arnout Vandecappelle]

  Hi Spenser,

On 07/06/13 22:18, Spenser Gilliland wrote:
> This is WIP of adding the TI Graphics SDK to buildroot.
>
> TODO:
>     Install startup files for sgx core.
>     Install khronos gles/egl/vg libraries.
>     Create .pc files to simplfy additional packaging.
>     Testing, lots of testing.
>
> ---
>   package/Config.in                              |    1 +
>   package/opengl/libegl/libegl.mk                |    4 +
>   package/opengl/libgles/libgles.mk              |    4 +
>   package/opengl/libopenvg/libopenvg.mk          |    4 +
>   package/ti-gfx/Config.in                       |   54 ++++++++++++++++++
>   package/ti-gfx/ti-gfx-km_install_modules.patch |   14 +++++
>   package/ti-gfx/ti-gfx-newclkapi.patch          |   55 ++++++++++++++++++
>   package/ti-gfx/ti-gfx.mk                       |   71 ++++++++++++++++++++++++
>   8 files changed, 207 insertions(+), 0 deletions(-)
>   create mode 100644 package/ti-gfx/Config.in
>   create mode 100644 package/ti-gfx/ti-gfx-km_install_modules.patch
>   create mode 100644 package/ti-gfx/ti-gfx-newclkapi.patch
>   create mode 100644 package/ti-gfx/ti-gfx.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index ce82e99..8c40b56 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -290,6 +290,7 @@ source "package/snowball-hdmiservice/Config.in"
>   source "package/sredird/Config.in"
>   source "package/statserial/Config.in"
>   source "package/sysstat/Config.in"
> +source "package/ti-gfx/Config.in"

  Don't we usually put this kind of stuff under Libraries / Graphics?

>   source "package/ti-utils/Config.in"
>   source "package/uboot-tools/Config.in"
>   source "package/udev/Config.in"
[snip]
> diff --git a/package/ti-gfx/Config.in b/package/ti-gfx/Config.in
> new file mode 100644
> index 0000000..c3ac984
> --- /dev/null
> +++ b/package/ti-gfx/Config.in
> @@ -0,0 +1,54 @@
> +config BR2_PACKAGE_TI_GFX
> +	bool "ti-gfx"
> +	select BR2_LINUX_KERNEL
> +	select BR2_PACKAGE_DEVMEM2

  Why is this needed?

> +	select BR2_PACKAGE_HAS_OPENGL_EGL
> +	select BR2_PACKAGE_HAS_OPENGL_ES
> +	depends on BR2_TOOLCHAIN_EXTERNAL_GLIBC || BR2_TOOLCHAIN_CTNG_eglibc || BR2_TOOLCHAIN_CTNG_glibc
> +	help
> +	  Graphics libraries for TI boards.
> +
> +	  http://downloads.ti.com/dsps/dsps_public_sw/gfxsdk/
> +
> +if BR2_PACKAGE_TI_GFX
> +
> +config BR2_PACKAGE_TI_GFX_DEBUG
> +	bool "enable debug support"
> +	help
> +	  Turn on debugging in kernel module and install libraries built with
> +	  debugging enabled
> +
> +choice
> +	prompt "Target"
> +	default BR2_PACKAGE_TI_GFX_OMAP3

  I guess you mean _ES3

> +	help
> +	  Select the SOC for which you would like to install drivers. Please
> +	  use the chart at
> +	  http://processors.wiki.ti.com/index.php/OMAP35x_Graphics_SDK_Getting_Started_Guide
> +
> +config BR2_PACKAGE_TI_GFX_ES3
> +	bool "es3.x"
> +	help
> +	 OMAP35xx, AM35xx Rev 3.1+
> +
> +config BR2_PACKAGE_TI_GFX_ES5
> +	bool "es5.x"
> +	help
> +	  AM37xx, DM37xx
> +
> +config BR2_PACKAGE_TI_GFX_ES6
> +	bool "es6.x"
> +	help
> +	  AM387x, C6A814x, AM389x, C6A816x
> +
> +config BR2_PACKAGE_TI_GFX_ES8
> +	bool "es8.x"
> +	help
> +	  AM335x
> +
> +endchoice
> +
> +endif
> +
> +comment "requires an external eglibc/glibc based toolchain"
  You must say that ti-gfx requires it, because the config option is not 
visible when there's no glibc.

> +	depends on !(BR2_TOOLCHAIN_EXTERNAL_GLIBC || BR2_TOOLCHAIN_CTNG_eglibc || BR2_TOOLCHAIN_CTNG_glibc)

  We really should refactor this into a single symbol...


> diff --git a/package/ti-gfx/ti-gfx-km_install_modules.patch b/package/ti-gfx/ti-gfx-km_install_modules.patch
> new file mode 100644
> index 0000000..63bfd19
> --- /dev/null
> +++ b/package/ti-gfx/ti-gfx-km_install_modules.patch
> @@ -0,0 +1,14 @@
> +Index: ti-gfx-4_09_00_01/GFX_Linux_KM/Makefile
> +===================================================================
> +--- ti-gfx-4_09_00_01.orig/GFX_Linux_KM/Makefile	2013-03-07 11:00:11.000000000 -0600
> ++++ ti-gfx-4_09_00_01/GFX_Linux_KM/Makefile	2013-05-23 01:36:29.356676281 -0500
> +@@ -479,6 +479,9 @@
> + all:
> + 	$(MAKE) -C $(KERNELDIR) M=`pwd` $*
> +
> ++install:
> ++	$(MAKE) -C $(KERNELDIR) M=`pwd` modules_install
> ++

  Actually, instead of patching the Makefile, you could just run the 
kernel make command directly from buildroot's .mk file. I think there are 
a few module packages that do that.

> + clean:
> + 	@find . -name "*.o" -exec rm -r {} \;
> + 	@find . -name "*.ko" -exec rm -r {} \;
> diff --git a/package/ti-gfx/ti-gfx-newclkapi.patch b/package/ti-gfx/ti-gfx-newclkapi.patch
> new file mode 100644
> index 0000000..b35ac31
> --- /dev/null
> +++ b/package/ti-gfx/ti-gfx-newclkapi.patch
> @@ -0,0 +1,55 @@

  This patch is missing an explanation and a SoB.

> +Index: ti-gfx-4_09_00_01/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c
> +===================================================================
> +--- ti-gfx-4_09_00_01.orig/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c	2013-03-04 08:41:35.000000000 -0600
> ++++ ti-gfx-4_09_00_01/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c	2013-06-05 12:00:08.778605221 -0500
> +@@ -166,11 +166,27 @@
> + 	}
> +
> + 	PVR_DPF((PVR_DBG_MESSAGE, "EnableSGXClocks: Enabling SGX Clocks"));
> +-	
> ++   res=clk_prepare(psSysSpecData->psSGX_FCK);
> ++	if (res < 0)
> ++        {
> ++                PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable SGX functional clock (%d)", res));
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> ++                return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> ++        }
> ++
> + 	res=clk_enable(psSysSpecData->psSGX_FCK);
> + 	if (res < 0)
> +         {
> +                 PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable SGX functional clock (%d)", res));
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> ++                return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> ++        }
> ++
> ++	res=clk_prepare(psSysSpecData->psSGX_ICK);
> ++	if(res < 0)
> ++        {
> ++                PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable SGX functional clock (%d)", res));
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> +                 return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> +         }
> +
> +@@ -178,8 +194,9 @@
> +         if (res < 0)
> +         {
> +                 PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable SGX interface clock (%d)", res));
> +-
> ++                clk_unprepare(psSysSpecData->psSGX_ICK);
> +                 clk_disable(psSysSpecData->psSGX_FCK);
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> +                 return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> +         }
> +
> +@@ -247,8 +264,9 @@
> + 	PVR_DPF((PVR_DBG_MESSAGE, "DisableSGXClocks: Disabling SGX Clocks"));
> + 	
> + 	clk_disable(psSysSpecData->psSGX_FCK);
> +-
> ++	clk_unprepare(psSysSpecData->psSGX_FCK);
> + 	clk_disable(psSysSpecData->psSGX_ICK);
> ++	clk_unprepare(psSysSpecData->psSGX_ICK);
> +
> + //	SysDisableSGXInterrupts(psSysData);
> +
> diff --git a/package/ti-gfx/ti-gfx.mk b/package/ti-gfx/ti-gfx.mk
> new file mode 100644
> index 0000000..154c792
> --- /dev/null
> +++ b/package/ti-gfx/ti-gfx.mk
> @@ -0,0 +1,71 @@
> +###############################################################################
> +#
> +# ti-gfx
> +#
> +###############################################################################
> +
> +TI_GFX_VERSION = 4_09_00_01
> +TI_GFX_SOURCE = Graphics_SDK_setuplinux_$(TI_GFX_VERSION)_minimal_demos.bin
> +TI_GFX_SITE = http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/$(TI_GFX_VERSION)/exports/
> +TI_GFX_LICENSE = TSPA

  This is not one of the well-known licenses, so should be expanded to 
"Texas Instruments Software Piracy Agreement" or whatever it stands for.

> +TI_GFX_LICENSE_FILES = TSPA.txt
> +TI_GFX_INSTALL_STAGING = YES
> +
> +TI_GFX_DEPENDENCIES = linux
> +
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES3),y)
> +TI_GFX_OMAPES = 3.x
> +TI_GFX_PLATFORM = omap3
> +endif
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES5),y)
> +TI_GFX_OMAPES = 5.x
> +TI_GFX_PLATFORM = omap3630
> +endif
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES6),y)
> +TI_GFX_OMPAES = 6.x
> +TI_GFX_PLATFORM = ti81xx
> +endif
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES8),y)
> +TI_GFX_OMAPES = 8.x
> +TI_GFX_PLATFORM = ti335x
> +endif

  Personally I prefer to do "case statements" like this in the Config.in, 
but it's a minor thing.

> +
> +define TI_GFX_EXTRACT_CMDS
> +	$(RM) -rf $(TI_GFX_DIR)

  We normally don't do that. Is it needed (i.e. does it fail if you don't 
and the source was already extracted before)?

  Also, use $(@D) instead of $(TI_GFX_DIR).

> +	chmod +x $(DL_DIR)/$(TI_GFX_SOURCE)
> +	printf "Y\nY\n qY\n\n" | $(DL_DIR)/$(TI_GFX_SOURCE) \
> +		--prefix $(TI_GFX_DIR) \
> +		--mode console
> +endef
> +
> +define TI_GFX_CONFIGURE_CMDS
> +	echo "no configure required binary only package"

  Just don't define it then.

> +endef
> +
> +TI_GFX_MAKE_CMD = cd $(TI_GFX_SRCDIR)/GFX_Linux_KM && \
> +		$(MAKE) $(LINUX_MAKE_FLAGS) \
> +			BUILD=$(BR2_PACKAGE_TI_GFX_DEBUG) \
> +			TI_PLATFORM=$(TI_GFX_PLATFORM) \
> +			OMAPES=$(TI_GFX_OMAPES) \
> +			SUPPORT_XORG=0 \
> +			KERNELDIR=$(LINUX_DIR)

  We normally only set the make flags, e.g.

TI_GFX_MAKE_OPTS = $(LINUX_MAKE_FLAGS) \
	...

and the build commands become

	$(MAKE) -C $(@D) $(TI_GFX_MAKE_OPTS) all

> +
> +define TI_GFX_BUILD_CMDS
> +	( $(TI_GFX_MAKE_CMD) clean && \

  Is the clean really needed? We normally don't.

  Also don't connect commands with && unless they really need to be 
executed in the same sub-shell.

> +	  $(TI_GFX_MAKE_CMD) all )
> +endef
> +
> +define TI_GFX_INSTALL_STAGING_CMDS
> +	

  If you have nothing to install than you shouldn't install to staging :-)

> +endef
> +
> +define TI_GFX_INSTALL_TARGET_CMDS
> +	( $(TI_GFX_MAKE_CMD) install ) || \

  Don't you need to pass TARGET_DIR anywhere?

> +		echo "Your kernel configuration must include FB_DA8XX"

  I think that should be checked by observing the kernel's .config in the 
CONFIGURE_CMDS.

  Ideally, it would be enabled automatically but I don't think we can do 
that at the moment.

> +endef
> +
> +define TI_GFX_CLEAN_CMDS
> +	( $(TI_GFX_MAKE_CMD) clean )
> +endef

  Clean is going to be deprecated so you don't need to add it. But I 
guess you're using it a lot now...

> +
> +$(eval $(generic-package))
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [RFC] ti-gfx: add new package

[Sundareson, Prabindh]

In case it helps the discussion,


1. TSPA stands for "Technology / Software Publicly Available"

>> > +TI_GFX_LICENSE = TSPA
>>  This is not one of the well-known licenses, so should be expanded to ...



2. devmem2 is used for querying the version of the SGX core at runtime to do the right initialization

> +	select BR2_PACKAGE_DEVMEM2
>>  Why is this needed?


regards,
Prabu



-----Original Message-----
From: buildroot-bounces@busybox.net [mailto:buildroot-bounces at busybox.net] On Behalf Of Arnout Vandecappelle
Sent: Thursday, June 13, 2013 10:20 PM
To: Spenser Gilliland
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] [RFC] ti-gfx: add new package

  Hi Spenser,

On 07/06/13 22:18, Spenser Gilliland wrote:
> This is WIP of adding the TI Graphics SDK to buildroot.
>
> TODO:
>     Install startup files for sgx core.
>     Install khronos gles/egl/vg libraries.
>     Create .pc files to simplfy additional packaging.
>     Testing, lots of testing.
>
> ---
>   package/Config.in                              |    1 +
>   package/opengl/libegl/libegl.mk                |    4 +
>   package/opengl/libgles/libgles.mk              |    4 +
>   package/opengl/libopenvg/libopenvg.mk          |    4 +
>   package/ti-gfx/Config.in                       |   54 ++++++++++++++++++
>   package/ti-gfx/ti-gfx-km_install_modules.patch |   14 +++++
>   package/ti-gfx/ti-gfx-newclkapi.patch          |   55 ++++++++++++++++++
>   package/ti-gfx/ti-gfx.mk                       |   71 ++++++++++++++++++++++++
>   8 files changed, 207 insertions(+), 0 deletions(-)
>   create mode 100644 package/ti-gfx/Config.in
>   create mode 100644 package/ti-gfx/ti-gfx-km_install_modules.patch
>   create mode 100644 package/ti-gfx/ti-gfx-newclkapi.patch
>   create mode 100644 package/ti-gfx/ti-gfx.mk
>
> diff --git a/package/Config.in b/package/Config.in index 
> ce82e99..8c40b56 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -290,6 +290,7 @@ source "package/snowball-hdmiservice/Config.in"
>   source "package/sredird/Config.in"
>   source "package/statserial/Config.in"
>   source "package/sysstat/Config.in"
> +source "package/ti-gfx/Config.in"

  Don't we usually put this kind of stuff under Libraries / Graphics?

>   source "package/ti-utils/Config.in"
>   source "package/uboot-tools/Config.in"
>   source "package/udev/Config.in"
[snip]
> diff --git a/package/ti-gfx/Config.in b/package/ti-gfx/Config.in new 
> file mode 100644 index 0000000..c3ac984
> --- /dev/null
> +++ b/package/ti-gfx/Config.in
> @@ -0,0 +1,54 @@
> +config BR2_PACKAGE_TI_GFX
> +	bool "ti-gfx"
> +	select BR2_LINUX_KERNEL
> +	select BR2_PACKAGE_DEVMEM2

  Why is this needed?

> +	select BR2_PACKAGE_HAS_OPENGL_EGL
> +	select BR2_PACKAGE_HAS_OPENGL_ES
> +	depends on BR2_TOOLCHAIN_EXTERNAL_GLIBC || BR2_TOOLCHAIN_CTNG_eglibc || BR2_TOOLCHAIN_CTNG_glibc
> +	help
> +	  Graphics libraries for TI boards.
> +
> +	  http://downloads.ti.com/dsps/dsps_public_sw/gfxsdk/
> +
> +if BR2_PACKAGE_TI_GFX
> +
> +config BR2_PACKAGE_TI_GFX_DEBUG
> +	bool "enable debug support"
> +	help
> +	  Turn on debugging in kernel module and install libraries built with
> +	  debugging enabled
> +
> +choice
> +	prompt "Target"
> +	default BR2_PACKAGE_TI_GFX_OMAP3

  I guess you mean _ES3

> +	help
> +	  Select the SOC for which you would like to install drivers. Please
> +	  use the chart at
> +	  
> +http://processors.wiki.ti.com/index.php/OMAP35x_Graphics_SDK_Getting_
> +Started_Guide
> +
> +config BR2_PACKAGE_TI_GFX_ES3
> +	bool "es3.x"
> +	help
> +	 OMAP35xx, AM35xx Rev 3.1+
> +
> +config BR2_PACKAGE_TI_GFX_ES5
> +	bool "es5.x"
> +	help
> +	  AM37xx, DM37xx
> +
> +config BR2_PACKAGE_TI_GFX_ES6
> +	bool "es6.x"
> +	help
> +	  AM387x, C6A814x, AM389x, C6A816x
> +
> +config BR2_PACKAGE_TI_GFX_ES8
> +	bool "es8.x"
> +	help
> +	  AM335x
> +
> +endchoice
> +
> +endif
> +
> +comment "requires an external eglibc/glibc based toolchain"
  You must say that ti-gfx requires it, because the config option is not visible when there's no glibc.

> +	depends on !(BR2_TOOLCHAIN_EXTERNAL_GLIBC || 
> +BR2_TOOLCHAIN_CTNG_eglibc || BR2_TOOLCHAIN_CTNG_glibc)

  We really should refactor this into a single symbol...


> diff --git a/package/ti-gfx/ti-gfx-km_install_modules.patch 
> b/package/ti-gfx/ti-gfx-km_install_modules.patch
> new file mode 100644
> index 0000000..63bfd19
> --- /dev/null
> +++ b/package/ti-gfx/ti-gfx-km_install_modules.patch
> @@ -0,0 +1,14 @@
> +Index: ti-gfx-4_09_00_01/GFX_Linux_KM/Makefile
> +===================================================================
> +--- ti-gfx-4_09_00_01.orig/GFX_Linux_KM/Makefile	2013-03-07 11:00:11.000000000 -0600
> ++++ ti-gfx-4_09_00_01/GFX_Linux_KM/Makefile	2013-05-23 01:36:29.356676281 -0500
> +@@ -479,6 +479,9 @@
> + all:
> + 	$(MAKE) -C $(KERNELDIR) M=`pwd` $*
> +
> ++install:
> ++	$(MAKE) -C $(KERNELDIR) M=`pwd` modules_install
> ++

  Actually, instead of patching the Makefile, you could just run the kernel make command directly from buildroot's .mk file. I think there are a few module packages that do that.

> + clean:
> + 	@find . -name "*.o" -exec rm -r {} \;
> + 	@find . -name "*.ko" -exec rm -r {} \;
> diff --git a/package/ti-gfx/ti-gfx-newclkapi.patch 
> b/package/ti-gfx/ti-gfx-newclkapi.patch
> new file mode 100644
> index 0000000..b35ac31
> --- /dev/null
> +++ b/package/ti-gfx/ti-gfx-newclkapi.patch
> @@ -0,0 +1,55 @@

  This patch is missing an explanation and a SoB.

> +Index: 
> +ti-gfx-4_09_00_01/GFX_Linux_KM/services4/system/omap3630/sysutils_lin
> +ux.c 
> +===================================================================
> +--- ti-gfx-4_09_00_01.orig/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c	2013-03-04 08:41:35.000000000 -0600
> ++++ ti-gfx-4_09_00_01/GFX_Linux_KM/services4/system/omap3630/sysutils_linux.c	2013-06-05 12:00:08.778605221 -0500
> +@@ -166,11 +166,27 @@
> + 	}
> +
> + 	PVR_DPF((PVR_DBG_MESSAGE, "EnableSGXClocks: Enabling SGX Clocks"));
> +-	
> ++   res=clk_prepare(psSysSpecData->psSGX_FCK);
> ++	if (res < 0)
> ++        {
> ++                PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable SGX functional clock (%d)", res));
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> ++                return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> ++        }
> ++
> + 	res=clk_enable(psSysSpecData->psSGX_FCK);
> + 	if (res < 0)
> +         {
> +                 PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't 
> + enable SGX functional clock (%d)", res));
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> ++                return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> ++        }
> ++
> ++	res=clk_prepare(psSysSpecData->psSGX_ICK);
> ++	if(res < 0)
> ++        {
> ++                PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't enable SGX functional clock (%d)", res));
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> +                 return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> +         }
> +
> +@@ -178,8 +194,9 @@
> +         if (res < 0)
> +         {
> +                 PVR_DPF((PVR_DBG_ERROR, "EnableSGXClocks: Couldn't 
> +enable SGX interface clock (%d)", res));
> +-
> ++                clk_unprepare(psSysSpecData->psSGX_ICK);
> +                 clk_disable(psSysSpecData->psSGX_FCK);
> ++                clk_unprepare(psSysSpecData->psSGX_FCK);
> +                 return PVRSRV_ERROR_UNABLE_TO_ENABLE_CLOCK;
> +         }
> +
> +@@ -247,8 +264,9 @@
> + 	PVR_DPF((PVR_DBG_MESSAGE, "DisableSGXClocks: Disabling SGX 
> +Clocks"));
> + 	
> + 	clk_disable(psSysSpecData->psSGX_FCK);
> +-
> ++	clk_unprepare(psSysSpecData->psSGX_FCK);
> + 	clk_disable(psSysSpecData->psSGX_ICK);
> ++	clk_unprepare(psSysSpecData->psSGX_ICK);
> +
> + //	SysDisableSGXInterrupts(psSysData);
> +
> diff --git a/package/ti-gfx/ti-gfx.mk b/package/ti-gfx/ti-gfx.mk new 
> file mode 100644 index 0000000..154c792
> --- /dev/null
> +++ b/package/ti-gfx/ti-gfx.mk
> @@ -0,0 +1,71 @@
> +#####################################################################
> +##########
> +#
> +# ti-gfx
> +#
> +#####################################################################
> +##########
> +
> +TI_GFX_VERSION = 4_09_00_01
> +TI_GFX_SOURCE = 
> +Graphics_SDK_setuplinux_$(TI_GFX_VERSION)_minimal_demos.bin
> +TI_GFX_SITE = 
> +http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gf
> +xsdk/$(TI_GFX_VERSION)/exports/
> +TI_GFX_LICENSE = TSPA

  This is not one of the well-known licenses, so should be expanded to "Texas Instruments Software Piracy Agreement" or whatever it stands for.

> +TI_GFX_LICENSE_FILES = TSPA.txt
> +TI_GFX_INSTALL_STAGING = YES
> +
> +TI_GFX_DEPENDENCIES = linux
> +
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES3),y)
> +TI_GFX_OMAPES = 3.x
> +TI_GFX_PLATFORM = omap3
> +endif
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES5),y)
> +TI_GFX_OMAPES = 5.x
> +TI_GFX_PLATFORM = omap3630
> +endif
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES6),y)
> +TI_GFX_OMPAES = 6.x
> +TI_GFX_PLATFORM = ti81xx
> +endif
> +ifeq ($(BR2_PACKAGE_TI_GFX_ES8),y)
> +TI_GFX_OMAPES = 8.x
> +TI_GFX_PLATFORM = ti335x
> +endif

  Personally I prefer to do "case statements" like this in the Config.in, but it's a minor thing.

> +
> +define TI_GFX_EXTRACT_CMDS
> +	$(RM) -rf $(TI_GFX_DIR)

  We normally don't do that. Is it needed (i.e. does it fail if you don't and the source was already extracted before)?

  Also, use $(@D) instead of $(TI_GFX_DIR).

> +	chmod +x $(DL_DIR)/$(TI_GFX_SOURCE)
> +	printf "Y\nY\n qY\n\n" | $(DL_DIR)/$(TI_GFX_SOURCE) \
> +		--prefix $(TI_GFX_DIR) \
> +		--mode console
> +endef
> +
> +define TI_GFX_CONFIGURE_CMDS
> +	echo "no configure required binary only package"

  Just don't define it then.

> +endef
> +
> +TI_GFX_MAKE_CMD = cd $(TI_GFX_SRCDIR)/GFX_Linux_KM && \
> +		$(MAKE) $(LINUX_MAKE_FLAGS) \
> +			BUILD=$(BR2_PACKAGE_TI_GFX_DEBUG) \
> +			TI_PLATFORM=$(TI_GFX_PLATFORM) \
> +			OMAPES=$(TI_GFX_OMAPES) \
> +			SUPPORT_XORG=0 \
> +			KERNELDIR=$(LINUX_DIR)

  We normally only set the make flags, e.g.

TI_GFX_MAKE_OPTS = $(LINUX_MAKE_FLAGS) \
	...

and the build commands become

	$(MAKE) -C $(@D) $(TI_GFX_MAKE_OPTS) all

> +
> +define TI_GFX_BUILD_CMDS
> +	( $(TI_GFX_MAKE_CMD) clean && \

  Is the clean really needed? We normally don't.

  Also don't connect commands with && unless they really need to be executed in the same sub-shell.

> +	  $(TI_GFX_MAKE_CMD) all )
> +endef
> +
> +define TI_GFX_INSTALL_STAGING_CMDS
> +	

  If you have nothing to install than you shouldn't install to staging :-)

> +endef
> +
> +define TI_GFX_INSTALL_TARGET_CMDS
> +	( $(TI_GFX_MAKE_CMD) install ) || \

  Don't you need to pass TARGET_DIR anywhere?

> +		echo "Your kernel configuration must include FB_DA8XX"

  I think that should be checked by observing the kernel's .config in the CONFIGURE_CMDS.

  Ideally, it would be enabled automatically but I don't think we can do that at the moment.

> +endef
> +
> +define TI_GFX_CLEAN_CMDS
> +	( $(TI_GFX_MAKE_CMD) clean )
> +endef

  Clean is going to be deprecated so you don't need to add it. But I guess you're using it a lot now...

> +
> +$(eval $(generic-package))
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F _______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [RFC] ti-gfx: add new package

[Thomas Petazzoni]

Dear Sundareson, Prabindh,

On Fri, 14 Jun 2013 02:20:12 +0000, Sundareson, Prabindh wrote:

> 2. devmem2 is used for querying the version of the SGX core at runtime to do the right initialization
> 
> > +	select BR2_PACKAGE_DEVMEM2
> >>  Why is this needed?

So in this case, there should be a comment "# Runtime dependency" right
before the "select BR2_PACKAGE_DEVMEM2".

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com