[meta-freescale] [meta-fsl-arm-extra PATCH 2/2] linux-boundary: Add support to Vivante 4.6.9p12 GPU code

Daiane Angolini daiane.angolini at freescale.com
Mon Aug 12 10:19:38 PDT 2013


On 08/12/2013 02:07 PM, Eric Nelson wrote:
> On 08/12/2013 09:45 AM, Daiane Angolini wrote:
>> On 08/12/2013 01:34 PM, Otavio Salvador wrote:
>>> On Mon, Aug 12, 2013 at 12:48 PM, Eric Nelson
>>> <eric.nelson at boundarydevices.com> wrote:
>>>> On 08/12/2013 08:18 AM, Otavio Salvador wrote:
>>>>>
>>>>> On Mon, Aug 12, 2013 at 11:05 AM, Eric Nelson
>>>>> <eric.nelson at boundarydevices.com> wrote:
>>>>>>
>>>>>> On 08/12/2013 05:50 AM, Otavio Salvador wrote:
>>>>>>>
>>>>>>> On Sat, Aug 10, 2013 at 7:12 PM, Eric Nelson
>>>>>>> <eric.nelson at boundarydevices.com> wrote:
>>>>>>>>
>>>>>>>> Right now, gpu-viv-bin-mx6q-3.5.7-1.0.0-hfp.bin only supports hard
>>>>>>>> float. Will the EABI (4.0.0) binaries continue to be supported or
>>>>>>>> will there be a corresponding package of EABI binaries?
>>>>>>>
>>>>>>>
>>>>>>> There's also a gpu-viv-bin-mx6q-3.5.7-1.0.0-sfp.bin and it is
>>>>>>> taken in
>>>>>>> case you're building for Soft Float-Point. It should 'Just Work'.
>>>>>>>
>>>>>>
>>>>>> If that's the case, we can just push the patches onto our
>>>>>> main branch and not deal with the old/new GPU package question.
>>>>>
>>>>> Not really as it will make impossible for your customers to use the
>>>>> kernel with LTIB at 4.0.0 BSP (well, I'd love they stop using it
>>>>> but...).
>>>>>
>>>>
>>>> It's not just LTIB that's a question mark. The same comment
>>>> goes for Debian, Buildroot, Timesys, Ubuntu, Arch or home-brew
>>>> userspaces.
>>>>
>>>> If it's Freescale's recommendation that this GPU package is
>>>> the **right** one for production use, our primary kernel
>>>> branch should probably reflect that.
>>>
>>> I think the recommendation is to stay in their 'official' and 'test'
>>> set of packages so I think it is better to have p12 support as patches
>>> so it is clear it is something we are doing 'by ourselves'.
>
> Okay. I didn't mean to open a can of worms here. I was just trying
> to simplify things.
>
>>
>> 3.5.7-1.0.0 - is an alpha release. It does not have the same "stability"
>> comparing with a GA release. It is not shared with *all* customers.
>>
>
> My bad. I figured since patches were being released into the wild,
> this is officially "shared".

If you try to look for the release under the normal freescale.com/imx 
you will not see it.

Please, don't ask me what's the difference.

>
>>>
>>>> There's no reason someone using another userspace builder
>>>> can't patch their process to update things.
>>>
>>> Well yes but it makes their life harder and a branch which won't work
>>> with 'official' package set. So I think patches are the way to go for
>>> now.
>>>
>>>> That said, I haven't quite heard this as Freescale's recommendation.
>>>> Daiane, I don't suppose you want to stick your neck out...?
>>>
>>> Poor Daiane ;-)
>
> I'm not trying to get you in trouble, Daiane. Just trying to grok
> the current status.

I know that ;)

>
>>
>> When I'm talking to meta-freescale I'm "Freescale". When I'm talking to
>> guys inside Freescale, I'm "community".
>>
>
> But but but, we're all the "community", right?
>
> We're all trying to get the best stuff into end-users' hands so they
> can build great applications with a minimum of hassle!
>
>> Here, I can only say public and official stuff. If you need Freescale's
>> help, please enter a SR or a question on imx-community.
>>
>> =(
>>
>
> Sounds scary! Like there may be lawyers trolling there ;)

lawyers, ninjas, gnomes, who knows?

>
> Regards,
>
>
> Eric
>


-- 
Daiane




More information about the meta-freescale mailing list