3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO)

3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO)

[Alexander Holler]

Hello,

as I'm curious how the accelerated graphics do look like on the i.mx6q, 
I've compiled and installed what's seems to be necessary to use 
xserver-xorg-video-imx-viv (kernel and all libs/drivers are at 
3.10.31-beta, xorg is 1.15.0, the system is hfp, not using yocto).

When starting the xserver it ends up with:

(...)
[    53.368] (II)         UploadToScreen
[    53.368] (EE) VIVANTE(0): internal error: GPU Ctx Init Failed
[    53.369] (EE) VIVANTE(0): internal error: initExaLayer failed in 
FBDevScreenInit()
[    53.369] (II) VIVANTE(0): Init SHM pixmap support
[    53.369] (==) VIVANTE(0): Backing store enabled
(...)

which comes because gcoHAL_Construct() returns -7 (gcvSTATUS_GENERIC_IO).

As most stuff is only binary, there isn't much I could do.

galcore.showArgs=1 says the following:

[    2.503451] Galcore version 5.0.11.19959
[    2.503454] Galcore options:
[    2.503456]   irqLine           = 41
[    2.503459]   registerMemBase   = 0x00130000
[    2.503462]   registerMemSize   = 0x00004000
[    2.503464]   irqLine2D         = 42
[    2.503466]   registerMemBase2D = 0x00134000
[    2.503468]   registerMemSize2D = 0x00004000
[    2.503470]   irqLineVG         = 43
[    2.503472]   registerMemBaseVG = 0x02204000
[    2.503473]   registerMemSizeVG = 0x00004000
[    2.503476]   contiguousSize    = 134217728
[    2.503478]   contiguousBase    = 0x6E700000
[    2.503480]   bankSize          = 0x00000000
[    2.503482]   fastClear         = -1
[    2.503484]   compression       = -1
[    2.503485]   signal            = 48
[    2.503488]   powerManagement   = 1
[    2.503490]   baseAddress       = 0x00000000
[    2.503491]   physSize          = 0x00000000
[    2.503493]   logFileSize       = 10240 KB
[    2.503495]   recovery          = 1
[    2.503497]   stuckDump         = 1
[    2.503498]   gpuProfiler       = 0

and that -7 doesn't seem to come from the kernel driver.

Any ideas?

Regards,

Alexander Holler

Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO)

[Alexander Holler]

Am 30.08.2014 22:06, schrieb Alexander Holler:
> Hello,
>
> as I'm curious how the accelerated graphics do look like on the i.mx6q,
> I've compiled and installed what's seems to be necessary to use
> xserver-xorg-video-imx-viv (kernel and all libs/drivers are at
> 3.10.31-beta, xorg is 1.15.0, the system is hfp, not using yocto).
>
> When starting the xserver it ends up with:
>
> (...)
> [    53.368] (II)         UploadToScreen
> [    53.368] (EE) VIVANTE(0): internal error: GPU Ctx Init Failed
> [    53.369] (EE) VIVANTE(0): internal error: initExaLayer failed in
> FBDevScreenInit()
> [    53.369] (II) VIVANTE(0): Init SHM pixmap support
> [    53.369] (==) VIVANTE(0): Backing store enabled
> (...)
>
> which comes because gcoHAL_Construct() returns -7 (gcvSTATUS_GENERIC_IO).
>
> As most stuff is only binary, there isn't much I could do.

I'm a bit further: the error does come from this part of the galcore 
stuff in the kernel (drv_ioctl())

     /* Now bring in the gcsHAL_INTERFACE structure. */
     if ((drvArgs.InputBufferSize  != sizeof(gcsHAL_INTERFACE))
     ||  (drvArgs.OutputBufferSize != sizeof(gcsHAL_INTERFACE))
     )
     {
	return some error
     }

where sizeof(gcsHAL_INTERFACE) is 264 bytes long on the other two are 
just 248 bytes long.

I'm using gcc 4.8.3 to compile both kernel and userland, but I have no 
idea what was used to compile the binary blobs.

Don't know if and when I will spend the time to search further, but if I 
will found out why, I'll send an update to this mail.

Regards,

Alexander Holler

Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO)

[Otavio Salvador]

On Sun, Aug 31, 2014 at 4:50 PM, Alexander Holler <holler@ahsoftware.de> wrote:
> Am 30.08.2014 22:06, schrieb Alexander Holler:
> Don't know if and when I will spend the time to search further, but if I
> will found out why, I'll send an update to this mail.

You seem to not be using Yocto Project-based system so in this case it
may be anything which we already fixed in past. In either case,
3.10.31 is being included in master-next and has not yet been tested
(as still has build errors) so I'd wait for this before porting it to
other distribution.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO)

[Alexander Holler]

Am 01.09.2014 14:36, schrieb Otavio Salvador:
> On Sun, Aug 31, 2014 at 4:50 PM, Alexander Holler <holler@ahsoftware.de> wrote:
>> Am 30.08.2014 22:06, schrieb Alexander Holler:
>> Don't know if and when I will spend the time to search further, but if I
>> will found out why, I'll send an update to this mail.
>
> You seem to not be using Yocto Project-based system so in this case it
> may be anything which we already fixed in past. In either case,
> 3.10.31 is being included in master-next and has not yet been tested
> (as still has build errors) so I'd wait for this before porting it to
> other distribution.

I haven't had much luck with 3.10.17 too and I definitely don't want to 
use Yocto. It doesn't met my requirements. And I can fix build errors 
myself, provided that I can build myself. Unfortunately that isn't the 
case for gpu-viv-bin-mx6q where gcoHAL_Construct() seems to be hidden.

Which is why I'm asking for help here. There doesn't seem to be another 
mailing list available in regard to i.mx6, just forums or similiar.

Anyway, thanks for the answer.

Alexander Holler

Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO)

[Alexander Holler]

Am 01.09.2014 14:59, schrieb Alexander Holler:
> Am 01.09.2014 14:36, schrieb Otavio Salvador:
>> On Sun, Aug 31, 2014 at 4:50 PM, Alexander Holler
>> <holler@ahsoftware.de> wrote:
>>> Am 30.08.2014 22:06, schrieb Alexander Holler:
>>> Don't know if and when I will spend the time to search further, but if I
>>> will found out why, I'll send an update to this mail.
>>
>> You seem to not be using Yocto Project-based system so in this case it
>> may be anything which we already fixed in past. In either case,
>> 3.10.31 is being included in master-next and has not yet been tested
>> (as still has build errors) so I'd wait for this before porting it to
>> other distribution.
>
> I haven't had much luck with 3.10.17 too and I definitely don't want to
> use Yocto. It doesn't met my requirements. And I can fix build errors
> myself, provided that I can build myself. Unfortunately that isn't the
> case for gpu-viv-bin-mx6q where gcoHAL_Construct() seems to be hidden.
>
> Which is why I'm asking for help here. There doesn't seem to be another
> mailing list available in regard to i.mx6, just forums or similiar.
>
> Anyway, thanks for the answer.

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

Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO)

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

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

Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO)

[Alexander Holler]

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
>