ARMv4, different file systems, and other patches.

64 views
Skip to first unread message

Ben Leslie

unread,
Nov 2, 2008, 6:33:35 AM11/2/08
to android...@googlegroups.com
I haven't had time to clean up my patches sufficently to submit them
for formal review, but I'm going away for two weeks tomorrow, and I
don't want people unnecessarily re-inventing the wheel (although Sean
and I seem to have gone and invented two wheels in parallel anyway).

I've been using two separate trees, one to try things on and get them
up and running, and a separate integration tree for submitting things
on. These patches come straight from the former, and hence won't apply
100% cleanly, but it should be relatively obvious what the changes
are (mostly adding ARCH_ARM_ to the front of HAVE_<x> variables).

The diffs are per project and in most cases should be split into
multiple separate diffs before committing.


The main other thing that patch addresses other than ARMv4 support is
using filesystems other than yaffs2, and support for frame-buffer
devices that don't support panning.

The rest of this just describes the patches in detail. Note, although
getting this running on the Neo 1973 was the ultimate driver for
this, most of these patches are really aimed to get Android compiling for
plain ARMv4 (_not_ ARMv4T). This is _not_ the best approach of running
Android on an actual OpenMoko phone, but hey there are still devices
with StrongARM chips out there too.

Note: I am off the air for the next two weeks, and don't plan on submitting
these for review until I get back from holiday. I'm hoping that someone (looks
like Sean), is going to be pushing through with ARMv4T support in the meantime,
so most of this will probably addressed one way or another by the time I'm
back.

If any of it is still relevant once I'm back I'll clean it up for
submissions then.

system/core:

libcutils/{atomic-android-arm.S,memset32.S}:

* Use BX<cc> macro rather than directly using bx<cc> instructions.
(see change 1663 for definition of BX<cc> macros).

libpixelflinger/Android.mk:

* Only compile t32cbblend.S when halfword multiplies are available.
* (Note: this actual check could be cleaned up).

libpixelflinger/scanline.cpp:

* Disable codegeneration on ARMv4

rootdir/Android.mk:
rootdir/gen_initrc.py:
rootdir/init.rc:

* Use a script to generate init.rc to allow different file systems
to be specified. (see other changes in the build project).

frameworks/base

servicemanager/{service_manager.c,binder.c}:

* Provide better debugger in error cases.

audioflinger/AudioMixer.cpp

* Conditionalise use of halfword multiple instructions.


libs/ui/EGLDisplaySurface.cpp

* Provide swapBuffers() implementation for case when PAGE_FLIP is
not supported. This is probably not the right way to do this.

opengl/libGLES_CM/gl_wrapper.cpp

* Handle return correctly for non-thumb targets.

opengl/libagl/fixed_asm.S

* Use macros for BX<cc>

dalvik:

Android.mk

* Revert to using C version of interpreter if 64bit data instructions
are not available. Sean's more comprehensive patches to change the
asm are probably better here once they are cleaned up. But this
does work for now

vm/alloc/clz.{ch}:

* Avoid using builtin clz if clz instruction is not available. Yet to determine
exactly why this should be necessary.

vm/arch/arm/CallEABI.S:

* This patch works but is hacky. The important thing for this file is that if
HAVE_THUMB is not defined, or HAVE_FASTINTERWORKING is defined, then using
'bx' is not needed and values can safely be loaded directly into
pc. Of course
on ARMv4T where you have THUMB, but no FASTINTERWORKING, more
extensive changes
are required, see Sean's patches.

build:

core/{Makefile,config.mk}:

* Add support for using different filesystems for system and user, as
well as support
for yaffs (not yaffs2) and jffs2. Rationale is: jffs2 is better
compression and can
work well for ro /system. yaffs works on NAND with 512 byte pages (as
opposed to yaffs2
for 2k pages). For NAND constrained devices you end up needing both
filesystems.

core/prelink-linux-arm.map:

* Very small change to layout which seems to work for both ARMv4 and ARMv5.


