GTA04 Block V4 / risk and possibility

Andy Green andy at openmoko.com
Thu May 1 22:31:09 CEST 2008


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

Somebody in the thread at some point said:

|> You two guys that now have a problem with the ~$2-3 MPU wasted most of
|> Friday's meeting trying to sell the frankly crazy alternative of adding
|> a *second S3C6400* to perform the MPU tasks.
|
| It wasn't a try to sell sth, it was a question why we can't use a MCU
that's
| more powerfull and costs us less, and has a known toolchain. Frankly
these

You can't use another S3C6400 with this "supervisor MPU" technique
because we need lowest power and minimal dependence on PMU, provided by
a small micro like MSP430... and not provided by a second S3C6400 -- it
needs a second PMU in fact so it can stay up while the other is
suspended... sigh.

I see I still failed to convince you that a little 16-bit MSP430 in
volume costs less than a S3C6400 (with 128MB DDR and 128MB NAND inside!)
in volume :-(  How are we going to agree about anything else? :-(

|> We can make a cool phone either way,
|
| So according to Sean_MP's rules, this means "do it without the MPU". Less
| parts, more functionality. Sorry!

There are certainly less parts if you take them out, but not the "more
functionality".  Everything that we would have chosen to do in the MPU
still has to be done another way, increasing complexity in bootloader
and Linux, elsewhere in the schematics, increasing latency in use and
increasing power.  We have been through this in GTA02 already.

Werner and I often find something to disagree about, but in this case it
seems we both are interested in how we can leverage a small supervisor
MPU in this design.  Our interests range from lowest level circuitry
design and power handling, up through bootloader and Linux drivers and
I, and I think Werner too, see opportunities for simplification and
features from having this considering the whole stack.

|> but if the MPU pans out, it will
|> allow us to go a further than people expect on battery life and in other
|> areas.  If it doesn't pan out, then no harm done since we design to work
|> without it too from the start.  Where is the problem?
|
| The problem is: it takes additional manpower do implement MCU to the
circuit,
| and to have the software (both firmware and CPU-linux-system) up and
running
| on end of prototype design deadline (a close deadline), to keep the
timeline
| schedule for GTA04.

I think I would say: don't panic.  Yes, you have to design in a small
16-bit MPU whose "failure is an option".  Its OK.

| And I have been told I should advertise these timeline constraints to all
| involved parties, with the premise from Sean "timeline is highest
priority".

There will be a timeline and constraints on it no matter what we do.
Don't panic.  Stuff we don't solve with MSP430 bulges out into another
place on the timeline in software-land.

| One of my problems (just started to find them, every day a few ;)

Oh, I had a problem once.

- -Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgaKI0ACgkQOjLpvpq7dMr5UQCbBVq/ySoxqGoankHEhFcQwNv0
U3AAoIZmai8CmBr33bwGfBeM6RB/XnM9
=nwUN
-----END PGP SIGNATURE-----




More information about the hardware mailing list