Porting Android to AVR32 platform

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

First thing: Great board!
Second: Has anyone already started thinking about a port of googles android? Since the source code is already released it should be doable. But how hard will it be? The first and only thing I have done so far is, to check through the kernel diff (http://benno.id.au/android/andro...). You can forget qemu and goldfish(simulator), (maybe yaffs2 too?) The rest like the "binder", could cause problems while porting the kernel. Do you think this is managable?
Second step would be to port de Dalvik VM, at the moment i can't take a look at the source code, but maybe anybody of you knows how much the source is optimized for ARMs.
Anybody interestet in such a project? Any ideas?

Greets
Michael

@sorry for this stuttering english :( I'm not the best in writing ;) but i think its readable

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

double post

Last Edited: Wed. Jan 14, 2009 - 07:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again,

Just for info.
I've looked over the code, created a patch and applied it two the buildroot-kernel.
Till now, i found to problems:
one with pmem. The arm code makes use of the dmac unit and provides specific codes like dmac_flush_cache. At the moment, i don't know what it realy does and maybe we could reuse the code from atmel and work with defines. For a booting android it seems to be unnecessary at the moment.
Second thing was a problem with the android alarm timer. At the first look, it serves ticks to the system. It needs the /arch/[mach]/include/timer.h (or something like that) The arm directories have this file, our avr32 not,only as_time. Maybe its possible to reuse it with defines.
I first tried to compile and it worked with disabling android_alarm and pmem.
Maybe I forgot to check something in menuconfig, or everything else is generic code and works (yaffs2 and binder (and much more) for example are compilling)
More infos maybe this night ;)

Michael

Last Edited: Wed. Jan 14, 2009 - 07:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure it's manageable. I don't know how much effort it would take but the Android dev's already have a reputation for writing poor, unmaintainable code which will take a hell of a lot of work before it's acceptable to the kernel community at large - if Google ever even tries to work with them. As you may have gathered, I'm not a fan of the Android team..

Android's also all (legally) packaged up in to one lump which means the Dalvik VM can't be used separately. A pity because that's one bit I quite like.

YAFFS2 is not platform dependent - it will work on AVR32. The question is more whether you want it. LogFS and UBIFS are in many ways superior and headed for the mainline kernel where they will live happily and securely for a long time.

Your english was fine :-). If you want to have a crack at it good luck to you but IMHO it's not a nice place to be.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was very suprised that I got a 11k lines diff. So it seems you are right. I don't know much about maintable code, but 11k in such an open source release seemed a little bit to much for me. But as far as I know, the team is working on a second release with "all" the code in it which goes into the mainline then. So we can hope ;)
YAFFS2 is needed, because the garbage-collecter makes use of special features (*from android-porting-group).
Why do you think we can't use Dalvik alone? All we need are the "core" packages. Dalvik isn't very ARM specific, just a few includes and for those, there are (slow) generic ones.
As you can see, I'm very impressed by the Android project. I like the idea behind.
I will give it a try.
We'll see how far i will get ;)
Michael

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bubi_00 wrote:
I was very suprised that I got a 11k lines diff. So it seems you are right. I don't know much about maintable code, but 11k in such an open source release seemed a little bit to much for me. But as far as I know, the team is working on a second release with "all" the code in it which goes into the mainline then. So we can hope ;)
Well a lot of their drivers have hit the mainline Staging directory so indeed there is hope. But they've done things like inventing their own power control framework from the ground up rather than fixing the Linux ones. And no, their new one isn't usable in the general case. Grr.
Quote:

YAFFS2 is needed, because the garbage-collecter makes use of special features (*from android-porting-group).
Exactly my point. Rather than improving the performance for all (or using a better filesystem) they make a stack of changes which, despite being open source, only benefit themselves. It seems to me that they obey the letter of the license (arguably) but they just have no community spirit.
Quote:
Why do you think we can't use Dalvik alone? All we need are the "core" packages. Dalvik isn't very ARM specific, just a few includes and for those, there are (slow) generic ones.
Last I checked, Android was distributed under a license which didn't allow the stack from being split. You could either run the whole Android stack or none. They did this to avoid fragmentation like has happened in the mobile Java scene.
Quote:
As you can see, I'm very impressed by the Android project. I like the idea behind.
Their goals are fine, my problem is entirely in how they've carried it all out. Call me an idealist :-)

That said, I of course wish you the best of luck with the port and don't hesitate to ask for any help here :-)

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was looking at Stellaris and
Android and it was pointed out that Android requires a MMU for virtual memory management. If AVR32 does not have that then it is a non starter.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The AP700X devices have a MMU, hence this Android-discussion.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FWIW, I've got one of the new Dell Streak tablets which uses Android running on a 1 GHz Snapdragon (ARM) CPU. I've been quite impressed by it.

Leon Heller G1HSM