[meta-fsl-arm PATCH v4 0/12] Fixes current found issues for 1.4 release

[meta-fsl-arm PATCH v4 0/12] Fixes current found issues for 1.4 release

[Otavio Salvador]

We've runned full build of 'fsl-image-gui' image in O.S. Systems build
server for ALL machines in meta-fsl-arm and meta-fsl-arm-extra, the
final build list is:

 cgtqmx6 ok
 imx233-olinuxino-maxi ok
 imx233-olinuxino-micro ok
 imx233-olinuxino-mini ok
 imx23evk ok
 imx28evk ok
 imx31pdk ok
 imx35pdk ok
 imx51evk ok
 imx53ard ok
 imx53qsb ok
 imx6dlsabresd ok
 imx6qsabreauto ok
 imx6qsabrelite ok
 imx6qsabresd ok
 imx6slevk ok
 nitrogen6x ok
 wandboard-dual ok
 wandboard-solo ok

The 'imx31pdk' and 'imx35pdk' machines depends on the 'fio' patch we
sent to Meta-OpenEmbedded to add support for ARMv6 assembly code but
appart from that those are the needed fixes.

Please give them a try so these can be merged soon.

Changes in v4:
- Merge hex format change (Daiane)

Changes in v3:
- Fix commit log U-Boot version
- New patch
- New patch
- New patch
- New patch
- New patch

Changes in v2:
- Remove change of i.MX6SL entry point format, for another patch
- New patch
- Improve commit log
- New patch

Otavio Salvador (12):
  u-boot-fslc: Update to patches-2013.04's 20130410 snapshot
  imx6dlsabresd: Use U-Boot 2009.08 from Freescale
  gst-fsl-plugin (3.0.6): Fix the tarball's checksum
  gst-fsl-plugin (3.0.6): Add 'virtual/kernel' dependency
  imx-base.inc: Disable firmware include for not fully supported BSPs
  imx-base.inc: Avoid including imx-audio for every SoC family
  imx-base.inc: Override GStreamer plugins for i.MX3
  imx-base.inc: Do not assign UBOOT_LOADADDRESS
  Fix use of SOC_FAMILY as the most right value is preferred
  xf86-dri-vivante: Ensure install fails if .la cannot be removed
  xf86-dri-vivante: Fix DRI module name
  xf86-video-imxfb-vivante: Enable software rendering support

 conf/machine/imx23evk.conf                         |  2 +-
 conf/machine/imx28evk.conf                         |  2 +-
 conf/machine/imx31pdk.conf                         |  2 +-
 conf/machine/imx35pdk.conf                         |  2 +-
 conf/machine/imx51evk.conf                         |  2 +-
 conf/machine/imx53ard.conf                         |  2 +-
 conf/machine/imx53qsb.conf                         |  2 +-
 conf/machine/imx6dlsabresd.conf                    |  4 +++-
 conf/machine/imx6qsabreauto.conf                   |  2 +-
 conf/machine/imx6qsabresd.conf                     |  2 +-
 conf/machine/imx6slevk.conf                        |  2 +-
 conf/machine/include/imx-base.inc                  | 24 ++++++++++------------
 recipes-bsp/u-boot/u-boot-fslc_2013.04.bb          |  2 +-
 recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb       |  2 +-
 .../xorg-driver/xf86-dri-vivante_1.1.0.bb          |  8 ++++++--
 .../xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb  |  2 +-
 .../gst-plugins/gst-fsl-plugin_3.0.6.bb            |  8 ++++----
 17 files changed, 37 insertions(+), 33 deletions(-)

-- 
1.8.1

[meta-fsl-arm PATCH v4 01/12] u-boot-fslc: Update to patches-2013.04's 20130410 snapshot

[Otavio Salvador]

Include following fixes:

 * i.MX6Q SabreSD/SabreAUTO: Environment fix for 'mmc rescan'
 * i.MX6SL EVK: Fix memory size

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Remove change of i.MX6SL entry point format, for another patch

 recipes-bsp/u-boot/u-boot-fslc_2013.04.bb    | 2 +-
 recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/u-boot/u-boot-fslc_2013.04.bb b/recipes-bsp/u-boot/u-boot-fslc_2013.04.bb
index 01b9d59..f339996 100644
--- a/recipes-bsp/u-boot/u-boot-fslc_2013.04.bb
+++ b/recipes-bsp/u-boot/u-boot-fslc_2013.04.bb
@@ -10,7 +10,7 @@ PROVIDES += "u-boot"
 
 PV = "v2013.04"
 
-SRCREV = "7e2cfc83e91229e2573a3b51aec9e8c9fd27ed79"
+SRCREV = "debad5d6cba77538d183ac947a41f6b88f9498b2"
 SRC_URI = "git://github.com/Freescale/u-boot-imx.git"
 
 S = "${WORKDIR}/git"
diff --git a/recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb b/recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb
index b6c271f..0ef48a2 100644
--- a/recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb
+++ b/recipes-bsp/u-boot/u-boot-mxsboot_2013.04.bb
@@ -5,7 +5,7 @@ SECTION = "bootloader"
 
 PV = "v2013.04"
 
-SRCREV = "7e2cfc83e91229e2573a3b51aec9e8c9fd27ed79"
+SRCREV = "debad5d6cba77538d183ac947a41f6b88f9498b2"
 SRC_URI = "git://github.com/Freescale/u-boot-imx.git"
 
 S = "${WORKDIR}/git"
-- 
1.8.1

[meta-fsl-arm PATCH v4 02/12] imx6dlsabresd: Use U-Boot 2009.08 from Freescale

[Otavio Salvador]

The U-Boot 2013.04 does not has support for i.MX6DL SabreSD so ensure
we use U-Boot 2009.08 until it is added.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3:
- Fix commit log U-Boot version

Changes in v2:
- New patch

 conf/machine/imx6dlsabresd.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/conf/machine/imx6dlsabresd.conf b/conf/machine/imx6dlsabresd.conf
index 754b555..215ec1b 100644
--- a/conf/machine/imx6dlsabresd.conf
+++ b/conf/machine/imx6dlsabresd.conf
@@ -7,6 +7,8 @@ include conf/machine/include/tune-cortexa9.inc
 
 SOC_FAMILY = "mx6dl:mx6"
 
+PREFERRED_PROVIDER_u-boot = "u-boot-imx"
+
 UBOOT_MACHINE = "mx6dl_sabresd_config"
 UBOOT_SUFFIX = "bin"
 UBOOT_PADDING = "2"
-- 
1.8.1

[meta-fsl-arm PATCH v4 03/12] gst-fsl-plugin (3.0.6): Fix the tarball's checksum

[Otavio Salvador]

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3:
- New patch

Changes in v2: None

 recipes-multimedia/gst-plugins/gst-fsl-plugin_3.0.6.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-multimedia/gst-plugins/gst-fsl-plugin_3.0.6.bb b/recipes-multimedia/gst-plugins/gst-fsl-plugin_3.0.6.bb
index 4c28442..0f5d5c3 100644
--- a/recipes-multimedia/gst-plugins/gst-fsl-plugin_3.0.6.bb
+++ b/recipes-multimedia/gst-plugins/gst-fsl-plugin_3.0.6.bb
@@ -5,7 +5,7 @@ require gst-fsl-plugin.inc
 
 DEPENDS = "gstreamer gst-plugins-base libfslcodec libfslparser"
 
-PR = "${INC_PR}.0"
+PR = "${INC_PR}.1"
 
 SRC_URI += "file://fix-missing-sys-types-h.patch \
             file://Link-with-the-Real-Time-Extension-lib.patch \
@@ -13,7 +13,7 @@ SRC_URI += "file://fix-missing-sys-types-h.patch \
 
 PACKAGE_NAME = "gst-fsl-plugins"
 
-SRC_URI[md5sum] = "fd7c9db129cbcc4dc79b7dd832061594"
-SRC_URI[sha256sum] = "546deb407993f726ef4e140f5bd734d612d5f8872c832ac820957f667f22306e"
+SRC_URI[md5sum] = "5416a727e8b0bd94eec077ac7d70aae7"
+SRC_URI[sha256sum] = "fdb0b5ab964f607a93664412702a131931da8ef0b557597cbf161c3d9c9d0c12"
 
 COMPATIBLE_MACHINE = "(mx28)"
