New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Couldn't boot #2

Open
ghost opened this Issue May 7, 2013 · 28 comments

Comments

Projects
None yet
5 participants
@ghost

ghost commented May 7, 2013

Hello,

I followed the wiki (https://github.com/cambridgehackers/zedboard_manifests/wiki/ZedboardAndroid4.1).
When I build, the first error that comes is:
find: 'src': no such file or directory

after that the compilation seems to work and the right files are created. But when I try to boot I get the following:
<7>[drm:drm_crtc_helper_set_config], [CRTC:3] [FB:19] #connectors=1 (x y) (0 0)
<7>[drm:drm_crtc_helper_set_config], [CONNECTOR:5:HDMI-A-1] to [CRTC:3]
<7>[drm:drm_crtc_helper_set_config],
<7>[drm:drm_crtc_helper_set_config], [CRTC:3] [FB:19] #connectors=1 (x y) (0 0)
<7>[drm:drm_crtc_helper_set_config], [CONNECTOR:5:HDMI-A-1] to [CRTC:3]
<7>[drm:drm_crtc_helper_set_config],
<7>[drm:drm_crtc_helper_set_config], [CRTC:3] [FB:19] #connectors=1 (x y) (0 0)
<7>[drm:drm_crtc_helper_set_config], [CONNECTOR:5:HDMI-A-1] to [CRTC:3]
<7>[drm:drm_crtc_helper_set_config],
<7>[drm:drm_crtc_helper_set_config], [CRTC:3] [FB:19] #connectors=1 (x y) (0 0)
<7>[drm:drm_crtc_helper_set_config], [CONNECTOR:5:HDMI-A-1] to [CRTC:3]
<3>init: untracked pid 1043 exited
[ 161.140000] init: untracked pid 1043 exited
<7>[drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status updated from 1 to 1
<3>init: untracked pid 1216 exited
[ 164.280000] init: untracked pid 1216 exited
<3>init: untracked pid 1226 exited
[ 166.790000] init: untracked pid 1226 exited
<3>init: untracked pid 1228 exited
[ 169.910000] init: untracked pid 1228 exited
<7>[drm:output_poll_execute], [CONNECTOR:5:HDMI-A-1] status updated from 1 to 1

So Android doesn't start.

What do I have to do in order fix this?

Thanks in advance!

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks May 7, 2013

Member

I'm going to have to clone and build this in order to test it, so it may take some time before I have any suggestions for you.

In the meantime, if you could post the whole boot log it might trigger some memory of how it was supposed to work.

Member

jameyhicks commented May 7, 2013

I'm going to have to clone and build this in order to test it, so it may take some time before I have any suggestions for you.

In the meantime, if you could post the whole boot log it might trigger some memory of how it was supposed to work.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 10, 2013

I don't have the ZedBoard right now, so i won't be able to give you the bootlog. Hopefuly you can reproduce (and fix) the problem?

Thanks in advance for you work!!!

ghost commented May 10, 2013

I don't have the ZedBoard right now, so i won't be able to give you the bootlog. Hopefuly you can reproduce (and fix) the problem?

Thanks in advance for you work!!!

@AntoninoVesp

This comment has been minimized.

Show comment
Hide comment
@AntoninoVesp

AntoninoVesp Nov 28, 2013

I have the same problem.
Has someone solved the problem?

AntoninoVesp commented Nov 28, 2013

I have the same problem.
Has someone solved the problem?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 28, 2013

I haven't been able to successfully load 4.1 on the ZedBoard.
However, I was able to boot Android 2.3 following this guide: http://elinux.org/Zedboard_Android

ghost commented Nov 28, 2013

I haven't been able to successfully load 4.1 on the ZedBoard.
However, I was able to boot Android 2.3 following this guide: http://elinux.org/Zedboard_Android

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Dec 4, 2013

Member

Hi Antonino,

We’ve moved the kernel forward and have been using our own display controller logic, so it’s diverged from supporting the Targeted Reference Design. Would this still be of interest to you?

We’ve also eliminated the need for u-boot, which simplifies the setup.

How far did you get in the boot process?

Cheers,
Jamey

On Nov 28, 2013, at 5:22 AM, AntoninoVesp notifications@github.com wrote:

I have the same problem.
Has someone solved the problem?


Reply to this email directly or view it on GitHub.

Member

jameyhicks commented Dec 4, 2013

Hi Antonino,

We’ve moved the kernel forward and have been using our own display controller logic, so it’s diverged from supporting the Targeted Reference Design. Would this still be of interest to you?

We’ve also eliminated the need for u-boot, which simplifies the setup.

How far did you get in the boot process?

Cheers,
Jamey

On Nov 28, 2013, at 5:22 AM, AntoninoVesp notifications@github.com wrote:

I have the same problem.
Has someone solved the problem?


Reply to this email directly or view it on GitHub.

@AntoninoVesp

This comment has been minimized.

Show comment
Hide comment
@AntoninoVesp

AntoninoVesp Dec 4, 2013

Hi, Jamey,
thanks for your answer, it is really interesting. I'm using the version 3.3 and my own Android file system jelly Bean 4.2, with VGA support, and all works well. I think that the problem, with HDMI support, is due to the kernel version/configuration. I'm try to forward the kernel from the version 3.3 to 3.6 using the source from https://github.com/Digilent/linux-digilent/tree/v3.6-digilent-13.01 and suit it to Android. At hardware layer I'm thinking to use the source provided by digilent web site.(http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1028&Prod=ZEDBOARD) Do you think could be a solution?

AntoninoVesp commented Dec 4, 2013

Hi, Jamey,
thanks for your answer, it is really interesting. I'm using the version 3.3 and my own Android file system jelly Bean 4.2, with VGA support, and all works well. I think that the problem, with HDMI support, is due to the kernel version/configuration. I'm try to forward the kernel from the version 3.3 to 3.6 using the source from https://github.com/Digilent/linux-digilent/tree/v3.6-digilent-13.01 and suit it to Android. At hardware layer I'm thinking to use the source provided by digilent web site.(http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1028&Prod=ZEDBOARD) Do you think could be a solution?

@zoocad

This comment has been minimized.

Show comment
Hide comment
@zoocad

zoocad Apr 26, 2014

Hi Jamey,
I followed your guide on how to run Android 4.1 on the ZedBoard. At the same time I wrote this blog.
"Running Android on ZedBoard": http://svenand.blogdrive.com/archive/200.html
I would be nice to be able to boot Android. Do you have a solution today?
Cheers
Sven

zoocad commented Apr 26, 2014

Hi Jamey,
I followed your guide on how to run Android 4.1 on the ZedBoard. At the same time I wrote this blog.
"Running Android on ZedBoard": http://svenand.blogdrive.com/archive/200.html
I would be nice to be able to boot Android. Do you have a solution today?
Cheers
Sven

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Apr 28, 2014

Member

Hi Sven,

It looks like you got as far as bootanimation but zygote is not running. I have to admit, I mostly run Android these days without a frame buffer, so neither bootanimation nor zygote run.

You might try restarting zygote and/or surfaceflinger to see if that helps:
stop surfaceflinger
start surfaceflinger
stop zygote
start zygote

Member

jameyhicks commented Apr 28, 2014

Hi Sven,

It looks like you got as far as bootanimation but zygote is not running. I have to admit, I mostly run Android these days without a frame buffer, so neither bootanimation nor zygote run.

You might try restarting zygote and/or surfaceflinger to see if that helps:
stop surfaceflinger
start surfaceflinger
stop zygote
start zygote

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Apr 28, 2014

Member

We're starting work on a 4.4.2 build for the zedboard, zc702, and zc706, by the way.

Member

jameyhicks commented Apr 28, 2014

We're starting work on a 4.4.2 build for the zedboard, zc702, and zc706, by the way.

@zoocad

This comment has been minimized.

Show comment
Hide comment
@zoocad

zoocad Apr 28, 2014

Hi Jamey,

Is there a simple command to stop the messages sent to the terminal.
It makes it hard to enter input commands.

Kind regards
Sven

PS. Looking forward to Android 4.4

28 apr 2014 kl. 14:47 skrev Jamey Hicks notifications@github.com:

Hi Sven,

It looks like you got as far as bootanimation but zygote is not running. I have to admit, I mostly run Android these days without a frame buffer, so neither bootanimation nor zygote run.

You might try restarting zygote and/or surfaceflinger to see if that helps:
stop surfaceflinger
start surfaceflinger
stop zygote
start zygote


Reply to this email directly or view it on GitHub.

zoocad commented Apr 28, 2014

Hi Jamey,

Is there a simple command to stop the messages sent to the terminal.
It makes it hard to enter input commands.

Kind regards
Sven

PS. Looking forward to Android 4.4

28 apr 2014 kl. 14:47 skrev Jamey Hicks notifications@github.com:

Hi Sven,

It looks like you got as far as bootanimation but zygote is not running. I have to admit, I mostly run Android these days without a frame buffer, so neither bootanimation nor zygote run.

You might try restarting zygote and/or surfaceflinger to see if that helps:
stop surfaceflinger
start surfaceflinger
stop zygote
start zygote


Reply to this email directly or view it on GitHub.

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Apr 28, 2014

Member

Hi Sven,

Although there is probably a way to redirect the Android log away from /dev/console, I always use:
adb connect
adb shell

to get a useable shell on the zedboard.

Member

jameyhicks commented Apr 28, 2014

Hi Sven,

Although there is probably a way to redirect the Android log away from /dev/console, I always use:
adb connect
adb shell

to get a useable shell on the zedboard.

@henrychoi

This comment has been minimized.

Show comment
Hide comment
@henrychoi

henrychoi Jan 29, 2015

Hello Jamey, I have a Android 5.0.1 shell over serial console on Zedboard, but I ran into the same problem that Sven did. I traced the problem to the surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188: LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference design, which does NOT have OpenGL acceleration), I want to use a Software OpenGL ES under the libhwui, but I am fumbling around trying to get my bearing in this foreign land of graphics. Do you have any useful links to share with me please?

w/ regards,
Henry

henrychoi commented Jan 29, 2015

Hello Jamey, I have a Android 5.0.1 shell over serial console on Zedboard, but I ran into the same problem that Sven did. I traced the problem to the surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188: LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference design, which does NOT have OpenGL acceleration), I want to use a Software OpenGL ES under the libhwui, but I am fumbling around trying to get my bearing in this foreign land of graphics. Do you have any useful links to share with me please?

