Dump Android emulator root filesystem (yaffs2 filesystem)

760 views
Skip to first unread message

Nicolas

unread,
Nov 13, 2007, 5:23:09 PM11/13/07
to Android Developers
Hi,

Could someone mount the emulator system.img and dump the content? It
is formatted using the yaffs2 filesystem (yaffs2 is not built in main
stream kernel - it needs a patch to mount this kind of fs). Maybe some
embedded developper here can do it?

My idea is to try to boot the system on a ARM device which already has
a working kernel. So we only need the usermode files (I mean the
content of system.img).

yaffs2 is a filesystem optimized for NAND storage.

Nicolas;

Benno

unread,
Nov 13, 2007, 6:19:04 PM11/13/07
to Android Developers
I have extracted these from a running system. See:

http://benno.id.au/blog/2007/11/14/android-filesystems

Cheers,

Ben

kokuryu

unread,
Nov 13, 2007, 6:30:09 PM11/13/07
to Android Developers
Interesting... What device are you going to put it on? Are you using
one of the open phones like OpenMoko or the Greenphone to try this?
Let us know how you fare with this - it would be nice to have an
Android device to work with.

TomCooksey

unread,
Nov 13, 2007, 6:51:57 PM11/13/07
to Android Developers
Well done! How did you manage to do that? I've been trying various
methods to try and extract the images all day!

The closet I came was to use the nandsim kernel module to try and
simulate a nand mtd device, copy the nandwrite the system.img to the
fake nand mtd device & mount it. Trouble is I had problems getting my
kernel to mount the yaffs2 filesystem - I believe the yaffs2 code
isn't 64-bit safe as I'm running a 64-bit kernel (& compiling the
module threw up loads of warnings about copying a pointer to an int).

I was going to try and get busybox compiled up and running on the
emulator so I could do a cp (which is conveniently missing!).


I'd _love_ to know how you did it. :-)

Benno

unread,
Nov 13, 2007, 6:55:53 PM11/13/07
to Android Developers
I compiled busybox (http://benno.id.au/blog/2007/11/14/android-
busybox), then
used tar to create an archive, and adb pull to get it across to the
host. As a result it isn't exactly pristine, but close enough.

TomCooksey

unread,
Nov 13, 2007, 6:57:19 PM11/13/07
to Android Developers
Ah, never mind - You went down the busybox route too huh? Nice work. :-
D

Time to try it on the OpenMoko.... although I suspect the Neo's ARM9
CPU isn't going to be able to execute code compiled for an ARM11
(assuming the Android code uses armv6 instructions). Worth a try
tho.... The N800 has an ARM11... might have better luck on that?

Aaron Ardiri

unread,
Nov 13, 2007, 7:02:11 PM11/13/07
to android-d...@googlegroups.com

# cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 331.77
Features : swp half thumb fastmult vfp edsp java

if you get it working on openmoko, let me know. i have a device i can use
for something like this myself :) i have actually been playing for an hour or
so and i have a few demo programs already running..

--
// Aaron Ardiri
Mobile Wizardry
http://www.mobilewizardry.com/

John Bloom

unread,
Nov 13, 2007, 10:42:14 PM11/13/07
to Android Developers
I did my own dump of the filesystem yesterday by borrowing a copy of
busybox-static from the ARMEL/EABI port of Debian Sid. I used busybox
to tar the contents of /system and /data onto the "sdcard" then
mounted that image file over loopback on my laptop. Probably the long
way around...

Anyways, I've been trying to get this running on both a Sharp Zaurus
SL-C1000[1] and a Nokia N800[2]
---
Update: Even as I type this I'm watching the "cylon" (red moving dot)
startup screen on my Zaurus. It's just sitting there though.
Hmm...maybe it needs dbus running?

Aaron: I'm really curious as to how well it worked for you. I'm
especially curious about how it performed on real hardware and also
any stumbling blocks you ran into. :)

