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;

I have extracted these from a running system. See:

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

Cheers,

Ben

On Nov 14, 9:23 am, Nicolas <nicola...@gmail.com> wrote:

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.

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

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.

On Nov 14, 10:51 am, TomCooksey <TomCook...@googlemail.com> wrote:

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?

On Nov 14, 2007 12:57 AM, TomCooksey <TomCook...@googlemail.com> wrote:

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

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
Features        : swp half thumb fastmult vfp edsp java

On Nov 14, 2007 4:42 AM, John Bloom <joh...@gmail.com> wrote:

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

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.

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

On Nov 14, 12:51 pm, "Aaron Ardiri" <ard...@gmail.com> wrote:
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. ;)

Aaah, I understand now. And here I was thinking I was missing
something obvious as everyone else was playing around with this
already. :D
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)

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

On Nov 14, 2007 5:44 AM, John Bloom <joh...@gmail.com> wrote:

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.

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

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

to the root? or to something like /android

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

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.

what kernel are you using on the zaurus?

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

yeah. the zuarus i have is very old.

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.

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