-- 
1.8.1

[meta-fsl-arm PATCH v4 04/12] gst-fsl-plugin (3.0.6): Add 'virtual/kernel' dependency

[Otavio Salvador]

The code includes kernel headers during the build so the kernel needs
to be built before doing the gst-fsl-plugins build.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3:
- New patch

Changes in v2: None

 recipes-multimedia/gst-plugins/gst-fsl-plugin_3.0.6.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-multimedia/gst-plugins/gst-fsl-plugin_3.0.6.bb b/recipes-multimedia/gst-plugins/gst-fsl-plugin_3.0.6.bb
index 0f5d5c3..77baa9a 100644
--- a/recipes-multimedia/gst-plugins/gst-fsl-plugin_3.0.6.bb
+++ b/recipes-multimedia/gst-plugins/gst-fsl-plugin_3.0.6.bb
@@ -3,7 +3,7 @@
 
 require gst-fsl-plugin.inc
 
-DEPENDS = "gstreamer gst-plugins-base libfslcodec libfslparser"
+DEPENDS = "virtual/kernel gstreamer gst-plugins-base libfslcodec libfslparser"
 
 PR = "${INC_PR}.1"
 
-- 
1.8.1

[meta-fsl-arm PATCH v4 05/12] imx-base.inc: Disable firmware include for not fully supported BSPs

[Otavio Salvador]

The i.MX25, i.MX27, i.MX31 and i.MX35 are not fully supported and we
don't have the firmware package for them so comment them out so it
doesn't break the build.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3:
- New patch

Changes in v2: None

 conf/machine/include/imx-base.inc | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/conf/machine/include/imx-base.inc b/conf/machine/include/imx-base.inc
index b421807..de48e98 100644
--- a/conf/machine/include/imx-base.inc
+++ b/conf/machine/include/imx-base.inc
@@ -44,10 +44,12 @@ MACHINE_FIRMWARE_mx6d = "firmware-imx-vpu-imx6d"
 MACHINE_FIRMWARE_mx6dl = "firmware-imx-vpu-imx6d"
 MACHINE_FIRMWARE_mx53 = "firmware-imx-vpu-imx53 firmware-imx-sdma-imx53"
 MACHINE_FIRMWARE_mx51 = "firmware-imx-vpu-imx51 firmware-imx-sdma-imx51"
-MACHINE_FIRMWARE_mx35 = "firmware-imx-sdma-imx35"
-MACHINE_FIRMWARE_mx31 = "firmware-imx-sdma-imx31"
-MACHINE_FIRMWARE_mx27 = "firmware-imx-vpu-imx27"
-MACHINE_FIRMWARE_mx25 = "firmware-imx-sdma-imx25"
+
+# FIXME: Needs addition of firmware-imx of official BSPs
+#MACHINE_FIRMWARE_mx35 = "firmware-imx-sdma-imx35"
+#MACHINE_FIRMWARE_mx31 = "firmware-imx-sdma-imx31"
+#MACHINE_FIRMWARE_mx27 = "firmware-imx-vpu-imx27"
+#MACHINE_FIRMWARE_mx25 = "firmware-imx-sdma-imx25"
 
 MACHINE_EXTRA_RRECOMMENDS += "${MACHINE_FIRMWARE}"
 
-- 
1.8.1

[meta-fsl-arm PATCH v4 06/12] imx-base.inc: Avoid including imx-audio for every SoC family

[Otavio Salvador]

The imx-audio package is currently only available for i.MX5 and i.MX6
so we should include it in every SoC family. This fixes i.MX31 and
i.MX35 image build due unsatisfied dependency.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3:
- New patch

Changes in v2: None

 conf/machine/include/imx-base.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/conf/machine/include/imx-base.inc b/conf/machine/include/imx-base.inc
index de48e98..56a0f92 100644
--- a/conf/machine/include/imx-base.inc
+++ b/conf/machine/include/imx-base.inc
@@ -54,7 +54,9 @@ MACHINE_FIRMWARE_mx51 = "firmware-imx-vpu-imx51 firmware-imx-sdma-imx51"
 MACHINE_EXTRA_RRECOMMENDS += "${MACHINE_FIRMWARE}"
 
 # Extra audio support
-MACHINE_EXTRA_RRECOMMENDS += "imx-audio"
+# FIXME: Add support for ALL SoC families
+MACHINE_EXTRA_RRECOMMENDS_append_mx5 = " imx-audio"
+MACHINE_EXTRA_RRECOMMENDS_append_mx6 = " imx-audio"
 
 # Extra udev rules
 MACHINE_EXTRA_RRECOMMENDS += "udev-extraconf"
-- 
1.8.1

[meta-fsl-arm PATCH v4 07/12] imx-base.inc: Override GStreamer plugins for i.MX3

[Otavio Salvador]

i.MX3 doesn't has GStreamer plugins packaged so we need to avoid its
installation for now.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3:
- New patch

Changes in v2: None

 conf/machine/include/imx-base.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/conf/machine/include/imx-base.inc b/conf/machine/include/imx-base.inc
index 56a0f92..456bbfb 100644
--- a/conf/machine/include/imx-base.inc
+++ b/conf/machine/include/imx-base.inc
@@ -63,6 +63,7 @@ MACHINE_EXTRA_RRECOMMENDS += "udev-extraconf"
 
 # Gstreamer plugin
 MACHINE_GSTREAMER_PLUGIN ?= "gst-fsl-plugin"
+MACHINE_GSTREAMER_PLUGIN_mx3 ?= ""
 
 # mx5 GPU libraries
 PREFERRED_PROVIDER_virtual/egl_mx5 ?= "amd-gpu-x11-bin-mx51"
-- 
1.8.1

[meta-fsl-arm PATCH v4 08/12] imx-base.inc: Do not assign UBOOT_LOADADDRESS

[Otavio Salvador]

The code uses UBOOT_ENTRYPOINT as default value for UBOOT_LOADADDRESS
so we don't need to have the variable UBOOT_LOADADDRESS set unless
it's different from UBOOT_ENTRYPOINT. This also fix the i.MX6SL entry
point hex format.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4:
- Merge hex format change (Daiane)

Changes in v3: None
Changes in v2:
- Improve commit log

 conf/machine/include/imx-base.inc | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/conf/machine/include/imx-base.inc b/conf/machine/include/imx-base.inc
index 456bbfb..c761626 100644
--- a/conf/machine/include/imx-base.inc
+++ b/conf/machine/include/imx-base.inc
@@ -14,16 +14,9 @@ UBOOT_MAKE_TARGET = "u-boot.imx"
 UBOOT_SUFFIX ?= "imx"
 
 UBOOT_ENTRYPOINT_mx51  = "0xa0000000"
-UBOOT_LOADADDRESS_mx51 = "0xa0000000"
-
 UBOOT_ENTRYPOINT_mx53  = "0x70800000"
-UBOOT_LOADADDRESS_mx53 = "0x70800000"
-
 UBOOT_ENTRYPOINT_mx6  = "0x10800000"
-UBOOT_LOADADDRESS_mx6 = "0x10800000"
-
-UBOOT_ENTRYPOINT_mx6sl = "0X80800000"
-UBOOT_LOADADDRESS_mx6sl = "0X80800000"
+UBOOT_ENTRYPOINT_mx6sl = "0x80800000"
 
 PREFERRED_VERSION_xserver-xorg_mx6 = "2:1.11.4"
 
-- 
1.8.1

[meta-fsl-arm PATCH v4 09/12] Fix use of SOC_FAMILY as the most right value is preferred

[Otavio Salvador]

The SOC_FAMILY uses the MACHINEOVERRIDES and it evaluates from left to
right. In this case, the most SoC specific value needs to be kept in
the right so it take precedence.

This has been catch when finding out why i.MX6SL EVK where using the
wrong value as entry point, and this was the root cause.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None

 conf/machine/imx23evk.conf       | 2 +-
 conf/machine/imx28evk.conf       | 2 +-
 conf/machine/imx31pdk.conf       | 2 +-
 conf/machine/imx35pdk.conf       | 2 +-
 conf/machine/imx51evk.conf       | 2 +-
 conf/machine/imx53ard.conf       | 2 +-
 conf/machine/imx53qsb.conf       | 2 +-
 conf/machine/imx6dlsabresd.conf  | 2 +-
 conf/machine/imx6qsabreauto.conf | 2 +-
 conf/machine/imx6qsabresd.conf   | 2 +-
 conf/machine/imx6slevk.conf      | 2 +-
 11 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/conf/machine/imx23evk.conf b/conf/machine/imx23evk.conf
