| Message ID | 1355752131-31966-1-git-send-email-arnout@mind.be |
|---|---|
| State | Superseded |
| Headers | show |
On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote: > +IMX_LIB_INCLUDE = \ > + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ > + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ > + -I$(LINUX_DIR)/include Actually, I wonder if this is the right thing to do... This is a userspace library that requires a platform-specific linux/xxx.h. For an external toolchain, these headers don't exist in $(STAGING_DIR)/usr/include/linux Directly using $(LINUX_DIR)/include means that the headers are not patched for userspace. For those platform-specific headers that's probably not a problem, but it's not good for e.g. linux/types.h. An easy workaround is to use -idirafter instead of -I. However, perhaps it's an even better idea to do 'make headers_install' as part of the normal linux build process, so that packages depending on those headers can use the patched version. But then again, is it a good idea to replace the toolchain's kernel headers with a new set of kernel headers? Any advice is welcome! Regards, Arnout
Dear Arnout Vandecappelle, On Monday, December 17, 2012 2:48:50 PM, Arnout Vandecappelle wrote: > From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be> > > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> > --- > I'm not sure if I'll get the packages that use this library in an > upstreamable state - but at least this one is. > > --- > package/Config.in | 1 + > package/imx-lib/Config.in | 53 > ++++++++++++++++++++++++++++++++++++++++++++ > package/imx-lib/imx-lib.mk | 41 ++++++++++++++++++++++++++++++++++ > 3 files changed, 95 insertions(+) > create mode 100644 package/imx-lib/Config.in > create mode 100644 package/imx-lib/imx-lib.mk > > diff --git a/package/Config.in b/package/Config.in > index d6af55d..5151346 100644 > --- a/package/Config.in > +++ b/package/Config.in > @@ -420,6 +420,7 @@ endmenu > > menu "Hardware handling" > source "package/ccid/Config.in" > +source "package/imx-lib/Config.in" > source "package/lcdapi/Config.in" > source "package/libaio/Config.in" > source "package/libraw1394/Config.in" > diff --git a/package/imx-lib/Config.in b/package/imx-lib/Config.in > new file mode 100644 > index 0000000..0ed452a > --- /dev/null > +++ b/package/imx-lib/Config.in > @@ -0,0 +1,53 @@ > +comment "imx-lib needs an imx-specific kernel to be built" > + depends on !BR2_LINUX_KERNEL > + > +config BR2_PACKAGE_IMX_LIB > + bool "imx-lib" > + depends on BR2_LINUX_KERNEL > + depends on BR2_arm > + 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. > + > +if BR2_PACKAGE_IMX_LIB > +choice > + prompt "i.MX platform" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK > + bool "imx25-3stack" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS > + bool "imx27ads" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK > + bool "imx37-3stack" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50 > + bool "imx50" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51 > + bool "imx51" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53 > + bool "imx53" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q > + bool "imx6q" > + > +endchoice > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM > + string > + default "IMX25_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK > + default "IMX27ADS" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS > + default "IMX37_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK > + default "IMX50" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50 > + default "IMX51" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51 > + default "IMX53" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53 > + default "IMX6Q" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q > +endif > diff --git a/package/imx-lib/imx-lib.mk b/package/imx-lib/imx-lib.mk > new file mode 100644 > index 0000000..29f5ae1 > --- /dev/null > +++ b/package/imx-lib/imx-lib.mk > @@ -0,0 +1,41 @@ > +############################################################# > +# > +# imx-lib > +# > +############################################################# > + > +IMX_LIB_VERSION = 12.09.01 > +# No official download site from freescale, just this mirror > +IMX_LIB_SITE = > http://download.ossystems.com.br/bsp/freescale/source > +IMX_LIB_LICENSE = LGPLv2.1+ > +# No license file included > + > +IMX_LIB_INSTALL_STAGING = YES > + > +# imx-lib needs access to imx-specific kernel headers > +IMX_LIB_DEPENDENCIES += linux > +IMX_LIB_INCLUDE = \ > + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ > + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ > + -I$(LINUX_DIR)/include > + > +IMX_LIB_MAKE_ENV = \ > + $(TARGET_MAKE_ENV) \ > + $(TARGET_CONFIGURE_OPTS) \ > + CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \ > + PLATFORM=$(BR2_PACKAGE_IMX_LIB_PLATFORM) \ > + INCLUDE="$(IMX_LIB_INCLUDE)" > + > +define IMX_LIB_BUILD_CMDS > + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) > +endef > + > +define IMX_LIB_INSTALL_STAGING_CMDS > + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(STAGING_DIR) > install > +endef > + > +define IMX_LIB_INSTALL_TARGET_CMDS > + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(TARGET_DIR) > install > +endef > + > +$(eval $(generic-package)) This looks good. There is however a missing runtime dependency on firmware-imx. Best regards, Benoît
Dear Arnout Vandecappelle, On Monday, December 17, 2012 4:50:37 PM, Arnout Vandecappelle wrote: > On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote: > > +IMX_LIB_INCLUDE = \ > > + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ > > + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ > > + -I$(LINUX_DIR)/include > > Actually, I wonder if this is the right thing to do... This is a > userspace library that requires a platform-specific linux/xxx.h. For > an > external toolchain, these headers don't exist in > $(STAGING_DIR)/usr/include/linux > > Directly using $(LINUX_DIR)/include means that the headers are not > patched for userspace. For those platform-specific headers that's > probably not a problem, but it's not good for e.g. linux/types.h. > > An easy workaround is to use -idirafter instead of -I. However, > perhaps it's an even better idea to do 'make headers_install' as part > of > the normal linux build process, so that packages depending on those > headers can use the patched version. But then again, is it a good > idea to > replace the toolchain's kernel headers with a new set of kernel > headers? > > Any advice is welcome! FYI, I've successfully built the 11.09.01 version under BuildRoot without the "-I$(LINUX_DIR)/include", and the issue that you mention is only for this folder. I had to make a patch to make the headers install work, but that should not be related. Can you try with your package? Best regards, Benoît
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Arnout> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote: >> +IMX_LIB_INCLUDE = \ >> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ >> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ >> + -I$(LINUX_DIR)/include Arnout> Actually, I wonder if this is the right thing to do... This is a Arnout> userspace library that requires a platform-specific linux/xxx.h. For Arnout> an external toolchain, these headers don't exist in Arnout> $(STAGING_DIR)/usr/include/linux Arnout> Directly using $(LINUX_DIR)/include means that the headers are not Arnout> patched for userspace. For those platform-specific headers that's Arnout> probably not a problem, but it's not good for e.g. linux/types.h. Arnout> An easy workaround is to use -idirafter instead of -I. However, Arnout> perhaps it's an even better idea to do 'make headers_install' as part Arnout> of the normal linux build process, so that packages depending on those Arnout> headers can use the patched version. But then again, is it a good idea Arnout> to replace the toolchain's kernel headers with a new set of kernel Arnout> headers? Another possibility is to bundle the needed kernel headers with the package, similar to how E.G. mtd-utils does it.
On 17/12/12 16:57, Benoît Thébaudeau wrote: > Dear Arnout Vandecappelle, > > On Monday, December 17, 2012 4:50:37 PM, Arnout Vandecappelle wrote: >> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote: >>> +IMX_LIB_INCLUDE = \ >>> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ >>> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ >>> + -I$(LINUX_DIR)/include >> >> Actually, I wonder if this is the right thing to do... This is a >> userspace library that requires a platform-specific linux/xxx.h. For >> an >> external toolchain, these headers don't exist in >> $(STAGING_DIR)/usr/include/linux >> >> Directly using $(LINUX_DIR)/include means that the headers are not >> patched for userspace. For those platform-specific headers that's >> probably not a problem, but it's not good for e.g. linux/types.h. >> >> An easy workaround is to use -idirafter instead of -I. However, >> perhaps it's an even better idea to do 'make headers_install' as part >> of >> the normal linux build process, so that packages depending on those >> headers can use the patched version. But then again, is it a good >> idea to >> replace the toolchain's kernel headers with a new set of kernel >> headers? >> >> Any advice is welcome! > > FYI, I've successfully built the 11.09.01 version under BuildRoot without the > "-I$(LINUX_DIR)/include", and the issue that you mention is only for this > folder. I had to make a patch to make the headers install work, but that should > not be related. Can you try with your package? ipu/mxc_ipu_hl_lib.h needs linux/mxcfb.h which only exists in the imx kernels. Regards, Arnout
On 17/12/12 17:01, Peter Korsgaard wrote: >>>>>> "Arnout" == Arnout Vandecappelle<arnout@mind.be> writes: > > Arnout> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote: > >> +IMX_LIB_INCLUDE = \ > >> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ > >> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ > >> + -I$(LINUX_DIR)/include > > Arnout> Actually, I wonder if this is the right thing to do... This is a > Arnout> userspace library that requires a platform-specific linux/xxx.h. For > Arnout> an external toolchain, these headers don't exist in > Arnout> $(STAGING_DIR)/usr/include/linux > > Arnout> Directly using $(LINUX_DIR)/include means that the headers are not > Arnout> patched for userspace. For those platform-specific headers that's > Arnout> probably not a problem, but it's not good for e.g. linux/types.h. > > Arnout> An easy workaround is to use -idirafter instead of -I. However, > Arnout> perhaps it's an even better idea to do 'make headers_install' as part > Arnout> of the normal linux build process, so that packages depending on those > Arnout> headers can use the patched version. But then again, is it a good idea > Arnout> to replace the toolchain's kernel headers with a new set of kernel > Arnout> headers? > > Another possibility is to bundle the needed kernel headers with the > package, similar to how E.G. mtd-utils does it. Unfortunately, Freescale probably has a much lower standard about ABI compatibility than kernel.org. Also it's relatively likely that a buildroot user will use a different Freescale kernel than the one assumed by buildroot. So you may end up with userspace assuming different struct layouts than the kernel... Regards, Arnout
On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote: > +if BR2_PACKAGE_IMX_LIB > +choice > + prompt "i.MX platform" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK > + bool "imx25-3stack" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS > + bool "imx27ads" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK > + bool "imx37-3stack" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50 > + bool "imx50" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51 > + bool "imx51" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53 > + bool "imx53" > + > +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q > + bool "imx6q" > + > +endchoice Here's a second issue that I'd like to get some feedback on: gst-fsl-plugins also uses a PLATFORM definition, but the list of platforms is slightly different: MX28/MX233/MX25/MX27/MX31/MX35/MX37/MX51/MX53/MX50/MX5X/MX6 Ideally the 'platform' should be defined only once, but where? Or should I add all the platforms to gst-fsl-plugins with a select of the appropriate imx-lib platform? What to do with the platforms that are different? In some cases, I can make a guess of course (e.g. MX27 -> IMX27ADS) I can only test the mx6q because that's the only one for which I have a board... Build-testing doesn't make a difference because all platforms use the same API. Regards, Arnout
Dear Arnout Vandecappelle, On Monday, December 17, 2012 6:27:19 PM, Arnout Vandecappelle wrote: > On 17/12/12 16:57, Benoît Thébaudeau wrote: > > Dear Arnout Vandecappelle, > > > > On Monday, December 17, 2012 4:50:37 PM, Arnout Vandecappelle > > wrote: > >> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote: > >>> +IMX_LIB_INCLUDE = \ > >>> + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ > >>> + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ > >>> + -I$(LINUX_DIR)/include > >> > >> Actually, I wonder if this is the right thing to do... This is > >> a > >> userspace library that requires a platform-specific linux/xxx.h. > >> For > >> an > >> external toolchain, these headers don't exist in > >> $(STAGING_DIR)/usr/include/linux > >> > >> Directly using $(LINUX_DIR)/include means that the headers are > >> not > >> patched for userspace. For those platform-specific headers that's > >> probably not a problem, but it's not good for e.g. linux/types.h. > >> > >> An easy workaround is to use -idirafter instead of -I. > >> However, > >> perhaps it's an even better idea to do 'make headers_install' as > >> part > >> of > >> the normal linux build process, so that packages depending on > >> those > >> headers can use the patched version. But then again, is it a good > >> idea to > >> replace the toolchain's kernel headers with a new set of kernel > >> headers? > >> > >> Any advice is welcome! > > > > FYI, I've successfully built the 11.09.01 version under BuildRoot > > without the > > "-I$(LINUX_DIR)/include", and the issue that you mention is only > > for this > > folder. I had to make a patch to make the headers install work, but > > that should > > not be related. Can you try with your package? > > ipu/mxc_ipu_hl_lib.h needs linux/mxcfb.h which only exists in the > imx > kernels. I see. I did not have this issue because I have built a custom toolchain based on Freescale's kernel, so including these headers. This would not be very practical to impose the use of a custom toolchain here. Best regards, Benoît
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: >> Another possibility is to bundle the needed kernel headers with the >> package, similar to how E.G. mtd-utils does it. Arnout> Unfortunately, Freescale probably has a much lower standard about ABI Arnout> compatibility than kernel.org. Also it's relatively likely that a Arnout> buildroot user will use a different Freescale kernel than the one Arnout> assumed by buildroot. So you may end up with userspace assuming Arnout> different struct layouts than the kernel... Yeah, closed source mess :/
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Arnout> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote: >> +if BR2_PACKAGE_IMX_LIB >> +choice >> + prompt "i.MX platform" >> + >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK >> + bool "imx25-3stack" >> + >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS >> + bool "imx27ads" >> + >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK >> + bool "imx37-3stack" >> + >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50 >> + bool "imx50" >> + >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51 >> + bool "imx51" >> + >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53 >> + bool "imx53" >> + >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q >> + bool "imx6q" >> + >> +endchoice Arnout> Here's a second issue that I'd like to get some feedback on: Arnout> gst-fsl-plugins also uses a PLATFORM definition, but the list of Arnout> platforms is slightly different: Arnout> MX28/MX233/MX25/MX27/MX31/MX35/MX37/MX51/MX53/MX50/MX5X/MX6 Arnout> Ideally the 'platform' should be defined only once, but where? Or Arnout> should I add all the platforms to gst-fsl-plugins with a select of the Arnout> appropriate imx-lib platform? We once talked about adding a SoC selection to buildroot, but decided it would be too much effort to maintain. Is the gst-fsl-plugins stuff still needed now that the coda driver is in mainline? Arnout> I can only test the mx6q because that's the only one for which Arnout> I have a board... Build-testing doesn't make a difference Arnout> because all platforms use the same API. I have access to mx28 / mx51 / mx53 / mx6q boards and could do some testing during christmas.
On 17/12/12 20:40, Benoît Thébaudeau wrote: >> > ipu/mxc_ipu_hl_lib.h needs linux/mxcfb.h which only exists in the >> > imx >> > kernels. > I see. I did not have this issue because I have built a custom toolchain based > on Freescale's kernel, so including these headers. This would not be very > practical to impose the use of a custom toolchain here. I guess the custom toolchain isn't uClibc-based? Because it looks like some of the binary packages depend on glibc. Regards, Arnout
On 17/12/12 21:44, Peter Korsgaard wrote: >>>>>> "Arnout" == Arnout Vandecappelle<arnout@mind.be> writes: > > Arnout> On 17/12/12 14:48, Arnout Vandecappelle (Essensium/Mind) wrote: > >> +if BR2_PACKAGE_IMX_LIB > >> +choice > >> + prompt "i.MX platform" > >> + > >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK > >> + bool "imx25-3stack" > >> + > >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS > >> + bool "imx27ads" > >> + > >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK > >> + bool "imx37-3stack" > >> + > >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50 > >> + bool "imx50" > >> + > >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51 > >> + bool "imx51" > >> + > >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53 > >> + bool "imx53" > >> + > >> +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q > >> + bool "imx6q" > >> + > >> +endchoice > > Arnout> Here's a second issue that I'd like to get some feedback on: > Arnout> gst-fsl-plugins also uses a PLATFORM definition, but the list of > Arnout> platforms is slightly different: > Arnout> MX28/MX233/MX25/MX27/MX31/MX35/MX37/MX51/MX53/MX50/MX5X/MX6 > > Arnout> Ideally the 'platform' should be defined only once, but where? Or > Arnout> should I add all the platforms to gst-fsl-plugins with a select of the > Arnout> appropriate imx-lib platform? > > We once talked about adding a SoC selection to buildroot, but decided it > would be too much effort to maintain. But of course, maintaining it per package is even more effort... > > Is the gst-fsl-plugins stuff still needed now that the coda driver is in > mainline? Mainline v3.7 only has support for mx27 and mx51. > Arnout> I can only test the mx6q because that's the only one for which > Arnout> I have a board... Build-testing doesn't make a difference > Arnout> because all platforms use the same API. > > I have access to mx28 / mx51 / mx53 / mx6q boards and could do some > testing during christmas. OK, I'll try to post patches before the end of the week. Regards, Arnout
On Monday, December 17, 2012 10:49:43 PM, Arnout Vandecappelle wrote: > On 17/12/12 20:40, Benoît Thébaudeau wrote: > >> > ipu/mxc_ipu_hl_lib.h needs linux/mxcfb.h which only exists > >> > in the > >> > imx > >> > kernels. > > I see. I did not have this issue because I have built a custom > > toolchain based > > on Freescale's kernel, so including these headers. This would not > > be very > > practical to impose the use of a custom toolchain here. > > I guess the custom toolchain isn't uClibc-based? Because it looks > like > some of the binary packages depend on glibc. It is indeed glibc-based. Regards, Benoît
On Monday, December 17, 2012 11:01:43 PM, Arnout Vandecappelle wrote: > On 17/12/12 21:44, Peter Korsgaard wrote: > > Is the gst-fsl-plugins stuff still needed now that the coda driver > > is in > > mainline? > > Mainline v3.7 only has support for mx27 and mx51. Even for mx27 and mx51, are you sure that the mainline implementation for CODA is compatible with Freescale's imx-lib? I highly doubt it. Regards, Benoît
On 17/12/12 23:12, Benoît Thébaudeau wrote: > On Monday, December 17, 2012 11:01:43 PM, Arnout Vandecappelle wrote: >> On 17/12/12 21:44, Peter Korsgaard wrote: >>> Is the gst-fsl-plugins stuff still needed now that the coda driver >>> is in >>> mainline? >> >> Mainline v3.7 only has support for mx27 and mx51. > > Even for mx27 and mx51, are you sure that the mainline implementation for CODA > is compatible with Freescale's imx-lib? I highly doubt it. Peter's point is that with coda you don't need all that proprietary stuff, it's just a media framework device. Regards, Arnout
On Monday, December 17, 2012 11:16:44 PM, Arnout Vandecappelle wrote: > On 17/12/12 23:12, Benoît Thébaudeau wrote: > > On Monday, December 17, 2012 11:01:43 PM, Arnout Vandecappelle > > wrote: > >> On 17/12/12 21:44, Peter Korsgaard wrote: > >>> Is the gst-fsl-plugins stuff still needed now that the coda > >>> driver > >>> is in > >>> mainline? > >> > >> Mainline v3.7 only has support for mx27 and mx51. > > > > Even for mx27 and mx51, are you sure that the mainline > > implementation for CODA > > is compatible with Freescale's imx-lib? I highly doubt it. > > Peter's point is that with coda you don't need all that proprietary > stuff, it's just a media framework device. Sure. But isn't there a custom (or not yet developed generic V4L2 mem2mem) GStreamer plugin required for the mainline CODA implementation? There is also the question of the CSI and IPU features that are not yet available in mainline, even for mx27 and mx51. Perhaps in BuildRoot there could be a solution for packages from Freescale, and another one for mainline stuff as long as mainline does not provide all features. Regards, Benoît
On 17/12/12 16:50, Benoît Thébaudeau wrote:
> This looks good. There is however a missing runtime dependency on firmware-imx.
You only need that firmware when running a vpu encoder or decoder.
Forcing a select seems like a bad idea. Instead, I'll add a comment in
the help text of the gst plugins that you need the firmware as well.
Regards,
Arnout
diff --git a/package/Config.in b/package/Config.in index d6af55d..5151346 100644 --- a/package/Config.in +++ b/package/Config.in @@ -420,6 +420,7 @@ endmenu menu "Hardware handling" source "package/ccid/Config.in" +source "package/imx-lib/Config.in" source "package/lcdapi/Config.in" source "package/libaio/Config.in" source "package/libraw1394/Config.in" diff --git a/package/imx-lib/Config.in b/package/imx-lib/Config.in new file mode 100644 index 0000000..0ed452a --- /dev/null +++ b/package/imx-lib/Config.in @@ -0,0 +1,53 @@ +comment "imx-lib needs an imx-specific kernel to be built" + depends on !BR2_LINUX_KERNEL + +config BR2_PACKAGE_IMX_LIB + bool "imx-lib" + depends on BR2_LINUX_KERNEL + depends on BR2_arm + 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. + +if BR2_PACKAGE_IMX_LIB +choice + prompt "i.MX platform" + +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK + bool "imx25-3stack" + +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS + bool "imx27ads" + +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK + bool "imx37-3stack" + +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50 + bool "imx50" + +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51 + bool "imx51" + +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53 + bool "imx53" + +config BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q + bool "imx6q" + +endchoice + +config BR2_PACKAGE_IMX_LIB_PLATFORM + string + default "IMX25_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK + default "IMX27ADS" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS + default "IMX37_3STACK" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK + default "IMX50" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX50 + default "IMX51" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX51 + default "IMX53" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX53 + default "IMX6Q" if BR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q +endif diff --git a/package/imx-lib/imx-lib.mk b/package/imx-lib/imx-lib.mk new file mode 100644 index 0000000..29f5ae1 --- /dev/null +++ b/package/imx-lib/imx-lib.mk @@ -0,0 +1,41 @@ +############################################################# +# +# imx-lib +# +############################################################# + +IMX_LIB_VERSION = 12.09.01 +# No official download site from freescale, just this mirror +IMX_LIB_SITE = http://download.ossystems.com.br/bsp/freescale/source +IMX_LIB_LICENSE = LGPLv2.1+ +# No license file included + +IMX_LIB_INSTALL_STAGING = YES + +# imx-lib needs access to imx-specific kernel headers +IMX_LIB_DEPENDENCIES += linux +IMX_LIB_INCLUDE = \ + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ + -I$(LINUX_DIR)/include + +IMX_LIB_MAKE_ENV = \ + $(TARGET_MAKE_ENV) \ + $(TARGET_CONFIGURE_OPTS) \ + CROSS_COMPILE="$(CCACHE) $(TARGET_CROSS)" \ + PLATFORM=$(BR2_PACKAGE_IMX_LIB_PLATFORM) \ + INCLUDE="$(IMX_LIB_INCLUDE)" + +define IMX_LIB_BUILD_CMDS + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) +endef + +define IMX_LIB_INSTALL_STAGING_CMDS + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(STAGING_DIR) install +endef + +define IMX_LIB_INSTALL_TARGET_CMDS + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(TARGET_DIR) install +endef + +$(eval $(generic-package))