-John
[1] Processor : XScale-PXA270 rev 4 (v5l)
CPU architecture: 5TE
Features : swp half thumb fastmult edsp iwmmxt
[2] Processor : Some Random V6 Processor rev 2 (v6l)
CPU architecture: 6TEJ

Aaron Ardiri

unread,
Nov 13, 2007, 10:51:08 PM11/13/07
to android-d...@googlegroups.com
On Nov 14, 2007 4:42 AM, John Bloom <joh...@gmail.com> wrote:
> Anyways, I've been trying to get this running on both a Sharp Zaurus
> SL-C1000[1] and a Nokia N800[2]
> ---
> Update: Even as I type this I'm watching the "cylon" (red moving dot)
> startup screen on my Zaurus. It's just sitting there though.
> Hmm...maybe it needs dbus running?

can you post instructions as to how you got this far?

> Aaron: I'm really curious as to how well it worked for you. I'm
> especially curious about how it performed on real hardware and also
> any stumbling blocks you ran into. :)

i never got it running - i have not tried it yet. i was only just playing
around with the sdk (the java one). i have a number of devices that
may be capable of using this, specifically:

- openmoko
- nokia n770
- sharp zaurus C550 (very old)
- a custom linux handheld (unreleased)

if someone can figure it out correctly, i would be more than happy to
try it on one of my devices as well and post the results. ideally, the
openmoko platform would be the best to get it working on.

John Bloom

unread,
Nov 13, 2007, 11:44:08 PM11/13/07
to Android Developers
On Nov 14, 12:51 pm, "Aaron Ardiri" <ard...@gmail.com> wrote:
> On Nov 14, 2007 4:42 AM, John Bloom <joh...@gmail.com> wrote:
>
> > Anyways, I've been trying to get this running on both a Sharp Zaurus
> > SL-C1000[1] and a Nokia N800[2]
> > ---
> > Update: Even as I type this I'm watching the "cylon" (red moving dot)
> > startup screen on my Zaurus. It's just sitting there though.
> > Hmm...maybe it needs dbus running?
>
> can you post instructions as to how you got this far?
Ok, here's the quick version. Ask if you need more details:
0) Have an ARM device running Linux capable of executing EABI binaries
1) Get together a filesystem image: Either grab it yourself with tar
from inside the emulator or unpack the ramdisk.img (gzipped cpio
archive) and grab Benno's system.tar.gz and data.tar.gz
2) unpack that on your guinea pig ARM machine.
3) chroot /path/to/android /system/bin/sh
4) export some variables:
export PATH=/sbin:/system/sbin:/system/bin
export LD_LIBRARY_PATH=/system/lib
export ANDROID_ROOT=/system
export ANDROID_ASSETS=/system/app
export ANDROID_DATA=/data
export EXTERNAL_STORAGE=/sdcard
export DRM_CONTENT=/data/drm/content
5) /system/bin/app_process -Xzygote /system/bin --zygote &
6) /system/bin/dbus-daemon --system &
7) runtime

Make sure you have some way to access the machine other than through
the console, because at this point you get the red cylon eye and are
left with no way to stop it from the physical console except with a
hard power cycle (or probably sysrq). I've left it running on that eye
for about half an hour now. top says that runtime is using no CPU time
and 33% of the RAM (64MB). runtime does complain about not being able
to access "/sys/android_power/acquire_partial_wake_lock". That file
is, of course, not provided by my Zaurus' kernel. This might mean we
need to apply some of Google's patches to a vanilla kernel or it may
mean non-Google ARM hardware won't work without some modification to
the Google userland stuff. Or maybe we can trick the runtime
process. ;)


>
> > Aaron: I'm really curious as to how well it worked for you. I'm
> > especially curious about how it performed on real hardware and also
> > any stumbling blocks you ran into. :)
>
> i never got it running - i have not tried it yet. i was only just playing
> around with the sdk (the java one). i have a number of devices that

Aaah, I understand now. And here I was thinking I was missing
something obvious as everyone else was playing around with this
already. :D


