Couldn't boot

[ghost]

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]

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]

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]

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

[ghost]

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]

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]

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]

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]

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]

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

[zoocad]

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]

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]

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]

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 .

[henrychoi]

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 .

[jameyhicks]

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 https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71961358 .

[jameyhicks]

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 < 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 https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71961358 .

[jameyhicks]

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 < 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 https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-71961358 .

[henrychoi]

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 < 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 < 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 .

[jameyhicks]

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 < 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 <

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 https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-72135355 .

[henrychoi]

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]

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 .

[henrychoi]

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 .

[jameyhicks]

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 https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-72387327 .

[henrychoi]

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]

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 https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-73439554 .

[henrychoi]

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.

[jankcorn]

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 https://github.com/cambridgehackers/zedboard_manifests/issues/2#issuecomment-73641657 .

[henrychoi]

Thanks for the explanation JCA! Parallela does look interesting. Perhaps I will look into it after getting my current project out of the way.