Patchwork [RFC] ti-gfx: add new package

login
register
mail settings
Submitter Naumann Andreas
Date June 13, 2013, 8:03 a.m.
Message ID <EE4E4767751A8B40949306E403F4DDD802EEB1D7@sv03ultra002.ultratronik.de>
Download mbox | patch
Permalink /patch/251007/
State Superseded
Headers show

Comments

Naumann Andreas - June 13, 2013, 8:03 a.m.
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(-)
Charles Krinke - June 13, 2013, 2:11 p.m.
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@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@busybox.net [mailto:buildroot-bounces@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
>
Spenser Gilliland - June 13, 2013, 2:58 p.m.
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
Thomas Petazzoni - June 14, 2013, 8:22 p.m.
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
Charles Krinke - June 14, 2013, 8:58 p.m.
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
>
Yann E. MORIN - June 14, 2013, 11:12 p.m.
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
Sundareson, Prabindh - June 15, 2013, 9:37 a.m.
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@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
Thomas Petazzoni - June 15, 2013, 4:28 p.m.
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
Andreas Naumann - June 17, 2013, 1:35 p.m.
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@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
Spenser Gilliland - June 17, 2013, 4:26 p.m.
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

Patch

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