> may be capable of using this, specifically:
>
> - openmoko
> - nokia n770
> - sharp zaurus C550 (very old)
> - a custom linux handheld (unreleased)
>
> if someone can figure it out correctly, i would be more than happy to
> try it on one of my devices as well and post the results. ideally, the
> openmoko platform would be the best to get it working on.

So far it looks like the userland stuff is just compiled for EABI with
no Armv6 specific optimizations. I have no idea about your custom
Linux handheld, but everythong on that list should be fine except for
the Zaurus SL-5500 (StronARM SA1100 aka Armv4)


>
> --
> // Aaron Ardiri
> Mobile Wizardryhttp://www.mobilewizardry.com/

UPDATE: I left it at the red cylon "startup screen" for maybe 45
minutes now. The dot stopped moving eventually, and now CPU usage is
basically pegged at 100% by runtime. ~15% of that is system time,
which I find interesting. It's still using the same amount of memory.

-John

Aaron Ardiri

unread,
Nov 14, 2007, 4:12:47 AM11/14/07
to android-d...@googlegroups.com
On Nov 14, 2007 5:44 AM, John Bloom <joh...@gmail.com> wrote:
> > can you post instructions as to how you got this far?
>
> Ok, here's the quick version. Ask if you need more details:
>
> 0) Have an ARM device running Linux capable of executing EABI binaries

got it, the custom linux device i have is a unit from unicon systems.
specifically:

http://www.uniconsys.com/devkit-ucn2410-c.html

i picked it up at linuxworld 2007. the specifications are:

- linux 2.6
- ARM9 S3C240A embedded CPU at 266 MHz
- 32mb SDRAM, 32mb FLASH
- TFT LCD QVGA 3.5'' 16M color screen (320x240)

have to check if the cpu is cable of EABI. the great thing about the unit
is that it boots to a login prompt and i have to hook up a keyboard. it
might be a great candidate for an entry level android unit.

> 1) Get together a filesystem image: Either grab it yourself with tar
> from inside the emulator or unpack the ramdisk.img (gzipped cpio
> archive) and grab Benno's system.tar.gz and data.tar.gz

i have bennos system.tar.gz and data.tar.gz

where do i get the ramdisk.img? doesnt bennos images do that?

> 2) unpack that on your guinea pig ARM machine.

to the root? or to something like /android

> 3) chroot /path/to/android /system/bin/sh
> 4) export some variables:
> export PATH=/sbin:/system/sbin:/system/bin
> export LD_LIBRARY_PATH=/system/lib
> export ANDROID_ROOT=/system
> export ANDROID_ASSETS=/system/app
> export ANDROID_DATA=/data
> export EXTERNAL_STORAGE=/sdcard
> export DRM_CONTENT=/data/drm/content

i assume these should map the path to android/ - correct?

> 5) /system/bin/app_process -Xzygote /system/bin --zygote &
> 6) /system/bin/dbus-daemon --system &
> 7) runtime
>
> Make sure you have some way to access the machine other than
> through the console, because at this point you get the red cylon
> eye and are left with no way to stop it from the physical console
> except with a hard power cycle (or probably sysrq).

the uniconsys unit does nothing really, i can setup wifi proir
to attempting to start the android binaries and ssh in. but, it
would just be nice if it just worked :)

what i dont want to do is trash the file system.

> I've left it running on that eye for about half an hour now. top says
> that runtime is using no CPU time and 33% of the RAM (64MB).
> runtime does complain about not being able to access
> "/sys/android_power/acquire_partial_wake_lock". That file
> is, of course, not provided by my Zaurus' kernel. This might mean we
> need to apply some of Google's patches to a vanilla kernel or it may
> mean non-Google ARM hardware won't work without some modification to
> the Google userland stuff. Or maybe we can trick the runtime
> process. ;)

what kernel are you using on the zaurus?

