pandaboard/omap4 support

pandaboard/omap4 support

[Jithin Raj]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

Hi ,

 

I am new to meta-ti.

1) Does meta-ti (master) supports pandaboard(omap4) completely (graphics
with sgx support). Because in the recipie-graphics/libgles these is only
omap3 files ?

 

2) In-order to support graphics in X11 (hardware graphics acceleration)
I have used 

 

       XSERVER += "xserver-xorg \

           xserver-xorg-module-exa \

           xf86-input-evdev \

           xserver-xf86-config \

           xserver-xorg-extension-dbe \

           xserver-xorg-extension-dri \

           xserver-xorg-extension-dri2 \

           xserver-xorg-extension-extmod \

           xserver-xorg-extension-glx \

           xf86-input-mouse \

           xf86-input-keyboard \

           mesa-driver-swrast \

           xf86-video-omap"

 

       With these option when I run the application am getting a error :

 

       libEGL warning DRI2: failed to open omap (search paths
/usr/lib/dri)

       PVRShell: EGL 1.4 Initialized

       PVRTTextureLoadFromPointer warning: PVRTC not supported.
Converting to RGBA8888 instead.

       PVRTTextureLoadFromPointer warning: PVRTC not supported.
Converting to RGBA8888 instead.

       PVRTTextureLoadFromPointer warning: PVRTC not supported.
Converting to RGBA8888 instead.

       PVRTTextureLoadFromPointer warning: PVRTC not supported.
Converting to RGBA8888 instead.

 

                And the graphical application stucks screen after
screen.

 

Experts please suggest.

 

Thanks in advance.

 

Thanks & regards

Jithin Raj

 

***** Confidentiality Statement/Disclaimer *****

This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt.
The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.


[-- Attachment #2: Type: text/html, Size: 8356 bytes --]

Re: pandaboard/omap4 support

[Denys Dmytriyenko]

On Tue, Nov 19, 2013 at 10:32:58AM +0530, Jithin Raj wrote:
> Hi ,
> 
>  
> 
> I am new to meta-ti.
> 
> 1) Does meta-ti (master) supports pandaboard(omap4) completely (graphics
> with sgx support). Because in the recipie-graphics/libgles these is only
> omap3 files ?

No graphics for omap4+ (yet) in meta-ti. There are recipes being worked out 
though.

-- 
Denys


> 2) In-order to support graphics in X11 (hardware graphics acceleration)
> I have used 
> 
>  
> 
>        XSERVER += "xserver-xorg \
> 
>            xserver-xorg-module-exa \
> 
>            xf86-input-evdev \
> 
>            xserver-xf86-config \
> 
>            xserver-xorg-extension-dbe \
> 
>            xserver-xorg-extension-dri \
> 
>            xserver-xorg-extension-dri2 \
> 
>            xserver-xorg-extension-extmod \
> 
>            xserver-xorg-extension-glx \
> 
>            xf86-input-mouse \
> 
>            xf86-input-keyboard \
> 
>            mesa-driver-swrast \
> 
>            xf86-video-omap"
> 
>  
> 
>        With these option when I run the application am getting a error :
> 
>  
> 
>        libEGL warning DRI2: failed to open omap (search paths
> /usr/lib/dri)
> 
>        PVRShell: EGL 1.4 Initialized
> 
>        PVRTTextureLoadFromPointer warning: PVRTC not supported.
> Converting to RGBA8888 instead.
> 
>        PVRTTextureLoadFromPointer warning: PVRTC not supported.
> Converting to RGBA8888 instead.
> 
>        PVRTTextureLoadFromPointer warning: PVRTC not supported.
> Converting to RGBA8888 instead.
> 
>        PVRTTextureLoadFromPointer warning: PVRTC not supported.
> Converting to RGBA8888 instead.
> 
>  
> 
>                 And the graphical application stucks screen after
> screen.
> 
>  
> 
> Experts please suggest.
> 
>  
> 
> Thanks in advance.
> 
>  
> 
> Thanks & regards
> 
> Jithin Raj
> 
>  
> 
> ***** Confidentiality Statement/Disclaimer *****
> 
> This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt.
> The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.
> 

> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

Re: pandaboard/omap4 support

[Richard Röjfors]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

On Tue, Nov 19, 2013 at 7:06 AM, Denys Dmytriyenko <denys@ti.com> wrote:

>
> No graphics for omap4+ (yet) in meta-ti. There are recipes being worked out
> though.
>

Good news, finally!

I hope this will be something like what was last released in the Ubuntu
PPA? Meaning it does not need X.

Will you link the userspace against a more recent wayland than in the
Ubuntu ppa?

Will this work with recent kernels, like 3.12? (This would mean forward
porting the userspace connector stuff to the non-staging omapdrm)

When will this happen?

I have done this myself but since the TI community effort disappeared for
OMAP4 I had to use a 3.4 kernel from the Ubuntu PPA.

--Richard

