imx-lib: new package
PATCH 1/1 imx-lib: new package
From: "Arnout Vandecappelle (Essensium/Mind)" <[email protected]>
---
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
package/Config.in +1 -0
@@ -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"
package/imx-lib/Config.in new file +53 -0
53 lines not on this page · raw message
package/imx-lib/imx-lib.mk new file +41 -0
41 lines not on this page · raw message
Signature · 1 line
1.7.10.4
PATCH 1/1 imx-lib: new package
package/imx-lib/imx-lib.mk line 20
Quoted 4 lines · Arnout Vandecappelle (Essensium/Mind)
package/imx-lib/imx-lib.mk new file +4
-0+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
Signature · 6 lines
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
PATCH 1/1 imx-lib: new package
Dear Arnout Vandecappelle,
Quoted 25 lines · Arnout Vandecappelle
package/imx-lib/imx-lib.mk line 20
Quoted 4 lines · Arnout Vandecappelle (Essensium/Mind)
package/imx-lib/imx-lib.mk new file +4
-0+IMX_LIB_INCLUDE = \ + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ + -I$(LINUX_DIR)/includeActually, I wonder if this is the right thing to do... This is a
userspace library that requires a platform-specificlinux/xxx.h. For an
external toolchain, these headers don't exist in $(STAGING_DIR)/usr/include/linuxDirectly 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 'makeheaders_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?
Quoted 1 line
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
PATCH 1/1 imx-lib: new package
Quoted 28 lines · Beno?t Th?baudeau
Dear Arnout Vandecappelle,
Quoted 25 lines · Arnout Vandecappelle
package/imx-lib/imx-lib.mk line 20
Quoted 4 lines · Arnout Vandecappelle (Essensium/Mind)
package/imx-lib/imx-lib.mk new file +4
-0+IMX_LIB_INCLUDE = \ + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ + -I$(LINUX_DIR)/includeActually, I wonder if this is the right thing to do... This is a
userspace library that requires a platform-specificlinux/xxx.h. For an
external toolchain, these headers don't exist in $(STAGING_DIR)/usr/include/linuxDirectly 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 'makeheaders_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?
Quoted 6 lines
Quoted 1 line
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
Signature · 6 lines
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
PATCH 1/1 imx-lib: new package
Dear Arnout Vandecappelle,
Quoted 46 lines · Arnout Vandecappelle
Quoted 37 lines · Beno?t Th?baudeau
Dear Arnout Vandecappelle,
Quoted 31 lines · Arnout Vandecappelle
package/imx-lib/imx-lib.mk line 20
Quoted 4 lines · Arnout Vandecappelle (Essensium/Mind)
package/imx-lib/imx-lib.mk new file +4
-0+IMX_LIB_INCLUDE = \ + -I$(LINUX_DIR)/drivers/mxc/security/rng/include \ + -I$(LINUX_DIR)/drivers/mxc/security/sahara2/include \ + -I$(LINUX_DIR)/includeActually, I wonder if this is the right thing to do... This is a
userspace library that requires a platform-specificlinux/xxx.h. For
an
external toolchain, these headers don't exist in $(STAGING_DIR)/usr/include/linuxDirectly 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 'makeheaders_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?Quoted 1 line
Any advice is welcome!
Quoted 7 lines
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?
Quoted 3 lines
ipu/mxc_ipu_hl_lib.hneedslinux/mxcfb.hwhich 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
PATCH 1/1 imx-lib: new package
Quoted 6 lines · Beno?t Th?baudeau
Quoted 3 lines
Quoted 3 lines
ipu/mxc_ipu_hl_lib.hneedslinux/mxcfb.hwhich 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
Signature · 6 lines
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
PATCH 1/1 imx-lib: new package
Quoted 11 lines · Arnout Vandecappelle
Quoted 9 lines · Beno?t Th?baudeau
Quoted 4 lines
Quoted 4 lines
ipu/mxc_ipu_hl_lib.hneedslinux/mxcfb.hwhich 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.
Quoted 3 lines
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
PATCH 1/1 imx-lib: new package
In reply to Arnout VandecappelleQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Quoted 4 lines · Arnout Vandecappelle (Essensium/Mind)
package/imx-lib/imx-lib.mk line 20
Quoted 4 lines
package/imx-lib/imx-lib.mk new file +4
-0+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.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 imx-lib: new package
Quoted 18 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle<[email protected]> 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)/includeArnout> 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/linuxArnout> 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,
Quoted 8 lines
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
Signature · 6 lines
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
PATCH 1/1 imx-lib: new package
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> 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 :/
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 imx-lib: new package
In reply to Arnout Vandecappelle (Essensium/Mind)Dear Arnout Vandecappelle,
Quoted 134 lines · Arnout Vandecappelle
From: "Arnout Vandecappelle (Essensium/Mind)" <[email protected]>
---
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.mkpackage/Config.in +1
-0@@ -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"package/imx-lib/Config.in new file +53
-0@@ -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 +endifpackage/imx-lib/imx-lib.mk new file +9
-0@@ -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
package/imx-lib/imx-lib.mk new file +25
-0+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
package/imx-lib/imx-lib.mk new file +4
-0+endef + +define IMX_LIB_INSTALL_TARGET_CMDS + $(IMX_LIB_MAKE_ENV) $(MAKE1) -C $(@D) DEST_DIR=$(TARGET_DIR)install
package/imx-lib/imx-lib.mk line 41
Quoted 3 lines
package/imx-lib/imx-lib.mk new file +3
-0+endef + +$(eval $(generic-package))
This looks good. There is however a missing runtime dependency on firmware-imx.
Best regards,
Beno?t
PATCH 1/1 imx-lib: new package
Quoted 1 line · Beno?t Th?baudeau
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
Signature · 6 lines
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
PATCH 1/1 imx-lib: new package
In reply to Arnout Vandecappelle (Essensium/Mind)Quoted 16 lines · Arnout Vandecappelle (Essensium/Mind)
package/imx-lib/Config.in new file +16
-0+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" +
package/imx-lib/Config.in line 42
Quoted 10 lines
package/imx-lib/Config.in new file +10
-0+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
Signature · 6 lines
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
PATCH 1/1 imx-lib: new package
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Quoted 18 lines · Arnout Vandecappelle (Essensium/Mind)
Quoted 18 lines
package/imx-lib/Config.in new file +18
-0+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"
Quoted 8 lines
package/imx-lib/Config.in line 42
Quoted 8 lines
package/imx-lib/Config.in new file +8
-0+ +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.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 imx-lib: new package
Quoted 35 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle<[email protected]> writes:
Quoted 18 lines · Arnout Vandecappelle (Essensium/Mind)
Quoted 18 lines
+if
BR2_PACKAGE_IMX_LIB
+choice
+ prompt "i.MX platform"
+
+configBR2_PACKAGE_IMX_LIB_PLATFORM_IMX25_3STACK
+ bool "imx25-3stack"
+
+configBR2_PACKAGE_IMX_LIB_PLATFORM_IMX27ADS
+ bool "imx27ads"
+
+configBR2_PACKAGE_IMX_LIB_PLATFORM_IMX37_3STACK
+ bool "imx37-3stack"
+
+configBR2_PACKAGE_IMX_LIB_PLATFORM_IMX50
+ bool "imx50"
+
+configBR2_PACKAGE_IMX_LIB_PLATFORM_IMX51
+ bool "imx51"Quoted 8 lines
Quoted 8 lines
+
+configBR2_PACKAGE_IMX_LIB_PLATFORM_IMX53
+ bool "imx53"
+
+configBR2_PACKAGE_IMX_LIB_PLATFORM_IMX6Q
+ bool "imx6q"
+
+endchoiceArnout> 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
Quoted 6 lines
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...
Quoted 3 lines
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.
Quoted 6 lines
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
Signature · 6 lines
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
PATCH 1/1 imx-lib: new package
Quoted 6 lines · Arnout Vandecappelle
Quoted 3 lines · Peter Korsgaard
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
PATCH 1/1 imx-lib: new package
Quoted 10 lines · Beno?t Th?baudeau
Quoted 6 lines · Arnout Vandecappelle
Quoted 3 lines · Peter Korsgaard
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
Signature · 6 lines
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
PATCH 1/1 imx-lib: new package
Quoted 9 lines · Arnout Vandecappelle
Quoted 8 lines · Beno?t Th?baudeau
Quoted 6 lines · Arnout Vandecappelle
Quoted 4 lines · Peter Korsgaard
Is the gst-fsl-plugins stuff still needed now that the coda driver
is in
mainline?
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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