> > > Aaron: I'm really curious as to how well it worked for you. I'm
> > > especially curious about how it performed on real hardware and also
> > > any stumbling blocks you ran into. :)
> >
> > i never got it running - i have not tried it yet. i was only just playing
> > around with the sdk (the java one). i have a number of devices that
>
> Aaah, I understand now. And here I was thinking I was missing
> something obvious as everyone else was playing around with this
> already. :D

:) oh.. if i get it working, i am sure a bunch of people may buy that
uniconsys device :P

> > may be capable of using this, specifically:
> >
> > - openmoko
> > - nokia n770
> > - sharp zaurus C550 (very old)
> > - a custom linux handheld (unreleased)
> >
> > if someone can figure it out correctly, i would be more than happy to
> > try it on one of my devices as well and post the results. ideally, the
> > openmoko platform would be the best to get it working on.
>
> So far it looks like the userland stuff is just compiled for EABI with
> no Armv6 specific optimizations. I have no idea about your custom
> Linux handheld, but everythong on that list should be fine except for
> the Zaurus SL-5500 (StronARM SA1100 aka Armv4)

yeah. the zuarus i have is very old.

> UPDATE: I left it at the red cylon "startup screen" for maybe 45
> minutes now. The dot stopped moving eventually, and now CPU usage is
> basically pegged at 100% by runtime. ~15% of that is system time,
> which I find interesting. It's still using the same amount of memory.

what does android depend on? x11? the uniconsys device has
a framebuffer, and a tinyx implementation. once the source is out i
am sure it will be easy to port to the uniconsys device - but, using
the current binaries may not be as nice.

Nicolas

unread,
Nov 14, 2007, 5:36:03 AM11/14/07
to Android Developers
Great! I see that much happened while I was sleeping :))

Benno, could you please make an archive of the root filesystem, not
just the /system directory? I'd like to see what happens during init.
As you guys have already managed to do it, I have the red eye running
on my Zaurus C760, but then it hangs... I'll make some tests and see
if it's possible to disable this splash screen to see what happens
under the hood.


Anyway that's great, I know at least that sooner or later, I will be
able to use my Zaurus with Android!


Nicolas.

Rajesh Sundaram

unread,
Nov 14, 2007, 10:35:02 AM11/14/07
to Android Developers
Did you come across, any part of the mobile's bootloader, kernel or
graphics' source code?
Doesn't look like the Android is really open. Does anybody think these
would
be supported so that the stuff is really open? Wont be fast enough and
wont be
causing much impact till these are supported openly.
Thanks in advance..
Rajesh.S
http://www.linkedin.com/in/rajeshsweb

On Nov 14, 7:55 am, Benno <ben.les...@gmail.com> wrote:
> I compiledbusybox(http://benno.id.au/blog/2007/11/14/android-busybox), then


> used tar to create an archive, and adb pull to get it across to the
> host. As a result it isn't exactly pristine, but close enough.
>
> On Nov 14, 10:51 am, TomCooksey <TomCook...@googlemail.com> wrote:
>
> > Well done! How did you manage to do that? I've been trying various
> > methods to try and extract the images all day!
>
> > The closet I came was to use the nandsim kernel module to try and
> > simulate a nand mtd device, copy the nandwrite the system.img to the
> > fake nand mtd device & mount it. Trouble is I had problems getting my
> > kernel to mount the yaffs2 filesystem - I believe the yaffs2 code
> > isn't 64-bit safe as I'm running a 64-bit kernel (& compiling the
> > module threw up loads of warnings about copying a pointer to an int).
>

> > I was going to try and getbusyboxcompiled up and running on the

John Bloom

unread,
Nov 14, 2007, 10:57:36 AM11/14/07
to Android Developers
On Nov 14, 7:36 pm, Nicolas <nicola...@gmail.com> wrote:
> Great! I see that much happened while I was sleeping :))
>
> Benno, could you please make an archive of the root filesystem, not
> just the /system directory? I'd like to see what happens during init.
> As you guys have already managed to do it, I have the red eye running
> on my Zaurus C760, but then it hangs... I'll make some tests and see
> if it's possible to disable this splash screen to see what happens
> under the hood.
If you ssh in and run it it spits some info out in the terminal. Also
"runtime -h" has a hint about how to make it log to a file (don't
remember the paramater off the top of my head) but it never worked for
me.