w/ regards,
Henry

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Jan 29, 2015

Member

Hi Henry,

I'll have to dig around a little bit to see how to activate the software
OpenGL ES implementation. I would also like to be able to move forward to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi notifications@github.com
wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on Zedboard,
but I ran into the same problem that Sven did. I traced the problem to the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference design,
which does NOT have OpenGL acceleration), I want to use a Software OpenGL
ES under the libhwui, but I am fumbling around trying to get my bearing in
this foreign land of graphics. Do you have any useful links to share with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
#2 (comment)
.

Member

jameyhicks commented Jan 29, 2015

Hi Henry,

I'll have to dig around a little bit to see how to activate the software
OpenGL ES implementation. I would also like to be able to move forward to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi notifications@github.com
wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on Zedboard,
but I ran into the same problem that Sven did. I traced the problem to the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference design,
which does NOT have OpenGL acceleration), I want to use a Software OpenGL
ES under the libhwui, but I am fumbling around trying to get my bearing in
this foreign land of graphics. Do you have any useful links to share with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
#2 (comment)
.

@henrychoi

This comment has been minimized.

Show comment
Hide comment
@henrychoi

henrychoi Jan 29, 2015

Thanks for the quick reply Jamie! I've been writing this blog entry for a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini (which
I've been using)? Why do you want to use a more recent version of mesa (I
assume that is what you are using as the software OpenGL)? I am curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks notifications@github.com
wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the software
OpenGL ES implementation. I would also like to be able to move forward to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi notifications@github.com
wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the problem to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference design,
which does NOT have OpenGL acceleration), I want to use a Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my bearing
in
this foreign land of graphics. Do you have any useful links to share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

henrychoi commented Jan 29, 2015

Thanks for the quick reply Jamie! I've been writing this blog entry for a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini (which
I've been using)? Why do you want to use a more recent version of mesa (I
assume that is what you are using as the software OpenGL)? I am curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks notifications@github.com
wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the software
OpenGL ES implementation. I would also like to be able to move forward to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi notifications@github.com
wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the problem to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference design,
which does NOT have OpenGL acceleration), I want to use a Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my bearing
in
this foreign land of graphics. Do you have any useful links to share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Jan 29, 2015

Member

I meant, be able to move forward to a newer Android version.

The manifest is the list of git repos that the "repo" tool checks out.
On Wed Jan 28 2015 at 10:03:24 PM Henry Choi notifications@github.com
wrote:

Thanks for the quick reply Jamie! I've been writing this blog entry for a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini (which
I've been using)? Why do you want to use a more recent version of mesa (I
assume that is what you are using as the software OpenGL)? I am curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks notifications@github.com
wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the software
OpenGL ES implementation. I would also like to be able to move forward
to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi notifications@github.com
wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the problem to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES
implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference design,
which does NOT have OpenGL acceleration), I want to use a Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my
bearing
in
this foreign land of graphics. Do you have any useful links to share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<

https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71958019>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

Member

jameyhicks commented Jan 29, 2015

I meant, be able to move forward to a newer Android version.

The manifest is the list of git repos that the "repo" tool checks out.
On Wed Jan 28 2015 at 10:03:24 PM Henry Choi notifications@github.com
wrote:

Thanks for the quick reply Jamie! I've been writing this blog entry for a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini (which
I've been using)? Why do you want to use a more recent version of mesa (I
assume that is what you are using as the software OpenGL)? I am curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks notifications@github.com
wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the software
OpenGL ES implementation. I would also like to be able to move forward
to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi notifications@github.com
wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the problem to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES
implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference design,
which does NOT have OpenGL acceleration), I want to use a Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my
bearing
in
this foreign land of graphics. Do you have any useful links to share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<

https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71958019>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Jan 29, 2015

Member

Hi Henry,

In device/xilinx/zedboard/BoardConfig.mk, it contains this line, which is
missing from the zedmini BoardConfig.mk:

USE_OPENGL_RENDERER := false

A remaining problem with this board configuration is that it tries to run
shaders in the launch screen, but they are not supported by the
I guess I did not test the zedmini very well. I made the zedmini
configuration so that it would build faster and use less storage but since
I build it so infrequently and have enough SD storage, I just use the
zedboard configuration.

During debug, I also modify init.rc so that it does not start
surfaceflinger or zygote automatically, so that at least I can connect via
console or adb, start them manually, and see what is going on.

Jamey

On Thu Jan 29 2015 at 9:23:16 AM Jamey Hicks jamey.hicks@gmail.com wrote:

I meant, be able to move forward to a newer Android version.

The manifest is the list of git repos that the "repo" tool checks out.
On Wed Jan 28 2015 at 10:03:24 PM Henry Choi notifications@github.com
wrote:

Thanks for the quick reply Jamie! I've been writing this blog entry for a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini (which
I've been using)? Why do you want to use a more recent version of mesa (I
assume that is what you are using as the software OpenGL)? I am curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks notifications@github.com
wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the
software
OpenGL ES implementation. I would also like to be able to move forward
to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi notifications@github.com
wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the problem
to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES
implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference
design,
which does NOT have OpenGL acceleration), I want to use a Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my
bearing
in
this foreign land of graphics. Do you have any useful links to share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<
#2
issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
<#2
issuecomment-71958019>
.


Reply to this email directly or view it on GitHub
#2 (comment)
.

Member

jameyhicks commented Jan 29, 2015

Hi Henry,

In device/xilinx/zedboard/BoardConfig.mk, it contains this line, which is
missing from the zedmini BoardConfig.mk:

USE_OPENGL_RENDERER := false

A remaining problem with this board configuration is that it tries to run
shaders in the launch screen, but they are not supported by the
I guess I did not test the zedmini very well. I made the zedmini
configuration so that it would build faster and use less storage but since
I build it so infrequently and have enough SD storage, I just use the
zedboard configuration.

During debug, I also modify init.rc so that it does not start
surfaceflinger or zygote automatically, so that at least I can connect via
console or adb, start them manually, and see what is going on.

Jamey

On Thu Jan 29 2015 at 9:23:16 AM Jamey Hicks jamey.hicks@gmail.com wrote:

I meant, be able to move forward to a newer Android version.

The manifest is the list of git repos that the "repo" tool checks out.
On Wed Jan 28 2015 at 10:03:24 PM Henry Choi notifications@github.com
wrote:

Thanks for the quick reply Jamie! I've been writing this blog entry for a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini (which
I've been using)? Why do you want to use a more recent version of mesa (I
assume that is what you are using as the software OpenGL)? I am curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks notifications@github.com
wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the
software
OpenGL ES implementation. I would also like to be able to move forward
to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi notifications@github.com
wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the problem
to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES
implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference
design,
which does NOT have OpenGL acceleration), I want to use a Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my
bearing
in
this foreign land of graphics. Do you have any useful links to share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<
#2
issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
<#2
issuecomment-71958019>
.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Jan 29, 2015

Member

Have you seen these links?

http://www.slideshare.net/noritsuna/zedroid-android-50-and-later-on-zedboard

He comments that the software renderer is very slow. Do you have a GPU in
your design?

On Thu Jan 29 2015 at 9:36:22 AM Jamey Hicks jamey.hicks@gmail.com wrote:

Hi Henry,

In device/xilinx/zedboard/BoardConfig.mk, it contains this line, which is
missing from the zedmini BoardConfig.mk:

USE_OPENGL_RENDERER := false

A remaining problem with this board configuration is that it tries to run
shaders in the launch screen, but they are not supported by the
I guess I did not test the zedmini very well. I made the zedmini
configuration so that it would build faster and use less storage but since
I build it so infrequently and have enough SD storage, I just use the
zedboard configuration.

During debug, I also modify init.rc so that it does not start
surfaceflinger or zygote automatically, so that at least I can connect via
console or adb, start them manually, and see what is going on.

Jamey

On Thu Jan 29 2015 at 9:23:16 AM Jamey Hicks jamey.hicks@gmail.com
wrote:

I meant, be able to move forward to a newer Android version.

The manifest is the list of git repos that the "repo" tool checks out.
On Wed Jan 28 2015 at 10:03:24 PM Henry Choi notifications@github.com
wrote:

Thanks for the quick reply Jamie! I've been writing this blog entry for
a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini (which
I've been using)? Why do you want to use a more recent version of mesa
(I
assume that is what you are using as the software OpenGL)? I am curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks notifications@github.com
wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the
software
OpenGL ES implementation. I would also like to be able to move forward
to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi notifications@github.com

wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the problem
to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES
implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference
design,
which does NOT have OpenGL acceleration), I want to use a Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my
bearing
in
this foreign land of graphics. Do you have any useful links to share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<
#2
issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
<#2
issuecomment-71958019>
.


Reply to this email directly or view it on GitHub
#2 (comment)
.

Member

jameyhicks commented Jan 29, 2015

Have you seen these links?

http://www.slideshare.net/noritsuna/zedroid-android-50-and-later-on-zedboard

He comments that the software renderer is very slow. Do you have a GPU in
your design?

On Thu Jan 29 2015 at 9:36:22 AM Jamey Hicks jamey.hicks@gmail.com wrote:

Hi Henry,

In device/xilinx/zedboard/BoardConfig.mk, it contains this line, which is
missing from the zedmini BoardConfig.mk:

USE_OPENGL_RENDERER := false

A remaining problem with this board configuration is that it tries to run
shaders in the launch screen, but they are not supported by the
I guess I did not test the zedmini very well. I made the zedmini
configuration so that it would build faster and use less storage but since
I build it so infrequently and have enough SD storage, I just use the
zedboard configuration.

During debug, I also modify init.rc so that it does not start
surfaceflinger or zygote automatically, so that at least I can connect via
console or adb, start them manually, and see what is going on.

Jamey

On Thu Jan 29 2015 at 9:23:16 AM Jamey Hicks jamey.hicks@gmail.com
wrote:

I meant, be able to move forward to a newer Android version.

The manifest is the list of git repos that the "repo" tool checks out.
On Wed Jan 28 2015 at 10:03:24 PM Henry Choi notifications@github.com
wrote:

Thanks for the quick reply Jamie! I've been writing this blog entry for
a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini (which
I've been using)? Why do you want to use a more recent version of mesa
(I
assume that is what you are using as the software OpenGL)? I am curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks notifications@github.com
wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the
software
OpenGL ES implementation. I would also like to be able to move forward
to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi notifications@github.com

wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the problem
to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES
implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference
design,
which does NOT have OpenGL acceleration), I want to use a Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my
bearing
in
this foreign land of graphics. Do you have any useful links to share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<
#2
issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
<#2
issuecomment-71958019>
.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@henrychoi

This comment has been minimized.

Show comment
Hide comment
@henrychoi

henrychoi Jan 30, 2015

Thank you Jamie, like I said earlier, I have a shell using the zedmini
already, using USE_OPENGL_RENDERER := false (but using the workaround I
described here https://code.google.com/p/android/issues/detail?id=79116).
Since I am NFS booting the kernel and NFS rootfsing, I don't care about the
storage space either. I figured out how to inherit from
thecore_minimal.mk product
(rather than generic.mk--as zedboard definition does)--which I HOPE is
smaller (and therefore cause fewer problems). I noticed that you used to
inherit from mini.mk product, which is not found in build/target/products/
any more.

I don't know what a shader is (shows you how non-Android-savvy I am), but I
would be interested in your change to init.rc that turns off surfaceflinger
and zygote; I think then I should stop seeing the "untracked pid killed"
problem that Sven reported originally.

I am still fumbling about, and I've been trying a few things (like setting
USE_OPENGL_RENDERER := true, which does NOT seem to work anyway), but
hopefully the link you point to will teach me a few things about the
software rendering.

My zedboard HW design is based on the ADI's ADV7511 reference design (used
for the "Ubuntu on Zedboard" demo), which uses X on /dev/fb. I've even
proven raw QT on the DRM device driver (skipping X altogether) on this HW
design. This is a long winded way of answering: no, I don't have a GPU in
the HW. As far as I know, folding in the Xylon IP is the only known way to
get an OpenGL HW rendering on the zedboard, but this will require changing
my kernel and DTS. Since I am do NOT need rendering speed for now, I just
want to keep going with the HW design I have. This youtube video
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0CDUQtwIwAw&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D-LtjvekCDKM&ei=-dTKVN3pMdL7oQTZ0oHIBQ&usg=AFQjCNHJc--Uas05V-_d-UX_ZWhAe-VcbQ&sig2=uAqMjWRkQgqzlNN-9kOhCg&bvm=bv.85076809,d.cGU
shows
that software rendering is NOT the end of the world!

It's amazing to me that these Android engineers can work without a halfway
decent documentation; I guess you are just expected to know the software/HW
stack (relationship between surface flinger, libui/libhwui, OpenGL ES,
/dev/fb, etc) like the back of your hand. I just find the whole thing
pretty confusing at this point.

On Thu, Jan 29, 2015 at 6:43 AM, Jamey Hicks notifications@github.com
wrote:

Have you seen these links?

http://www.slideshare.net/noritsuna/zedroid-android-50-and-later-on-zedboard

He comments that the software renderer is very slow. Do you have a GPU in
your design?

On Thu Jan 29 2015 at 9:36:22 AM Jamey Hicks jamey.hicks@gmail.com
wrote:

Hi Henry,

In device/xilinx/zedboard/BoardConfig.mk, it contains this line, which
is
missing from the zedmini BoardConfig.mk:

USE_OPENGL_RENDERER := false

A remaining problem with this board configuration is that it tries to
run
shaders in the launch screen, but they are not supported by the
I guess I did not test the zedmini very well. I made the zedmini
configuration so that it would build faster and use less storage but
since
I build it so infrequently and have enough SD storage, I just use the
zedboard configuration.

During debug, I also modify init.rc so that it does not start
surfaceflinger or zygote automatically, so that at least I can connect
via
console or adb, start them manually, and see what is going on.

Jamey

On Thu Jan 29 2015 at 9:23:16 AM Jamey Hicks jamey.hicks@gmail.com
wrote:

I meant, be able to move forward to a newer Android version.

The manifest is the list of git repos that the "repo" tool checks out.
On Wed Jan 28 2015 at 10:03:24 PM Henry Choi notifications@github.com

wrote:

Thanks for the quick reply Jamie! I've been writing this blog entry
for
a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini
(which
I've been using)? Why do you want to use a more recent version of mesa
(I
assume that is what you are using as the software OpenGL)? I am
curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks notifications@github.com

wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the
software
OpenGL ES implementation. I would also like to be able to move
forward
to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi <
notifications@github.com>

wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the
problem
to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES
implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference
design,
which does NOT have OpenGL acceleration), I want to use a Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my
bearing
in
this foreign land of graphics. Do you have any useful links to
share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<
#2
issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
<#2
issuecomment-71958019>
.


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71961358>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

