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..
On Nov 30, 11:03 am, lqoyzy <[EMAIL PROTECTED]> wrote:
> 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?
>
> On Nov 29, 3:45 pm, Sean McNeil <[EMAIL PROTECTED]> wrote:
>
> > 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 wrote:
> > > 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~
>
> > > On Nov 2, 7:33 pm, "Ben Leslie" <[EMAIL PROTECTED]> wrote:
>
> > >> 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
> > >> 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
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