bionic:

libc/Android.mk,libc/string/ffs.c:

* Nasty hack for ffs() implementation. Note: the whole subject of gcc builtins
should be better addressed. I think Sean has an assembler implementation of
ffs().

strlen,memcpy,memset:

* Use PLD() macro to avoid unknown instruction on ARMv4.

gensyscalls.py:

* Updated to use BX<cc> macro

everything else:

* Regeneration of syscalls.

(Due to regenerating all syscalls this patch is quite large, hence it
is gzipped before attaching).

external/yaffs2:

* Add support for generating yaffs as well as yaffs2 images.

external/sonivox:

* Only compile optimised ASM if half word multiply is available.

external/skia:

* Conditionalise use of __built_clz, and halfword multiple optimisations.

external/opencore:

* Conditionalise compilation based on having halfword multiply and
clz instructions as necessary.

external/jpeg:

* Conditionalise jpeg optimisation based on having halfword multiplies.

* Only use prefetch-loop-arrays when PLD instruction exists. This is
not a great approach here, I think Marcello's is probably better.

external/extras:

* Use BX<cc> macros.

build.diff
system-core.diff
bionic.diff.gz
dalvik.diff
external-extras.diff
external-jpeg.diff
external-opencore.diff
external-skia.diff
external-sonivox.diff
external-yaffs2.diff
frameworks-base.diff

lqoyzy

unread,
Nov 29, 2008, 2:24:43 AM11/29/08
to android-porting
Hi Ben,

I'm trying to port android to a s3c2410 develop board..which's only
64m ram..
now I've successfully built out armv4t images with your submitted
patch and sean's patches under reviewing.
but I'm getting servicemanager exiting problem while using nfs as
rootfs.
I'm doubting it's the binder who cannot be inited.. likely you've met
the same problem, as in your patch that add some log for this.
what's the problem it is? about mmap? or is there some option to
enable the nfs support this? or 64m limits this?
I've checked the /dev/binder & /dev/ashmen, both are 777.
looking forward for your replay :-), thanks!
I've no usb cable now..and don't know how to make adb to use a
usb2serial cable..so some help on this is also very nice~
>  build.diff
> 5KViewDownload
>
>  dalvik.diff
> 3KViewDownload
>
>  external-extras.diff
> 1KViewDownload
>
>  external-jpeg.diff
> 1KViewDownload
>
>  external-opencore.diff
> 3KViewDownload
>
>  external-skia.diff
> 1KViewDownload
>
>  external-sonivox.diff
> < 1KViewDownload
>
>  external-yaffs2.diff
> 1KViewDownload
>
>  frameworks-base.diff
> 8KViewDownload
>
>  system-core.diff
> 8KViewDownload
>
>  bionic.diff.gz
> 16KViewDownload

Sean McNeil

unread,
Nov 29, 2008, 2:45:14 AM11/29/08
to android...@googlegroups.com
What version of the kernel are you using? Newer versions of the linux
kernel will pass VM_EXEC on mmap which will cause the binder to fail.
You might need to fix the binder so that it is no longer a
FORBIDDEN_MMAP_FLAGS.

lqoyzy

unread,
Nov 29, 2008, 10:03:40 PM11/29/08
to android-porting
I've changed this flag and the problem still there..
I'm directly using android's official kernel with s3c2410_decconfig,
only changed some option and merged some bsp drivers for it..
I wonna get adb to use my usb2serial cable to connect, any advice for
that?

lqoyzy

unread,
Dec 1, 2008, 12:21:05 PM12/1/08
to android-porting
switch to ben's patches in this topic and his change 1663, finally get
android running on my 2410 board..:-)
still need to merge so many drivers like touchpanel, etc..
I've no idea about the speed android running on 2410 now, maybe in
future I can do some optimization job on this~
as I wanna android run smoothly on cheap platforms, as a common
software platform for some special devices..not only for phones..
Reply all
Reply to author
Forward
0 new messages