[Buildroot] [PATCH] imx-lib: new package

[Buildroot] [PATCH] imx-lib: new package

[Arnout Vandecappelle]

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))
-- 
1.7.10.4

[Buildroot] [PATCH] imx-lib: new package

[Arnout Vandecappelle]

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

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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] [PATCH] imx-lib: new package

[Benoît Thébaudeau]

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

[Buildroot] [PATCH] imx-lib: new package

[Arnout Vandecappelle]

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

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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] [PATCH] imx-lib: new package

[Benoît Thébaudeau]

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

[Buildroot] [PATCH] imx-lib: new package

[Arnout Vandecappelle]

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

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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] [PATCH] imx-lib: new package

[Benoît Thébaudeau]

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

[Buildroot] [PATCH] imx-lib: new package

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] imx-lib: new package

[Arnout Vandecappelle]

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
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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] [PATCH] imx-lib: new package

[Peter Korsgaard]

>>>>> "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 :/

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] imx-lib: new package

[Benoît Thébaudeau]

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

[Buildroot] [PATCH] imx-lib: new package

[Arnout Vandecappelle]

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

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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] [PATCH] imx-lib: new package

[Arnout Vandecappelle]

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

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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] [PATCH] imx-lib: new package

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] imx-lib: new package

[Arnout Vandecappelle]

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


-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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] [PATCH] imx-lib: new package

[Benoît Thébaudeau]

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

[Buildroot] [PATCH] imx-lib: new package

[Arnout Vandecappelle]

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


-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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] [PATCH] imx-lib: new package

[Benoît Thébaudeau]

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