henrychoi commented Jan 30, 2015

Thank you Jamie, like I said earlier, I have a shell using the zedmini
already, using USE_OPENGL_RENDERER := false (but using the workaround I
described here https://code.google.com/p/android/issues/detail?id=79116).
Since I am NFS booting the kernel and NFS rootfsing, I don't care about the
storage space either. I figured out how to inherit from
thecore_minimal.mk product
(rather than generic.mk--as zedboard definition does)--which I HOPE is
smaller (and therefore cause fewer problems). I noticed that you used to
inherit from mini.mk product, which is not found in build/target/products/
any more.

I don't know what a shader is (shows you how non-Android-savvy I am), but I
would be interested in your change to init.rc that turns off surfaceflinger
and zygote; I think then I should stop seeing the "untracked pid killed"
problem that Sven reported originally.

I am still fumbling about, and I've been trying a few things (like setting
USE_OPENGL_RENDERER := true, which does NOT seem to work anyway), but
hopefully the link you point to will teach me a few things about the
software rendering.

My zedboard HW design is based on the ADI's ADV7511 reference design (used
for the "Ubuntu on Zedboard" demo), which uses X on /dev/fb. I've even
proven raw QT on the DRM device driver (skipping X altogether) on this HW
design. This is a long winded way of answering: no, I don't have a GPU in
the HW. As far as I know, folding in the Xylon IP is the only known way to
get an OpenGL HW rendering on the zedboard, but this will require changing
my kernel and DTS. Since I am do NOT need rendering speed for now, I just
want to keep going with the HW design I have. This youtube video
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0CDUQtwIwAw&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D-LtjvekCDKM&ei=-dTKVN3pMdL7oQTZ0oHIBQ&usg=AFQjCNHJc--Uas05V-_d-UX_ZWhAe-VcbQ&sig2=uAqMjWRkQgqzlNN-9kOhCg&bvm=bv.85076809,d.cGU
shows
that software rendering is NOT the end of the world!

It's amazing to me that these Android engineers can work without a halfway
decent documentation; I guess you are just expected to know the software/HW
stack (relationship between surface flinger, libui/libhwui, OpenGL ES,
/dev/fb, etc) like the back of your hand. I just find the whole thing
pretty confusing at this point.

On Thu, Jan 29, 2015 at 6:43 AM, Jamey Hicks notifications@github.com
wrote:

Have you seen these links?

http://www.slideshare.net/noritsuna/zedroid-android-50-and-later-on-zedboard

He comments that the software renderer is very slow. Do you have a GPU in
your design?

On Thu Jan 29 2015 at 9:36:22 AM Jamey Hicks jamey.hicks@gmail.com
wrote:

Hi Henry,

In device/xilinx/zedboard/BoardConfig.mk, it contains this line, which
is
missing from the zedmini BoardConfig.mk:

USE_OPENGL_RENDERER := false

A remaining problem with this board configuration is that it tries to
run
shaders in the launch screen, but they are not supported by the
I guess I did not test the zedmini very well. I made the zedmini
configuration so that it would build faster and use less storage but
since
I build it so infrequently and have enough SD storage, I just use the
zedboard configuration.

During debug, I also modify init.rc so that it does not start
surfaceflinger or zygote automatically, so that at least I can connect
via
console or adb, start them manually, and see what is going on.

Jamey

On Thu Jan 29 2015 at 9:23:16 AM Jamey Hicks jamey.hicks@gmail.com
wrote:

I meant, be able to move forward to a newer Android version.

The manifest is the list of git repos that the "repo" tool checks out.
On Wed Jan 28 2015 at 10:03:24 PM Henry Choi notifications@github.com

wrote:

Thanks for the quick reply Jamie! I've been writing this blog entry
for
a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini
(which
I've been using)? Why do you want to use a more recent version of mesa
(I
assume that is what you are using as the software OpenGL)? I am
curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks notifications@github.com

wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the
software
OpenGL ES implementation. I would also like to be able to move
forward
to
new versions. Do you have a pointer to your Android 5.0.1 manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi <
notifications@github.com>

wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the
problem
to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES
implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference
design,
which does NOT have OpenGL acceleration), I want to use a Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my
bearing
in
this foreign land of graphics. Do you have any useful links to
share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<
#2
issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
<#2
issuecomment-71958019>
.


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71961358>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Jan 30, 2015

Member

Hi Henry,

Thank you for the comprehensive description of your setup. The Xylon GPU is
the only one I know about for FPGAs, but you never know when someone else
might work on one.

Software rendering with Android 4.x was slow but OK. The new Material
Design for Android 5.x looks like it might require more GPU support to get
useable performance, but I have not tried it. Not just OpenGL ES but heavy
use of shaders. I'm very interested in how it works out.

I suppose I'm no longer surprised about lack of documentation in general.
Android's API is a Java API, and that is well documented. The information
needed for porting to a new chip is only needed by a few customers. I am
somewhat curious how much documentation an Android hardware licensee would
get, or if they have to just work it out on their own.

The problem for the non-GPU boards is now like it was for ARM before it had
floating point hardware. The most common case for Android devices is to
have a GPU. Mobile GPUs are very cheap.

Please send a link to your blog post when you publish it.

Best regards,
Jamey

On Thu Jan 29 2015 at 7:54:46 PM Henry Choi notifications@github.com
wrote:

Thank you Jamie, like I said earlier, I have a shell using the zedmini
already, using USE_OPENGL_RENDERER := false (but using the workaround I
described here https://code.google.com/p/android/issues/detail?id=79116).

Since I am NFS booting the kernel and NFS rootfsing, I don't care about
the
storage space either. I figured out how to inherit from
thecore_minimal.mk product
(rather than generic.mk--as zedboard definition does)--which I HOPE is
smaller (and therefore cause fewer problems). I noticed that you used to
inherit from mini.mk product, which is not found in
build/target/products/
any more.

I don't know what a shader is (shows you how non-Android-savvy I am), but
I
would be interested in your change to init.rc that turns off
surfaceflinger
and zygote; I think then I should stop seeing the "untracked pid killed"
problem that Sven reported originally.

I am still fumbling about, and I've been trying a few things (like setting
USE_OPENGL_RENDERER := true, which does NOT seem to work anyway), but
hopefully the link you point to will teach me a few things about the
software rendering.

My zedboard HW design is based on the ADI's ADV7511 reference design (used
for the "Ubuntu on Zedboard" demo), which uses X on /dev/fb. I've even
proven raw QT on the DRM device driver (skipping X altogether) on this HW
design. This is a long winded way of answering: no, I don't have a GPU in
the HW. As far as I know, folding in the Xylon IP is the only known way to
get an OpenGL HW rendering on the zedboard, but this will require changing
my kernel and DTS. Since I am do NOT need rendering speed for now, I just
want to keep going with the HW design I have. This youtube video
<
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0CDUQtwIwAw&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D-LtjvekCDKM&ei=-dTKVN3pMdL7oQTZ0oHIBQ&usg=AFQjCNHJc--Uas05V-_d-UX_ZWhAe-VcbQ&sig2=uAqMjWRkQgqzlNN-9kOhCg&bvm=bv.85076809,d.cGU>

shows
that software rendering is NOT the end of the world!

It's amazing to me that these Android engineers can work without a halfway
decent documentation; I guess you are just expected to know the
software/HW
stack (relationship between surface flinger, libui/libhwui, OpenGL ES,
/dev/fb, etc) like the back of your hand. I just find the whole thing
pretty confusing at this point.

On Thu, Jan 29, 2015 at 6:43 AM, Jamey Hicks notifications@github.com
wrote:

Have you seen these links?

http://www.slideshare.net/noritsuna/zedroid-android-50-and-later-on-zedboard

He comments that the software renderer is very slow. Do you have a GPU
in
your design?

On Thu Jan 29 2015 at 9:36:22 AM Jamey Hicks jamey.hicks@gmail.com
wrote:

Hi Henry,

In device/xilinx/zedboard/BoardConfig.mk, it contains this line, which
is
missing from the zedmini BoardConfig.mk:

USE_OPENGL_RENDERER := false

A remaining problem with this board configuration is that it tries to
run
shaders in the launch screen, but they are not supported by the
I guess I did not test the zedmini very well. I made the zedmini
configuration so that it would build faster and use less storage but
since
I build it so infrequently and have enough SD storage, I just use the
zedboard configuration.