index a5c0f98..80a771f 100644
--- a/conf/machine/imx23evk.conf
+++ b/conf/machine/imx23evk.conf
@@ -4,7 +4,7 @@
 
 include conf/machine/include/mxs-base.inc
 
-SOC_FAMILY = "mx23:mxs"
+SOC_FAMILY = "mxs:mx23"
 
 IMXBOOTLETS_MACHINE = "stmp378x_dev"
 UBOOT_MACHINE = "mx23evk_config"
diff --git a/conf/machine/imx28evk.conf b/conf/machine/imx28evk.conf
index df00203..d80e9d9 100644
--- a/conf/machine/imx28evk.conf
+++ b/conf/machine/imx28evk.conf
@@ -4,7 +4,7 @@
 
 include conf/machine/include/mxs-base.inc
 
-SOC_FAMILY = "mx28:mxs"
+SOC_FAMILY = "mxs:mx28"
 
 IMXBOOTLETS_MACHINE = "iMX28_EVK"
 UBOOT_MACHINE = "mx28evk_config"
diff --git a/conf/machine/imx31pdk.conf b/conf/machine/imx31pdk.conf
index 9b6da31..3aa6606 100644
--- a/conf/machine/imx31pdk.conf
+++ b/conf/machine/imx31pdk.conf
@@ -6,7 +6,7 @@ include conf/machine/include/soc-family.inc
 include conf/machine/include/imx-base.inc
 require conf/machine/include/tune-arm1136jf-s.inc
 
-SOC_FAMILY = "mx31:mx3"
+SOC_FAMILY = "mx3:mx31"
 
 GUI_MACHINE_CLASS = "smallscreen"
 
diff --git a/conf/machine/imx35pdk.conf b/conf/machine/imx35pdk.conf
index 62e6930..2d48699 100644
--- a/conf/machine/imx35pdk.conf
+++ b/conf/machine/imx35pdk.conf
@@ -6,7 +6,7 @@ include conf/machine/include/soc-family.inc
 include conf/machine/include/imx-base.inc
 require conf/machine/include/tune-arm1136jf-s.inc
 
-SOC_FAMILY = "mx35:mx3"
+SOC_FAMILY = "mx3:mx35"
 
 UBOOT_ENTRYPOINT = "0x80008000"
 UBOOT_LOADADDRESS = "0x80008000"
diff --git a/conf/machine/imx51evk.conf b/conf/machine/imx51evk.conf
index 2e27ed7..8ac38f0 100644
--- a/conf/machine/imx51evk.conf
+++ b/conf/machine/imx51evk.conf
@@ -5,7 +5,7 @@
 include conf/machine/include/imx-base.inc
 include conf/machine/include/tune-cortexa8.inc
 
-SOC_FAMILY = "mx51:mx5"
+SOC_FAMILY = "mx5:mx51"
 
 KERNEL_DEVICETREE = "${S}/arch/arm/boot/dts/imx51-babbage.dts"
 
diff --git a/conf/machine/imx53ard.conf b/conf/machine/imx53ard.conf
index 4f15493..20898c4 100644
--- a/conf/machine/imx53ard.conf
+++ b/conf/machine/imx53ard.conf
@@ -5,7 +5,7 @@
 include conf/machine/include/imx-base.inc
 include conf/machine/include/tune-cortexa8.inc
 
-SOC_FAMILY = "mx53:mx5"
+SOC_FAMILY = "mx5:mx53"
 
 KERNEL_DEVICETREE = "${S}/arch/arm/boot/dts/imx53-ard.dts"
 
diff --git a/conf/machine/imx53qsb.conf b/conf/machine/imx53qsb.conf
index 9aec913..1a95a71 100644
--- a/conf/machine/imx53qsb.conf
+++ b/conf/machine/imx53qsb.conf
@@ -5,7 +5,7 @@
 include conf/machine/include/imx-base.inc
 include conf/machine/include/tune-cortexa8.inc
 
-SOC_FAMILY = "mx53:mx5"
+SOC_FAMILY = "mx5:mx53"
 
 KERNEL_DEVICETREE = "${S}/arch/arm/boot/dts/imx53-qsb.dts"
 
diff --git a/conf/machine/imx6dlsabresd.conf b/conf/machine/imx6dlsabresd.conf
index 215ec1b..99c9b85 100644
--- a/conf/machine/imx6dlsabresd.conf
+++ b/conf/machine/imx6dlsabresd.conf
@@ -5,7 +5,7 @@
 include conf/machine/include/imx-base.inc
 include conf/machine/include/tune-cortexa9.inc
 
-SOC_FAMILY = "mx6dl:mx6"
+SOC_FAMILY = "mx6:mx6dl"
 
 PREFERRED_PROVIDER_u-boot = "u-boot-imx"
 
diff --git a/conf/machine/imx6qsabreauto.conf b/conf/machine/imx6qsabreauto.conf
index 6f0bd8c..8ebd156 100644
--- a/conf/machine/imx6qsabreauto.conf
+++ b/conf/machine/imx6qsabreauto.conf
@@ -5,7 +5,7 @@
 include conf/machine/include/imx-base.inc
 include conf/machine/include/tune-cortexa9.inc
 
-SOC_FAMILY = "mx6q:mx6"
+SOC_FAMILY = "mx6:mx6q"
 
 KERNEL_DEVICETREE = "${S}/arch/arm/boot/dts/imx6q-sabreauto.dts"
 
diff --git a/conf/machine/imx6qsabresd.conf b/conf/machine/imx6qsabresd.conf
index d5a5192..67bdc65 100644
--- a/conf/machine/imx6qsabresd.conf
+++ b/conf/machine/imx6qsabresd.conf
@@ -5,7 +5,7 @@
 include conf/machine/include/imx-base.inc
 include conf/machine/include/tune-cortexa9.inc
 
-SOC_FAMILY = "mx6q:mx6"
+SOC_FAMILY = "mx6:mx6q"
 
 KERNEL_DEVICETREE = "${S}/arch/arm/boot/dts/imx6q-sabresd.dts"
 
diff --git a/conf/machine/imx6slevk.conf b/conf/machine/imx6slevk.conf
index 454c34f..78bc24b 100644
--- a/conf/machine/imx6slevk.conf
+++ b/conf/machine/imx6slevk.conf
@@ -5,7 +5,7 @@
 include conf/machine/include/imx-base.inc
 include conf/machine/include/tune-cortexa9.inc
 
-SOC_FAMILY = "mx6sl:mx6"
+SOC_FAMILY = "mx6:mx6sl"
 
 UBOOT_MACHINE = "mx6slevk_config"
 
-- 
1.8.1

[meta-fsl-arm PATCH v4 10/12] xf86-dri-vivante: Ensure install fails if .la cannot be removed

[Otavio Salvador]

To ensure we catch when the makefile stops to install the .la file, we
ensure the install fails in case .la file does not exist.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None

 recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb b/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb
index aa2361a..975041d 100644
--- a/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb
+++ b/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb
@@ -28,8 +28,8 @@ do_install_append () {
     cp -axr ${S}/src/*.h ${D}${includedir}/xorg
     find ${D}${includedir} -type f -exec chmod 660 {} \;
 
-    # don't install libtool (*.la) archive not usefull, fix Makefile.am
-    find ${D}${libdir}/xorg/modules -regex ".*\.la$" | xargs rm -f --
+    # FIXME: don't install libtool (*.la) file
+    rm ${D}${libdir}/xorg/modules/extensions/*.la
 }
 
 FILES_${PN}-dev += "${includedir}/xorg/*.h"
-- 
1.8.1

[meta-fsl-arm PATCH v4 11/12] xf86-dri-vivante: Fix DRI module name

[Otavio Salvador]

The Xorg Vivante driver has a hardcoded module name as 'vivante_dri'
so we need to rename it for full Xorg acceleration to work.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None

 recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb b/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb
index 975041d..6e8f8db 100644
--- a/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb
+++ b/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb
@@ -30,6 +30,10 @@ do_install_append () {
 
     # FIXME: don't install libtool (*.la) file
     rm ${D}${libdir}/xorg/modules/extensions/*.la
+
+    # FIXME: The Xorg driver has a hardcoded library name
+    mv ${D}${libdir}/xorg/modules/extensions/libdri.so \
+       ${D}${libdir}/xorg/modules/extensions/libvivante_dri.so
 }
 
 FILES_${PN}-dev += "${includedir}/xorg/*.h"
-- 
1.8.1

[meta-fsl-arm PATCH v4 12/12] xf86-video-imxfb-vivante: Enable software rendering support

[Otavio Salvador]

This is used by Vivante for 2D acceleration support. Fixes some
slowness seen when testing GUI images.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- New patch

 recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb
index 837b59c..22e8d6e 100644
--- a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb
+++ b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb
@@ -36,7 +36,7 @@ do_install_append () {
 	find ${D}${includedir} -type f -exec chmod 660 {} \;
 }
 
-RDEPENDS_${PN} += "xserver-xorg-module-exa xf86-dri-vivante"
+RDEPENDS_${PN} += "xserver-xorg-module-exa mesa-driver-swrast xf86-dri-vivante"
 
 # Add the ABI dependency at package generation time, as otherwise bitbake will
 # attempt to find a provider for it (and fail) when it does the parse.
-- 
1.8.1

Re: [meta-fsl-arm PATCH v4 0/12] Fixes current found issues for 1.4 release

[Daiane Angolini]

On 04/15/2013 05:15 PM, Otavio Salvador wrote:
> We've runned full build of 'fsl-image-gui' image in O.S. Systems build
> server for ALL machines in meta-fsl-arm and meta-fsl-arm-extra, the
> final build list is:
>

I tested (runtime) the following boards:

>   imx28evk ok
OK
touchscreen - OK
calibration - OK
mouse - OK
X11 - OK

>   imx53qsb ok
OK

>   imx6dlsabresd ok
X11 is up
3D Vivante seems to be down

>   imx6qsabreauto ok
X11 is up
3D Vivante seems to be down

>   imx6qsabresd ok
core-image-base - OK

>   imx6slevk ok
kernel does not get loaded. loadaddress for kernel is not OK (i'm 
investigating what's the root cause)


If you think you can merge it and *AFTER* fix imx6slevk, I'm OK with 
that (as I know imx6slevk is broken on HEAD of master)



Daiane

Re: [meta-fsl-arm PATCH v4 0/12] Fixes current found issues for 1.4 release

[Diego]

> On 04/15/2013 05:15 PM, Otavio Salvador wrote:
> > We've runned full build of 'fsl-image-gui' image in O.S. Systems build
> > server for ALL machines in meta-fsl-arm and meta-fsl-arm-extra, the
> 
> > final build list is:
> I tested (runtime) the following boards:

I'm still having problems with X on Nitrogen6x rev1 with latest master. fsl-
image-gui is giving me the following problem:
http://pastebin.com/JjzDCpEH
It stops at:
[4112708.170] (II) VIVANTE(0): test Initializing EXA
and never goes past it.

If I add:
Option      "NoAccel" "true"
to my xorg.conf then the X11 server starts fine, but that's not optimal. This 
is the log with exa disabled:
http://pastebin.com/6T7MdNn9

Regards,
Diego

Re: [meta-fsl-arm PATCH v4 0/12] Fixes current found issues for 1.4 release

[Otavio Salvador]

On Wed, Apr 17, 2013 at 1:03 PM, Diego <diego.ml@zoho.com> wrote:
>> On 04/15/2013 05:15 PM, Otavio Salvador wrote:
>> > We've runned full build of 'fsl-image-gui' image in O.S. Systems build
>> > server for ALL machines in meta-fsl-arm and meta-fsl-arm-extra, the
>>
>> > final build list is:
>> I tested (runtime) the following boards:
>
> I'm still having problems with X on Nitrogen6x rev1 with latest master. fsl-
> image-gui is giving me the following problem:
> http://pastebin.com/JjzDCpEH
> It stops at:
> [4112708.170] (II) VIVANTE(0): test Initializing EXA
> and never goes past it.
>
> If I add:
> Option      "NoAccel" "true"
> to my xorg.conf then the X11 server starts fine, but that's not optimal. This
> is the log with exa disabled:
> http://pastebin.com/6T7MdNn9

With the patchset applied?

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [meta-fsl-arm PATCH v4 0/12] Fixes current found issues for 1.4 release

[Otavio Salvador]

On Wed, Apr 17, 2013 at 2:49 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Wed, Apr 17, 2013 at 1:03 PM, Diego <diego.ml@zoho.com> wrote:
>>> On 04/15/2013 05:15 PM, Otavio Salvador wrote:
>>> > We've runned full build of 'fsl-image-gui' image in O.S. Systems build
>>> > server for ALL machines in meta-fsl-arm and meta-fsl-arm-extra, the
>>>
>>> > final build list is:
>>> I tested (runtime) the following boards:
>>
>> I'm still having problems with X on Nitrogen6x rev1 with latest master. fsl-
>> image-gui is giving me the following problem:
>> http://pastebin.com/JjzDCpEH
>> It stops at:
>> [4112708.170] (II) VIVANTE(0): test Initializing EXA
>> and never goes past it.
>>
>> If I add:
>> Option      "NoAccel" "true"
>> to my xorg.conf then the X11 server starts fine, but that's not optimal. This
>> is the log with exa disabled:
>> http://pastebin.com/6T7MdNn9
>
> With the patchset applied?

I applied the v4 of the patchset; can you build it again and give it a go?

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [meta-fsl-arm PATCH v4 0/12] Fixes current found issues for 1.4 release

[Diego]

In data mercoledì 17 aprile 2013 19:08:53, Otavio Salvador ha scritto:
> On Wed, Apr 17, 2013 at 2:49 PM, Otavio Salvador
> 
> <otavio@ossystems.com.br> wrote:
> > On Wed, Apr 17, 2013 at 1:03 PM, Diego <diego.ml@zoho.com> wrote:
> >>> On 04/15/2013 05:15 PM, Otavio Salvador wrote:
> >>> > We've runned full build of 'fsl-image-gui' image in O.S. Systems build
> >>> > server for ALL machines in meta-fsl-arm and meta-fsl-arm-extra, the
> >>> 
> >>> > final build list is:
> >>> I tested (runtime) the following boards:
> >> I'm still having problems with X on Nitrogen6x rev1 with latest master.
> >> fsl- image-gui is giving me the following problem:
> >> http://pastebin.com/JjzDCpEH
> >> It stops at:
> >> [4112708.170] (II) VIVANTE(0): test Initializing EXA
> >> and never goes past it.
> >> 
> >> If I add:
> >> Option      "NoAccel" "true"
> >> to my xorg.conf then the X11 server starts fine, but that's not optimal.
> >> This is the log with exa disabled:
> >> http://pastebin.com/6T7MdNn9
> > 
> > With the patchset applied?
> 
> I applied the v4 of the patchset; can you build it again and give it a go?

Building now.

I did not had the patchset applied but manually removed ".la" files (patch 10) 
and renamed libdri.so to libvivante_dri.so (patch 11) in my binary image and 
had no change. Is there any other patch which might affect X11 startup?

Will let you know if I have any change with the new build.

Diego

Re: [meta-fsl-arm PATCH v4 0/12] Fixes current found issues for 1.4 release

[Otavio Salvador]

On Thu, Apr 18, 2013 at 4:50 AM, Diego <diego.ml@zoho.com> wrote:
> In data mercoledì 17 aprile 2013 19:08:53, Otavio Salvador ha scritto:
>> On Wed, Apr 17, 2013 at 2:49 PM, Otavio Salvador
>>
>> <otavio@ossystems.com.br> wrote:
>> > On Wed, Apr 17, 2013 at 1:03 PM, Diego <diego.ml@zoho.com> wrote:
>> >>> On 04/15/2013 05:15 PM, Otavio Salvador wrote:
>> >>> > We've runned full build of 'fsl-image-gui' image in O.S. Systems build
>> >>> > server for ALL machines in meta-fsl-arm and meta-fsl-arm-extra, the
>> >>>
>> >>> > final build list is:
>> >>> I tested (runtime) the following boards:
>> >> I'm still having problems with X on Nitrogen6x rev1 with latest master.
>> >> fsl- image-gui is giving me the following problem:
>> >> http://pastebin.com/JjzDCpEH
>> >> It stops at:
>> >> [4112708.170] (II) VIVANTE(0): test Initializing EXA
>> >> and never goes past it.
>> >>
>> >> If I add:
>> >> Option      "NoAccel" "true"
>> >> to my xorg.conf then the X11 server starts fine, but that's not optimal.
>> >> This is the log with exa disabled:
>> >> http://pastebin.com/6T7MdNn9
>> >
>> > With the patchset applied?
>>
>> I applied the v4 of the patchset; can you build it again and give it a go?
>
> Building now.
>
> I did not had the patchset applied but manually removed ".la" files (patch 10)
> and renamed libdri.so to libvivante_dri.so (patch 11) in my binary image and
> had no change. Is there any other patch which might affect X11 startup?
>
> Will let you know if I have any change with the new build.

It will be good to know your feedback as we'll be at same page and can
further debug it.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Diego]

In data giovedì 18 aprile 2013 09:20:41, Otavio Salvador ha scritto:
> On Thu, Apr 18, 2013 at 4:50 AM, Diego <diego.ml@zoho.com> wrote:
> >> I applied the v4 of the patchset; can you build it again and give it a
> >> go?
> > 
> > Building now.
> > 
> > I did not had the patchset applied but manually removed ".la" files (patch
> > 10) and renamed libdri.so to libvivante_dri.so (patch 11) in my binary
> > image and had no change. Is there any other patch which might affect X11
> > startup?
> > 
> > Will let you know if I have any change with the new build.
> 
> It will be good to know your feedback as we'll be at same page and can
> further debug it.

To recap: I still have the same problem with latest master on Nitrogen6x. The 
full Xorg.0.log is here:
http://pastebin.com/7w9U8ueV

I'm here for any test.

Diego

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Otavio Salvador]

On Thu, Apr 18, 2013 at 11:07 AM, Diego <diego.ml@zoho.com> wrote:
> In data giovedì 18 aprile 2013 09:20:41, Otavio Salvador ha scritto:
>> On Thu, Apr 18, 2013 at 4:50 AM, Diego <diego.ml@zoho.com> wrote:
>> >> I applied the v4 of the patchset; can you build it again and give it a
>> >> go?
>> >
>> > Building now.
>> >
>> > I did not had the patchset applied but manually removed ".la" files (patch
>> > 10) and renamed libdri.so to libvivante_dri.so (patch 11) in my binary
>> > image and had no change. Is there any other patch which might affect X11
>> > startup?
>> >
>> > Will let you know if I have any change with the new build.
>>
>> It will be good to know your feedback as we'll be at same page and can
>> further debug it.
>
> To recap: I still have the same problem with latest master on Nitrogen6x. The
> full Xorg.0.log is here:
> http://pastebin.com/7w9U8ueV
>
> I'm here for any test.

I'm on it, right now...

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Diego]

> On Thu, Apr 18, 2013 at 11:07 AM, Diego <diego.ml at zoho.com> wrote:
> > In data giovedì 18 aprile 2013 09:20:41, Otavio Salvador ha scritto:
> >> On Thu, Apr 18, 2013 at 4:50 AM, Diego <diego.ml at zoho.com> wrote:
> >> >> I applied the v4 of the patchset; can you build it again and give it a
> >> >> go?
> >> > 
> >> > Building now.
> >> > 
> >> > I did not had the patchset applied but manually removed ".la" files
> >> > (patch
> >> > 10) and renamed libdri.so to libvivante_dri.so (patch 11) in my binary
> >> > image and had no change. Is there any other patch which might affect
> >> > X11
> >> > startup?
> >> > 
> >> > Will let you know if I have any change with the new build.
> >> 
> >> It will be good to know your feedback as we'll be at same page and can
> >> further debug it.
> > 
> > To recap: I still have the same problem with latest master on Nitrogen6x.
> > The
> > full Xorg.0.log is here:
> > http://pastebin.com/7w9U8ueV
> > 
> > I'm here for any test.
> 
> I'm on it, right now...

Hi Otavio.

Have you been able to reproduce the same issue?

Diego

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Otavio Salvador]

On Mon, Apr 22, 2013 at 4:02 AM, Diego <diego.ml@zoho.com> wrote:
>> On Thu, Apr 18, 2013 at 11:07 AM, Diego <diego.ml at zoho.com> wrote:
>> > In data giovedì 18 aprile 2013 09:20:41, Otavio Salvador ha scritto:
>> >> On Thu, Apr 18, 2013 at 4:50 AM, Diego <diego.ml at zoho.com> wrote:
>> >> >> I applied the v4 of the patchset; can you build it again and give it a
>> >> >> go?
>> >> >
>> >> > Building now.
>> >> >
>> >> > I did not had the patchset applied but manually removed ".la" files
>> >> > (patch
>> >> > 10) and renamed libdri.so to libvivante_dri.so (patch 11) in my binary
>> >> > image and had no change. Is there any other patch which might affect
>> >> > X11
>> >> > startup?
>> >> >
>> >> > Will let you know if I have any change with the new build.
>> >>
>> >> It will be good to know your feedback as we'll be at same page and can
>> >> further debug it.
>> >
>> > To recap: I still have the same problem with latest master on Nitrogen6x.
>> > The
>> > full Xorg.0.log is here:
>> > http://pastebin.com/7w9U8ueV
>> >
>> > I'm here for any test.
>>
>> I'm on it, right now...
>
> Hi Otavio.
>
> Have you been able to reproduce the same issue?

Yes and I fixed it. I am about to send the patches for checking.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Diego]

In data lunedì 22 aprile 2013 08:38:33, Otavio Salvador ha scritto:
> On Mon, Apr 22, 2013 at 4:02 AM, Diego <diego.ml@zoho.com> wrote:
> >> On Thu, Apr 18, 2013 at 11:07 AM, Diego <diego.ml at zoho.com> wrote:
> >> > In data giovedì 18 aprile 2013 09:20:41, Otavio Salvador ha scritto:
> >> > 
> >> > To recap: I still have the same problem with latest master on
> >> > Nitrogen6x.
> >> > The
> >> > full Xorg.0.log is here:
> >> > http://pastebin.com/7w9U8ueV
> >> > 
> >> > I'm here for any test.
> >> 
> >> I'm on it, right now...
> > 
> > Hi Otavio.
> > 
> > Have you been able to reproduce the same issue?
> 
> Yes and I fixed it. I am about to send the patches for checking.

Hi!

Finally good news! On a clean build I'm now able to boot and start X11 
correctly! Thank you for your work.

I'm now going to test 3D applications.

Regards,
Diego

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Daiane Angolini]

On 04/24/2013 09:20 AM, Diego wrote:
> In data lunedì 22 aprile 2013 08:38:33, Otavio Salvador ha scritto:
>> On Mon, Apr 22, 2013 at 4:02 AM, Diego <diego.ml@zoho.com> wrote:
>>>> On Thu, Apr 18, 2013 at 11:07 AM, Diego <diego.ml at zoho.com> wrote:
>>>>> In data giovedì 18 aprile 2013 09:20:41, Otavio Salvador ha scritto:
>>>>>
>>>>> To recap: I still have the same problem with latest master on
>>>>> Nitrogen6x.
>>>>> The
>>>>> full Xorg.0.log is here:
>>>>> http://pastebin.com/7w9U8ueV
>>>>>
>>>>> I'm here for any test.
>>>>
>>>> I'm on it, right now...
>>>
>>> Hi Otavio.
>>>
>>> Have you been able to reproduce the same issue?
>>
>> Yes and I fixed it. I am about to send the patches for checking.
>
> Hi!
>
> Finally good news! On a clean build I'm now able to boot and start X11
> correctly! Thank you for your work.

\o/

>
> I'm now going to test 3D applications.

Could you share how you test 3D applications?

-- 
Daiane

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Diego]

In data mercoledì 24 aprile 2013 09:30:29, Daiane Angolini ha scritto:
> On 04/24/2013 09:20 AM, Diego wrote:
> > 
> > Hi!
> > 
> > Finally good news! On a clean build I'm now able to boot and start X11
> > correctly! Thank you for your work.
> 
> \o/
> 
> > I'm now going to test 3D applications.
> 
> Could you share how you test 3D applications?

At the moment I tested with mesa-demo (es2 demos) and vivante's own demo 
sources.

Let me define the two.

For mesa-demo I cross-compiled the mesa-demo-8.0.1 (planning to move to 8.1.0 
which has been released just a couple of month ago 
http://cgit.freedesktop.org/mesa/demos/tag/?id=mesa-demos-8.1.0 ). In 
particular I built the es2 demos, which are not enabled by default in the 
Makefile:
http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles2

For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is available here 
under the voice "Snippets, Boot Code, Headers, Monitors, etc.", called 
"IMX6_GPU_SDK":
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp=1&tab=Design_Tools_Tab

The current status is still the same as I described here:
https://lists.yoctoproject.org/pipermail/meta-freescale/2013-April/001963.html
So I have white windows with mesa demos, and black windows with Vivante 
Samples.

I'll try with glmark2-es2 as suggested here:
https://lists.yoctoproject.org/pipermail/meta-freescale/2013-April/001965.html
but I don't expect any improvement.

Anybody else with the same problem on Nitrogen6x? Anybody else has results for 
these tests (I can provide binaries, if anybody asks)?

Bests,
Diego

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Daiane Angolini]

On 04/24/2013 11:12 AM, Diego wrote:
> In data mercoledì 24 aprile 2013 09:30:29, Daiane Angolini ha scritto:
>> On 04/24/2013 09:20 AM, Diego wrote:
>>>
>>> Hi!
>>>
>>> Finally good news! On a clean build I'm now able to boot and start X11
>>> correctly! Thank you for your work.
>>
>> \o/
>>
>>> I'm now going to test 3D applications.
>>
>> Could you share how you test 3D applications?
>
> At the moment I tested with mesa-demo (es2 demos) and vivante's own demo
> sources.
>
> Let me define the two.

Thanks a lot! I always wonder what would be the best test for GPU support ;)


>
> For mesa-demo I cross-compiled the mesa-demo-8.0.1 (planning to move to 8.1.0
> which has been released just a couple of month ago
> http://cgit.freedesktop.org/mesa/demos/tag/?id=mesa-demos-8.1.0 ). In
> particular I built the es2 demos, which are not enabled by default in the
> Makefile:
> http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles2
>
> For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is available here
> under the voice "Snippets, Boot Code, Headers, Monitors, etc.", called
> "IMX6_GPU_SDK":
> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp=1&tab=Design_Tools_Tab

Do you have the recipe for this package? It was on my list to be 
included on meta-fsl-demos. If you have it I will be very happy to 
include it to meta-fsl-demos.


-- 
Daiane

Vivante 3D tests [Was] Xorg fails to start on "test Initializing EXA" on Nitrogen6x

[Diego]

In data mercoledì 24 aprile 2013 11:21:25, Daiane Angolini ha scritto:
> On 04/24/2013 11:12 AM, Diego wrote:
> > For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is available
> > here under the voice "Snippets, Boot Code, Headers, Monitors, etc.",
> > called "IMX6_GPU_SDK":
> > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp
> > =1&tab=Design_Tools_Tab
>
> Do you have the recipe for this package? It was on my list to be
> included on meta-fsl-demos. If you have it I will be very happy to
> include it to meta-fsl-demos.

I don't have one, as I'm a bitbake receipe newbie, but I'm willing to try to 
write one, if someone is willing to review it and give me directions when I'm 
lost. Would you be happy to review my work?

Bests,
Diego

Re: Vivante 3D tests [Was] Xorg fails to start on "test Initializing EXA" on Nitrogen6x

[Otavio Salvador]

On Wed, Apr 24, 2013 at 12:08 PM, Diego <diego.ml@zoho.com> wrote:
> In data mercoledì 24 aprile 2013 11:21:25, Daiane Angolini ha scritto:
>> On 04/24/2013 11:12 AM, Diego wrote:
>> > For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is available
>> > here under the voice "Snippets, Boot Code, Headers, Monitors, etc.",
>> > called "IMX6_GPU_SDK":
>> > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp
>> > =1&tab=Design_Tools_Tab
>>
>> Do you have the recipe for this package? It was on my list to be
>> included on meta-fsl-demos. If you have it I will be very happy to
>> include it to meta-fsl-demos.
>
> I don't have one, as I'm a bitbake receipe newbie, but I'm willing to try to
> write one, if someone is willing to review it and give me directions when I'm
> lost. Would you be happy to review my work?

I am sure Daiane will be happy to review it, so do I :-)

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Vivante 3D tests [Was] Xorg fails to start on "test Initializing EXA" on Nitrogen6x

[Daiane Angolini]

On 04/24/2013 12:08 PM, Diego wrote:
> In data mercoledì 24 aprile 2013 11:21:25, Daiane Angolini ha scritto:
>> On 04/24/2013 11:12 AM, Diego wrote:
>>> For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is available
>>> here under the voice "Snippets, Boot Code, Headers, Monitors, etc.",
>>> called "IMX6_GPU_SDK":
>>> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp
>>> =1&tab=Design_Tools_Tab
>>
>> Do you have the recipe for this package? It was on my list to be
>> included on meta-fsl-demos. If you have it I will be very happy to
>> include it to meta-fsl-demos.
>
> I don't have one, as I'm a bitbake receipe newbie, but I'm willing to try to
> write one, if someone is willing to review it and give me directions when I'm
> lost. Would you be happy to review my work?

Absolutely!!!!!!!!!!



-- 
Daiane

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Otavio Salvador]

On Wed, Apr 24, 2013 at 11:12 AM, Diego <diego.ml@zoho.com> wrote:
...
> For mesa-demo I cross-compiled the mesa-demo-8.0.1 (planning to move to 8.1.0
> which has been released just a couple of month ago
> http://cgit.freedesktop.org/mesa/demos/tag/?id=mesa-demos-8.1.0 ). In
> particular I built the es2 demos, which are not enabled by default in the
> Makefile:
> http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles2

How did you build them? I did try to include --enable-gles2 but these
were not build.

> For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is available here
> under the voice "Snippets, Boot Code, Headers, Monitors, etc.", called
> "IMX6_GPU_SDK":
> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp=1&tab=Design_Tools_Tab

Looking forward to hear from you :-) Please send the recipe :-)

> The current status is still the same as I described here:
> https://lists.yoctoproject.org/pipermail/meta-freescale/2013-April/001963.html
> So I have white windows with mesa demos, and black windows with Vivante
> Samples.
>
> I'll try with glmark2-es2 as suggested here:
> https://lists.yoctoproject.org/pipermail/meta-freescale/2013-April/001965.html
> but I don't expect any improvement.
>
> Anybody else with the same problem on Nitrogen6x? Anybody else has results for
> these tests (I can provide binaries, if anybody asks)?

It seems windowed mode is currently broken; there's no known
workaround or solution for it yet.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Diego]

In data mercoledì 24 aprile 2013 13:30:47, Otavio Salvador ha scritto:
> On Wed, Apr 24, 2013 at 11:12 AM, Diego <diego.ml@zoho.com> wrote:
> ...
> 
> > For mesa-demo I cross-compiled the mesa-demo-8.0.1 (planning to move to
> > 8.1.0 which has been released just a couple of month ago
> > http://cgit.freedesktop.org/mesa/demos/tag/?id=mesa-demos-8.1.0 ). In
> > particular I built the es2 demos, which are not enabled by default in the
> > Makefile:
> > http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles2
> 
> How did you build them? I did try to include --enable-gles2 but these
> were not build.

I remember having that problem on mesa demos 8.0.1 too. The manual workaround 
was to run "make" in the opengles2 folder.

With mesa demos 8.1.0 I don't have this problem anymore. Both cmake 
(autodetection) and autoconf (via --enable-gles2) build correctly everything 
in opengles2.

> > For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is available
> > here under the voice "Snippets, Boot Code, Headers, Monitors, etc.",
> > called "IMX6_GPU_SDK":
> > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp
> > =1&tab=Design_Tools_Tab
> Looking forward to hear from you :-) Please send the recipe :-)
> 

I'll work on in it.

> > The current status is still the same as I described here:
> > https://lists.yoctoproject.org/pipermail/meta-freescale/2013-April/001963.
> > html So I have white windows with mesa demos, and black windows with
> > Vivante Samples.
> > 
> > I'll try with glmark2-es2 as suggested here:
> > https://lists.yoctoproject.org/pipermail/meta-freescale/2013-April/001965.
> > html but I don't expect any improvement.
> > 
> > Anybody else with the same problem on Nitrogen6x? Anybody else has results
> > for these tests (I can provide binaries, if anybody asks)?
> 
> It seems windowed mode is currently broken; there's no known
> workaround or solution for it yet.
> 

With that do you mean fullscreen mode is working fine? Have you been able to 
run any demo / program OpenGL ES accelerated on Nitrogen in X11?

Bests,
Diego

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Otavio Salvador]

On Fri, Apr 26, 2013 at 10:04 AM, Diego <diego.ml@zoho.com> wrote:
> In data mercoledì 24 aprile 2013 13:30:47, Otavio Salvador ha scritto:
>> On Wed, Apr 24, 2013 at 11:12 AM, Diego <diego.ml@zoho.com> wrote:
>> ...
>>
>> > For mesa-demo I cross-compiled the mesa-demo-8.0.1 (planning to move to
>> > 8.1.0 which has been released just a couple of month ago
>> > http://cgit.freedesktop.org/mesa/demos/tag/?id=mesa-demos-8.1.0 ). In
>> > particular I built the es2 demos, which are not enabled by default in the
>> > Makefile:
>> > http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles2
>>
>> How did you build them? I did try to include --enable-gles2 but these
>> were not build.
>
> I remember having that problem on mesa demos 8.0.1 too. The manual workaround
> was to run "make" in the opengles2 folder.
>
> With mesa demos 8.1.0 I don't have this problem anymore. Both cmake
> (autodetection) and autoconf (via --enable-gles2) build correctly everything
> in opengles2.

Did you find the commit which fixes it? It'd be willing to try to
backport it to 8.0.1 and avoid using dirty hacks to package these.

>> > For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is available
>> > here under the voice "Snippets, Boot Code, Headers, Monitors, etc.",
>> > called "IMX6_GPU_SDK":
>> > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fpsp
>> > =1&tab=Design_Tools_Tab
>> Looking forward to hear from you :-) Please send the recipe :-)
>>
>
> I'll work on in it.
>
>> > The current status is still the same as I described here:
>> > https://lists.yoctoproject.org/pipermail/meta-freescale/2013-April/001963.
>> > html So I have white windows with mesa demos, and black windows with
>> > Vivante Samples.
>> >
>> > I'll try with glmark2-es2 as suggested here:
>> > https://lists.yoctoproject.org/pipermail/meta-freescale/2013-April/001965.
>> > html but I don't expect any improvement.
>> >
>> > Anybody else with the same problem on Nitrogen6x? Anybody else has results
>> > for these tests (I can provide binaries, if anybody asks)?
>>
>> It seems windowed mode is currently broken; there's no known
>> workaround or solution for it yet.
>>
>
> With that do you mean fullscreen mode is working fine? Have you been able to
> run any demo / program OpenGL ES accelerated on Nitrogen in X11?

It was. I didn't test it again lately.

Did you got the Vivante SDK examples running? these were used for the test.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Mesa demos and Vivante 3D

[Diego]

In data venerdì 26 aprile 2013 12:09:04, Otavio Salvador ha scritto:
> On Fri, Apr 26, 2013 at 10:04 AM, Diego <diego.ml@zoho.com> wrote:
> > In data mercoledì 24 aprile 2013 13:30:47, Otavio Salvador ha scritto:
> >> On Wed, Apr 24, 2013 at 11:12 AM, Diego <diego.ml@zoho.com> wrote:
> >> ...
> >> 
> >> > For mesa-demo I cross-compiled the mesa-demo-8.0.1 (planning to move to
> >> > 8.1.0 which has been released just a couple of month ago
> >> > http://cgit.freedesktop.org/mesa/demos/tag/?id=mesa-demos-8.1.0 ). In
> >> > particular I built the es2 demos, which are not enabled by default in
> >> > the
> >> > Makefile:
> >> > http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles2
> >> 
> >> How did you build them? I did try to include --enable-gles2 but these
> >> were not build.
> > 
> > I remember having that problem on mesa demos 8.0.1 too. The manual
> > workaround was to run "make" in the opengles2 folder.
> > 
> > With mesa demos 8.1.0 I don't have this problem anymore. Both cmake
> > (autodetection) and autoconf (via --enable-gles2) build correctly
> > everything in opengles2.
> 
> Did you find the commit which fixes it? It'd be willing to try to
> backport it to 8.0.1 and avoid using dirty hacks to package these.

I think this is it:
http://cgit.freedesktop.org/mesa/demos/commit/?id=4a6a75b454ec181d267af9af0b153459d677251e

Please take into account that this patch is at least required too (tri 
renaming) if you don't want to modify the original one:
http://cgit.freedesktop.org/mesa/demos/commit/src/egl/opengles2?id=024df5987e4da9288cc9c62dc71df1812d84a347

> >> It seems windowed mode is currently broken; there's no known
> >> workaround or solution for it yet.
> > 
> > With that do you mean fullscreen mode is working fine? Have you been able
> > to run any demo / program OpenGL ES accelerated on Nitrogen in X11?
> 
> It was. I didn't test it again lately.

Interesting. Do you remember if it was in 1.3 release or somewhere between 1.3 
and now?

> Did you got the Vivante SDK examples running? these were used for the test.

Nope. I have no clue on how to solve that white window...

Diego

Re: Mesa demos and Vivante 3D

[Otavio Salvador]

On Fri, Apr 26, 2013 at 12:32 PM, Diego <diego.ml@zoho.com> wrote:
> In data venerdì 26 aprile 2013 12:09:04, Otavio Salvador ha scritto:
>> On Fri, Apr 26, 2013 at 10:04 AM, Diego <diego.ml@zoho.com> wrote:
>> > In data mercoledì 24 aprile 2013 13:30:47, Otavio Salvador ha scritto:
>> >> On Wed, Apr 24, 2013 at 11:12 AM, Diego <diego.ml@zoho.com> wrote:
>> >> ...
>> >>
>> >> > For mesa-demo I cross-compiled the mesa-demo-8.0.1 (planning to move to
>> >> > 8.1.0 which has been released just a couple of month ago
>> >> > http://cgit.freedesktop.org/mesa/demos/tag/?id=mesa-demos-8.1.0 ). In
>> >> > particular I built the es2 demos, which are not enabled by default in
>> >> > the
>> >> > Makefile:
>> >> > http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengles2
>> >>
>> >> How did you build them? I did try to include --enable-gles2 but these
>> >> were not build.
>> >
>> > I remember having that problem on mesa demos 8.0.1 too. The manual
>> > workaround was to run "make" in the opengles2 folder.
>> >
>> > With mesa demos 8.1.0 I don't have this problem anymore. Both cmake
>> > (autodetection) and autoconf (via --enable-gles2) build correctly
>> > everything in opengles2.
>>
>> Did you find the commit which fixes it? It'd be willing to try to
>> backport it to 8.0.1 and avoid using dirty hacks to package these.
>
> I think this is it:
> http://cgit.freedesktop.org/mesa/demos/commit/?id=4a6a75b454ec181d267af9af0b153459d677251e
>
> Please take into account that this patch is at least required too (tri
> renaming) if you don't want to modify the original one:
> http://cgit.freedesktop.org/mesa/demos/commit/src/egl/opengles2?id=024df5987e4da9288cc9c62dc71df1812d84a347

I am finishing the patch to send to Poky, in fact it needed another
one (for configure.ac).

>> >> It seems windowed mode is currently broken; there's no known
>> >> workaround or solution for it yet.
>> >
>> > With that do you mean fullscreen mode is working fine? Have you been able
>> > to run any demo / program OpenGL ES accelerated on Nitrogen in X11?
>>
>> It was. I didn't test it again lately.
>
> Interesting. Do you remember if it was in 1.3 release or somewhere between 1.3
> and now?

It was when testing the changes I sent (a week ago?). So dylan.

>> Did you got the Vivante SDK examples running? these were used for the test.
>
> Nope. I have no clue on how to solve that white window...

First step is to get it building so we can check why it fails later.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Diego]

In data venerdì 26 aprile 2013 15:04:36, Diego ha scritto:
> In data mercoledì 24 aprile 2013 13:30:47, Otavio Salvador ha scritto:
> > On Wed, Apr 24, 2013 at 11:12 AM, Diego <diego.ml@zoho.com> wrote:
> > > For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is
> > > available
> > > here under the voice "Snippets, Boot Code, Headers, Monitors, etc.",
> > > called "IMX6_GPU_SDK":
> > > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fp
> > > sp
> > > =1&tab=Design_Tools_Tab
> > 
> > Looking forward to hear from you :-) Please send the recipe :-)
> 
> I'll work on in it.
> 

Diane (or any other Freescale guys lurking here), are you able to host the 
gpu_sdk_v1.00.tar.gz package somewhere in Freescale's hosting without 
requiring a Freescale's login so that I can use a Freescale's URL in the 
recipe?

I think there's no licensing issues, as it's a Freescale derivative of someone 
else's work, and COPYING seems to list only Open Source licenses.

Diane, what do you think?

Bests,
Diego

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Daiane Angolini]

On 04/29/2013 06:33 AM, Diego wrote:
> In data venerdì 26 aprile 2013 15:04:36, Diego ha scritto:
>> In data mercoledì 24 aprile 2013 13:30:47, Otavio Salvador ha scritto:
>>> On Wed, Apr 24, 2013 at 11:12 AM, Diego <diego.ml@zoho.com> wrote:
>>>> For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is
>>>> available
>>>> here under the voice "Snippets, Boot Code, Headers, Monitors, etc.",
>>>> called "IMX6_GPU_SDK":
>>>> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fp
>>>> sp
>>>> =1&tab=Design_Tools_Tab
>>>
>>> Looking forward to hear from you :-) Please send the recipe :-)
>>
>> I'll work on in it.
>>
>
> Diane (or any other Freescale guys lurking here), are you able to host the
> gpu_sdk_v1.00.tar.gz package somewhere in Freescale's hosting without
> requiring a Freescale's login so that I can use a Freescale's URL in the
> recipe?
>
> I think there's no licensing issues, as it's a Freescale derivative of someone
> else's work, and COPYING seems to list only Open Source licenses.
>
> Diane, what do you think?

I will check it and let you know when/if it's uploaded.

Are you able to start your work without this package being on a server? 
(at least for a while?)


-- 
Daiane

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Otavio Salvador]

On Mon, Apr 29, 2013 at 8:57 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/29/2013 06:33 AM, Diego wrote:
>>
>> In data venerdì 26 aprile 2013 15:04:36, Diego ha scritto:
>>>
>>> In data mercoledì 24 aprile 2013 13:30:47, Otavio Salvador ha scritto:
>>>>
>>>> On Wed, Apr 24, 2013 at 11:12 AM, Diego <diego.ml@zoho.com> wrote:
>>>>>
>>>>> For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is
>>>>> available
>>>>> here under the voice "Snippets, Boot Code, Headers, Monitors, etc.",
>>>>> called "IMX6_GPU_SDK":
>>>>>
>>>>> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&fp
>>>>> sp
>>>>> =1&tab=Design_Tools_Tab
>>>>
>>>>
>>>> Looking forward to hear from you :-) Please send the recipe :-)
>>>
>>>
>>> I'll work on in it.
>>>
>>
>> Diane (or any other Freescale guys lurking here), are you able to host the
>> gpu_sdk_v1.00.tar.gz package somewhere in Freescale's hosting without
>> requiring a Freescale's login so that I can use a Freescale's URL in the
>> recipe?
>>
>> I think there's no licensing issues, as it's a Freescale derivative of
>> someone
>> else's work, and COPYING seems to list only Open Source licenses.
>>
>> Diane, what do you think?
>
>
> I will check it and let you know when/if it's uploaded.
>
> Are you able to start your work without this package being on a server? (at
> least for a while?)

I can add it at O.S. Systems server in meanwhile however the tarball
name is way too generic (and might conflict in DL_DIR) so I renamed it
to vivante-gpu-sdk_1.0.tar.gz. Is it OK?

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Diego]

In data lunedì 29 aprile 2013 09:06:09, Otavio Salvador ha scritto:
> On Mon, Apr 29, 2013 at 8:57 AM, Daiane Angolini
> 
> <daiane.angolini@freescale.com> wrote:
> > On 04/29/2013 06:33 AM, Diego wrote:
> >> In data venerdì 26 aprile 2013 15:04:36, Diego ha scritto:
> >>> In data mercoledì 24 aprile 2013 13:30:47, Otavio Salvador ha scritto:
> >>>> On Wed, Apr 24, 2013 at 11:12 AM, Diego <diego.ml@zoho.com> wrote:
> >>>>> For Vivante demos I mean the gpu_sdk_v1.00.tar.gz file which is
> >>>>> available
> >>>>> here under the voice "Snippets, Boot Code, Headers, Monitors, etc.",
> >>>>> called "IMX6_GPU_SDK":
> >>>>> 
> >>>>> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&
> >>>>> fp
> >>>>> sp
> >>>>> =1&tab=Design_Tools_Tab
> >>>> 
> >>>> Looking forward to hear from you :-) Please send the recipe :-)
> >>> 
> >>> I'll work on in it.
> >> 
> >> Diane (or any other Freescale guys lurking here), are you able to host
> >> the
> >> gpu_sdk_v1.00.tar.gz package somewhere in Freescale's hosting without
> >> requiring a Freescale's login so that I can use a Freescale's URL in the
> >> recipe?
> >> 
> >> I think there's no licensing issues, as it's a Freescale derivative of
> >> someone
> >> else's work, and COPYING seems to list only Open Source licenses.
> >> 
> >> Diane, what do you think?
> > 
> > I will check it and let you know when/if it's uploaded.
> > 
> > Are you able to start your work without this package being on a server?
> > (at
> > least for a while?)
> 

Sure I am. I'm hacking it locally in the meanwhile.

> I can add it at O.S. Systems server in meanwhile however the tarball
> name is way too generic (and might conflict in DL_DIR) so I renamed it
> to vivante-gpu-sdk_1.0.tar.gz. Is it OK?

I named the recipe exactly that way even before you posted it!

Will share the recipe when I'll have a rough draft.

Diego

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Daiane Angolini]

On 04/29/2013 09:06 AM, Otavio Salvador wrote:
> On Mon, Apr 29, 2013 at 8:57 AM, Daiane Angolini

>> I will check it and let you know when/if it's uploaded.
>>
>> Are you able to start your work without this package being on a server? (at
>> least for a while?)
>
> I can add it at O.S. Systems server in meanwhile however the tarball
> name is way too generic (and might conflict in DL_DIR) so I renamed it
> to vivante-gpu-sdk_1.0.tar.gz. Is it OK?

I prefer to keep the original name, at least for the tarball.

For the recipe you can use any name.

At least until I understand exactly the license for the package


-- 
Daiane

Re: Xorg fails to start on "test Initializing EXA" on Nitrogen6x [Was] Fixes current ...

[Otavio Salvador]

On Mon, Apr 29, 2013 at 9:13 AM, Daiane Angolini
<daiane.angolini@freescale.com> wrote:
> On 04/29/2013 09:06 AM, Otavio Salvador wrote:
>>
>> On Mon, Apr 29, 2013 at 8:57 AM, Daiane Angolini
>
>
>>> I will check it and let you know when/if it's uploaded.
>>>
>>> Are you able to start your work without this package being on a server?
>>> (at
>>> least for a while?)
>>
>>
>> I can add it at O.S. Systems server in meanwhile however the tarball
>> name is way too generic (and might conflict in DL_DIR) so I renamed it
>> to vivante-gpu-sdk_1.0.tar.gz. Is it OK?
>
>
> I prefer to keep the original name, at least for the tarball.

The problem 'gpu' is way too generic. Currently I don't know if any
recipe using this namespace but it is way easy to this to happen in
future. So renaming the binary avoid name clash in the DL_DIR, seems
safer for me.

> For the recipe you can use any name.
>
> At least until I understand exactly the license for the package

Right.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br