>
> Anyway that's great, I know at least that sooner or later, I will be
> able to use my Zaurus with Android!
Yup, just don't hold your breath. :)

>
> Nicolas.
>


> On Nov 14, 10:12 am, "Aaron Ardiri" <ard...@gmail.com> wrote:
>
> > On Nov 14, 2007 5:44 AM, John Bloom <joh...@gmail.com> wrote:
>
> > > > can you post instructions as to how you got this far?
>
> > > Ok, here's the quick version. Ask if you need more details:
>
> > > 0) Have an ARM device running Linux capable of executing EABI binaries
>
> > got it, the custom linux device i have is a unit from unicon systems.
> > specifically:
>
> >http://www.uniconsys.com/devkit-ucn2410-c.html

Looks nice.


>
> > i picked it up at linuxworld 2007. the specifications are:
>
> > - linux 2.6
> > - ARM9 S3C240A embedded CPU at 266 MHz
> > - 32mb SDRAM, 32mb FLASH
> > - TFT LCD QVGA 3.5'' 16M color screen (320x240)
>
> > have to check if the cpu is cable of EABI. the great thing about the unit
> > is that it boots to a login prompt and i have to hook up a keyboard. it
> > might be a great candidate for an entry level android unit.

Quick way to check: cat /proc/cpuinfo | grep architecture
I think if it's 4T or above (5TE, 6TEJ) that hardware is capable. Then
it's just a question of having a kernel with EABI support...


>
> > > 1) Get together a filesystem image: Either grab it yourself with tar
> > > from inside the emulator or unpack the ramdisk.img (gzipped cpio
> > > archive) and grab Benno's system.tar.gz and data.tar.gz
>
> > i have bennos system.tar.gz and data.tar.gz
>
> > where do i get the ramdisk.img? doesnt bennos images do that?

It comes with the SDK. /path/to/android/tools/lib/images/


>
> > > 2) unpack that on your guinea pig ARM machine.
>
> > to the root? or to something like /android

Wherever you have some space. Could even be NFS.


>
> > > 3) chroot /path/to/android /system/bin/sh
> > > 4) export some variables:
> > > export PATH=/sbin:/system/sbin:/system/bin
> > > export LD_LIBRARY_PATH=/system/lib
> > > export ANDROID_ROOT=/system
> > > export ANDROID_ASSETS=/system/app
> > > export ANDROID_DATA=/data
> > > export EXTERNAL_STORAGE=/sdcard
> > > export DRM_CONTENT=/data/drm/content
>
> > i assume these should map the path to android/ - correct?

This is after you're chroot'ed into the android fs, to reset your
environment.


>
> > > 5) /system/bin/app_process -Xzygote /system/bin --zygote &
> > > 6) /system/bin/dbus-daemon --system &
> > > 7) runtime
>
> > > Make sure you have some way to access the machine other than
> > > through the console, because at this point you get the red cylon
> > > eye and are left with no way to stop it from the physical console
> > > except with a hard power cycle (or probably sysrq).
>
> > the uniconsys unit does nothing really, i can setup wifi proir
> > to attempting to start the android binaries and ssh in. but, it
> > would just be nice if it just worked :)

We are quite a ways off from "just works." That probably won't happen
until Google gives us more source to play with or someone quite a bit
more clever than me starts hacking on this. Plus, where's the fun it
"just works"


>
> > what i dont want to do is trash the file system.

You could setup a "dead man's switch"


>
> > > I've left it running on that eye for about half an hour now. top says
> > > that runtime is using no CPU time and 33% of the RAM (64MB).
> > > runtime does complain about not being able to access
> > > "/sys/android_power/acquire_partial_wake_lock". That file
> > > is, of course, not provided by my Zaurus' kernel. This might mean we
> > > need to apply some of Google's patches to a vanilla kernel or it may
> > > mean non-Google ARM hardware won't work without some modification to
> > > the Google userland stuff. Or maybe we can trick the runtime
> > > process. ;)
>
> > what kernel are you using on the zaurus?

2.6.22 from Angstrom (www.angstrom-distribution.org)


>
> > > > > Aaron: I'm really curious as to how well it worked for you. I'm
> > > > > especially curious about how it performed on real hardware and also
> > > > > any stumbling blocks you ran into. :)
>
> > > > i never got it running - i have not tried it yet. i was only just playing
> > > > around with the sdk (the java one). i have a number of devices that
>
> > > Aaah, I understand now. And here I was thinking I was missing
> > > something obvious as everyone else was playing around with this
> > > already. :D
>
> > :) oh.. if i get it working, i am sure a bunch of people may buy that
> > uniconsys device :P

I think I'll be perfectly happy to run it on my Zaurus. :P


>
> > > > may be capable of using this, specifically:
>
> > > > - openmoko
> > > > - nokia n770
> > > > - sharp zaurus C550 (very old)
> > > > - a custom linux handheld (unreleased)
>
> > > > if someone can figure it out correctly, i would be more than happy to
> > > > try it on one of my devices as well and post the results. ideally, the
> > > > openmoko platform would be the best to get it working on.
>
> > > So far it looks like the userland stuff is just compiled for EABI with
> > > no Armv6 specific optimizations. I have no idea about your custom
> > > Linux handheld, but everythong on that list should be fine except for
> > > the Zaurus SL-5500 (StronARM SA1100 aka Armv4)
>
> > yeah. the zuarus i have is very old.
>
> > > UPDATE: I left it at the red cylon "startup screen" for maybe 45
> > > minutes now. The dot stopped moving eventually, and now CPU usage is
> > > basically pegged at 100% by runtime. ~15% of that is system time,
> > > which I find interesting. It's still using the same amount of memory.
>
> > what does android depend on? x11? the uniconsys device has
> > a framebuffer, and a tinyx implementation. once the source is out i
> > am sure it will be easy to port to the uniconsys device - but, using
> > the current binaries may not be as nice.

It runs on the framebuffer. It will probably want access to at least
the following devices:
/dev/input/mice
/dev/graphics/fb0
[probably many more]
If you want to do some research, start up the emulator, get into a
shell, and do:
1) ps (and look in its output to find the PID of system_server)
2) Now go to /proc/-pid of system_server-/fd
3) ls
You'll see all the files system_server is holding open, so it should
give you a better idea of what it requires to run. I need to catch
some sleep now. Hopefully I'll find incredible progress when I wake
up. :D

>
> > --
> > // Aaron Ardiri
> > Mobile Wizardryhttp://www.mobilewizardry.com/

-John

John Bloom

unread,
Nov 14, 2007, 11:04:49 AM11/14/07
to Android Developers
This page might answer some of your questions:
http://code.google.com/android/kb/licensingandoss.html
It does take time to clean up source code for release so I can
understand why they haven't released that much source yet.

On Nov 15, 12:35 am, Rajesh Sundaram <rajeshs...@gmail.com> wrote:
> Did you come across, any part of the mobile's bootloader, kernel or
> graphics' source code?
> Doesn't look like the Android is really open. Does anybody think these
> would
> be supported so that the stuff is really open? Wont be fast enough and
> wont be
> causing much impact till these are supported openly.
> Thanks in advance..

> Rajesh.Shttp://www.linkedin.com/in/rajeshsweb

AdrianC

unread,
Nov 14, 2007, 11:18:07 AM11/14/07
to Android Developers
I'm interested in getting Android running on my Gumstix verdex (PXA270
with 128MB RAM and 4.3" touchscreen LCD) so that when Gumstix finally
ships their Goliath homebrew phone motherboard we can figure out the
device drivers needed to get Android running with the GSM, GPS,
accelerometers etc.