During debug, I also modify init.rc so that it does not start
surfaceflinger or zygote automatically, so that at least I can connect
via
console or adb, start them manually, and see what is going on.

Jamey

On Thu Jan 29 2015 at 9:23:16 AM Jamey Hicks jamey.hicks@gmail.com
wrote:

I meant, be able to move forward to a newer Android version.

The manifest is the list of git repos that the "repo" tool checks
out.
On Wed Jan 28 2015 at 10:03:24 PM Henry Choi <
notifications@github.com>

wrote:

Thanks for the quick reply Jamie! I've been writing this blog entry
for
a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini
(which
I've been using)? Why do you want to use a more recent version of
mesa
(I
assume that is what you are using as the software OpenGL)? I am
curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks <
notifications@github.com>

wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the
software
OpenGL ES implementation. I would also like to be able to move
forward
to
new versions. Do you have a pointer to your Android 5.0.1
manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi <
notifications@github.com>

wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the
problem
to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES
implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference
design,
which does NOT have OpenGL acceleration), I want to use a
Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my
bearing
in
this foreign land of graphics. Do you have any useful links to
share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<
#2
issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
<#2
issuecomment-71958019>
.


Reply to this email directly or view it on GitHub
<

https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71961358>

.


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-72035560>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

Member

jameyhicks commented Jan 30, 2015

Hi Henry,

Thank you for the comprehensive description of your setup. The Xylon GPU is
the only one I know about for FPGAs, but you never know when someone else
might work on one.

Software rendering with Android 4.x was slow but OK. The new Material
Design for Android 5.x looks like it might require more GPU support to get
useable performance, but I have not tried it. Not just OpenGL ES but heavy
use of shaders. I'm very interested in how it works out.

I suppose I'm no longer surprised about lack of documentation in general.
Android's API is a Java API, and that is well documented. The information
needed for porting to a new chip is only needed by a few customers. I am
somewhat curious how much documentation an Android hardware licensee would
get, or if they have to just work it out on their own.

The problem for the non-GPU boards is now like it was for ARM before it had
floating point hardware. The most common case for Android devices is to
have a GPU. Mobile GPUs are very cheap.

Please send a link to your blog post when you publish it.

Best regards,
Jamey

On Thu Jan 29 2015 at 7:54:46 PM Henry Choi notifications@github.com
wrote:

Thank you Jamie, like I said earlier, I have a shell using the zedmini
already, using USE_OPENGL_RENDERER := false (but using the workaround I
described here https://code.google.com/p/android/issues/detail?id=79116).

Since I am NFS booting the kernel and NFS rootfsing, I don't care about
the
storage space either. I figured out how to inherit from
thecore_minimal.mk product
(rather than generic.mk--as zedboard definition does)--which I HOPE is
smaller (and therefore cause fewer problems). I noticed that you used to
inherit from mini.mk product, which is not found in
build/target/products/
any more.

I don't know what a shader is (shows you how non-Android-savvy I am), but
I
would be interested in your change to init.rc that turns off
surfaceflinger
and zygote; I think then I should stop seeing the "untracked pid killed"
problem that Sven reported originally.

I am still fumbling about, and I've been trying a few things (like setting
USE_OPENGL_RENDERER := true, which does NOT seem to work anyway), but
hopefully the link you point to will teach me a few things about the
software rendering.

My zedboard HW design is based on the ADI's ADV7511 reference design (used
for the "Ubuntu on Zedboard" demo), which uses X on /dev/fb. I've even
proven raw QT on the DRM device driver (skipping X altogether) on this HW
design. This is a long winded way of answering: no, I don't have a GPU in
the HW. As far as I know, folding in the Xylon IP is the only known way to
get an OpenGL HW rendering on the zedboard, but this will require changing
my kernel and DTS. Since I am do NOT need rendering speed for now, I just
want to keep going with the HW design I have. This youtube video
<
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0CDUQtwIwAw&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D-LtjvekCDKM&ei=-dTKVN3pMdL7oQTZ0oHIBQ&usg=AFQjCNHJc--Uas05V-_d-UX_ZWhAe-VcbQ&sig2=uAqMjWRkQgqzlNN-9kOhCg&bvm=bv.85076809,d.cGU>

shows
that software rendering is NOT the end of the world!

It's amazing to me that these Android engineers can work without a halfway
decent documentation; I guess you are just expected to know the
software/HW
stack (relationship between surface flinger, libui/libhwui, OpenGL ES,
/dev/fb, etc) like the back of your hand. I just find the whole thing
pretty confusing at this point.

On Thu, Jan 29, 2015 at 6:43 AM, Jamey Hicks notifications@github.com
wrote:

Have you seen these links?

http://www.slideshare.net/noritsuna/zedroid-android-50-and-later-on-zedboard

He comments that the software renderer is very slow. Do you have a GPU
in
your design?

On Thu Jan 29 2015 at 9:36:22 AM Jamey Hicks jamey.hicks@gmail.com
wrote:

Hi Henry,

In device/xilinx/zedboard/BoardConfig.mk, it contains this line, which
is
missing from the zedmini BoardConfig.mk:

USE_OPENGL_RENDERER := false

A remaining problem with this board configuration is that it tries to
run
shaders in the launch screen, but they are not supported by the
I guess I did not test the zedmini very well. I made the zedmini
configuration so that it would build faster and use less storage but
since
I build it so infrequently and have enough SD storage, I just use the
zedboard configuration.

During debug, I also modify init.rc so that it does not start
surfaceflinger or zygote automatically, so that at least I can connect
via
console or adb, start them manually, and see what is going on.

Jamey

On Thu Jan 29 2015 at 9:23:16 AM Jamey Hicks jamey.hicks@gmail.com
wrote:

I meant, be able to move forward to a newer Android version.

The manifest is the list of git repos that the "repo" tool checks
out.
On Wed Jan 28 2015 at 10:03:24 PM Henry Choi <
notifications@github.com>

wrote:

Thanks for the quick reply Jamie! I've been writing this blog entry
for
a
week now. I could publish it just so you can read it, but I guess by
"Android Manifest", you mean the content of device/xilinx/zedmini
(which
I've been using)? Why do you want to use a more recent version of
mesa
(I
assume that is what you are using as the software OpenGL)? I am
curious
what the benefit is...

On Wed, Jan 28, 2015 at 6:24 PM, Jamey Hicks <
notifications@github.com>

wrote:

Hi Henry,

I'll have to dig around a little bit to see how to activate the
software
OpenGL ES implementation. I would also like to be able to move
forward
to
new versions. Do you have a pointer to your Android 5.0.1
manifest?

Cheers,
Jamey

On Wed Jan 28 2015 at 7:46:55 PM Henry Choi <
notifications@github.com>

wrote:

Hello Jamey, I have a Android 5.0.1 shell over serial console on
Zedboard,
but I ran into the same problem that Sven did. I traced the
problem
to
the
surfaceflinger dying here:

frameworks/native/opengl/libs/EGL/Loader.cpp:188:
LOG_ALWAYS_FATAL_IF(!hnd, "couldn't find an OpenGL ES
implementation");

Since I do have a /dev/fb0 (I am running ADI ADV7511 reference
design,
which does NOT have OpenGL acceleration), I want to use a
Software
OpenGL
ES under the libhwui, but I am fumbling around trying to get my
bearing
in
this foreign land of graphics. Do you have any useful links to
share
with
me please?

w/ regards,
Henry


Reply to this email directly or view it on GitHub
<
#2
issuecomment-71948257>

.


Reply to this email directly or view it on GitHub
<#2
issuecomment-71958019>
.


Reply to this email directly or view it on GitHub
<

https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71961358>

.


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-72035560>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@henrychoi

This comment has been minimized.

Show comment
Hide comment
@henrychoi

henrychoi Jan 31, 2015

Hi Jamie, the good news is that the link you sent me kind of works; I see
the Android logo on my DVI monitor, as you can see here
http://henryomd.blogspot.com/2015/01/android-on-zedboard.html, and there
is no "untracked pid" problem any more. This is the farthest I've come
with Android on Zedboard project.

The bad news is that I skipped trying to boot the image from SD card and
went straight to NFS booting. Since I CAN boot, I must be pretty close.
It's strange that there isn't much resource on NFS rootfs-ing an Android.
I mean: isn't that the first thing you want to do when you bring up an
embedded system? Note that when I was using YOUR device/xilinx/zedmini,
the shell was always responsive--even when running over NFS (I would have
been happy to stick to zedmini except for the untracked PID problem, and
maybe I should try to merge your definitions with siprop's).

I am going to continue dorking with it some more, and may even try to put
the system.img and userdata.img as siprop as done in the document you
pointed me to.

henrychoi commented Jan 31, 2015

Hi Jamie, the good news is that the link you sent me kind of works; I see
the Android logo on my DVI monitor, as you can see here
http://henryomd.blogspot.com/2015/01/android-on-zedboard.html, and there
is no "untracked pid" problem any more. This is the farthest I've come
with Android on Zedboard project.

The bad news is that I skipped trying to boot the image from SD card and
went straight to NFS booting. Since I CAN boot, I must be pretty close.
It's strange that there isn't much resource on NFS rootfs-ing an Android.
I mean: isn't that the first thing you want to do when you bring up an
embedded system? Note that when I was using YOUR device/xilinx/zedmini,
the shell was always responsive--even when running over NFS (I would have
been happy to stick to zedmini except for the untracked PID problem, and
maybe I should try to merge your definitions with siprop's).

I am going to continue dorking with it some more, and may even try to put
the system.img and userdata.img as siprop as done in the document you
pointed me to.

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Feb 1, 2015

Member

I'm glad that link was helpful!

I try to avoid NFS on all my systems, especially the embedded ones. It is
kind of a pain to pull out the SD card to rewrite it, but once you get to
adb reliably you can update it with adb push and pull. But that is just a
personal quirk.

Please keep me posted, or I can follow your blog.

On Fri, Jan 30, 2015 at 8:53 PM, Henry Choi notifications@github.com
wrote:

Hi Jamie, the good news is that the link you sent me kind of works; I see
the Android logo on my DVI monitor, as you can see here
http://henryomd.blogspot.com/2015/01/android-on-zedboard.html, and there
is no "untracked pid" problem any more. This is the farthest I've come
with Android on Zedboard project.

The bad news is that I skipped trying to boot the image from SD card and
went straight to NFS booting. Since I CAN boot, I must be pretty close.
It's strange that there isn't much resource on NFS rootfs-ing an Android.
I mean: isn't that the first thing you want to do when you bring up an
embedded system? Note that when I was using YOUR device/xilinx/zedmini,
the shell was always responsive--even when running over NFS (I would have
been happy to stick to zedmini except for the untracked PID problem, and
maybe I should try to merge your definitions with siprop's).

I am going to continue dorking with it some more, and may even try to put
the system.img and userdata.img as siprop as done in the document you
pointed me to.


Reply to this email directly or view it on GitHub
#2 (comment)
.

Member

jameyhicks commented Feb 1, 2015

I'm glad that link was helpful!

I try to avoid NFS on all my systems, especially the embedded ones. It is
kind of a pain to pull out the SD card to rewrite it, but once you get to
adb reliably you can update it with adb push and pull. But that is just a
personal quirk.

Please keep me posted, or I can follow your blog.

On Fri, Jan 30, 2015 at 8:53 PM, Henry Choi notifications@github.com
wrote:

Hi Jamie, the good news is that the link you sent me kind of works; I see
the Android logo on my DVI monitor, as you can see here
http://henryomd.blogspot.com/2015/01/android-on-zedboard.html, and there
is no "untracked pid" problem any more. This is the farthest I've come
with Android on Zedboard project.

The bad news is that I skipped trying to boot the image from SD card and
went straight to NFS booting. Since I CAN boot, I must be pretty close.
It's strange that there isn't much resource on NFS rootfs-ing an Android.
I mean: isn't that the first thing you want to do when you bring up an
embedded system? Note that when I was using YOUR device/xilinx/zedmini,
the shell was always responsive--even when running over NFS (I would have
been happy to stick to zedmini except for the untracked PID problem, and
maybe I should try to merge your definitions with siprop's).

I am going to continue dorking with it some more, and may even try to put
the system.img and userdata.img as siprop as done in the document you
pointed me to.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@henrychoi

This comment has been minimized.

Show comment
Hide comment
@henrychoi

henrychoi Feb 1, 2015

I requested logcat from siprop, to diff against the problems I see.

I am now trying to remember how to go back to initramfs. Can you please
share your U-Boot sdboot and bootargs env variables?

On Sun, Feb 1, 2015 at 12:41 PM, Jamey Hicks notifications@github.com
wrote:

I'm glad that link was helpful!

I try to avoid NFS on all my systems, especially the embedded ones. It is
kind of a pain to pull out the SD card to rewrite it, but once you get to
adb reliably you can update it with adb push and pull. But that is just a
personal quirk.

Please keep me posted, or I can follow your blog.

On Fri, Jan 30, 2015 at 8:53 PM, Henry Choi notifications@github.com
wrote:

Hi Jamie, the good news is that the link you sent me kind of works; I
see
the Android logo on my DVI monitor, as you can see here
http://henryomd.blogspot.com/2015/01/android-on-zedboard.html, and
there
is no "untracked pid" problem any more. This is the farthest I've come
with Android on Zedboard project.

The bad news is that I skipped trying to boot the image from SD card and
went straight to NFS booting. Since I CAN boot, I must be pretty close.
It's strange that there isn't much resource on NFS rootfs-ing an
Android.
I mean: isn't that the first thing you want to do when you bring up an
embedded system? Note that when I was using YOUR device/xilinx/zedmini,
the shell was always responsive--even when running over NFS (I would
have
been happy to stick to zedmini except for the untracked PID problem, and
maybe I should try to merge your definitions with siprop's).

I am going to continue dorking with it some more, and may even try to
put
the system.img and userdata.img as siprop as done in the document you
pointed me to.


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-72299012>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

henrychoi commented Feb 1, 2015

I requested logcat from siprop, to diff against the problems I see.

I am now trying to remember how to go back to initramfs. Can you please
share your U-Boot sdboot and bootargs env variables?

On Sun, Feb 1, 2015 at 12:41 PM, Jamey Hicks notifications@github.com
wrote:

I'm glad that link was helpful!

I try to avoid NFS on all my systems, especially the embedded ones. It is
kind of a pain to pull out the SD card to rewrite it, but once you get to
adb reliably you can update it with adb push and pull. But that is just a
personal quirk.

Please keep me posted, or I can follow your blog.

On Fri, Jan 30, 2015 at 8:53 PM, Henry Choi notifications@github.com
wrote:

Hi Jamie, the good news is that the link you sent me kind of works; I
see
the Android logo on my DVI monitor, as you can see here
http://henryomd.blogspot.com/2015/01/android-on-zedboard.html, and
there
is no "untracked pid" problem any more. This is the farthest I've come
with Android on Zedboard project.

The bad news is that I skipped trying to boot the image from SD card and
went straight to NFS booting. Since I CAN boot, I must be pretty close.
It's strange that there isn't much resource on NFS rootfs-ing an
Android.
I mean: isn't that the first thing you want to do when you bring up an
embedded system? Note that when I was using YOUR device/xilinx/zedmini,
the shell was always responsive--even when running over NFS (I would
have
been happy to stick to zedmini except for the untracked PID problem, and
maybe I should try to merge your definitions with siprop's).

I am going to continue dorking with it some more, and may even try to
put
the system.img and userdata.img as siprop as done in the document you
pointed me to.


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-72299012>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Feb 2, 2015

Member

Hi Henry,

We are not using u-boot. We boot the kernel directly from the zynq fsbl.

See http://github.com/cambridgehackers/zynq-boot for that part. The kernel
cmdline is in the dts file:

https://github.com/cambridgehackers/zynq-boot/blob/master/imagefiles/zynq-zedboard-portal.dts

On Sun Feb 01 2015 at 5:11:30 PM Henry Choi notifications@github.com
wrote:

I requested logcat from siprop, to diff against the problems I see.

I am now trying to remember how to go back to initramfs. Can you please
share your U-Boot sdboot and bootargs env variables?

On Sun, Feb 1, 2015 at 12:41 PM, Jamey Hicks notifications@github.com
wrote:

I'm glad that link was helpful!

I try to avoid NFS on all my systems, especially the embedded ones. It
is
kind of a pain to pull out the SD card to rewrite it, but once you get
to
adb reliably you can update it with adb push and pull. But that is just
a
personal quirk.

Please keep me posted, or I can follow your blog.

On Fri, Jan 30, 2015 at 8:53 PM, Henry Choi notifications@github.com
wrote:

Hi Jamie, the good news is that the link you sent me kind of works; I
see
the Android logo on my DVI monitor, as you can see here
http://henryomd.blogspot.com/2015/01/android-on-zedboard.html, and
there
is no "untracked pid" problem any more. This is the farthest I've come
with Android on Zedboard project.

The bad news is that I skipped trying to boot the image from SD card
and
went straight to NFS booting. Since I CAN boot, I must be pretty
close.
It's strange that there isn't much resource on NFS rootfs-ing an
Android.
I mean: isn't that the first thing you want to do when you bring up an
embedded system? Note that when I was using YOUR
device/xilinx/zedmini,
the shell was always responsive--even when running over NFS (I would
have
been happy to stick to zedmini except for the untracked PID problem,
and
maybe I should try to merge your definitions with siprop's).

I am going to continue dorking with it some more, and may even try to
put
the system.img and userdata.img as siprop as done in the document you
pointed me to.


Reply to this email directly or view it on GitHub
<

https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-72299012>

.


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-72383174>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

Member

jameyhicks commented Feb 2, 2015

Hi Henry,

We are not using u-boot. We boot the kernel directly from the zynq fsbl.

See http://github.com/cambridgehackers/zynq-boot for that part. The kernel
cmdline is in the dts file:

https://github.com/cambridgehackers/zynq-boot/blob/master/imagefiles/zynq-zedboard-portal.dts

On Sun Feb 01 2015 at 5:11:30 PM Henry Choi notifications@github.com
wrote:

I requested logcat from siprop, to diff against the problems I see.

I am now trying to remember how to go back to initramfs. Can you please
share your U-Boot sdboot and bootargs env variables?

On Sun, Feb 1, 2015 at 12:41 PM, Jamey Hicks notifications@github.com
wrote:

I'm glad that link was helpful!

I try to avoid NFS on all my systems, especially the embedded ones. It
is
kind of a pain to pull out the SD card to rewrite it, but once you get
to
adb reliably you can update it with adb push and pull. But that is just
a
personal quirk.

Please keep me posted, or I can follow your blog.

On Fri, Jan 30, 2015 at 8:53 PM, Henry Choi notifications@github.com
wrote:

Hi Jamie, the good news is that the link you sent me kind of works; I
see
the Android logo on my DVI monitor, as you can see here
http://henryomd.blogspot.com/2015/01/android-on-zedboard.html, and
there
is no "untracked pid" problem any more. This is the farthest I've come
with Android on Zedboard project.

The bad news is that I skipped trying to boot the image from SD card
and
went straight to NFS booting. Since I CAN boot, I must be pretty
close.
It's strange that there isn't much resource on NFS rootfs-ing an
Android.
I mean: isn't that the first thing you want to do when you bring up an
embedded system? Note that when I was using YOUR
device/xilinx/zedmini,
the shell was always responsive--even when running over NFS (I would
have
been happy to stick to zedmini except for the untracked PID problem,
and
maybe I should try to merge your definitions with siprop's).

I am going to continue dorking with it some more, and may even try to
put
the system.img and userdata.img as siprop as done in the document you
pointed me to.


Reply to this email directly or view it on GitHub
<

https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-72299012>

.


Reply to this email directly or view it on GitHub
<
https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-72383174>

.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@henrychoi

This comment has been minimized.

Show comment
Hide comment
@henrychoi

henrychoi Feb 8, 2015

Hi Jamey, I finally saw the AOSP 5.0.2_r1 Home screen on my DVI monitor,
using the mesa package from siprop (Imamura-san, the link you pointed me
to). Unfortunately, the launcher crashes. It may be happening somewhere
deep inside gralloc. Among many things, I learned that Anroid over NFS is
really painful; rather disappointing after a few weeks of nights and
weekends. Still, much better than just skimming Karim Yagmor's book, so no
regrets.

IMHO, the show stopper is the lack of GPU on Zedboard--the GUI experiences
hundreds of dropped frames, and as a result, the runtime spazzes out about
the apparent rendering slowness, and dumps stack trace to /data/anr/
frequently--slowing things down even more). Imamura-san's build all invoke
software GLES 3.0 implementation (regardless of the build preferences
indicated in the mk file); I confirmed that the logcat from Imamura-san had
the same problem, but did not bring up the problem with Imamura-san.

I don't know why Android 5.0 with software GLES just crawls like this, when
this was apparently possible in ICS days (saw the youtube video the Linaro
team posted while bringing up ICS). Personally, I am convinced that
Android 5.0 on Zedboard should not be attempted without a GPU. Rather than
sink more effort to integrate Xylon IP, I would rather just plug in an
nVidia GeForce PCIe card into a Mini-ITX
http://zedboard.org/product/mini-itx, since nVidia keeps ARM Linux nVidia
drivers current.

So I am afraid that this is as far as I want to go with Zedroid for
now--unless I hear a new discovery by others.

P.S. I started this whole project because I wanted to shrink expensive
biotech instrument controller HW/FW/SW into zedboard, but the experience
told me that Android alone needs more horsepower available on Zedboard for
a great UI experience. At the last X-fest, Xilinx engineer told me they
are considering a quad-core Zynq follow-on, but that wasn't going to be
until they figure out the next process than 28 nm.

henrychoi commented Feb 8, 2015

Hi Jamey, I finally saw the AOSP 5.0.2_r1 Home screen on my DVI monitor,
using the mesa package from siprop (Imamura-san, the link you pointed me
to). Unfortunately, the launcher crashes. It may be happening somewhere
deep inside gralloc. Among many things, I learned that Anroid over NFS is
really painful; rather disappointing after a few weeks of nights and
weekends. Still, much better than just skimming Karim Yagmor's book, so no
regrets.

IMHO, the show stopper is the lack of GPU on Zedboard--the GUI experiences
hundreds of dropped frames, and as a result, the runtime spazzes out about
the apparent rendering slowness, and dumps stack trace to /data/anr/
frequently--slowing things down even more). Imamura-san's build all invoke
software GLES 3.0 implementation (regardless of the build preferences
indicated in the mk file); I confirmed that the logcat from Imamura-san had
the same problem, but did not bring up the problem with Imamura-san.

I don't know why Android 5.0 with software GLES just crawls like this, when
this was apparently possible in ICS days (saw the youtube video the Linaro
team posted while bringing up ICS). Personally, I am convinced that
Android 5.0 on Zedboard should not be attempted without a GPU. Rather than
sink more effort to integrate Xylon IP, I would rather just plug in an
nVidia GeForce PCIe card into a Mini-ITX
http://zedboard.org/product/mini-itx, since nVidia keeps ARM Linux nVidia
drivers current.

So I am afraid that this is as far as I want to go with Zedroid for
now--unless I hear a new discovery by others.

P.S. I started this whole project because I wanted to shrink expensive
biotech instrument controller HW/FW/SW into zedboard, but the experience
told me that Android alone needs more horsepower available on Zedboard for
a great UI experience. At the last X-fest, Xilinx engineer told me they
are considering a quad-core Zynq follow-on, but that wasn't going to be
until they figure out the next process than 28 nm.

@jameyhicks

This comment has been minimized.

Show comment
Hide comment
@jameyhicks

jameyhicks Feb 9, 2015

Member

Hi Henry,

If you look at the visual effects in the Android 5.0 GUI, I think you will
see more shadows and other effects that use more OpenGL shaders than in
previous releases.

A pcie graphics card would be a good thing to try. Or maybe if someone
comes up with a good OpenGL ES implementation for parallela.

Jamey

On Sun Feb 08 2015 at 6:34:02 PM Henry Choi notifications@github.com
wrote:

Hi Jamey, I finally saw the AOSP 5.0.2_r1 Home screen on my DVI monitor,
using the mesa package from siprop (Imamura-san, the link you pointed me
to). Unfortunately, the launcher crashes. It may be happening somewhere
deep inside gralloc. Among many things, I learned that Anroid over NFS is
really painful; rather disappointing after a few weeks of nights and
weekends. Still, much better than just skimming Karim Yagmor's book, so no
regrets.

IMHO, the show stopper is the lack of GPU on Zedboard--the GUI experiences
hundreds of dropped frames, and as a result, the runtime spazzes out about
the apparent rendering slowness, and dumps stack trace to /data/anr/
frequently--slowing things down even more). Imamura-san's build all invoke
software GLES 3.0 implementation (regardless of the build preferences
indicated in the mk file); I confirmed that the logcat from Imamura-san had
the same problem, but did not bring up the problem with Imamura-san.

I don't know why Android 5.0 with software GLES just crawls like this, when
this was apparently possible in ICS days (saw the youtube video the Linaro
team posted while bringing up ICS). Personally, I am convinced that
Android 5.0 on Zedboard should not be attempted without a GPU. Rather than
sink more effort to integrate Xylon IP, I would rather just plug in an
nVidia GeForce PCIe card into a Mini-ITX
http://zedboard.org/product/mini-itx, since nVidia keeps ARM Linux
nVidia
drivers current.

So I am afraid that this is as far as I want to go with Zedroid for
now--unless I hear a new discovery by others.

P.S. I started this whole project because I wanted to shrink expensive
biotech instrument controller HW/FW/SW into zedboard, but the experience
told me that Android alone needs more horsepower available on Zedboard for
a great UI experience. At the last X-fest, Xilinx engineer told me they
are considering a quad-core Zynq follow-on, but that wasn't going to be
until they figure out the next process than 28 nm.


Reply to this email directly or view it on GitHub
#2 (comment)
.

Member

jameyhicks commented Feb 9, 2015

Hi Henry,

If you look at the visual effects in the Android 5.0 GUI, I think you will
see more shadows and other effects that use more OpenGL shaders than in
previous releases.

A pcie graphics card would be a good thing to try. Or maybe if someone
comes up with a good OpenGL ES implementation for parallela.

Jamey

On Sun Feb 08 2015 at 6:34:02 PM Henry Choi notifications@github.com
wrote:

Hi Jamey, I finally saw the AOSP 5.0.2_r1 Home screen on my DVI monitor,
using the mesa package from siprop (Imamura-san, the link you pointed me
to). Unfortunately, the launcher crashes. It may be happening somewhere
deep inside gralloc. Among many things, I learned that Anroid over NFS is
really painful; rather disappointing after a few weeks of nights and
weekends. Still, much better than just skimming Karim Yagmor's book, so no
regrets.

IMHO, the show stopper is the lack of GPU on Zedboard--the GUI experiences
hundreds of dropped frames, and as a result, the runtime spazzes out about
the apparent rendering slowness, and dumps stack trace to /data/anr/
frequently--slowing things down even more). Imamura-san's build all invoke
software GLES 3.0 implementation (regardless of the build preferences
indicated in the mk file); I confirmed that the logcat from Imamura-san had
the same problem, but did not bring up the problem with Imamura-san.

I don't know why Android 5.0 with software GLES just crawls like this, when
this was apparently possible in ICS days (saw the youtube video the Linaro
team posted while bringing up ICS). Personally, I am convinced that
Android 5.0 on Zedboard should not be attempted without a GPU. Rather than
sink more effort to integrate Xylon IP, I would rather just plug in an
nVidia GeForce PCIe card into a Mini-ITX
http://zedboard.org/product/mini-itx, since nVidia keeps ARM Linux
nVidia
drivers current.

So I am afraid that this is as far as I want to go with Zedroid for
now--unless I hear a new discovery by others.

P.S. I started this whole project because I wanted to shrink expensive
biotech instrument controller HW/FW/SW into zedboard, but the experience
told me that Android alone needs more horsepower available on Zedboard for
a great UI experience. At the last X-fest, Xilinx engineer told me they
are considering a quad-core Zynq follow-on, but that wasn't going to be
until they figure out the next process than 28 nm.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@henrychoi

This comment has been minimized.

Show comment
Hide comment
@henrychoi

henrychoi Feb 10, 2015

henrychoi commented Feb 10, 2015

@jankcorn

This comment has been minimized.

Show comment
Hide comment
@jankcorn

jankcorn Feb 10, 2015

Member

Henry,

I think that Jamey was just mentioning that because their eval board is
connected to a Zynq 020 and seems to render graphics demos pretty fast. If
someone had the skill/patience, it could possibly be a good fabric for a
s/w GPU (but seems quite difficult).

Your other comments caused me to remember another project we had done,
which we called Klaatu:
https://gitorious.org/cambridge/pages/SysrootBuild

This project is a bit out of date (last version of Android supported was
4.4???), but it did the following:
1) Took an existing Android distro (not just AOSP, but also Qualcomm,
TI, blah, blah)
2) Stripped off the Java layer
3) Documented the upper i/f of the slim Android C++ middleware (which
is quite good, IMO)
4) ported Qt/5 on top
5) had a demo UI in QML, but could use standard Qt/C++ apps as well.
6) as an option to building apps 'in-tree' (like standard android), we
packaged up environments in RPMs that make it easy to make a pretty
standard sysroot, so you can do "./configure; make; make install" types of
builds (instead of cobbling together a weird Android.mk for random existing
packages you want to use)

