Hi all,
I'm trying GLES on Snowball board with Mali GPU, without X.
The board was installed linaro-nano 12.07 (with mali400-dev package
installed) and had been connected with an TV via HDMI cable;
After booting up, I run "hdmistart" command and /dev/fb0 appeared; HDMI
ran fine with "cat /dev/urandom > /dev/fb0" command.
However, when testing GLES with sample codes from Mali SDK
(http://malideveloper.arm.com/downloads/Mali_OpenGL_ES_2.0_SDK_for_Linux_On_…)
I got following error:
Error: eglGetError(): 12288 (0x3000)
Error: No EGL Display available at
/root/Mali_OpenGL_ES_2.0_SDK_for_Linux_On_ARM_v1.2.0/simple-framework/src/EGLRuntime.cpp:105
The argument of eglGetDisplay is EGL_DEFAULT_DISPLAY:
EGLDisplay display = eglGetDisplay(EGL_DEFAULT_DISPLAY);
So I wonder if Mali can works without X or not?
Any help will be greatly appreciate,
---
Hiep
On 04/17/2013 06:26 PM, linaro-dev-request(a)lists.linaro.org wrote:
> Send linaro-dev mailing list submissions to
> linaro-dev(a)lists.linaro.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.linaro.org/mailman/listinfo/linaro-dev
> or, via email, send a message with subject or body 'help' to
> linaro-dev-request(a)lists.linaro.org
>
> You can reach the person managing the list at
> linaro-dev-owner(a)lists.linaro.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of linaro-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Suggestion (Jonathan Aquilina)
> 2. Re: Suggestion (Jon Medhurst (Tixy))
> 3. Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal
> toolchain. (Arnd Bergmann)
> 4. Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal
> toolchain. (Jon Medhurst (Tixy))
> 5. Re: Mali-ization (Tushar Behera)
> 6. Re: Mali-ization (Jon Medhurst (Tixy))
> 7. Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal
> toolchain. (Rob Clark)
> 8. Re: Mali-ization (Andy Green)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 17 Apr 2013 09:54:11 +0200
> From: Jonathan Aquilina <eagles051387(a)gmail.com>
> To: Nicolas Dechesne <nicolas.dechesne(a)linaro.org>
> Cc: Linaro Dev <linaro-dev(a)lists.linaro.org>
> Subject: Re: Suggestion
> Message-ID:
> <CAHdpx60hYtqb+kdthhr79mvcc5JnsWHuaV3psOMPyw-EPn2BHA(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Totally under stand :). Hopefully come summer I will be able to get my
> hands on a board and start contributing :)
>
>
> On Wed, Apr 17, 2013 at 9:51 AM, Nicolas Dechesne <
> nicolas.dechesne(a)linaro.org> wrote:
>
>> On Wed, Apr 17, 2013 at 6:21 AM, Jonathan Aquilina
>> <eagles051387(a)gmail.com> wrote:
>>> Doesnt email run the risk of a patch slipping through the cracks?
>> as highlighted by Deepak above, each project will use the
>> processes/methods inherited from its 'upstream'. That's why gerrit is
>> being used for Android activities for example. many successful open
>> source projects are using solely email for patch submission and
>> review, and that happens to work fine. yes, that makes lots of emails,
>> and patches can be lost, but the general rule is that it's up to the
>> patch author to follow-up and potentially resubmit when such things
>> happen. for example, the Linux kernel documentation says this:
>>
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Docume…
>>
>> nicolas
>>
>
>
Hi -
At the moment the Mali T624 OOT module sources I have do not build
against 3.9-rcX / linux-linaro-core-tracking. A colleague checked it
and it does build against 3.4. The problems I saw are around ION
compatibility but they didn't look tremendously bad.
I could work around the problems myself, but it seems to me this might
be something that Linaro could solve centrally, dealing with it using
the Androidization model - sync a Linaro repo against code drops coming
from "upstream", ie, ARM, but keep it always building against llct
inbetween. Perhaps even inside llct.
I know we're not the only LT in this boat, Anmar mentioned Arndale
acceleration is pending, a central Mali-ization tree will also solve
that, especially if it's always there and always building in llct already.
There may be stuff to take care about for support for different IP
revision. But there aren't that many AFAIK.
How does this sound to folks?
-Andy
--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
Hello,
On Fri, 12 Apr 2013 18:28:26 -0500
Nishanth Menon <nm(a)ti.com> wrote:
> From: Paul Sokolovsky <paul.sokolovsky(a)linaro.org>
>
> An ifdef in drm.h expects to be compiled with full-fledged Linux
> toolchain, but it's common to compile kernel with just bare-metal
> toolchain which doesn't define __linux__. So, also add __KERNEL__
> check.
>
> [nm(a)ti.com: port forward to 3.9-rc6 and post to dri devel for
> feedback as RFC] Signed-off-by: Paul Sokolovsky
> <paul.sokolovsky(a)linaro.org> ---
> Paul, Dri devel list,
> I picked up this patch from linaro tree:
> https://git.linaro.org/gitweb?p=people/asac/android/kernel/lt-ti.git;a=patc…
> Discussion thread:
> http://lists.linaro.org/pipermail/linaro-dev/2011-June/thread.html#4874
> Seems to me as a valid fix even for upstream perhaps?
Yes, IIRC, per the discussion you quote above, I sent this patch for
review of our (Linaro's) kernel folks to see if it's ok (the patch is
simple, story why it's needed may be not such, though I was positive
it's needed). It might be forgotten somehow, thanks for picking it up!
> Regards, Nishanth Menon
>
> include/uapi/drm/drm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 8d1e2bb..73a99e4 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -36,7 +36,7 @@
> #ifndef _DRM_H_
> #define _DRM_H_
>
> -#if defined(__linux__)
> +#if defined(__KERNEL__) || defined(__linux__)
>
> #include <linux/types.h>
> #include <asm/ioctl.h>
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Greetings,
This is a reminder that this wiki page:
https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule
- is now tracking the linux-linaro kernel rebuilds for 13.04.
v3.9-rc6 based linux-linaro-core-tracking (llct) rebuild has just been
published, the tag is llct-20130411.0.
The next step is:
April 12: ll rebuild based on llct-20130411.0.
The last llct update for this cycle is scheduled on April 16,
The last linux-linaro update for this cycle is scheduled on April 18.
April 18 is the linux-linaro code freeze for 13.04 (only bug fixes
allowed after this date).
Thanks,
Andrey
>From my research I gather arm is just an architecture or chip producer as
well? As i have a project, that might do sufficiently running on a dev
board, or even a custom developed arm based board.
I have been trying to find a contact email at arm but to no avail. Any help
and information would be greatly appreciated.
--
Jonathan Aquilina
When the kernel is built with CONFIG_ARCH_OMAP2 it will select
CPU_V6 and other dependencies which causes issues in user space.
For example when clients try to connect to PulseAudio they will
crash with:
Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.
Remove support for OMAP2 for now.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
---
Hi Andrey,
Can you take a look at this patch?
In the latest hwpack for panda (with 3.9 kernel) PulseAudio clients all asserts
with the following error:
Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.
The same userspace works fine (well, mostly) with 3.8 based hwpacks.
It turns out that this is cased by the CONFIG_ARCH_OMAP2, if we disable it PA
clients no longer assert.
Since the config in question is for OMAP4, I see no issue removing the OMAP2
support since in this way we can get PA working.
One issue still remain with PA:
None of float resample method works:
speex-float-[0-10]
However speex-fixed-[0-10] and ffmpeg seams to be working, but it is not perfect.
I'll try to figure out why we have this failure since on my Gentoo FS all resample
method works fine with the same kernel.
Regards,
Peter
linaro/configs/omap4.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/linaro/configs/omap4.conf b/linaro/configs/omap4.conf
index 59e9f23..82c9365 100644
--- a/linaro/configs/omap4.conf
+++ b/linaro/configs/omap4.conf
@@ -11,6 +11,7 @@ CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_SOC_OMAP5=y
+CONFIG_ARCH_OMAP2=n
CONFIG_ARCH_VEXPRESS_CA9X4=y
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_ERRATA_411920=y
--
1.7.10.4