From: Alexander Holler <holler@ahsoftware.de>
To: Lauren Post <Lauren.Post@freescale.com>,
Otavio Salvador <otavio@ossystems.com.br>
Cc: "meta-freescale@yoctoproject.org" <meta-freescale@yoctoproject.org>
Subject: Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO)
Date: Tue, 02 Sep 2014 16:18:26 +0200 [thread overview]
Message-ID: <5405D1B2.9060900@ahsoftware.de> (raw)
In-Reply-To: <7aafbc08e6ca43d397588d97da15e011@DM2PR0301MB0701.namprd03.prod.outlook.com>
Am 02.09.2014 15:32, schrieb Lauren Post:
> You can't mix and match 3.10.17 kernel with 3.10.31 graphics unless
> you take the 3.10.31 graphics driver and put it on 3.10.17 kernel.
> The kernel driver and graphics package must align.
>
> That is why you have build issues.
Am 02.09.2014 15:32, schrieb Lauren Post:
> You can't mix and match 3.10.17 kernel with 3.10.31 graphics unless
> you take the 3.10.31 graphics driver and put it on 3.10.17 kernel.
> The kernel driver and graphics package must align.
>
> That is why you have build issues.
Found it.
During the various test with various kernels and imx-lib-versions (all
unsuccesfull up to now) /usr/lib/libGAL-x11.so somehow changed from a
symlink to a binary. The binary for 3.10.17. And it looks like my
installation of libGAL 3.10.31 didn't overwrite that or whatever, I
still have to search the reason.
Besides that, you sound like a new gpu-library is unable to deal with an
old kernel. Not very nice as it ties userland to the kernel version.
Anyway, sorry for wrong error message.
But you have to deal with such, when the installation is as complicated
as it currently is with all the various binary libraries and various
necessary patches.
What makes it further complicated is, that I have to switch between
mesa-opengl and imx-opengl for building various packages. For example
the xorg-x11-server fails when building against imx-libraries (because
it uses "-lGL -ldrm" and the imx-libraries do require "-ldrm -lGL").
It's really a pain to set that up.
So the opengl-stuff is currently a symlink-hell here I have to change
quite often and I seem to have made a failure I didn't seen before. Even
I've looked multiple times at the links and there target before posting
the message, but Murphy is almost always present.
Regards,
Alexander Holler
>
> Lauren
>
> -----Original Message----- From:
> meta-freescale-bounces@yoctoproject.org
> [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of
> Alexander Holler Sent: Monday, September 01, 2014 9:01 AM To: Otavio
> Salvador Cc: meta-freescale@yoctoproject.org Subject: Re:
> [meta-freescale] 3.10.31-beta: gcoHAL_Construct returns -7
> (gcvSTATUS_GENERIC_IO)
>
>
> Just checked 3.10.17 and there the size of gcsHAL_INTERFACE is 248,
> the same as used by the libs in gpu-viv-bin-mx6q-3.10.31-1.1.0-beta.
> So the libs seem to have been compiled against headers with an old
> gcsHAL_INTERFACE and are therefor unusable with kernel 3.10.31.
>
> Here is a small test program one can check against kernel 3.10.17 and
> 3.10.31:
>
> ----------------------------- #include <stdio.h>
>
> #include
> "/usr/src/linux/drivers/mxc/gpu-viv/hal/kernel/inc/gc_hal.h"
>
> int main(void) { printf("Size: %u\n", sizeof(gcsHAL_INTERFACE));
> return 0; } -----------------------------
>
> Regards,
>
> Alexander Holler -- _______________________________________________
> meta-freescale mailing list meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
No.
I don't mix and match drivers, libraries or kernels. The kernel is
3.10.31, the library is 3.10.31 and the driver is 3.10.31 too. And I've
written that.
What I did was reverting commit 28a4a163b561c39ac0c798d420e0927f29e9d4c8
"drm: platform multi-device support" in the 3.10.31 kernel. Had to do
this to let the x11-driver find the device. Maybe that is the reason why
the binary blob thinks it deals with an old kernel. But it's just
another assumption as I don't and can't know what the binary lib is
doing and how it decides (if it does that at all) with which kernel it
deals.
Besides that, you sound like a new library is unable to deal with an old
kernel.
If so, then there is for sure something wrong, because I see in kernel
3.10.31 the size mismatch and I'm using the xorg-driver 3.10.31 together
with gpu* 3.10.31 (as written before).
>
> Lauren
>
> -----Original Message----- From:
> meta-freescale-bounces@yoctoproject.org
> [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of
> Alexander Holler Sent: Monday, September 01, 2014 9:01 AM To: Otavio
> Salvador Cc: meta-freescale@yoctoproject.org Subject: Re:
> [meta-freescale] 3.10.31-beta: gcoHAL_Construct returns -7
> (gcvSTATUS_GENERIC_IO)
>
>
> Just checked 3.10.17 and there the size of gcsHAL_INTERFACE is 248,
> the same as used by the libs in gpu-viv-bin-mx6q-3.10.31-1.1.0-beta.
> So the libs seem to have been compiled against headers with an old
> gcsHAL_INTERFACE and are therefor unusable with kernel 3.10.31.
>
> Here is a small test program one can check against kernel 3.10.17
> and 3.10.31:
>
> ----------------------------- #include <stdio.h>
>
> #include
> "/usr/src/linux/drivers/mxc/gpu-viv/hal/kernel/inc/gc_hal.h"
>
> int main(void) { printf("Size: %u\n", sizeof(gcsHAL_INTERFACE));
> return 0; } -----------------------------
>
> Regards,
>
> Alexander Holler -- _______________________________________________
> meta-freescale mailing list meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
prev parent reply other threads:[~2014-09-02 14:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-30 20:06 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO) Alexander Holler
2014-08-31 19:50 ` Alexander Holler
2014-09-01 12:36 ` Otavio Salvador
2014-09-01 12:59 ` Alexander Holler
2014-09-01 14:01 ` Alexander Holler
2014-09-02 13:32 ` Lauren Post
2014-09-02 14:18 ` Alexander Holler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5405D1B2.9060900@ahsoftware.de \
--to=holler@ahsoftware.de \
--cc=Lauren.Post@freescale.com \
--cc=meta-freescale@yoctoproject.org \
--cc=otavio@ossystems.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.