ARMv4 (as opposed to ARMv4T) support
Ben Leslie
Looking for some feedback here.
I have support for ARMv4 in my tree right now, which is mainly because
the current compiler doesn't do interworking properly. There are some
chips, (StrongARM based) that are ARMv4 (as opposed to ARMv4T).
Is it worth putting support for ARMv4 (and ARMv4T) in the tree?
If so, I'll put forward the patches I have now. Obviously people with
an ARM920T should use ARMv4T and a fixed up compiler.
Cheers,
Benno
Brian Swetland
It does look like ARMv4 (vs ARMv4T) is going to be more work. It really
depends if somebody with a v4 target is willing/interested to make it
happen. We sort of expected V5T would be the baseline for the platform,
but V4T doesn't look like a big stretch (based on the work you and Sean
have done).
Brian
Sean McNeil
What compiler are you using? The best baseline that works for me is:
binutils 2.18
gcc-4.2.4 + gcc41-java-arm4.patch
I've had problems with the gcc 4.3 compilers.
If you don't have Thumb support, though, you can't be using
interworking. gcc-4.2.4 works just fine with thumb/arm interworking on
arm4t.
> Cheers,
>
> Benno
>
> >
>
Ben Leslie
Currently I am running completely in ARMv4 mode, and I think it is
pretty clean. (Mostly it is using the BX<cc>() macros that I put
forward in my recent proposed patch).
If people are happy to have these type of patches in the source code
I'm happy to make them clean and contribute them.
For me the main advantage is that I can use an ARMv4 compiler, since
(at least some versions of) gcc don't 100% support interworking.
Cheers,
Benno
Ben Leslie
>
> Ben Leslie wrote:
>> Hi all,
>>
>> Looking for some feedback here.
>>
>> I have support for ARMv4 in my tree right now, which is mainly because
>> the current compiler doesn't do interworking properly. There are some
>> chips, (StrongARM based) that are ARMv4 (as opposed to ARMv4T).
>>
>> Is it worth putting support for ARMv4 (and ARMv4T) in the tree?
>>
>> If so, I'll put forward the patches I have now. Obviously people with
>> an ARM920T should use ARMv4T and a fixed up compiler.
>>
>
> What compiler are you using? The best baseline that works for me is:
I'm using 4.2.1 compiled from the source Brian provided earlier.
> binutils 2.18
> gcc-4.2.4 + gcc41-java-arm4.patch
I'll try that, it probably fixes the errors I was seeing.
> I've had problems with the gcc 4.3 compilers.
>
> If you don't have Thumb support, though, you can't be using
> interworking. gcc-4.2.4 works just fine with thumb/arm interworking on
> arm4t.
I only disabled thumb support due to the compiler. Obviously with
ARMv4 I'm not using interworking. Looks like 4.2.4 is the best
approach.
Jean-Baptiste Queru
en end in itself. Like you said, that would only explicitly help for
StrongARM devices. Looking around for StrongARM devices that are
likely to run any linux at all (and especially a recent 2.6) and that
can hold enough RAM for Android to run reasonably usable (64MB isn't
currently enough) doesn't seem to find many strong candidates.
That being said, I can't rule it out entirely either. With a lot of
dedication, it might be possible to get Android to do something useful
on some of those machines. In the grand scheme of things, I'm not
convinced that targeting StrongARM would have a lot of impact compared
to the investment that'd be necessary.
I agree that trying to get a compiler that properly targets ARMv4T
would probably generate more bang for the buck.
JBQ
David Given
[...]
> Looking around for StrongARM devices that are
> likely to run any linux at all (and especially a recent 2.6) and that
> can hold enough RAM for Android to run reasonably usable (64MB isn't
> currently enough) doesn't seem to find many strong candidates.
Where are you getting your hardware figures? The reason why I ask is
that I'd like to get Android running on a piece of hardware I've got
with 32MB of RAM; I was under the impression that that was sufficient
(there's a quotation from Andy Rubin that Android would run in 32MB RAM
and 32MB flash).
If more memory is needed, is that just for the base system, or is it
only required for running particular apps? Maps, for example, seems to
be considered a memory hog.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ ⍎'⎕',∊N⍴⊂S←'←⎕←(3=T)⋎M⋏2=T←⊃+/(V⌽"⊂M),(V⊝"M),(V,⌽V)⌽"(V,V←1⎺1)⊝"⊂M)'
│ --- Conway's Game Of Life, in one line of APL
Jean-Baptiste Queru
and that wasn't quite enough to smoothly run the applications that
ship with the G1. Even if all the device's RAM could be allocated to
Android (no baseband, no framebuffer) 64MB would probably be very
tight, to the point where even foreground applications would risk
getting killed because of low memory conditions (the browser
especially comes to mind). In 32MB the system is likely to be
thrashing for memory even before it's done starting the system server
(if it can even start it at all).
JBQ
Brian Swetland
Well, to clarify a bit, the shipping G1s have 101MB available to Linux.
The radio firmware is pretty large (it has a 41MB ram footprint), and a
big chunk of memory is set aside for GPU / media buffers, etc (the
hardware unfortunately needs some large physically contiguous regions to
work well).
I believe the system will boot and be usable (as shipped on G1) in
80-90MB. 101MB gives enough headroom that a number of apps can survive
in the background without being reclaimed, which provides faster app
switching and a better experience to the user.
It'd be nice if things were put on a diet to the point where 64MB was
a reasonable minimum footprint. That'd probably be quite a bit of work,
but worth doing in my opinion. I think 32MB would require some significant
rearchitecture of things (probably ditching the multiple process model,
etc) to accomplish.
Brian
[Jean-Baptiste Queru <j...@google.com>]
Gergely Kis
I am trying to work in this direction, with a 64MB target, since I
currently only have hardware with 64MB RAM and a Cirrus EP9315 CPU.
I would like to take the opportunity and ask: what do you think about
"headless" Android devices like routers with a web interface. Since I
think Jetty is already ported to Android, it should be certainly
possible
My questions are:
- is the footprint of the system without all the GUI stuff small
enough to reasonably fit into a device with 32MB RAM. Or is this still
unrealistic?
- does it make sense in your opinion? Of course many things in the
Android platform are about GUI development, but I still like the
process model, and the nice development environment (Java, Dalvik ...
etc.).
- is there already a possibility to build a minimal non-GUI version (I
know I should check it myself....:-) )
- if there isn't, would you accept patches to make it possible?
Best Regards,
Gergely
Jean-Baptiste Queru
-32MB should be enough to get the kernel and libc off the ground "as
is" and doing something useful.
-Dalvik should be able to run in there as well "as is". Dalvik and its
core library are expected to be highly portable and independent from
higher-level Android constructs.
-This'll require to fine-tune the memory thresholds (right now if you
have the kernel kill processes when there's 16MB left and you left
dalvik allocate 16MB of heap you'll run into surprises if you only
have 32MB).
-Beware of the process model: having many processes around is quite expensive.
-I'm pretty sure I heard that being able to run the "inner" layers of
the system without the "outer" ones was actually a goal, so if you
find that this isn't the case it's likely that high-quality patches
will be accepted. You'll probably find the process more pleasant if
you discuss the issues you encounter and the design for your solutions
on this mailing list, and then submit small patches to address the
individual issues one at a time.
JBQ