All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Rehsack <rehsack@gmail.com>
To: Daiane Angolini <daiane.list@gmail.com>
Cc: "meta-freescale@yoctoproject.org" <meta-freescale@yoctoproject.org>
Subject: Re: Right lib-imx/firmware-imx ... versions
Date: Wed, 23 Jul 2014 16:51:51 +0200	[thread overview]
Message-ID: <DF533160-2978-4351-90C3-C5D78B138012@gmail.com> (raw)
In-Reply-To: <CA+jg_OVRMTN4cVVWvkQyWc2x+F9eBQDff9YxwTmiDqf1EPg0_w@mail.gmail.com>


Am 23.07.2014 um 16:19 schrieb Daiane Angolini <daiane.list@gmail.com>:

> On Tue, Jul 22, 2014 at 2:24 AM, Jens Rehsack <rehsack@gmail.com> wrote:
>> Hi,
>> 
>> as mentioned in my very first post here, we're trying to get a board
>> running with yocto with a bsp for linux-imx-3.0.35_4.1.0 (bdde708).
>> 
>> As firmware-imx we have 3.0.35_4.0.0 (tried 3.10.17, too - without
>> difference).
> 
> Long story short: Stick to one branch and use it, with the kernel
> version and the imx-lib/gpu/imx-vpu/firmware version already there. It
> was what we tested someway.

But there is no Yocto support for imx-lib-3.0.35_4.1.0, neither that
imx-vpu nor gpu-viv-lib-mxq version. Only 3.10.9 and 3.10.17 is included
(daisy has only 3.10.17).

> Long story long:
> 
>> When we run xmbc with lib-imx, gpu-viv-ib-mx6q, lib-vpu in daisy
>> versions (3.10.17), xbmc immediately crashes with a segfault in
>> gpu-viv-ib-mx6q (does someone wants the trace?). Using Dora versions
>> (3.10.9) we can at least start xbmc and can start one movie. When
>> we play a second movie, the system crashes with "dma physical memory
>> allocation error" (trace/console output wanted?).
> 
> I don´t have previous success cases in running xbmc. I mean, I have
> never (myself) tried it, but in other hand, I have never heard about
> someone that had succeeded.

http://stephan-rafin.net/blog/ or more concrete: http://stephan-rafin.net/blog/2014/01/29/yet-another-yocto-image/

But as far as I see from his recipes, he's using mx6d.

> So, I don´t know if *any* combination works.
> 
>> The board manufacturer recommends we try the freescale libs (firmware,
>> lib-imx, gpu...) in precisely matching version (3.0.35_4.1.0), but none
>> of them seems to exist in meta-fsl-arm(-extra). That confuses me in the
>> way that I expect, the distributed versions are stable.
> 
> When dealing with GPU, is important that the kernel GPU driver and the
> GPU user-space package match.

As said, I have linux-imx-3.0.35_4.1.0 at revision bdde708 with patches
https://github.com/rehsack/meta-jens/tree/master/recipes-kernel/linux/linux-curie-3.0.35

Doesn't look to me as if any modifies GPU kernel driver ...

> When working with IPU for imx6. It does not matter what imx-lib you is
> working with. ipu-lib is not used for imx6 since 3.0.15, or something
> like that. So, for IPU, no user-space package needed.

k

> When working with VPU, imx-vpu is needed, and imx-firmware is needed.
> However, any should work, and what you miss from one to another is
> only bugfixes. (of course, it´s may be a huge difference, however I
> don´t see it causing a crash)

The crash I see with xbmc and 3.10.9 drivers (firmware-imx-3.0.35_4.0.0+
imx-lib-, imx-vpu- & gpu-viv-lib-mx6q-3.10.9_1.0.0) is nearly byte-identical
to https://community.freescale.com/thread/304414 ...

However, with gpu-viv-lib-mx6q (other versions doesn't seem to matter in
any way), it immediately crashes 

#0  0x2be582b0 in gcoHAL_QueryChipCount (Hal=Hal@entry=0x0,
   Count=Count@entry=0x1c3b65c) at gc_hal_user_query.c:1726
#1  0x2b275244 in veglGetThreadData () at gc_egl.c:137
#2  0x2b26e210 in eglfGetDisplay (display_id=0x1c2b568) at gc_egl_init.c:464
#3  eglGetDisplay (DisplayID=0x1c2b568) at gc_egl_init.c:565
#4  0x00880fac in CEGLWrapper::InitDisplay (this=0x1c16c40,
   display=display@entry=0x1a64e50) at EGLWrapper.cpp:206

which points to gpu-viv-lib-mx6q ...

>> Though I don't have a concrete question beside "what library versions
>> are good for us?" - any hints, resources to study, ...?
> 
> So, the question "what library version are good for us" should be
> answered by another question "do you need libraries?"

From available xbmc recipes I think so - but maybe the imx port isn't
the right way. OTOH, looks as if wolfgar did a good job there, at least
for wandboard, uitite & co.

> Or, let´s be more practical. Have you tested your GPU integration?
> What is the GPU driver version in your kernel, and your GPU user-space
> version?

Nope, how can I do that (fsl for dummies - I'm happy controlling Yocto
meanwhile). Just bitbake imx-test or something more?

Thanks in advance.

Best regards
-- 
Jens Rehsack
rehsack@gmail.com







  reply	other threads:[~2014-07-23 14:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-22  5:24 Right lib-imx/firmware-imx ... versions Jens Rehsack
2014-07-23  3:57 ` Jens Rehsack
2014-07-23 14:19 ` Daiane Angolini
2014-07-23 14:51   ` Jens Rehsack [this message]
2014-07-23 15:14     ` xxiao8
2014-07-23 15:46       ` Daiane Angolini
2014-07-23 15:45     ` Daiane Angolini
2014-07-23 17:31       ` Jens Rehsack
2014-08-02 14:59         ` Jens Rehsack
2014-08-04 15:41           ` John Weber
2014-08-04 19:04             ` Jens Rehsack
2014-08-04 19:48               ` John Weber

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=DF533160-2978-4351-90C3-C5D78B138012@gmail.com \
    --to=rehsack@gmail.com \
    --cc=daiane.list@gmail.com \
    --cc=meta-freescale@yoctoproject.org \
    /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.