* 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO) @ 2014-08-30 20:06 Alexander Holler 2014-08-31 19:50 ` Alexander Holler 0 siblings, 1 reply; 7+ messages in thread From: Alexander Holler @ 2014-08-30 20:06 UTC (permalink / raw) To: meta-freescale 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO) 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 0 siblings, 1 reply; 7+ messages in thread From: Alexander Holler @ 2014-08-31 19:50 UTC (permalink / raw) To: meta-freescale 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO) 2014-08-31 19:50 ` Alexander Holler @ 2014-09-01 12:36 ` Otavio Salvador 2014-09-01 12:59 ` Alexander Holler 0 siblings, 1 reply; 7+ messages in thread From: Otavio Salvador @ 2014-09-01 12:36 UTC (permalink / raw) To: Alexander Holler; +Cc: meta-freescale 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO) 2014-09-01 12:36 ` Otavio Salvador @ 2014-09-01 12:59 ` Alexander Holler 2014-09-01 14:01 ` Alexander Holler 0 siblings, 1 reply; 7+ messages in thread From: Alexander Holler @ 2014-09-01 12:59 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO) 2014-09-01 12:59 ` Alexander Holler @ 2014-09-01 14:01 ` Alexander Holler 2014-09-02 13:32 ` Lauren Post 0 siblings, 1 reply; 7+ messages in thread From: Alexander Holler @ 2014-09-01 14:01 UTC (permalink / raw) To: Otavio Salvador; +Cc: meta-freescale 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO) 2014-09-01 14:01 ` Alexander Holler @ 2014-09-02 13:32 ` Lauren Post 2014-09-02 14:18 ` Alexander Holler 0 siblings, 1 reply; 7+ messages in thread From: Lauren Post @ 2014-09-02 13:32 UTC (permalink / raw) To: Alexander Holler, Otavio Salvador; +Cc: meta-freescale 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: 3.10.31-beta: gcoHAL_Construct returns -7 (gcvSTATUS_GENERIC_IO) 2014-09-02 13:32 ` Lauren Post @ 2014-09-02 14:18 ` Alexander Holler 0 siblings, 0 replies; 7+ messages in thread From: Alexander Holler @ 2014-09-02 14:18 UTC (permalink / raw) To: Lauren Post, Otavio Salvador; +Cc: meta-freescale 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-09-02 14:19 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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.