On Wednesday, 14 September 2011 05:03:53 UTC+2, lakehousetech wrote:
>
> I tried both suggestions (with the exception of recompiling the kernel) to
> no avail. I'm going to try to increase the buffer size and recompile the
> kernel, and press on. Here's a snippet from my last_kmsg where the failure
> occurs (perhaps someone can shed some light?):
>
> [ 7.353576] init: command 'write' r=0
> [ 7.357039] init: waitpid returned pid 68, status = 0000000b
> [ 7.357078] init: process 'logcat', pid 68 exited
> [ 7.357199] init: waitpid returned pid 69, status = 0000000b
> [ 7.357229] init: process 'servicemanager', pid 69 exited
>
> I was having similar problems with a Linaro ICS root file system and a
kernel.org 3.7rc7 kernel but the same android filesystem worked fine with a
Linaro 3.1 kernel.
I also have a Debian root file system which worked fine with both
filesystems.
The problem turned out to be that the kernel was configured with a 2G / 2G
memory split. Rebuilding with 3G / 1G (CONFIG_VMSPLIG_3G) fixed everything.
It appears that 2G /2G is the default for some ARM builds using the
upstream defconfigs:
$ grep VMSPLIT arch/arm/configs/*
arch/arm/configs/imx_v6_v7_defconfig:CONFIG_VMSPLIT_2G=y
arch/arm/configs/s5pv210_defconfig:CONFIG_VMSPLIT_2G=y
arch/arm/configs/socfpga_defconfig:CONFIG_VMSPLIT_2G=y
arch/arm/configs/vexpress_defconfig:CONFIG_VMSPLIT_2G=y
To debug this I built two android hello world programs, one dynamically
linked and the other statically linked and tried running them under Debian
(it's easier with a working system...)
Initially the static binary worked fine (as does the android init program)
but the dynamic one failed with a file not found (ENOENT) from execve (as
seen by strace).
This was strange since this was not the same behaviour as under android
(where the program started but segfaulted immediately).
Digging around the kernel and sprinkling a few printk()s in fs/binfmt_elf.c
showed that it was failing to find the elf interpreter /system/bin/linker
(this is the binary that handles the shared library loading) and is loaded
directly by the kernel so does not show up in strace.
Copying this file (with the same path) from the android root fs gave a
segfault as in the android case.
A few more printk()s showed that the segfault was being forced by the
kernel since /system/bin/linker has a high load address:
$ arm-linux-androideabi-objdump -x system/bin/linker
system/bin/linker: file format elf32-littlearm
system/bin/linker
architecture: arm, flags 0x00000102:
EXEC_P, D_PAGED
start address 0xb0001000
Program Header:
LOAD off 0x000000d4 vaddr 0x00000000 paddr 0xb0000000 align 2**12
filesz 0x00000000 memsz 0x00000000 flags r--
LOAD off 0x00001000 vaddr 0xb0001000 paddr 0xb0001000 align 2**12
filesz 0x00007e1c memsz 0x00007e1c flags r-x
LOAD off 0x00009000 vaddr 0xb0009000 paddr 0xb0009000 align 2**12
filesz 0x00000738 memsz 0x0000b57c flags rw-
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**0
filesz 0x00000000 memsz 0x00000000 flags rw-
0x70000001 off 0x00008b1c vaddr 0xb0008b1c paddr 0xb0008b1c align 2**2
filesz 0x00000300 memsz 0x00000300 flags r--
private flags = 5000000: [Version5 EABI]
However with a 2G / 2G memory split 0xB0001000 is not accessible to user
space.
Hope this helps anyone else having this type of problem.
Regards,
Martin
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