There is a Bay Area meeting of the Homebrew Mobile Phone club this
evening at Mozilla HQ (discussion of mobile Mozilla, and eclipse based
setup for the Gumstix Linux 2.6 buildroot are on the agenda). See
http://www.hbmobile.org/wiki for details.

Adrian

mviswan1

unread,
Nov 14, 2007, 12:07:06 PM11/14/07
to Android Developers
The application apk files under system\app can be renamed to .zip
files and can be extracted. The only issue is the class is in
bytecodes(dex format). So no further luck. But it does give you access
to resources and layouts of the apps...

Benno

unread,
Nov 14, 2007, 3:51:23 PM11/14/07
to Android Developers
There is no bootloader for this system. Qemu directly loads the kernel
into memory, so there is no need.

The kernel source is available from Google's website.

I don't believe they have opened the graphics source code yet, but
they have indicated their intent to do so.

In any case, I'm not sure why you would expect the source code to be
on the actual filesystem of the running platform.

On Nov 15, 2:35 am, Rajesh Sundaram <rajeshs...@gmail.com> wrote:
> Did you come across, any part of the mobile's bootloader, kernel or
> graphics' source code?
> Doesn't look like the Android is really open. Does anybody think these
> would
> be supported so that the stuff is really open? Wont be fast enough and
> wont be
> causing much impact till these are supported openly.
> Thanks in advance..

> Rajesh.Shttp://www.linkedin.com/in/rajeshsweb

zhao liang

unread,
Nov 21, 2007, 1:18:22 AM11/21/07
to Android Developers
I have a marvell pxa3xx evb-board, and kernel 2.6.14 running on it,
which should be EABI compliance.
And I've tried the instructions that you posted before, and then I got
"Illegal instruction" exception when running "runtime".
I did strace with runtime and found runtime is killed by SIGILL. :(

I can't get any log information from "runtime -l log.txt". It seems it
does not work at all.

It seems that we can't go on until:
1). have google's source code to find out the low level dependency.
2). port some drivers to my current kernel to meet android's
dependency.

Thanks,
Zhao Liang
> -John- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Aaron P. D'Souza

unread,
Nov 24, 2007, 2:48:27 AM11/24/07
to Android Developers
hello:

i wonder if this is helpful.

On Nov 14, 9:44 am, John Bloom <joh...@gmail.com> wrote:
> UPDATE: I left it at the red cylon "startup screen" for maybe 45
> minutes now. The dot stopped moving eventually, and now CPU usage is
> basically pegged at 100% by runtime. ~15% of that is system time,
> which I find interesting. It's still using the same amount of memory.

README - Poky images with QEMU
http://svn.o-hand.com/view/*checkout*/poky/trunk/scripts/poky-qemu.README?rev=2020
[...]
Known Issues
============

- There is a bug in the ARM qemu in that means occasionally it will
use 100%
cpu. You will need to restart it in this situation.
[....]

Gergely Kis

unread,
Nov 29, 2007, 6:30:51 AM11/29/07
to Android Developers
Hello,
I tried your instructions on a SL-C760, but it does not get through to
the cylon screen.
1. I compiled an Angstrom console-image
2. I compiled a patched Angstrom kernel. Took the big patch from
Benno's site, removed only some goldfish specific patches.
Binder + Android power management were compiled in, but the USB gadget
support was switched off.

3. Created an image with the Angstrom console image + the Android
files in /android
The /android/dev included the devices from the emulator + I had to
change the binder major number because it got a different major
assigned in my kernel.
4. Created a shell script with the above contents + mount commands for
proc and sysfs under /android and launched it using "chroot /android /
a.sh"
Unfortunately it only prints "post-zygote" and does not switch to the
cylon screen. I also tried to execute the Android init, but it
segfaults after reading the config files.

Did anyone have more success with a Zaurus? Care to share the
installkit? (kernel + rootfs image)?

Thank you,
Gergely
Reply all
Reply to author
Forward
0 new messages