[-- Attachment #2: Type: text/html, Size: 1161 bytes --]

Re: pandaboard/omap4 support

[Richard Röjfors]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

Hi,

On Tue, Nov 19, 2013 at 7:06 AM, Denys Dmytriyenko <denys@ti.com> wrote:

>
> No graphics for omap4+ (yet) in meta-ti. There are recipes being worked out
> though.
>

Any updates on this?

Now when oe-core is on gcc 4.8 (and there is some binary incompatibilities
between gcc 4.7 and 4.8) I think it's getting important to get those binary
blobs out compiled with gcc 4.8.

--Richard

[-- Attachment #2: Type: text/html, Size: 789 bytes --]

Re: pandaboard/omap4 support

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 332 bytes --]


On Feb 12, 2014, at 2:46 AM, Richard Röjfors <richard.rojfors@gmail.com> wrote:

> Now when oe-core is on gcc 4.8 (and there is some binary incompatibilities between gcc 4.7 and 4.8) I think it's getting important to get those binary blobs out compiled with gcc 4.8.
> 
what incompatibilities do you see between 4.7 and 4.8 ? 

[-- Attachment #2: Type: text/html, Size: 1049 bytes --]

Re: pandaboard/omap4 support

[Richard Röjfors]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On Wed, Feb 12, 2014 at 2:52 PM, Khem Raj <raj.khem@gmail.com> wrote:

>
> what incompatibilities do you see between 4.7 and 4.8 ?
>

I saw this in the gcc 4.8 changelog:
"On ARM, a bug has been fixed in GCC's implementation of the AAPCS rules
for the layout of vectors that could lead to wrong code being generated.
Vectors larger than 8 bytes in size are now by default aligned to an 8-byte
boundary. This is an ABI change: code that makes explicit use of vector
types may be incompatible with binary objects built with older versions of
GCC. Auto-vectorized code is not affected by this change."

--Richard

[-- Attachment #2: Type: text/html, Size: 1116 bytes --]

Re: pandaboard/omap4 support

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]


On Feb 12, 2014, at 6:03 AM, Richard Röjfors <richard.rojfors@gmail.com> wrote:

> On Wed, Feb 12, 2014 at 2:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> what incompatibilities do you see between 4.7 and 4.8 ? 
> 
> I saw this in the gcc 4.8 changelog:
> "On ARM, a bug has been fixed in GCC's implementation of the AAPCS rules for the layout of vectors that could lead to wrong code being generated. Vectors larger than 8 bytes in size are now by default aligned to an 8-byte boundary. This is an ABI change: code that makes explicit use of vector types may be incompatible with binary objects built with older versions of GCC. Auto-vectorized code is not affected by this change.” 

OK. are you seeing this use case here ?

> 
> --Richard


[-- Attachment #2: Type: text/html, Size: 1733 bytes --]

Re: pandaboard/omap4 support

[Richard Röjfors]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

On Wed, Feb 12, 2014 at 3:07 PM, Khem Raj <raj.khem@gmail.com> wrote:

>
> On Feb 12, 2014, at 6:03 AM, Richard Röjfors <richard.rojfors@gmail.com>
> wrote:
>
> On Wed, Feb 12, 2014 at 2:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>>
>> what incompatibilities do you see between 4.7 and 4.8 ?
>>
>
> I saw this in the gcc 4.8 changelog:
> "On ARM, a bug has been fixed in GCC's implementation of the AAPCS rules
> for the layout of vectors that could lead to wrong code being generated.
> Vectors larger than 8 bytes in size are now by default aligned to an 8-byte
> boundary. This is an ABI change: code that makes explicit use of vector
> types may be incompatible with binary objects built with older versions of
> GCC. Auto-vectorized code is not affected by this change.”
>
>
> OK. are you seeing this use case here ?
>

Nope I've not hit it nor gone through the calls between the blobs and the
surrounding code.

I just think it makes sense to compile the blobs with a compiler similar to
the one provided by oe-core, to avoid the risk...

--Richard

[-- Attachment #2: Type: text/html, Size: 2131 bytes --]

Re: pandaboard/omap4 support

[Denys Dmytriyenko]

On Wed, Feb 12, 2014 at 03:15:38PM +0100, Richard Röjfors wrote:
> On Wed, Feb 12, 2014 at 3:07 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> >
> > On Feb 12, 2014, at 6:03 AM, Richard Röjfors <richard.rojfors@gmail.com>
> > wrote:
> >
> > On Wed, Feb 12, 2014 at 2:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
> >
> >>
> >> what incompatibilities do you see between 4.7 and 4.8 ?
> >>
> >
> > I saw this in the gcc 4.8 changelog:
> > "On ARM, a bug has been fixed in GCC's implementation of the AAPCS rules
> > for the layout of vectors that could lead to wrong code being generated.
> > Vectors larger than 8 bytes in size are now by default aligned to an 8-byte
> > boundary. This is an ABI change: code that makes explicit use of vector
> > types may be incompatible with binary objects built with older versions of
> > GCC. Auto-vectorized code is not affected by this change.”
> >
> >
> > OK. are you seeing this use case here ?
> >
> 
> Nope I've not hit it nor gone through the calls between the blobs and the
> surrounding code.
> 
> I just think it makes sense to compile the blobs with a compiler similar to
> the one provided by oe-core, to avoid the risk...

The biggest problem is not 4.7 vs. 4.8, but rather incompatibilities in ABIs 
and call conventions. E.g. we have switched to hardfp for our products and 
some of our components distributed in binary form are only available in hardfp 
format. And oe-core doesn't use hardfp by default yet...

-- 
Denys

Re: pandaboard/omap4 support

[Khem Raj]

On Feb 12, 2014, at 8:28 AM, Denys Dmytriyenko <denys@ti.com> wrote:

> On Wed, Feb 12, 2014 at 03:15:38PM +0100, Richard Röjfors wrote:
>> On Wed, Feb 12, 2014 at 3:07 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> 
>>> 
>>> On Feb 12, 2014, at 6:03 AM, Richard Röjfors <richard.rojfors@gmail.com>
>>> wrote:
>>> 
>>> On Wed, Feb 12, 2014 at 2:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> 
>>>> 
>>>> what incompatibilities do you see between 4.7 and 4.8 ?
>>>> 
>>> 
>>> I saw this in the gcc 4.8 changelog:
>>> "On ARM, a bug has been fixed in GCC's implementation of the AAPCS rules
>>> for the layout of vectors that could lead to wrong code being generated.
>>> Vectors larger than 8 bytes in size are now by default aligned to an 8-byte
>>> boundary. This is an ABI change: code that makes explicit use of vector
>>> types may be incompatible with binary objects built with older versions of
>>> GCC. Auto-vectorized code is not affected by this change.”
>>> 
>>> 
>>> OK. are you seeing this use case here ?
>>> 
>> 
>> Nope I've not hit it nor gone through the calls between the blobs and the
>> surrounding code.
>> 
>> I just think it makes sense to compile the blobs with a compiler similar to
>> the one provided by oe-core, to avoid the risk...
> 
> The biggest problem is not 4.7 vs. 4.8, but rather incompatibilities in ABIs 
> and call conventions. E.g. we have switched to hardfp for our products and 
> some of our components distributed in binary form are only available in hardfp 
> format. And oe-core doesn't use hardfp by default yet…
> 

yes thats a genuine concern, so when you publish prebuilt components then demand
the required ABI compatibilities, but there isn’t much else one can do.

> -- 
> Denys

Re: pandaboard/omap4 support

[Denys Dmytriyenko]

On Wed, Feb 12, 2014 at 08:38:04AM -0800, Khem Raj wrote:
> 
> On Feb 12, 2014, at 8:28 AM, Denys Dmytriyenko <denys@ti.com> wrote:
> 
> > On Wed, Feb 12, 2014 at 03:15:38PM +0100, Richard Röjfors wrote:
> >> On Wed, Feb 12, 2014 at 3:07 PM, Khem Raj <raj.khem@gmail.com> wrote:
> >> 
> >>> 
> >>> On Feb 12, 2014, at 6:03 AM, Richard Röjfors <richard.rojfors@gmail.com>
> >>> wrote:
> >>> 
> >>> On Wed, Feb 12, 2014 at 2:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
> >>> 
> >>>> 
> >>>> what incompatibilities do you see between 4.7 and 4.8 ?
> >>>> 
> >>> 
> >>> I saw this in the gcc 4.8 changelog:
> >>> "On ARM, a bug has been fixed in GCC's implementation of the AAPCS rules
> >>> for the layout of vectors that could lead to wrong code being generated.
> >>> Vectors larger than 8 bytes in size are now by default aligned to an 8-byte
> >>> boundary. This is an ABI change: code that makes explicit use of vector
> >>> types may be incompatible with binary objects built with older versions of
> >>> GCC. Auto-vectorized code is not affected by this change.”
> >>> 
> >>> 
> >>> OK. are you seeing this use case here ?
> >>> 
> >> 
> >> Nope I've not hit it nor gone through the calls between the blobs and the
> >> surrounding code.
> >> 
> >> I just think it makes sense to compile the blobs with a compiler similar to
> >> the one provided by oe-core, to avoid the risk...
> > 
> > The biggest problem is not 4.7 vs. 4.8, but rather incompatibilities in ABIs 
> > and call conventions. E.g. we have switched to hardfp for our products and 
> > some of our components distributed in binary form are only available in hardfp 
> > format. And oe-core doesn't use hardfp by default yet…
> > 
> 
> yes thats a genuine concern, so when you publish prebuilt components then demand
> the required ABI compatibilities, but there isn’t much else one can do.

Indeed, I do this for now:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-graphics/libgles/libgles-omap3_5.01.00.01.bb#n25

I was hoping this would be a temporary limitation and there might be a softfp 
binary released too...

-- 
Denys