Android already works on neo Freerunner
Sean McNeil
Please stop submitting patches to google for this armv4 stuff. I have
already everything in place and Android is fully functional on
Freerunner. Now I find that someone has submitted a very messy patch
to support armv4 in linux-arm.mk. There is a much cleaner and minimal
change that works much better.
As soon as I have a place to put a roosfs image, I'll post where to
find it so you too can run Android on your Freerunner. The best thing
anyone can work on is a virtual keyboard. Right now there is no way to
send text messages or add contacts because there is no keyboard.
Cheers,
Sean
Brian Swetland
What's your objection to the build system changes featurizing things
for arm builds?
We'd prefer to have #if ARCH_ARM_HAVE_PLD to #ifndef __ARM_ARCH_4__
for example.
http://r.android.com/1661 was the result of discussion with our build
system lead and Ben Leslie on the list and in patches, and we'd rather
fix it if it has issues than just revert it.
http://r.android.com/1663 is the second piece of that, which we should
pick up as well.
Most of the changes you submitted to, if adjusted for the above, look
good. There are a few cases of single changes that could stand to be
broken into a couple pieces, like: http://r.android.com/1684 which
makes the pixelflinger armv4-friendly, and tweaks a few other things.
Having it split into a couple changes with descriptions of each piece
simplifies review and allows obvious and/or easy-to-verify changes to
be picked up quickly (the init/devices.c change to use subsystem instead
of path looks like a really simple, good fix, for example).
Some of the changes do look like they'll potentially break the existing
emulator or dream targets, so we'll have to figure out how to avoid
that. (moving init to sbin, for example)
Brian
Ben Leslie
Mmm, it looks a lot like Sean and I have been doing pretty similar
changes. I've got Android booting on the older Neo 1973.
I'm going on holiday tomorrow, so I'm more than happy for him to take
the lead on these patches.
I'll try and clean up the rest of my patches, and simply post them to
the mailing list and if people are interested they can pick them up.
In the mean time, I'll comment on Sean's patches, since they seem
pretty similar to what I did.
Cheers,
Benno
Sean McNeil
Brian Swetland wrote:
> [Sean McNeil <seanm...@gmail.com>]
>
>> Hi folks!
>>
>> Please stop submitting patches to google for this armv4 stuff. I have
>> already everything in place and Android is fully functional on
>> Freerunner. Now I find that someone has submitted a very messy patch
>> to support armv4 in linux-arm.mk. There is a much cleaner and minimal
>> change that works much better.
>>
>> As soon as I have a place to put a roosfs image, I'll post where to
>> find it so you too can run Android on your Freerunner. The best thing
>> anyone can work on is a virtual keyboard. Right now there is no way to
>> send text messages or add contacts because there is no keyboard.
>>
>
> What's your objection to the build system changes featurizing things
> for arm builds?
>
I don't have any objections, it is just that it seems like that file is
getting a little over-complicated. If we could just have an architecture
CFLAGS that can be overridden, then it makes things much cleaner and
nothing prevents additional tweaks from being made for a particular
platform.
> We'd prefer to have #if ARCH_ARM_HAVE_PLD to #ifndef __ARM_ARCH_4__
> for example.
>
Having PLD or not is very specific to an architecture. Same with some of
the other DSP instructions. Will we have corresponding defines for
SMLAxx and SMULxx? CLZ? It's OK with me whichever mechanism you want to
use. Just didn't want to clutter things up.
> http://r.android.com/1661 was the result of discussion with our build
> system lead and Ben Leslie on the list and in patches, and we'd rather
> fix it if it has issues than just revert it.
> http://r.android.com/1663 is the second piece of that, which we should
> pick up as well.
>
I'll try to keep on top of it so I can work it into my effort.
> Most of the changes you submitted to, if adjusted for the above, look
> good. There are a few cases of single changes that could stand to be
> broken into a couple pieces, like: http://r.android.com/1684 which
> makes the pixelflinger armv4-friendly, and tweaks a few other things.
>
> Having it split into a couple changes with descriptions of each piece
> simplifies review and allows obvious and/or easy-to-verify changes to
> be picked up quickly (the init/devices.c change to use subsystem instead
> of path looks like a really simple, good fix, for example).
>
> Some of the changes do look like they'll potentially break the existing
> emulator or dream targets, so we'll have to figure out how to avoid
> that. (moving init to sbin, for example)
>
Ah, I forgot that was in there. I'm not certain why init wasn't placed
in the standard /sbin location in the first place. A typical kernel
doesn't look in / for init if I'm not mistaken.
> Brian
>
> >
>
Ben Leslie
>
> Hi Brian,
>
> Brian Swetland wrote:
>> [Sean McNeil <seanm...@gmail.com>]
>>
>>> Hi folks!
>>>
>>> Please stop submitting patches to google for this armv4 stuff. I have
>>> already everything in place and Android is fully functional on
>>> Freerunner. Now I find that someone has submitted a very messy patch
>>> to support armv4 in linux-arm.mk. There is a much cleaner and minimal
>>> change that works much better.
>>>
>>> As soon as I have a place to put a roosfs image, I'll post where to
>>> find it so you too can run Android on your Freerunner. The best thing
>>> anyone can work on is a virtual keyboard. Right now there is no way to
>>> send text messages or add contacts because there is no keyboard.
>>>
>>
>> What's your objection to the build system changes featurizing things
>> for arm builds?
>>
>
> I don't have any objections, it is just that it seems like that file is
> getting a little over-complicated. If we could just have an architecture
> CFLAGS that can be overridden, then it makes things much cleaner and
> nothing prevents additional tweaks from being made for a particular
> platform.
My main motivation with this approach was that there are going to be
many specific boards with a given architecture, and duplicating the
cflags in each would not be great. Of course, I have no problem with
making it so that it can be overridden.
>> We'd prefer to have #if ARCH_ARM_HAVE_PLD to #ifndef __ARM_ARCH_4__
>> for example.
>>
>
> Having PLD or not is very specific to an architecture. Same with some of
> the other DSP instructions. Will we have corresponding defines for
> SMLAxx and SMULxx? CLZ? It's OK with me whichever mechanism you want to
> use. Just didn't want to clutter things up.
That is the approach that was discussed on the list, hence my patch.
Cheers,
Benno
Brian Swetland
> >
> > What's your objection to the build system changes featurizing things
> > for arm builds?
>
> I don't have any objections, it is just that it seems like that file is
> getting a little over-complicated. If we could just have an architecture
> CFLAGS that can be overridden, then it makes things much cleaner and
> nothing prevents additional tweaks from being made for a particular
> platform.
There was discussion of splitting it into subfiles, and/or allowing a
target or architecture to volunteer its own file. We may want to do
some further build system changes here to make something like that work.
I'll bow to Dave's preference on this (he owns the build system).
> > We'd prefer to have #if ARCH_ARM_HAVE_PLD to #ifndef __ARM_ARCH_4__
> > for example.
>
> Having PLD or not is very specific to an architecture. Same with some of
> the other DSP instructions. Will we have corresponding defines for
> SMLAxx and SMULxx? CLZ? It's OK with me whichever mechanism you want to
> use. Just didn't want to clutter things up.
This doesn't necessarily have to be per-instruction, but (and I may be
wrong here) I thought that the presence/absence of some instructions/
features were not as simple as "in all ARM > 4" or "in all ARM != 4".
> > Some of the changes do look like they'll potentially break the existing
> > emulator or dream targets, so we'll have to figure out how to avoid
> > that. (moving init to sbin, for example)
>
> Ah, I forgot that was in there. I'm not certain why init wasn't placed
> in the standard /sbin location in the first place. A typical kernel
> doesn't look in / for init if I'm not mistaken.
It does look for one in / on initrd -- which is what the root filesystem
becomes for us. The kernel does look for a couple different possible
things to start as process 1, so it may be we've latched on to an older
or unusual option here. If sbin/init in initrd works and it also makes
it easier for other platforms, I wouldn't be opposed to changing that.
Brian
Ben Leslie
FWIW, picture of Android running on Neo 1973 here:
http://benno.id.au/blog/2008/11/02/android-on-neo1973
I'll try and clean up my patches and submit before I get on the plane
in the morning. I'll leave it up to the group to decide which ones are
worth using and which are not, as I won't be in a position to refine
them for two weeks.
Cheers,
Benno
Anonymous
publish your work to stop people from doing the same thing. Nobody
knows how to build an image, nobody knows even your complete patch
set. When you search a place to upload to, use a 1-click-filehoster
like rapidshare.com or uploaded.to.
Levy "Lewis" S.
On Nov 1, 11:15 pm, Sean McNeil <seanmcne...@gmail.com> wrote:
> Hi folks!
>
> Please stop submitting patches to google for this armv4 stuff. I have
> already everything in place and Android is fully functional on
> Freerunner.
how can I run Android on my GTA02?
Thanks,
Levy "Lewis" S.
Gergely Kis
Sean released his first patches on the 23rd, however only on the
OpenMoko lists. So I think he is well aware of what "release early -
release often" means.
From my point of view Sean and Ben provided all the necessary
information to reproduce the success:
- toolchain configuration
- source code patches
- kernel hints
Do not expect step by step tutorials for end users at this point.
About Sean's first reaction regarding the armv4 patches, I can
understand him, because in my opinion as well there is no use case for
supporting armv4. All cores that can run Android at a reasonable speed
will support at least armv4t. However, I do think that the feature
based differentiation of the architectures is the right way to go, and
that the already merged patches provide a good first start for that.
Best Regards,
Gergely
Sean McNeil
intense and I've got a lot of cleanup to do before things are in
acceptable shape. In the meantime I'll have binary forms available in
very short order. Just awaiting a password before I can put it up.
Piethein Strengholt
http://review.source.android.com/user/sean,,mcneil.com
I hope you can sort it out with cleaning up your patches. If you need
storage for uploading your images please let me know! I can help!
Regards,
Piethein
On Nov 3, 9:49 am, Sean McNeil <seanmcne...@gmail.com> wrote:
> I'm working to get my changes submitted. The review process is quite
> intense and I've got a lot of cleanup to do before things are in
> acceptable shape. In the meantime I'll have binary forms available in
> very short order. Just awaiting a password before I can put it up.
>
> Gergely Kis wrote:
> > Hi,
>
> > Sean released his first patches on the 23rd, however only on the
> > OpenMoko lists. So I think he is well aware of what "release early -
> > release often" means.
>
> > From my point of view Sean and Ben provided all the necessary
> > information to reproduce the success:
> > - toolchain configuration
> > - source code patches
> > - kernel hints
>
> > Do not expect step by step tutorials for end users at this point.
>
> > About Sean's first reaction regarding the armv4 patches, I can
> > understand him, because in my opinion as well there is no use case for
> > supporting armv4. All cores that can run Android at a reasonable speed
> > will support at least armv4t. However, I do think that the feature
> > based differentiation of the architectures is the right way to go, and
> > that the already merged patches provide a good first start for that.
>
> > Best Regards,
> > Gergely
>
natr0x
you!
regards,
Daniel
On 3 Nov., 11:57, Piethein Strengholt <pietheinstrengh...@gmail.com>
wrote: