G1 has two CPU cores, one is dedicated to phone function?

[luke]

I read somewhere that the G1 has two ARM CPU cores (and I'm sure there
are a couple of other embedded ones). However the article stated that
one core is exclusively dedicated to operating the phone during
calls. Does this mean that only during calls there is only one core
available for general use, or that there is always only one core
available for general use?

I am writing an app that will benefit substantially from SMP
operation. I hope that the second core is not locked down while the
phone radio is not in use.

[Disconnect]

The second core is not available in any way to the operating system. It runs a specialized (and, obviously, closed-source) gsm phone stack and controls the application cpu (boots, halts, secures, etc).

The limits of interaction are rild (half-open daemon that handles AT commands) and - if you work at it - you can brick it with a bad radio.img.

[luke]

Shoot. It would make a lot more sense to just use kernel scheduling
priorities to give important system tasks like those full reign over
one CPU anytime they needed it... How is this locked down? How idle
is the second CPU most of the time?

The G1 processor is also purportedly a 528MHz Qualcomm 7210, but runs
at a hardwired max of 350MHz for battery-saving reasons. Is the
second core also locked down for battery-saving reasons? I'd be happy
to charge my phone twice a day if needed to get the extra processor
speed.

On Jan 20, 12:24 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> The second core is not available in any way to the operating system. It runs
> a specialized (and, obviously, closed-source) gsm phone stack and controls
> the application cpu (boots, halts, secures, etc).
>
> The limits of interaction are rild (half-open daemon that handles AT
> commands) and - if you work at it - you can brick it with a bad radio.img.
>

[luke]

PS it is also interesting to me that T-Mobile and others have been
promoting this phone as having a 528MHz processor and therefore being
"faster than the iPhone" when it really maxes out at 350MHz. Does
nobody know this?

[Disconnect]

Its not a second core.

It is, more literally than not, a full, second, differently-specced cpu that shares the on-chip ram and flash.

Forget it exists. It is task specific and not available. (And won't be, even if it gets hacked. It does gsm and protects its own security, and thats it..)

[San Mehat]

The 'modem' processor caches are not coherent with the application processor.

--
----------
San Mehat
Staff Software Engineer
Google Inc.
o: 650-253-7422
c: 408-382-1249
s...@google.com

[Dianne Hackborn]

This is typical smart phone design.  The second CPU is dedicated to the phone stack, and allows the main CPU to be completely turned off when the phone is "asleep" (but still needs to wake up for incoming calls, network activity, etc).  The radio CPU is also a slower, lower-power CPU providing just enough for the radio stack to reduce battery usage while in these lower power states.  I think but am not sure that the radio CPU is an ARM 7, without an MMU, so would be completely inappropriate to use for Linux let alone applications.

On Tue, Jan 20, 2009 at 9:34 AM, luke <luke....@gmail.com> wrote:

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them.

[Jason]

Discussion into running code on the baseband processor is pretty much
a dead end (as it relates to the G1, anyway), but just to add another
ingredient to the pot: there is no specification in Android for what
type of architecture the baseband processor should be running. In fact
from what I can tell there is no requirement to have a baseband
processor at all. Possible scenarios would be an application processor
capable of running the radio stack in an isolated vm or perhaps a
hypothetical future Android with a real-time kernel.

> hack...@android.com

[Anders Nilsson Plymoth]

A relevant fact is also that FCC doesn't allow you to have this kind of functionality on a market phone. If there was any way you could write code that directly interact with the radio interface, FCC would shut you down. You can do this in a closed test environment, but not on any phone that can be bought and used in a regular system. I would say the ADP1 falls into this category, and without doubt the G1.

Anders

[Ben Leslie]

FWIW, The second core is an ARM9 running the radio stack on top of
OKL4. But as pointed out, this is processor is not available to the
application processor.

[Disconnect]

My understanding is that that is not actually true - while it is true that the radio (and software) has to be vetted and approved for release, software radios are still legal (gnuradio has approved hw for sale) so long as its reasonably limited. (And realistically, most radios are reasonably limited by their hw design, unless intentionally made generic..)

That doesn't change the simple fact that we're never getting access to that processor, due in large part to it's inbuilt security and the lack of any sources (or references, or -anything-) for it. (As I understand, its proven difficult to even get basic docs on the thing, much less anything else..)

[David Given]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dianne Hackborn wrote:
> I think but am not sure that the radio CPU
> is an ARM 7, without an MMU, so would be completely inappropriate to use
> for Linux let alone applications.

I found literature somewhere saying it's an ARM9, with an ARM11 as the
main CPU.

These things typically run an ultra-real-time embedded OS, and they
don't idle much, if at all: they need to be ready to respond to incoming
GSM packets within the rigidly specced timeframes. Linux basically can't
do this without major modification --- it's not real-time enough.

The G1 processor actually looks like a *five* core device: there are the
two ARM processors, there are two DSP processors, and there's the 3D
unit (although that might be integrated with the DSP). Does anyone know
how Android deals with the DSPs, which I assume are used for media
codecs? Is it possible to download your own code into them? Is one of
them 'owned' by the radio stack for GSM audio compression?

- --
David Given
d...@cowlark.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl2Eh8ACgkQf9E0noFvlzgGXQCfVuwtHGnZZgb09sGiYYMXlHiP
BEQAnRvJV3yjxAbnWg9PTk/oyXcUd8hQ
=iNcW
-----END PGP SIGNATURE-----

[BradChow]

Hi,

As far as I know, the chip manufacturer provide the library, driver,
and maybe some individual software or hardware architecture to make
the communication between modem and application core is workable. So ,
I think that the target need the chip and have to use the solution by
chip manufacturer. Otherwise, the target will not work appropriately.
If you want to use the modem core to do something you like, the only
way is hack the software architecture. It should a terrible an huge
work and finally you can not make it commercialization because the
copyright is in chip manufacturer.

Best Regards,
Brad Chou

On Jan 21, 2:05 am, David Given <d...@cowlark.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dianne Hackborn wrote:
> > I think but am not sure that the radio CPU
> > is an ARM 7, without an MMU, so would be completely inappropriate to use
> > for Linux let alone applications.
>
> I found literature somewhere saying it's an ARM9, with an ARM11 as the
> main CPU.
>
> These things typically run an ultra-real-time embedded OS, and they
> don't idle much, if at all: they need to be ready to respond to incoming
> GSM packets within the rigidly specced timeframes. Linux basically can't
> do this without major modification --- it's not real-time enough.
>
> The G1 processor actually looks like a *five* core device: there are the
> two ARM processors, there are two DSP processors, and there's the 3D
> unit (although that might be integrated with the DSP). Does anyone know
> how Android deals with the DSPs, which I assume are used for media
> codecs? Is it possible to download your own code into them? Is one of
> them 'owned' by the radio stack for GSM audio compression?
>
> - --
> David Given
> d...@cowlark.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)

> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org

[Dave Sparks]

That's a pretty good summation.

For example, all the ARM9 and DSP firmware for the G1 comes as a big
binary blob. Even some of the user space drivers are supplied only in
binary form. The drivers usually expose specific functionality, such
as an AVC decoder or a JPEG encoder. There is no way to execute
arbitrary code on the DSP.

We hope that over time the chip manufacturers will see the value in
open sourcing the complete stack. For now though, you can assume that
everything below the app processor is a sealed box.