| Message ID | EE4E4767751A8B40949306E403F4DDD802EEB1D7@sv03ultra002.ultratronik.de |
|---|---|
| State | Superseded |
| Headers | show |
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 >
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
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
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, 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
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
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
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 >
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
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