So titled because my problem is very similar in symptoms to the thread
"Problem porting Android to OMAP". My port to the iPhone runs Debian
and X.org with the multitouch screen, sound, WLAN and USB gadget ether
net working fine. In order to maintain dual-boot capability, I put the
Android images on one of the iPhone's partitions (which is HFS+ on top
of Samsung's Whimory FTL on top of a few NAND chips) and I'm planning
on booting Android from that. I built the images from a checkout with
repo using the generic instructions from http://pdk.android.com. I set
TARGET_USERIMAGES_USE_EXT2 in the environment so I get ext2 images. I
created a 1 MB ext2 image to store the ramdisk files instead of using
it as an actual initramfs. I modified the /init.rc to comment out the
mtd mounts, since my code will be mounting /system, /data and /cache
before Android's init is called.

Android's /init doesn't seem to care if it's PID 1 (I've observed from
reading this mailing list), so I've been calling it from my
busybox/buildroot ramdisk. However, it doesn't seem to work. After
awhile, it will complain "init: critical process 'servicemanager'
exited 4 times in 4 minutes" and will reboot. I commented out the
"critical" specification for the servicemanager service in init.rc and
ran /init under strace. You can see all the logs that resulted as well
as the exact commands I performed here:
http://iphwn.org/planetbeing/postmortem/

kernel-config.txt is my kernel configuration, in case there is some
option I forgot to enable or some option I must not enable. My patches
to kernel/common android-2.6.32 (done on commit
e27f17b5318851395a66cbaf1524ea89ff8f0cb9) is also present in that
directory if those are helpful. Finally, here's what df shows:

# df
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 9.2M      8.1M      1.0M  89% /
tmpfs                    60.8M     96.0K     60.7M   0% /tmp
/dev/nand0p2             14.4G      1.4G     13.0G  10% /mnt
/dev/loop0             1003.0K    278.0K    674.0K  29% /android
/dev/loop1               72.1M     52.2M     20.0M  72% /android/system
/dev/loop2              193.7M     14.8M    168.9M   8% /android/data
/dev/loop3               48.4M    810.0K     45.1M   2% /android/cache

I think that's enough space for Android. /dev/loop0 is ramdisk.img.

>From my analysis of the strace files, it seems as if servicemanager is
being sent SIGKILL by an unknown murderer soon after it starts
(http://iphwn.org/planetbeing/postmortem/strace.486.txt). None of
Android's init or its children seem to be to blame from the strace
outputs. Android's init DOES send a SIGKILL to servicemanager but only
after it receives a notification that it has already died. There's no
kernel messages (http://iphwn.org/planetbeing/postmortem/messages.txt)
that indicate that some OOM killer is at work (unless Android's
LOW_MEMORY_KILLER is utterly silent). I certainly did not kill the
process myself.

Ignore the stuff in messages.txt about the multitouch firmware
requests. I didn't bother to send the firmware for that test but it
doesn't make a difference if I load the firmware before running
Android's init.

I don't own an Android-capable phone so I can't even test whether the
images produced by my build are sane at all. Anyone have any hints
about what could be happening? Is there an alternate track I should be
following?


Thanks,

David

-- 
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting

Reply via email to