Haven't worked on it in a while, but, if you are happy doing apps in Qt, it
seems much, much better than doing stuff on top of a standard Android
distro.

Given my documentation skills, it is probably quite problematic to
understand how to use the stuff, but I am happy to answer questions, if you
are interested.

Anyway, just more food for thought!
jca

On Mon, Feb 9, 2015 at 11:14 PM, Henry Choi notifications@github.com
wrote:

Parallela? That's a bit from the left field isn't it? It's
"reconfigurable computing", but for a hardware maker like me, the benefit
of FPGA is not so much on the computing itself, but rather the IOs (and of
course doing a bit of computation on the IO). As long as we are talking
about architecture, I rather thought a better route for me is just to run
Buildroot (with QT5 possibility) on Zedboard, and open up a low level
access to my hardware, with an UNSEXY slow GUI (possibly web-based), and
open things up over Ethernet to an Android or WPF based sexy GUI running on
a tablet (which I will NOT program).

Brings back memories of the conversations I had with my former colleagues
about reconfigurable computing for the sake of reconfigurable computing--in
context of why anybody will buy an FPGA just to run a Soft CPU--when the
hard CPU are so much faster and more mainstream.


Reply to this email directly or view it on GitHub
#2 (comment)
.

Member

jankcorn commented Feb 10, 2015

