GTA04 Block V4 / risk and possibility

joerg at openmoko.org joerg at openmoko.org
Thu May 1 23:47:34 CEST 2008


Am Fr  2. Mai 2008 schrieb Andy Green:
> 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? :-(

This topic is thru for me. Just had to make clear where this 2*6400 suggestion 
came from, when we talked about the benefits and costs of MCU. Benefits of 
2*6400 would be much higher than 430, if only it would be fit for the low 
power job. As I stated in last posting, I'd prefer to see no MCU at all and 
have a lightning fast kernel suspend/clockdown & resume on the one and only 
CPU.
I agreed on Friday already we can't plan to use a second PMU and design this 
crazy shared mem stuff without for sure breaking our cost and time deadlines. 
No more need to convince me about that. It's utterly clear.


> 
> |> 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,

Yep. But MPU also needs software. So this is "do it with MPU + software, or do 
it just with software"

> increasing complexity in bootloader 
> and Linux, 

bootloader also has to care whether there is a MCU that already did the job!
So again, more complexity with or without MCU.
Even more: the uBoot added complexity allegedly already is there and we won't 
gain anything in doing it again in MPU, for the amount of work we have to do. 
Just adding tests for MCU to it. In the end we are planning to run without 
MCU as well, no?

> 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.

I agree there are good chances it will be exactly this way in the end. Just 
for now I have no argument I can proof when someone asks me why MCU is a good 
thing.
And I think we should just calculate what's the "TCO" for MCU, and what 
for "ultrafast" resume sw-solution. Based on different sales-quantities.
And I *really* like to see a detailed list of usecases where we see benefit 
from a MCU, so we can verify design based on this. Up to someone else to 
ponder whether these benefits are worth an MCU or not or we should try if we 
got enough time or whatever. I'm just here to proofread any design, and for 
these benefits/usecases I need info at level of "schematics" and "specs", not 
like blockdiagrams and commercials (metaphoric spoken).
Maybe in the end the benefits from a MCU even would justify to push the 
deadline, but to decide on this we need *Numbers* like "these five 
usecases..." vs "gains us x new customers, but we will lose y due to delay".
So please let's start with the usecases! I need them anyway for the 
schematics.
 
> |> but if the MPU pans out, it will
> |> allow us to go a further than people expect on battery life and in other
> |> areas.  
> |> 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.

Andy, when they ask me "will we get this done in time" I have to have a better 
reply than just quoting your "Don't panic", that's not what I'm payed for. 
(that's what I will be fired for if things go wrong ;)

 
> | 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.

So if I can document this, with a rough estimate on quantity - FINE!
But PLEASE give me numbers/facts, not just statements. I can't 
propagate "don't panic" when I have no own idea whether there *is* reason to 
panic or not. Please give me a list of usecases targeted by MCU, so e.g. I 
can ask sw-development whether they have a better "offer" to solve the issue.

/jOERG




More information about the hardware mailing list