Henry,

I think that Jamey was just mentioning that because their eval board is
connected to a Zynq 020 and seems to render graphics demos pretty fast. If
someone had the skill/patience, it could possibly be a good fabric for a
s/w GPU (but seems quite difficult).

Your other comments caused me to remember another project we had done,
which we called Klaatu:
https://gitorious.org/cambridge/pages/SysrootBuild

This project is a bit out of date (last version of Android supported was
4.4???), but it did the following:
1) Took an existing Android distro (not just AOSP, but also Qualcomm,
TI, blah, blah)
2) Stripped off the Java layer
3) Documented the upper i/f of the slim Android C++ middleware (which
is quite good, IMO)
4) ported Qt/5 on top
5) had a demo UI in QML, but could use standard Qt/C++ apps as well.
6) as an option to building apps 'in-tree' (like standard android), we
packaged up environments in RPMs that make it easy to make a pretty
standard sysroot, so you can do "./configure; make; make install" types of
builds (instead of cobbling together a weird Android.mk for random existing
packages you want to use)

Haven't worked on it in a while, but, if you are happy doing apps in Qt, it
seems much, much better than doing stuff on top of a standard Android
distro.

Given my documentation skills, it is probably quite problematic to
understand how to use the stuff, but I am happy to answer questions, if you
are interested.

Anyway, just more food for thought!
jca

On Mon, Feb 9, 2015 at 11:14 PM, Henry Choi notifications@github.com
wrote:

Parallela? That's a bit from the left field isn't it? It's
"reconfigurable computing", but for a hardware maker like me, the benefit
of FPGA is not so much on the computing itself, but rather the IOs (and of
course doing a bit of computation on the IO). As long as we are talking
about architecture, I rather thought a better route for me is just to run
Buildroot (with QT5 possibility) on Zedboard, and open up a low level
access to my hardware, with an UNSEXY slow GUI (possibly web-based), and
open things up over Ethernet to an Android or WPF based sexy GUI running on
a tablet (which I will NOT program).

Brings back memories of the conversations I had with my former colleagues
about reconfigurable computing for the sake of reconfigurable computing--in
context of why anybody will buy an FPGA just to run a Soft CPU--when the
hard CPU are so much faster and more mainstream.


Reply to this email directly or view it on GitHub
#2 (comment)
.

@henrychoi

This comment has been minimized.

Show comment
Hide comment
@henrychoi

henrychoi Feb 10, 2015

henrychoi commented Feb 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment